Después de muchos meses trabajando en una aplicación que, por azares del destino, alguien decidió que se realizase en php utilizando como frontend Drupal (del que solo se utiliza el sistema de registro y poco más) y después de infinitos test de usuarios (que nunca son suficientes) y después de generar un proyecto con 31.000 líneas de código propias (el total sin contar drupal suma más de 203.000) llega el momento de venderlo.
El primer cliente siempre es el peor, pero es que el segundo ¡es holandés! y, claro, lo quiere en inglés… Y algún lumbrera le asegura que tendrán la versión en inglés ¡¡en una semana!!. Lo bonito del tema es que cuando aseguró eso no preguntó a nadie del equipo de desarrollo. ¿Para qué? Las fechas las ponen ellos, qué más da que sea algo imposible.
Total, que, de casualidad, nos enteramos de que hay que hacer este «pequeño» cambio, las traducciones no serán un problema, porque tenemos gente que puede hacerlo bien y rápido, pero, ¿cómo internacionalizamos el php? La parte que cubre Drupal (y que podría traducirse desde el mismo sistema) es mínima, en total tenemos 425 archivos php donde hay textos en castellano en cualquiera de ellos, además, parte en html, parte en php y parte en javascript… Cualquier otro programador hubiese presentado su carta de renuncia o hubiese pedido una baja laboral. Además, ya nos han dicho que no piensan pagarnos las horas extras y que si cometemos errores tendremos que arreglarlos en nuestro tiempo libre.. ¡Eso si que son condiciones laborales y no las de los mineros de asturias!
Sin embargo mi responsabilidad como profesional me obliga a atender las peticiones por absurdas que sean e intentar dar soluciones… Así que os pongo un resumen de lo que hicimos:
Problema número 1: qué sistema de internacionalización usar.
Al contrario que Java, que dispone de un sistema i18n con properties desde el principio, php adolece de este mecanismo estandar. Después de valorar varias opciones (muchas usadas en programas populares como prestashop, etc.) descubrimos que lo mejor es utilizar gettext.
Gettext es un proyecto GNU que, afortunadamente, es utilizado muy ampliamente en Linux para proporcionar internacionalización a sus programas. Es por ello que está presente en la mayoría de las distribuciones (incluyendo las que usamos para desarrollo y pruebas) y, además, tiene un módulo para php que también está normalmente incluida en las instalaciones normales de php (incluso en XAMPP está).
¿Cómo funciona gettext? Básicamente se basa en localizar todas las cadenas de texto ya escritas y sustituirlas por una función que la traduce. En el caso de php esta suele ser la función gettext(‘cadena’) o, abreviada _(‘cadena’). De esta forma, el texto en html:
<p>Esto es un texto</p>
Lo modificaremos en:
<p><?php _("Esto es un texto")?></p>
Luego el sistema localizará, según los parámetros de idioma, su traducción y la escribirá. Si no encuentra ninguna escribirá esa misma cadena.
Así que el primer, y más tedioso, problema es sustituir todas las cadenas de texto en nuestro programa por estas sustituciones. No hay una forma única y automatizada de hacerlo, porque podemos encontrarnos texto dentro del código php, dentro de etiquetas html o incluso dentro de código javascript y dependiendo de dónde se encuentre esa cadena deberá traducirse (o no).
Problema número 2: traducir las cadenas
Una vez que tenemos «marcadas» todas nuestras cadenas, deberemos generar un archivo con las traducciones… Esto ya es más sencillo de automatizar porque podemos utilizar herramientas que ya existen. La más adecuada es poedit. Esta herramienta nos permite escanear directorios de fuentes y almacena las cadenas que no están traducidas en un catálogo para después permitir que un traductor las vaya traduciendo sin tener que saber nada de php.
Antes de utilizar poedit es muy recomendable que establezcamos las rutas de los directorios donde vamos a guardar los catálogos traducidos. Generalmente esto se hace en el directorio raiz de la aplicación creando estos directorios:
locale/xx_XX/LC_MESSAGES
donde xx_XX es el código del idioma y país (en_GB en nuestro caso). Dentro de cada uno de esos directorios almacenaremos los .po (y .mo que compilamos) que generaremos con poedit.
Una vez creados los directorios, arrancamos el poedit y lo configuramos indicando que el directorio principal será «.» y los directorios a escanear serán ../../../ (suponiendo que hemos respetado la estructura que os he comentado). También es importante el tema de los plurales que, en caso del español sería:
nplurals=2; plural=n != 1;\n
Una vez todo en su lugar solo tendremos que actualizar para que poedit busque en todos los archivos y nos encuentre todas las cadenas que se pueden internacionalizar. Utilizando el mismo programa podemos hacer que los traductores nos traduzcan las cadenas y nos devuelvan el mismo .po ya traducido.
Problema número 3: hacer que el sistema use el idioma del usuario
Para que funcione gettext para php hay que incluir las siguientes líneas al principio del script:
putenv("LC_ALL=$locale");
setlocale(LC_ALL, $locale, 'english');
bindtextdomain("messages", __DIR__."/Locale");
bind_textdomain_codeset("messages", 'UTF-8');
textdomain("messages");
Lo relevante ahí es que $locale ha de contener el idioma (en_GB) messages es el nombre que tiene el catálogo poedit (así tendremos un messages.po en el directorio correspondiente) y que a bindtextdomain hay que pasarle el directorio donde hemos colocado nuestros locales.
Para el caso de drupal vamos a utilizar el idioma que el usuario ha puesto en su perfil, por lo que el código adicional a utilizar es:
global $language; $locale = $language->language; if ($locale=='en') $locale="en_GB.utf8"; else $locale = 'es_ES.utf8';
Esto es así porque los locales han de ser tal como están en el sistema operativo y, sin embargo, los idiomas en drupal solo indican el idioma y no el locale.
Seguimos en ello (hay muchos archivos) y además, nos queda pendiente la internacionalización de los correos y de los informes que generamos… Seguiremos informando.
Pega al Rubius