Un plugin mal traducido le hace perder ventas a una tienda real. Confunde a alguien que no sabe inglés y está tratando de configurar su medio de pago. Le suma tickets a quien da soporte. Eso es un problema tan concreto como un bug, solo que no se ve en el código y por eso nadie quiere agarrarlo.
Lo segundo, y esto sí no me lo esperaba: la parte difícil no fue el inglés. Fue el español. Fue tener enfrente dos traducciones igual de correctas y tener que elegir una pensando en quién la va a leer. Ver que España, México, Chile y Argentina resolvieron la misma frase de tres formas distintas y que ninguna está mal me obligó a entender que traducir es tomar decisiones, no buscar equivalencias.
Lo tercero es sobre cómo funciona una comunidad distribuida. Nadie me asignó tareas. No hubo un jefe ni una reunión de arranque. Lo que hay es un sistema con reglas explícitas: estados de revisión, gente con permisos para validar, historial público de cada cambio y de quién lo hizo. Es autoorganización con trazabilidad total, y funciona a una escala que ninguna empresa podría pagar. La lista de contribuidores del proyecto tenía a alguien con más de diez mil traducciones acumuladas.
Qué haría distinto en el método. Habría dedicado más tiempo a las cadenas en estado “changes requested” en lugar de ir siempre a las sin traducir. Hay cien esperando en ese estado. Son cadenas donde alguien ya hizo el trabajo y solo falta afinarlas.
Profesionalmente me llevo algo que no esperaba de una tarea de traducción aprendí a leer código para entender contexto. Las referencias de archivo que aparecen en cada cadena me obligaron a abrir el repositorio y ubicar dónde vivía cada texto.
Leave a comment