Algunas consideraciones:
¿Quién hará las traducciones? ¿Personas que también están conectadas al sitio? ¿Una agencia de traducción? Cuando utilice Gettext, trabajará con archivos 'pot' (.po). Estos archivos contienen el ID del mensaje y la cadena del mensaje (la traducción). Ejemplo:
msgid "A string to be translated would go here"
msgstr ""Ahora, esto se ve bien y es comprensible para cualquiera que necesite traducirlo. Pero, ¿qué sucede cuando usa palabras clave, como sugiere Mike, en lugar de oraciones completas? Si alguien necesita traducir un msgstr llamado "address_home", no tiene ni idea de si debe ser un encabezado "Dirección de casa" o si es una oración completa. En este caso, asegúrese de agregar comentarios al archivo justo antes de llamar a la función gettext, así:
/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");
Usando xgettext --add-comments=/// al crear los archivos .po agregará estos comentarios. Sin embargo, no creo que Gettext se use de esta manera. Además, si necesita agregar comentarios con every texto que desea mostrar:a) probablemente cometerá un error en algún momento, b) su secuencia de comandos completa se llenará con los textos de todos modos, solo en forma de comentario, c) los comentarios deben colocarse directamente encima de Gettext función, que no siempre es conveniente, dependiendo de la posición de la función en su código.
Una vez que su sitio crezca (aún más) y sus archivos de idioma junto con él, puede ser bastante difícil mantener todas las diferentes traducciones de esta manera. Cada vez que agrega un texto, necesita crear nuevos archivos, enviar los archivos a los traductores, recibir los archivos de vuelta, asegurarse de que la estructura aún esté intacta (los traductores ansiosos siempre están felices de traducir la sintaxis también, haciendo que todo el archivo inutilizable :)), y termine con la importación de las nuevas traducciones. Es factible, seguro, pero tenga en cuenta los posibles problemas en este sentido con sitios grandes y muchos idiomas diferentes.
Otra opción:combina tu segunda y tercera alternativa:
Personalmente, me parece más útil gestionar la traducción mediante un (simple) CMS, manteniendo las variables y traducciones en una base de datos y exportando los textos relevantes a archivos de idioma usted mismo:
- añadir variables a la base de datos (por ejemplo:id, página, variable);
- añadir traducciones a estas variables (por ejemplo:id, varId, idioma, traducción);
- seleccione variables y traducciones relevantes, escríbalas en un archivo;
- incluya el archivo de idioma relevante en su sitio;
- cree su propia función para mostrar un texto de variables:
text('var'); o tal vez algo como __('faq','register','lost_password_text');
El punto 3 puede ser tan simple como seleccionar todas las variables y traducciones relevantes de la base de datos, colocarlas en una matriz y escribir la matriz serializada en un archivo.
Ventajas:
-
Mantenimiento. Mantener los textos puede ser mucho más fácil para grandes proyectos. Puede agrupar variables por página, secciones u otras partes dentro de su sitio, simplemente agregando una columna a su base de datos que define a qué parte del sitio pertenece esta variable. De esa manera, puede obtener rápidamente una lista de todas las variables utilizadas, p. la página de preguntas frecuentes.
-
Traductorio. Puede mostrar la variable con todas las traducciones de todos los diferentes idiomas en una sola página. Esto podría ser útil para las personas que pueden traducir textos a varios idiomas al mismo tiempo. Y podría ser útil ver otras traducciones para tener una idea del contexto para que la traducción sea lo mejor posible. También puede consultar la base de datos para averiguar qué se ha traducido y qué no. Tal vez agregue marcas de tiempo para realizar un seguimiento de las posibles traducciones obsoletas.
-
Acceso. Esto depende de quién traducirá. Puede empaquetar el CMS con un simple inicio de sesión para otorgar acceso a personas de una agencia de traducción si es necesario, y solo permitirles cambiar ciertos idiomas o incluso ciertas partes del sitio. Si esta no es una opción, aún puede enviar los datos a un archivo que se puede traducir manualmente e importarlo más tarde (aunque esto podría tener los mismos problemas que se mencionaron anteriormente). Puede agregar una de las traducciones que ya están allí (inglés u otro idioma principal) como contexto para el traductor.
Considerándolo todo, creo que encontrará que tendrá mucho más control sobre las traducciones de esta manera, especialmente a largo plazo. No puedo decirle nada sobre la velocidad o la eficiencia de este enfoque en comparación con la función gettext nativa. Pero, dependiendo del tamaño de los archivos de idioma, no creo que haya una gran diferencia. Si agrupa las variables por página o sección, siempre puede incluir solo las partes requeridas.
