i18n - internationalisation or internationalization

Práctica recomendada para valores clave en archivos de traducción

Question

En general, los métodos de traducción toman una asignación de clave> valor y usan la clave para transformar eso en un valor. Ahora reconozco dos métodos diferentes para nombrar sus claves de traducción y dentro de mi equipo no llegamos a un consenso sobre cuál es el mejor método.

Método 1: Use palabras u oraciones en inglés completo:

Name => Name
Please enter your email address => Please enter your email address

Método 2: utilice palabras clave que describan la situación:

NAME => Name
ENTER_EMAIL => Please enter your email address

Personalmente prefiero el método n. ° 1 porque muestra directamente el significado del mensaje. Si la traducción no está presente, puede recurrir a la clave y esto no causa ningún problema. Sin embargo, el método es engorroso cuando una traducción cambia con frecuencia, porque todos los archivos deben actualizarse. También para textos más largos estas teclas se vuelven muy grandes. Esto se resuelve usando claves como ENTER_EMAIL , pero el fraseo está completamente fuera del contexto. La lista de claves abstractas de traducción sería enorme, necesita metadatos para todas las claves que explican su uso y las colisiones pueden ser mucho más fáciles.

¿Hay lo mejor de ambos mundos o un tercer método? ¿Cómo utilizas las claves de traducción en tu aplicación? En nuestro caso, se trata de una aplicación web basada en php, pero creo que el problema anterior es lo suficientemente genérico como para hablar de i18n en general.

Answer 1

Esta es una pregunta que también enfrentan los desarrolladores de iOS / OSX. Y para ellos existe incluso una herramienta estándar llamada genstrings que asume el método 1. Pero, por supuesto, los desarrolladores de Apple no tienen que usar esta herramienta, yo no.

Si bien la red de seguridad que se obtiene con el método 1 es agradable (es decir, puede mostrar la clave si de alguna manera se olvidó de localizar una cadena), tiene la desventaja de que puede llevar a claves conflictivas. A veces, una pieza idéntica de texto de visualización necesita ser localizada de dos maneras diferentes, debido a reglas gramaticales o diferencias en el contexto. Por ejemplo, la traducción al francés de "E-mail" sería "E-mail" si es un título de diálogo y "Envoyer un e-mail" si es un botón (en francés, la palabra "E-mail" es solo un nombre y no se puede usar como un verbo, a diferencia de en inglés donde es tanto un sustantivo como un verbo). Con el método 2, podría tener las claves EMAIL_TITLE y EMAIL_BUTTON para resolver este problema, y ​​como un bono esto daría una pista a los traductores para ayudarlos a traducir correctamente.

Una ventaja más del método 2 es que puede cambiar el texto en inglés sin tener que preocuparse por actualizar la clave en inglés y en todas sus localizaciones.

¡Entonces recomiendo el método 2!

Answer 2

¿Por qué no usar ambos mundos? Utilizo el método n. ° 1 para cadenas cortas, y el método n. ° 2 para cadenas largas que son oraciones completas. No tengo miedo de mezclar ambos en el mismo archivo.

Por ejemplo, en la siguiente cadena, el texto puede cambiar si en una nueva versión de la aplicación se modifica la experiencia del usuario:

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details.";

Entonces aquí tiene sentido aplicar el método n. ° 2. Sin embargo, para cadenas simples como en el siguiente ejemplo, el método n. ° 1 es más útil:

"Preferences" = "Preferences";

En general, cuando las personas intentan estandarizar las cosas, a menudo me parece restrictivo. Personalmente, prefiero un enfoque más "anarquista" donde varios métodos son válidos (no solo como en este método # 1 vs thread # 2 del método, sino también, por ejemplo, cuando un equipo de desarrolladores lucha por el estilo de codificación).