Localización over-the-air

Contexto

Las pantallas nuevas se escribían en React Native y necesitaban textos en varios idiomas. Hasta ahí, nada raro. Lo raro era cómo llegaban las traducciones a las apps, que era dentro de la release.

Problema

Si traducir un texto exige publicar una versión, el ciclo de traducción queda atado al ciclo de release. Un typo en un idioma, una frase mejorable, una campaña con texto nuevo, todo esperaba al próximo tren. En la práctica, una semana. Y encima los textos viajaban empaquetados en la app, con más peso, más archivos que mantener y más conflictos al mergear.

Había otro problema, más humano. Los desarrolladores no sabían cómo pedir una traducción bien. Sin contexto, un traductor ve “Close” y no sabe si es un verbo o un adjetivo.

Qué decidimos (y qué descartamos)

Hicimos un spike para comparar alternativas y decidimos usar una plataforma de traducción con entrega over-the-air, donde las traducciones viven en un servidor y la app las baja en tiempo de ejecución.

Descartamos:

• Archivos de traducción dentro de la app. Simples, pero atan el ciclo a la release.
• Construir nuestro propio sistema. Más control, mucho más mantenimiento. No era nuestro negocio.

Lo escribimos en un documento de estrategia con las pegas, no solo con las ventajas. Hace falta conexión para la primera descarga, una traducción nueva se aplica la próxima vez que se abre la app y dependemos de la disponibilidad del servicio. Una buena decisión tiene sus contras por escrito.

Cómo lo hicimos

1. Una sola función para marcar textos. Los desarrolladores envuelven el texto en una función común. Nunca se renombra, porque el extractor la busca por nombre.
2. El contexto es obligatorio. Cada texto lleva una descripción para el traductor. Sin contexto no hay PR. Parece pesado, es lo que más mejoró la calidad.
3. Extracción automática. Al abrir un PR, una acción de CI sube a la plataforma los textos nuevos, etiquetados por feature. Nadie tiene que acordarse.
4. Un único proyecto para todo React Native, con los textos de todas las features consolidados. Más fácil de gobernar para quien traduce.
5. Una guía para equipos. Cómo configurar, cómo marcar textos, cómo probar. Si el proceso solo lo entiende su autor, no es un proceso.
6. Adopción repo por repo, empezando por las features con más textos.

Resultado

Más de 500 strings migrados por los equipos de producto, traducidos a 12 idiomas y entregados over-the-air. El ciclo para desplegar una traducción nueva pasó de una semana a segundos.

Lo más lindo no está en la cifra. Un cambio de texto dejó de ser una release. Los equipos de producto pueden corregir una frase un martes por la tarde sin pedirle favores a nadie.

Qué haría distinto

Pondría más temprano un chequeo automático de textos sin traducir por idioma, para que “falta una traducción” fuera un aviso en el PR y no una sorpresa en producción.

Y probaría antes el caso de la primera apertura sin conexión. Es el límite de este modelo y lo documentamos, pero me habría gustado enseñar el comportamiento con un prototipo, no solo con un párrafo.