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

Esto es un no parar. Si hace poco teníamos a dos niños correteando por el nire-salón (nirudia y niretv), ahora llega otro nuevo bebé. Y en éste tenemos muchas ilusiones puestas porque será el primer bebé libre. Le abriremos las tripas a todo el mundo (esto último me ha quedado un poco macabro… pero es lo que tiene el software libre ).

Queremos crear una plataforma en la que todos participéis y necesitamos ayuda de todo tipo: en diseño, seguridad, traducciones, testeo, … Cualquier cosa que se os ocurra será bienvenida para enriquecer el proyecto. Y por supuesto, lo más importante es generar una comunidad. Si todos tiramos de este carro, tendremos una herramienta instalable en multitud de lugares.

Por descontado, ya contamos con la traducción a multitud de idiomas de la plataforma. Todo gracias a nuestro niretrad querido (en el que también nos podéis ayudar).

¿Qué diferencia Nirewiki de otros sistemas como MediaWiki, DocuWiki, etc, …?

Pues básicamente en que con estas aplicaciones podemos crear un wiki. Con Nirewiki podremos tener una plataforma desde la que crear muchos wikis. Algo así como un WordPress MU para los blogs. Esa es la novedad que creo que hasta ahora no se había implementado (igual me equivoco, pero entonces me tiráis de las orejas ).

La idea es crear un sistema abierto no sólo en el código sino en la utilización de estándares y posibilidades de importar y exportar contenidos en formatos que cumplan los estándares.

No pretendemos reinventar la rueda. Creemos que es positivo reutilizar partes de otros proyectos que llevan funcionando ya muchos años: por ejemplo, para la traducción a otros idiomas utilizamos las traducciones del sistema Mediawiki uno de los más traducidos y que soporta la Wikipedia.

Para la edición de los contenidos utilizamos la versión del editor Wysiwyg utilizada por WordPress, por varias razones. Entre ellas, porque es bastante sencilla de utilizar y está traducida a bastantes idiomas.

En estos momentos ya hay una versión de Nirewiki funcionando, pero somos conscientes que para poder liberar el código con las mínimas condiciones de seguridad y facilidad de uso es necesario darle un buen repaso.

Estamos buscando gente que quiera unirse al proyecto: programadores, diseñadores, o cualquier persona que nos ayude a mejorar las prestaciones del sistema. Mejoras en varios aspectos: usabilidad, accesibilidad y apariencia, pero también en nuevas funcionalidades y en incrementar las posibilidades de reutilización de aplicaciones externas que puedan añadirse a Nirewiki como plugins, themes u otras similares.

Si quieres colaborar con nosotros, pásate por el wiki. Serás bienvenido

Más información en el blog de David.