La decisión que tenía enfrente

WPCredits parte de una premisa simple: para aparecer en los créditos de WordPress hay que contribuir de verdad a alguno de los equipos del proyecto. Lo que no es simple es el paso previo, escoger cuál.

WordPress se organiza en equipos (“Make teams”) que trabajan de forma bastante independiente, cada uno con su propio handbook, su canal de Slack y sus reuniones. Cuando abrí make.wordpress.org por primera vez me encontré con más de quince opciones. Ninguna estaba marcada como “empiece por aquí”.

Mi situación al momento de decidir: estudiante de Ingeniería en Sistemas en la Universidad Fidélitas, sin experiencia previa contribuyendo a software libre, con tiempo limitado por el semestre y con ganas de que la primera contribución llegara pronto —no dentro de tres meses.

Cómo hice la comparación

En vez de escoger por intuición, definí cuatro criterios y evalué cada área contra ellos.

Mis criterios

1. Tiempo hasta la primera contribución real. ¿Cuánto tengo que aprender antes de poder aportar algo que le sirva a alguien?
2. Ajuste con lo que ya sé. ¿Puedo apalancar algo que ya tengo —idiomas, programación, capacidad de documentar— o arranco de cero?
3. Trazabilidad de la contribución. ¿Puedo ver, medir y documentar lo que hice? Esto importa mucho para una bitácora como esta.
4. Relevancia local. ¿El aporte tiene algún efecto en Costa Rica o en la comunidad hispanohablante?

Las áreas que evalué en serio

Área	Qué hace	Por qué la consideré	Por qué no la escogí
Core	Desarrollo del núcleo de WordPress	Es lo más cercano a mi carrera	Curva alta: PHP, Trac, entorno local, revisión de parches. La primera contribución podía tardar semanas.
Documentation	Manuales y documentación técnica	Buen ajuste con escribir y explicar	Requiere conocer bien el producto antes de documentarlo. Todavía no lo conozco lo suficiente.
Support	Foros de ayuda a usuarios	Entrada rápida, sin herramientas complejas	Para responder bien hay que haber resuelto esos problemas antes. Responder mal es peor que no responder.
Photos	Banco de fotos libres para el proyecto	Muy accesible, aporte inmediato	Aporte real, pero poco conectado con lo técnico. Lo dejé como área secundaria.
Training / Learn	Cursos y material educativo	Me interesa enseñar	Igual que Documentation: primero hay que dominar el tema.
Polyglots	Traducción de WordPress a otros idiomas	Ver abajo	—

Cómo verifiqué la decisión antes de comprometerme

1. Abrí translate.wordpress.org y busqué el locale es_CR para ver cuánto trabajo pendiente había realmente.
2. Revisé un par de proyectos con cadenas sin traducir y me pregunté honestamente: ¿podría traducir esto hoy? La respuesta fue sí en la mayoría.
3. Leí el Polyglots Handbook y la guía de estilo del español para confirmar que existía un camino documentado y no tenía que inventarlo.
4. Entré al canal #polyglots en el Slack de Making WordPress y leí conversaciones de las semanas anteriores para ver si el equipo estaba activo.
5. Confirmé que el flujo de aprobación (sugerencia → revisión de un GTE/PTE → aprobada) deja un registro visible, o sea, contribución trazable.

Por qué Polyglots ganó

• Criterio 1 (tiempo hasta contribuir): puedo sugerir una traducción el mismo día que creo la cuenta. No hay entorno local que configurar, ni parche que enviar, ni build que compilar.
• Criterio 2 (ajuste): hablo español nativo y leo inglés técnico todos los días por la carrera. Eso es exactamente el insumo que necesita el equipo.
• Criterio 3 (trazabilidad): cada sugerencia queda registrada con estado —waiting, current, rejected— en mi perfil de traductor. Es la métrica perfecta para documentar avance semana a semana.
• Criterio 4 (relevancia local): es_CR existe como locale y tiene trabajo pendiente. Cada cadena aprobada mejora WordPress específicamente para quien lo usa en Costa Rica.

Hay un quinto factor que no era un criterio formal pero pesó: Polyglots tiene un componente técnico que no se ve desde afuera. Traducir cadenas implica respetar marcadores de posición como %s y %1$s, no romper etiquetas HTML embebidas, manejar formas plurales y entender el contexto de una cadena que a veces son tres palabras sueltas. Es más parecido a programar de lo que esperaba.

Obstáculos: con qué me topé al decidir

• No hay una comparación oficial de áreas. Cada equipo describe lo suyo, pero nadie las pone lado a lado. Tuve que armar la tabla de arriba por mi cuenta, leyendo handbook por handbook.
• Confundí “fácil de entrar” con “poco valioso”. Mi primer instinto fue ir a Core porque sonaba más serio. Me costó aceptar que escoger el área donde puedo aportar hoy es mejor decisión que escoger la que suena más impresionante.
• No sabía cuánta actividad tenía cada equipo. Un área con handbook bonito pero sin gente revisando es un callejón sin salida. Terminé usando Slack y la fecha de los últimos posts en Make como termómetro.
• Duda sobre es_CR versus es_ES. Al principio no entendía si traducir a un locale regional “cuenta” igual. Sí cuenta, pero implica seguir las decisiones de estilo propias de ese locale, no las del español de España.
• Miedo a equivocarme de área y perder el semestre. Esto me frenó más de lo que debería. Lo resolví aceptando que nadie firma exclusividad: se puede contribuir a varios equipos.

Aprendizajes

• Los criterios explícitos vencen a la intuición. Escribir mis cuatro criterios antes de comparar convirtió una decisión difusa en una tabla. Si hubiera decidido “por sensación”, habría escogido Core y probablemente seguiría atascado configurando el entorno.
• La velocidad del primer aporte importa más de lo que parece. Contribuir algo pequeño en la primera semana genera impulso; esperar tres meses a la contribución perfecta genera abandono.
• Ningún área de WordPress es “la de segunda”. El proyecto se sostiene sobre traducción, soporte y documentación tanto como sobre código. Un WordPress que no se puede leer en tu idioma no sirve, por más limpio que esté el core.
• La decisión es reversible. Empezar en Polyglots no me cierra Core. Al contrario: me da contexto del producto que después voy a necesitar.
• Verificar la actividad del equipo es parte de escoger. Un handbook actualizado y un canal de Slack con movimiento reciente dicen más que la descripción oficial del área.

Reflexión: cómo me sentí y qué sigue

La parte incómoda de este proceso fue admitir que no estaba listo para Core. Como estudiante de Ingeniería en Sistemas uno siente cierta presión de ir directo al código, y escoger traducción se sintió al inicio como bajarle el nivel a la meta. Me tomó unos días entender que eso era ego, no criterio.

Una vez que solté esa idea, la decisión se volvió obvia y hasta cómoda. Tener claro por qué escogí Polyglots —y no solo que lo escogí— me deja con algo que no tenía la semana pasada: una forma de saber si estoy avanzando. Si en un mes no tengo cadenas aprobadas, el problema no será la elección del área, será mi ejecución. Eso es un buen lugar donde estar.

Próximo paso: pasar de la teoría a la práctica. Voy a hacer mis primeras sugerencias de traducción en un proyecto pequeño de es_CR, con el glosario y la guía de estilo abiertos al lado, y a documentar el resultado —incluidas las cadenas que me rechacen— en el siguiente post.