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: Uso palabras en inglés completas o frases:

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

Método 2: Use palabras clave que describen la situación:

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

yo personalmente prefiero el método # 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 hay incluso un standard tool called 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 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 conducir 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 una bonificación, 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 de actualizar la clave en inglés y en todas sus localizaciones.

¡Así que recomiendo el método 2!

Answer 2

¿Por qué no utilizar 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 de 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."; 

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

"Preferences" = "Preferences"; 

En general cuando la gente trata de normalizar las cosas a menudo parece restrictiva para mí. 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 pelea por el estilo de codificación).