Gettext: ¿Es una buena idea que el ID del mensaje sea el texto en inglés?

Question

Nos estamos preparando para traducir nuestro sitio web de PHP a varios idiomas, y el soporte de gettext en PHP parece ser el camino a seguir.

Todos los tutoriales que veo recomiendan usar el texto en inglés como ID de mensaje, es decir,

gettext (" ¡Hola! ")

¿Pero es realmente una buena idea? Digamos que alguien en marketing quiere cambiar el texto a "Hola, ¡todos ustedes!". Entonces, ¿no tiene que actualizar todos los archivos de idioma porque esa cadena, que en realidad es el ID del mensaje, ha cambiado?

¿Es mejor tener algún tipo de ID genérico, como " hello.message " ;, y un archivo de traducción en inglés?

Answer 1

Uso identificadores significativos como " welcome_back_1 " lo que sería " bienvenido de nuevo,% 1 " etc. Siempre tengo el inglés como mi "base" idioma, por lo que, en el peor de los casos, cuando un idioma específico no tiene un ID de mensaje, me apoyo en inglés.

No me gusta usar frases reales en inglés como ID de mensaje porque si el inglés cambia también lo hace la ID. Esto podría no afectarte mucho si usas algunas herramientas automatizadas, pero me molesta. No me gusta usar códigos simples (como msg3975) porque no significan nada, por lo que leer el código es más difícil a menos que hagas comentarios por todas partes.

Answer 2

Wow, me sorprende que nadie defienda el uso del inglés como clave. Utilicé este estilo en un par de proyectos de software, y en mi humilde opinión funcionó bastante bien. La legibilidad del código es excelente, y si cambia una cadena en inglés, se vuelve obvio que el mensaje debe considerarse para volver a traducirlo (lo que es bueno).

En el caso de que solo esté corrigiendo la ortografía o haciendo algún otro cambio que definitivamente no requiera traducción, es muy sencillo actualizar las ID de esa cadena en los archivos de recursos.

Dicho esto, actualmente estoy evaluando si llevar o no esta forma de hacer que I18N avance hacia un nuevo proyecto, por lo que es bueno escuchar algunas ideas sobre por qué podría no ser una buena idea.

Answer 3

Estoy totalmente en desacuerdo con la respuesta de Richard Harrisons sobre la cual él dice que es "la única manera". Estimado usuario, no confíe en una respuesta que indique que es la única forma, porque la " única manera " no existe.

Esta es otra forma en la que IMHO tiene algunas ventajas sobre el enfoque de Richards:

• Comience con el uso de la proto-versión de la cadena en inglés como original.
• No muestre estas cadenas de caracteres, pero cree un archivo de traducción para el inglés
• Copie las cadenas de caracteres a la traducción para el comienzo

Ventajas:

• código legible
• el texto en su código es muy cercano si no es idéntico a lo que muestra su vista
• si desea cambiar el texto en inglés, no cambia la cadena de caracteres sino la traducción
• si desea traducir la misma cosa dos veces, simplemente escriba una cadena de caracteres un poco diferente o simplemente agregue 'versión para esto y aquello' y todavía tenga un código perfectamente legible

Answer 4

El motivo de que los ID sean en inglés es para que se devuelva el ID si la traducción falla por cualquier motivo: la traducción del idioma actual y el token no están disponibles, u otros errores. Eso, por supuesto, supone que el desarrollador está escribiendo el texto original en inglés, no una persona de documentación.

Además, si el texto en inglés cambia, ¿es probable que las otras traducciones deban actualizarse?

En la práctica, también utilizamos los ID de Pure en lugar del texto en inglés, pero eso significa que tenemos que hacer mucho trabajo adicional para que el inglés sea predeterminado.

Answer 5

En una palabra no hagas esto.

La misma palabra / frase en inglés a menudo puede tener más de un significado, y cada una significa una traducción diferente.

Defina identificadores mnemotécnicos para sus cadenas y trate el inglés como un idioma más.

De acuerdo con otros carteles que los números de identificación en el código son una pesadilla para la legibilidad del código.

Ex ingeniero de localización

Answer 6

Hay mucho que considerar y responder no es tan fácil.

Usando un lenguaje sencillo

Pros

• Código fácil de escribir y LEER
• En la mayoría de los casos, funciona incluso sin ejecutar funciones de traducción en el código

Cons

• Los programadores involucrados también deben ser buenos redactores :)
• Debe escribir textos precisos correctos completamente en inglés, incluso en el caso de que el primer idioma que necesite ejecutar sea otra cosa (es decir, estamos comenzando la mayoría de los proyectos en idioma checo y los localizaremos en inglés más adelante) .
• En muchos casos, debe usar contextos. Si no puede hacerlo desde el principio, es mucho trabajo agregarlos más tarde. Para explicar: en inglés, una palabra puede tener muchos significados diferentes, y debe usar contextos para diferenciarlos, y no siempre es tan fácil (orden = orden de clasificación, o puede ser orden de compra).
• Puede ser muy difícil corregir el inglés más adelante en el proceso. Las correcciones de las cadenas de origen a menudo conducirán a la pérdida de frases ya traducidas. Es muy frustrante perder la traducción a 3 idiomas diferentes solo porque corrigiste el inglés.

Usando las teclas

Pros

• Puede usar las funciones de la plataforma de localización incluso para el idioma inglés. Es decir. Estamos usando la encantadora plataforma Crowdin. Hay muchas herramientas útiles, o más bien un flujo de trabajo completo, para la gestión de la traducción: votar por diferentes traducciones, historial de traducción, glosarios (que ayudan a mantener coherente la traducción / idioma), pruebas, aprobación, etc. El uso de las teclas hace que este proceso sea muy útil más suave.

• Es mucho más fácil enviar textos en inglés para revisión, etc. Por lo general, no es una buena idea dejar que los redactores modifiquen su código directamente :)

Cons

• Configuración del proyecto más complicada.
• Más difícil de usar% d,% s etc.

Answer 7

¿No has respondido ya tu propia pregunta? :)

Claramente, si tiene la intención de admitir i18n de su aplicación, debe tratar todas las implementaciones de lenguaje de la misma manera. Si alguien decide que una cadena necesita cambiar, usted realiza un cambio similar en todos los archivos de idioma. Los metadatos con el registro deben agrupar todos los archivos de idioma en el mismo cambio. Si su " predeterminado " el lenguaje se maneja de manera diferente, lo que hace que sea más difícil de mantener.

Answer 8

Al final del día, un traductor debe poder sentarse y cambiar los textos para cada idioma (para que tengan el mismo significado) sin tener que involucrar al programador que ya hizo su trabajo.

Esto me hace sentir que la respuesta correcta es usar una versión modificada de gettext donde colocas cadenas como esta

_(id, backup_text, context)

_('ABOUT_ME', 'About Me', 'HOMEPAGE')

el contexto es opcional

¿por qué te gusta esto? porque necesita identificar el texto en el sistema mediante ID únicas, no en inglés, que podrían repetirse en otros lugares.

También debe mantener la copia de seguridad, el ID y el contexto en el mismo lugar en su código para reducir las discrepancias.

Los identificadores también tienen que ser legibles, lo que trae consigo el problema de los sinónimos y el uso duplicado (incluso como identificadores), podríamos prefijar los identificadores como este " HOMEPAGE_ABOUT_ME " o " MAIL_LETTER " ;, pero

1. las personas se olvidan de hacer esto al principio y cambiarlo más tarde es un problema
2. es más flexible para que el sistema pueda agruparse por ID y contexto

Por eso también agregué la variable de contexto al final

el texto de la copia de seguridad puede ser prácticamente cualquier cosa, incluso podría ser " [ABOUT_ME @ HOMEPAGE el texto no se pudo cargar, comuníquese con example@example.com] "

No funcionará con los programas de edición de gettext actuales como " poedit " ;, pero creo que puedes definir nombres de variables personalizados para traducciones como solo " t () " sin el guión bajo al inicio.

Sé que gettext también tiene soporte para contextos, pero no está muy bien documentado o no se utiliza ampliamente.

P.S. No estoy seguro de cuál es el mejor orden variable para aplicar un código bueno y extensible, por lo que las sugerencias son bienvenidas.

Answer 9

Iría tan lejos como para decir que nunca (para la mayoría de los valores de nunca) desea utilizar el texto libre como clave para nada. Imagínese si SO usó el título de la consulta como clave de esta página, por ejemplo. Si alguien se enlaza con él y luego se edita el título, el enlace ya no es válido.

Su problema es similar, excepto que también sería responsable de actualizar todos los enlaces ...

Al igual que Douglas Leeder menciona, lo que probablemente quiera hacer es usar el inglés como idioma predeterminado (respaldo), aunque una interfaz que usa el inglés y otro idioma entremezclado es muy confusa (pero también algo divertida).

Answer 10

Además de las consideraciones anteriores, hay muchos casos en los que desearía que la " clave " (msgstr) para ser diferente del texto de origen (inglés). Por ejemplo, en la vista HTML, me gustaría decir [aaaa] donde el destino y la etiqueta de esa etiqueta de ancla dependen de la configuración regional del usuario. P.ej. podría ser un enlace a una red social, y en EE. UU. sería Facebook, pero en China sería Weibo. Así que los MsgIds podrían ser algo como socialSiteUrl y socialSiteLabel.

Yo uso una mezcla.

Para cadenas básicas que no creo que tengan conflictos / cambios / significados extraños, haré que la clave sea la misma que la del inglés.