¿Por qué los archivos de traducción se siguen desincronizando?

Los archivos de traducción se desincronizan porque dos sistemas son dueños de los mismos datos y ninguno gana. Tu repositorio cambia cuando un desarrollador hace merge. Tus archivos de traducción cambian cuando alguien se acuerda de actualizarlos. Son relojes distintos, y en la brecha entre ambos viven las claves faltantes, las claves huérfanas y las cadenas obsoletas. globalize.now es infraestructura de localización impulsada por IA que cierra esa brecha generando las claves y los archivos de locale donde se escribe el código, de modo que no hay un segundo reloj que se pueda atrasar.

¿Qué causa realmente que los archivos de locale se desincronicen?

Un archivo se redacta y el resto se mantiene, y eso no es el mismo trabajo.

Un desarrollador que construye una función edita en.json porque es el archivo al que va la cadena. Los demás idiomas son problema de otra persona, en el calendario de otra persona. Un desarrollador que escribió sobre este patrón en DEV describió las dos formas de fallo: las claves se añaden al archivo en inglés y se olvidan en los demás, así que parte de la app vuelve en silencio al inglés, y las claves se eliminan en un idioma pero sobreviven en otro, así que se acumulan entradas muertas. El mecanismo de descubrimiento en ambos casos es una queja de un cliente, semanas después.

Ninguno de esos dos casos es un problema de traducción. Nada se tradujo mal. Las cadenas nunca llegaron a ninguna parte.

Este es el modo de fallo que sobrevive a cualquier mejora de herramientas, porque las herramientas actúan aguas abajo del punto donde se creó la cadena. Si la cadena nunca entra en el pipeline, un pipeline mejor no sirve de nada. La misma causa raíz aparece más arriba en la cadena cuando un coding agent escribe cadenas que nunca llegaron a tener clave.

¿Por qué los archivos de traducción generan tantos conflictos de merge?

Porque son datos generados que se editan a mano, en un formato pensado para que lo escriban máquinas.

Un archivo de traducción es un mapa plano de claves a cadenas. Dos branches que añaden cada una una función acaban añadiendo entradas a ese mapa, normalmente cerca del mismo punto, normalmente en el mismo vecindario alfabético. Git ve dos ediciones en líneas adyacentes de un archivo sin ninguna estructura semántica que entienda, y le pide a una persona que lo resuelva.

La persona que resuelve el conflicto es un desarrollador que no lee el idioma de destino. La opción segura es mantener las dos versiones, y así es como aparecen las claves duplicadas. La opción rápida es quedarse con una, y así es como las traducciones desaparecen sin que nadie se entere.

Nadie resuelve a mano los conflictos de un lockfile. Se regenera. Los archivos de traducción merecen el mismo trato en cuanto dejan de ser documentos que escribe una persona.

¿Cuánto se desactualiza una traducción mientras espera revisión?

Lo suficiente como para dejar de describir el producto, y esto se puede medir públicamente.

Un informe de campo publicado en DevOps.com repasó cinco pull requests de localización reales en proyectos open source. El caso más revelador es el PR n.º 8377 de Kilo Code: las comprobaciones automáticas salieron limpias, la revisión del mantenedor llegó después, y para entonces el repositorio ya había evolucionado por debajo. El PR se cerró con la invitación a volver a enviarlo contra la arquitectura actual. El mismo informe recoge un issue de OpenClaw en el que varios voluntarios ofrecieron traducciones en español, japonés, portugués, coreano, chino y vietnamita, y los mantenedores respondieron que no tenían forma de incorporarlas.

Léelos como informes de latencia, no de calidad. Las traducciones eran correctas cuando se escribieron. La interfaz cambió mientras esperaban en la cola.

Ese es el coste que nadie tiene en cuenta al comparar herramientas de localización. Todo el mundo mide la traducción. Casi nadie mide cuánto tiempo pasa una cadena en tránsito, ni qué le ocurrió a la interfaz mientras tanto.

¿Cuánto cuesta realmente el ida y vuelta?

Más en coordinación que en traducción, por eso la factura nunca explica de dónde viene el dolor.

El coste visible es por palabra, por clave o por asiento, y aparece en una factura una vez al mes. El coste invisible es un desarrollador preguntando «¿qué archivo edito?», un segundo desarrollador resolviendo un conflicto en un idioma que no lee, un tercero dándose cuenta de que al build alemán le faltan once claves, y al autor original de la función preguntándole por una cadena que escribió hace cinco semanas.

Nada de eso aparece en una comparativa de precios. Todo eso se paga en tiempo de desarrollo, a precio de desarrollo, cada sprint. Una herramienta con un precio de etiqueta bajo que le cuesta a dos ingenieros un día a la semana no es barata.

El ida y vuelta es lo que genera ese coste. Mover archivos entre el lugar donde se crean las cadenas y el lugar donde se traducen es el paso caro, y sigue siendo caro sin importar a quién se lo compres. Por eso también la localización sigue moviéndose hacia arriba, hacia el propio flujo de desarrollo.

¿Qué cambia cuando las claves se generan donde se escribe el código?

El segundo reloj desaparece, y el desfase deja de tener de dónde salir.

La secuencia deja de ser: el desarrollador escribe una cadena codificada, alguien la encuentra más tarde, alguien le pone clave, alguien envía el archivo, alguien lo traduce, alguien lo trae de vuelta. Pasa a ser: la cadena se escribe como clave con un valor, en el mismo commit que la función, y la traducción sigue a partir de ahí.

Con globalize.now todo empieza con una conversión única. Conectas tu repositorio en la app y las cadenas codificadas existentes se extraen a claves y archivos de traducción en un solo paso. A partir de ahí, los agent skills hacen que coding agents como Cursor y Claude Code escriban cadenas con clave desde el principio en lugar de codificarlas, y los push jobs traducen las nuevas unidades del catálogo a medida que aparecen.

La palabra clave es «una vez». La conversión es la parte difícil y ocurre una sola vez. Lo que viene después es lo que antes era manual, funcionando al mismo ritmo que el código, que es precisamente el sentido de integrarlo en el flujo de trabajo del desarrollador en lugar de dejarlo al lado.

Las bibliotecas de runtime no se ven afectadas. i18next y next-intl siguen leyendo los archivos de traducción exactamente igual que antes. Nada cambia en cómo se sirven las traducciones. Lo que cambia es quién escribe los archivos.

¿Cómo distingues el desfase de un problema de traducción real?

Pregúntate si algún traductor llegó a ver la cadena.

Si al archivo alemán le falta una clave, ningún traductor falló. La cadena nunca le llegó. Eso es un fallo de enrutado, y añadir pasos de revisión lo empeora, porque suma tiempo de cola a un proceso cuyo problema ya es la latencia.

Si el archivo alemán tiene la clave y el texto no encaja en el contexto, eso sí es un problema de traducción genuino, y merece una persona que hable alemán y pueda ver dónde se renderiza la cadena. Ese tiempo vale la pena.

La mayoría de los equipos tienen muchos más casos del primer tipo que del segundo, y los tratan como si fueran el mismo problema, por eso la localización parece interminable. Sepáralos y la carga de trabajo baja, porque la mitad del enrutado deja de ser trabajo humano por completo. Esa distinción importa más cuanto más pequeño es el equipo, por eso se nota con más fuerza en desarrolladores solos y equipos pequeños que lanzan rápido.

Una prueba útil: cuenta cuántos de tus últimos diez bugs de localización eran palabras mal traducidas frente a palabras que faltaban. Si la mayoría faltaban, no tienes un problema de traducción. Tienes un problema de fontanería, y la fontanería se puede automatizar de una forma que el criterio humano no. La misma lógica aplica cuando estás calculando cuánto debería costarte realmente la localización.

El desfase en los archivos de traducción es un problema de enrutado disfrazado de problema de traducción. Conecta el repositorio una vez y el enrutado deja de ser tu trabajo.