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 PHP a varios idiomas, y el soporte de gettext en PHP parece ser el camino a seguir.

Todos los tutoriales que veo recomienda utilizar el texto Inglés como el identificador del mensaje, es decir,

gettext ("¡Hola!")

Pero es que realmente una buena idea? Digamos que alguien en marketing quiere cambiar el texto a "Hola, ¡todos!". 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 identificación genérica, como "hola.mensaje", y un archivo de traducción al inglés?

Answer 1

Uso ID significativos como "welcome_back_1" que serían "welcome back, %1" etc. Siempre tengo el inglés como mi idioma "base", así que en el peor de los casos, cuando un idioma específico no tiene un ID de mensaje, retroceso en inglés.

No me gusta utilizar frases en inglés reales como ID de mensaje porque si el inglés cambia también lo hace la ID. Esto podría no afectarle demasiado si usa 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 desperdicies comentarios en todas partes.

Answer 2

¿Ya no respondió su propia pregunta? :)

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

Answer 3

El motivo de que los ID sean en inglés es para que se devuelva el ID si la traducción falla por alguna razón: la traducción del idioma actual y el token no están disponibles u otros errores. Eso, por supuesto, asume 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 Pure IDs en lugar de texto en inglés, pero significa que tenemos que hacer mucho trabajo extra para el inglés por defecto.

Answer 4

Me atrevería a decir que nunca (para la mayoría de los valores de nunca) desea utilizar el texto libre como claves para nada. Imagínese si SO utilizó el título de la consulta como clave para esta página, por ejemplo. Si alguien lo vincula, 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 ...

como Douglas Leeder menciona, lo que probablemente querrá hacer es utilizar el Inglés como idioma por defecto (copia de seguridad), aunque una La interfaz que usa el inglés y otro idioma entremezclado es muy confuso (pero ligeramente divertido, también).

Answer 5

Estoy totalmente en desacuerdo con la respuesta de Richard Harrisons acerca de que él dice que es "la única manera". Querido amigo, no confíes en una respuesta que diga que es la única manera, porque la "única manera" no existe.

Aquí hay otra manera, que en mi humilde opinión tiene algunas ventajas sobre el enfoque Richards:

• comenzar con el uso de los proto-versión de la cadena de Inglés como original.
• No mostrar estos proto-cuerdas, pero crear un archivo de traducción para Inglés nontheless
• Copiar los proto-cuerdas a la traducción para el comienzo

Ventajas:

• código legible
• texto en su código está muy cerca si no es idéntico a lo que muestra su vista
• si desea cambiar el texto en inglés, no lo haga ge la proto-cadena pero la traducción
• si quiere traducir lo mismo dos veces, simplemente escriba una proto-cadena ligeramente diferente o simplemente agregue 'versión para esto y aquello' y todavía tiene un código perfectamente legible

Answer 6

Guau, me sorprende que nadie defienda el uso del inglés como clave. Usé 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, resulta obvio que el mensaje debe considerarse para la retraducción (lo cual es algo bueno).

En el caso de que solo corrija la ortografía o haga algún otro cambio que definitivamente no requiera traducción, es una cuestión simple actualizar los ID de esa cadena en los archivos de recursos.

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

Answer 7

En una palabra, no hagas esto.

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

Define identificadores mnemotécnicos para tus cadenas y trata 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 8

Además de las consideraciones anteriores, hay muchos casos en los que te gustaría la "llave" (msgstr) a ser diferente del texto original (Inglés). Por ejemplo, en la vista HTML, me gustaría decir [aaaa] dónde el destino y la etiqueta de esa etiqueta de anclaje 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. Entonces los MsgIds podrían ser algo así como socialSiteUrl y socialSiteLabel.

Uso una mezcla.

Para las 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.

Answer 9

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

Esto me hace sentir que la respuesta correcta es utilizar una versión modificada del gettext donde pones cuerdas como este contexto

_(id, backup_text, context) 

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

siendo opcional

por qué así? porque necesita identificar el texto en el sistema usando ID únicos que no sean textos en inglés que podrían repetirse en otros lugares.

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

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

1. la gente se olvida de hacer esto al principio y cambiarlo más adelante es un problema
2. su más flexible para que el sistema sea capaz de grupo, tanto por id y el contexto

por lo que también he añadido la variable de contexto en el final

el texto de copia de seguridad puede ser casi cualquier cosa, incluso podría ser "[ABOUT_ME @ PÁGINA DE INICIO texto no se pudo cargar, por favor, póngase en contacto con example@example.com]"

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

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

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

Answer 10

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

El uso de la llanura Inglés

Pros

• Fácil de escribir y leer el código
• En la mayoría de los casos, que funciona incluso sin ejecutar las funciones de traducción en código

Contras

• programadores involucrados deben ser también buenos redactores :)
• Usted tiene que escribir textos precisos correctas totalmente en Inglés, incluso en el caso de que la primera lengua que necesita para funcionar es algo más (es decir, que estamos empezando lof de proyectos en idioma checo y los estamos traduciendo a EN más tarde).
• En muchos casos, necesita utilizar contextos. Si no lo haces desde el principio, es mucho trabajo agregarlos más tarde. Para explicar: en inglés, una palabra puede tener muchos meands diferentes, y necesita 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 fuente a menudo llevarán a la pérdida de frases ya traducidas. Es muy frustrante perder la traducción a 3 idiomas diferentes solo porque corrigió el inglés.

Utilizando las teclas de

Pros

• puede utilizar 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 mejor dicho, un flujo de trabajo completo para la gestión de la traducción: votar por diferentes traducciones, historial de traducción, glosarios (lo que ayuda a mantener la traducción/el lenguaje coherente), pruebas, aprobación, etc. El uso de claves hace que este proceso mas suave.

• Es mucho más fácil de enviar mensajes de texto Engish para la corrección, etc. Por lo general, no es una buena idea dejar que los redactores de modificar su código directamente :)

Contras

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