Arranqué siendo un estudiante de Ingeniería en Sistemas de la Universidad Fidélitas que nunca había contribuido a un proyecto de software libre y que, sinceramente, no tenía claro cómo se hacía. WordPress era algo que había usado, no algo en lo que se pudiera participar.

Termino con una cuenta activa en WordPress.org, un área escogida con criterios propios, 126 traducciones enviadas al locale es_CR y una comprensión bastante concreta de cómo funciona por dentro una comunidad de miles de personas que nunca se han visto.

El recorrido, en orden

1. Presentación. Quién soy y por qué entré al proyecto.
2. Exploración del ecosistema. Make WordPress, los equipos, el Slack, el handbook.
3. Selección de área. Cuatro criterios explícitos, seis áreas comparadas, Polyglots como resultado.
4. Primera contribución. 130 cadenas del conjunto WordPress core 4.7.x.
5. Profundización técnica. Glosario, Consistency Tool y por qué la consistencia gana sobre el gusto personal.
6. Cierre. Este post.

Indicador	Resultado
Cadenas sugeridas	126
Cadenas aprobadas (current)	0
Cadenas rechazadas	0
Cadenas en espera (waiting)	126
Proyecto trabajado	WordPress core, conjunto 4.7.x
Locale	es_CR
Posts publicados	6

Cero aprobadas y cero rechazadas es un dato importante: no es que mi trabajo fuera malo, es que nadie lo ha visto. Son dos problemas completamente distintos y confundirlos sería el peor cierre posible.

Por qué quedó todo en espera

Reconstruyendo el proceso, identifico tres causas y ninguna es misteriosa.

1. Escogí un proyecto de baja prioridad

Traduje el conjunto de WordPress 4.7.x porque ahí había cadenas sin traducir. Lo que no consideré es que un equipo de voluntarios revisa primero lo que está en uso: la versión actual, los plugins populares, Gutenberg. Una versión antigua está al final de la fila, y con razón.

Traduje donde había hueco, no donde había necesidad. No es lo mismo.

2. Trabajé en silencio

El handbook de Polyglots lo dice de forma explícita: las sugerencias de contribuidores activos y localizables tienen muchas más probabilidades de ser aprobadas. Yo leí esa frase, la copié en mi guía personal, y aun así envié 126 cadenas sin avisarle a nadie.

Un equipo con doce editores generales no anda revisando la cola al azar. Revisa lo que le piden que revise. Mis cadenas nunca entraron en el radar de nadie porque nunca las puse ahí.

3. Confundí producir con contribuir

Medí mi avance en cadenas enviadas porque era lo que podía controlar y lo que se sentía productivo. Pero en un proyecto colaborativo el trabajo no está terminado cuando vos terminás: está terminado cuando entra al producto. Enviar es la mitad del trabajo, y yo traté la otra mitad como si fuera trámite ajeno.

Aprendizajes

• En software libre, comunicar es parte de contribuir. No es un extra social ni una habilidad blanda opcional: es un requisito funcional del proceso. Este es el aprendizaje más grande del ciclo y me costó un semestre entenderlo.
• Escoger dónde trabajar pesa tanto como la calidad del trabajo. 126 cadenas en un proyecto activo habrían tenido otro destino. El esfuerzo fue el mismo; la ubicación, no.
• La consistencia vale más que el criterio individual. El glosario y la guía de estilo no limitan al traductor, lo liberan de decidir dos veces lo mismo. Es el equivalente lingüístico de una convención de código.
• Traducir software es técnico. Marcadores de posición, formas plurales, etiquetas HTML embebidas, cadenas ambiguas que hay que resolver leyendo el código fuente. Entré pensando que era un ejercicio de idiomas y salí sabiendo que no.
• La revisión por pares no es un obstáculo. Es lo que hace que valga la pena que WordPress exista en 200 idiomas y no sea un desastre en 200 idiomas.
• Documentar mientras se hace tiene un valor que no se ve al inicio. Releer el primer post desde acá muestra un salto que yo no habría podido reconstruir de memoria.
• Un resultado incompleto sigue siendo un resultado. Las 130 cadenas existen, están enviadas y no vencen. El ciclo académico se cierra; la cola de revisión no.

Qué haría distinto

• Presentarme en el canal del equipo antes de traducir la primera cadena, no después de la número 126.
• Preguntar cuáles son las prioridades reales del locale en vez de deducirlas de un contador.
• Empezar con un lote pequeño —diez o quince cadenas— y pedir retroalimentación antes de escalar. Corregir el rumbo con quince cadenas mal enfocadas es barato; con 130, no.
• Trabajar en tandas cortas. La calidad de mis traducciones después de la cadena 70 no era la misma que al inicio.
• Medir el avance en cadenas aprobadas desde el día uno, aunque el número tarde en moverse.

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

No voy a fingir que cerrar con cero aprobadas se siente bien. Uno espera terminar un proyecto con algo que mostrar, y lo que tengo es una lista amarilla de cadenas esperando.

Al mismo tiempo, cuando lo miro con distancia, este resultado me enseñó más de lo que me habría enseñado una aprobación fácil. Si mis primeras diez cadenas se hubieran aprobado de una, me habría llevado la conclusión de que contribuir es simplemente trabajar duro y solo. Habría sido una lección equivocada.

Lo que aprendí en su lugar es que un proyecto de software libre no es un repositorio: es un grupo de personas que se coordinan. El código, las traducciones y la documentación son el resultado de esa coordinación, no el sustituto. Como estudiante de Ingeniería en Sistemas, esa distinción me parece más valiosa que cualquier cadena aprobada.

También hay algo que quiero dejar dicho para quien lea esto pensando en empezar: la barrera de entrada a WordPress es más baja de lo que parece desde afuera y más alta de lo que parece una vez adentro. Baja porque cualquiera con una cuenta puede sugerir una traducción hoy mismo. Alta porque contribuir de verdad exige entrar a una comunidad, hacer preguntas y aceptar correcciones. La parte técnica es la fácil.