Por Qué los Archivos de Localización Traducidos Rompen las Aplicaciones (y Qué Debe Quedar Intacto)

Un Archivo de Localización Es Código con Frases Dentro

Los archivos de idioma PO, YAML, .properties, RESX, XLIFF y JSON parecen listas de frases, pero solo los valores son prosa. Las claves son identificadores que el código busca; los marcadores de posición son huecos que el código rellena en tiempo de ejecución; los escapes y el marcado son sintaxis de la que depende el analizador. Un traductor que trate toda la línea como texto producirá un archivo que se lee de maravilla y no se carga, o que se carga y después falla la primera vez que una pantalla da formato a un número. El fallo suele aparecer en un solo idioma, lo que lo convierte en el tipo de error más difícil de detectar en una revisión.

Cinco Cosas que Deben Sobrevivir Intactas a la Traducción

• Claves y nombres de recursos — el código busca las cadenas por su clave, así que una clave traducida es simplemente una cadena que falta.
• Marcadores de posición — %s, %1$d, {0}, {name} y los argumentos ICU los rellena el código; renombrar o eliminar uno rompe el formato o provoca un error en tiempo de ejecución.
• Escapes y reglas de codificación — un archivo .properties leído con el método clásico Properties.load(InputStream) se trata como Latin-1, con los demás caracteres escritos como escapes \uXXXX, por lo que el texto no latino sin escapar puede convertirse en mojibake.
• Marcado dentro de las cadenas — las etiquetas HTML, los códigos en línea de XLIFF y Markdown deben quedar equilibrados, o la cadena renderizada rompe la página que la rodea.
• Estructura del archivo — la sangría de YAML, los escalares de bloque, los anclajes y alias, y el anidamiento XML son sintaxis; una sangría desplazada o un nombre de anclaje traducido cambia lo que significa el archivo.

Los Plurales No Son un Singular Más una "s"

El inglés tiene dos formas de plural, así que es tentador pensar que todos los idiomas las tienen. El manual de GNU gettext muestra por qué eso falla: cada idioma declara su propia regla Plural-Forms, el inglés usa nplurals=2 y el ruso necesita tres formas elegidas según las últimas cifras del número. Un archivo PO traducido al ruso con solo dos formas rellenas compila, se ejecuta e imprime la gramática incorrecta para cada cantidad que termina en 2, 3 o 4. Gestionar bien los plurales significa producir el número de entradas msgstr que exige el idioma de destino, no el número que resultó tener el idioma de origen.

A Veces los Marcadores de Posición Tienen que Moverse

El orden de las palabras varía entre idiomas, así que una frase con dos valores a menudo tiene que colocarlos al revés. Los marcadores posicionales como %1$s y %2$s, o los nombrados como {count} y {user}, existen precisamente para eso: la traducción puede reordenarlos, pero cada uno debe seguir presente exactamente una vez. Los marcadores anónimos, como un %s a secas, no se pueden reordenar con seguridad, y es un problema que conviene corregir en las cadenas de origen antes de traducir, no después.

Reglas de Formato que Conviene Conocer Antes de Traducir

Cada formato tiene sus propias aristas. En YAML, la especificación da a un bloque literal (|) y a un bloque plegado (>) un comportamiento distinto con los saltos de línea, y los anclajes (&) y alias (*) permiten que un nodo reutilice otro, así que ambos deben pasar intactos. XLIFF 2.1 envuelve el formato original en elementos en línea como <ph> y <pc>, que la traducción debe mantener en su sitio alrededor de las palabras correctas. En .NET, los recursos RESX se buscan por nombre en tiempo de ejecución para la referencia cultural de la interfaz actual, así que un elemento data renombrado recurre en silencio al idioma predeterminado. Y un archivo .properties de Java trata el primer =, : o espacio en blanco sin escapar como separador de la clave, así que unos dos puntos sueltos en una clave traducida la parten en dos.

Una Lista de Revisión que Detecta la Mayoría de las Roturas

1. Cuente los marcadores de posición en cada cadena de origen y de destino — el multiconjunto debe coincidir, aunque el orden no lo haga.
2. Compare las claves, no los valores — cualquier clave presente en el origen y ausente o renombrada en el destino es un error.
3. Cargue el archivo traducido con el analizador real (msgfmt, un cargador YAML, ResXResourceReader) antes de publicarlo.
4. Compruebe las entradas de plural con la regla del idioma de destino, no con la del idioma de origen.
5. Muestre la traducción más larga en el elemento de interfaz más estrecho — el texto en otros idiomas suele ocupar más que el inglés.