Ando embarcada en varios proyectos sustentados por el gestor de contenidos WordPress y uno de los requisitos imprescindibles es la navegación multi-idioma. Así que dejaré por aquí mi experiencia, por si a alguien le sirve de ayuda o puede ser enriquecida por otras personas (y a ver si así podemos devolver algo de todo lo que nos ofrece este tipo de paquetes de software libre).

Lo primero de todo, necesitamos un plugin que consiga gestionar correctamente ese sistema multi-idioma. Para ello, y tras probar unos cuantos, el vencedor ha sido xlanguage. Las características que le hacen caballo ganador:

• Se encarga de la administración de tantos idiomas como queramos manejar. Esa gestión afecta a los contenidos del blog (tanto posts como páginas estáticas), a las categorías, etiquetas, feeds, theme, etc, …
• En el theme sólo será necesario contar con una carpeta donde almacenar los ficheros de idioma: un .mo con el nombre del idioma. Si tenemos plugins que generan contenidos, también podremos traducirlos y dejar aquí sus .mo.
• Una funcionalidad muy interesante es que gestiona el cambio de idioma mediante cookies, así que si cambiamos el lenguaje que arranca por defecto, en próximas navegaciones recordará nuestra preferencia. También detecta el idioma del navegador, para mostrarnos directamente esa opción.
• Por cada idioma genera una url diferente, lo que hace que los buscadores indexen los contenidos en todos los idiomas. Esa fue una de las razones por las que me decanté por xlanguage y no por qtranslate, que usa la misma dirección para todas las traducciones.

¿Y cómo conseguimos traducir nuestro theme y nuestros plugins? Sencillo: todas las llamadas php que muestren cadenas de texto, tendrán que ir con la función _e() o bien con la función __() (la diferencia entre ambas es que _e hace un echo de la cadena. Es decir, echo __(“Hola mundo”); es lo mismo que _e(“Hola Mundo”); ). De esta manera, con las herramientas que nos ofrece WordPress para la localización e internalización, podremos generar un .pot del theme donde introducir las traducciones pertinentes para luego generar el .mo que entenderá nuestro xlanguage.

• .pot: este fichero se genera de manera automática y recoge todas las cadenas de texto que aparecen en nuestro site. Por cada una de ellas, aparece justo debajo el espacio donde se debe dejar su traducción. Este es un ejemplo donde aparece primero el lugar en el que está dentro del código, la cadena en sí y el espacio donde se dejará la traducción correspondiente:
  

  #: presentacion.php:36
  msgid “Hello World”
  msgstr “”

• .po: es el fichero .pot con las traducciones ya incluidas. Siguiendo el ejemplo anterior:
  

  #: presentacion.php:36
  msgid “Hello World”
  msgstr “Hola Mundo”

• .mo: fichero binario que entienden las máquinas generado a partir del .po.

Expliquemos el proceso paso por paso.

1. Instalamos xlanguage y configuramos todos los idiomas en los que queremos que funcione nuestro blog. Mi recomendación es que usemos el código ISO3166 para identificar a cada uno.
2. Tendremos que repasar todos nuestros plugins y el theme para identificar dónde se generan cadenas de texto y comprobar que se usa o la función _e() o __(). WordPress usa la librería de internacionalización (i18n) gettext. Si dentro de una cadena de texto aparece una variable, no podemos usar sin más _e(“Tenemos $num amigos”); pero sí printf(__(“Tenemos %d amigos.”), $num);
3. Después de marcar todas las cadenas a traducir, ahora toca generar el .pot con ellas. Para ello, nos bajamos el script add-textdomain.php de WordPress. Lo lanzamos de la siguiente manera:
   

   php add-textdomain.php -i domain phpfile.php

   El domain marca el ámbito de lo que traducimos. Podemos poner default, por ejemplo, para el theme y el nombre del plugin para cada uno de ellos. Luego generamos el .pot mediante makepot.php:
   

   php makepot.php wp-theme el-directorio-del-theme languages/traduccion.pot

   En el caso de un plugin ponemos wp-plugin en vez de wp-theme. Para usar todas estas herramientas tenemos que tener el paquete gettext en nuestro servidor.

4. Para optener el .mo (fichero binario que entienden las máquinas) del .po (fichero con texto que entendemos las personas), lanzamos el siguiente conjuro desde bash:
   

   msgfmt fichero_idioma.pot -o fichero_idioma.mo

5. Ahora sólo falta que el theme sepa dónde encontrar esos ficheros .mo. Para ello usaremos el fichero de funciones de los themes de wordpress: functions.php. Allí agregaremos lo siguiente, teniendo en cuenta que hemos dejado los ficheros .mo en la carpeta languages y que el domain del theme es default:
   

   function theme_init(){
   load_theme_textdomain(‘default’, get_template_directory() . ‘/languages’);
   }

   Si además queremos traducir algún plugin:

   function theme_init(){
   load_theme_textdomain(‘default’, get_template_directory() . ‘/languages’);
   //Aquí ponemos el plugin cuyo domain es plugin1:
   load_theme_textdomain(‘plugin1′, get_template_directory() . ‘/languages/plugin1′);
   }

6. Para introducir contenidos, en el título, las categorías y las etiquetas, se separa cada idioma con un carácter definido en la parte de administración de xlanguage. Por defecto se usa el carácter | (el pipe que está en la tecla del uno y la exclamación). Por ejemplo, publicaríamos “Etiketak|Etiquetas” para crear un contenido cuyo título en euskera sería Etiketak y Etiquetas en castellano (siempre se usa el orden de creación de los idiomas). En los contenidos, en el editor de WordPress tenemos unos botones para marcar el idioma de cada parte. Y si lo queremos manejar desde la parte html, sólo tendremos que marcarlo con la etiqueta <span lang=”idioma”></span> (una etiqueta estandarizada por el W3C)

Enlaces de interés:

• Más información sobre internalización y localización en WordPress.
• Cómo optimizar xlanguage para los buscadores.

Imagen de ButterflySha (vía Flickr). Licencia CC-by

Hoy he despertado con la siguiente noticia: Microsoft ha recibido una de las menciones especiales de los premios Ukan por editar Windows y Office en euskera. Y se me ha quedado una cara de tonta…

Recapitulando un poco, los premios Ukan Sariak son unos galardones que se entregan desde el año 2007. Fueron creados por la Viceconsejería de Política Lingüística del Gobierno Vasco para reconocer públicamente a las personas u organizaciones que desarrollen un trabajo excepcional en favor de la normalización, difusión y fomento del euskera. A lo largo de sus dos ediciones se han premiado a la Caja Laboral, Eroski, Ikea… y este año a Microsoft.

Me gustaría separar dos preguntas a la hora de analizar este galardón: el qué y el cuándo.

El qué: “premiar a una empresa por el fomento de euskera”. Me parece bien aunque me chirría un poco que se haga tras el bonito acuerdo de BiscayTIK. Además nos quedaremos tan anchos pensando que Microsoft realmente tiene un interés en el euskera: ¡Ja! Esto es igualito que la campaña de verano “klik egin euskarari” (”haz click al euskera”).

El cuándo: me parece increíble que se haya premiado a una multinacional extranjera antes de hacerlo a muchos de los voluntarios que hacen de forma desinteresada las localizaciones de softwares como OpenOffice, la familia Mozilla, la Euskalbar, … Eso sí que promueve realmente el uso del euskera.

Cuando estuve en las jornadas SLUN 08 descubrí, para mi sorpresa, que Iñaki Larrañaga hacía él solito la traducción de OpenOffice. Y para más inri, la última versión, por amor al arte, porque no había recibido una subvención del Gobierno Vasco para ello (sólo dan subvenciones para un año hábil).

Pero claro, rellena más titulares entregar un premio a Microsoft, ¿verdad?

Pues nada, esperaremos a que el año próximo se vea recompensado el trabajo que hace mucha gente de la tierra porque el euskera tenga presencia en las nuevas tecnologías.