Conseguir un sitio multilingüe ha sido uno de los problemas históricos de WordPress. En el principio de los tiempos se hacía diferenciando los idiomas por categorías, luego empezaron a aparecer plugins; por fin apareció uno completo, fiable y estable, y al poco tiempo se volvió de pago (aunque no dejó de ser una buena opción). La alternativa siempre ha sido crear una instalación independiente para cada idioma, lo cual solía ser un infierno a nivel de mantenimiento; desde la versión 3.0 de WordPress y la integración estable de la estructura multisite esta posibilidad se democratizó y dejó de crear héroes. Tras leer Build a multilingual site with WordPress, y haber probado previamente las opciones que acabo de comentar, he llegado a la conclusión de que la opción multisite para conseguir un sitio multilingüe es ventajosa.
A continuación enumero y desarrollo todos los pasos necesarios para, partiendo de una instalación convencional de WordPress, conseguir un sitio multilingüe.
- Convertir una instalación convencional de WordPress en un multisite. Una vez hecho esto, hay que crear cada uno de los sitios en My Sites :: Network Admin :: Sites.
- Configurar el idioma para cada sitio creado del multisite, para que los paneles de administración estén en el idioma correcto. Para ello hay que conseguir los archivos de regionalización
.moy.pocorrespondientes; podemos encontrarlos dentro del paquete WordPress de dicho idioma, en la carpetawp-content/languages/, así que basta descargar el paquete de wordpress.org. Luego los subimos a nuestro servidor, a la carpetawp-content/languagesy en cada sitio de la red, seleccionamos el idioma deseado en Settings :: General. - Instalar el plugin Multisite Language Switcher. El plugin hay que configurarlo en cada uno de los sitios. Esto puedo parecer tedioso pero en realidad proporciona flexibilidad a costa de un trabajo extra relativamente escaso.El selector de idiomas se puede incorporar a la página mediante un widget o mediante el siguiente código, que permite mayor personalización:
if ( function_exists( 'the_msls' )) the_msls();
Para relacionar contenido –páginas, posts, e incluso las categorías y las etiquetas bajo las que los clasificamos– entre los diferentes sitios, de manera que se pueda saltar entre diferentes traducciones del mismo contenido, el plugin añade una columna en las listas de posts, de páginas y de categorías que nos permitirá hacerlo de manera sencilla e intuitiva.
- Regionalizar un tema. Lo preparamos para que sea traducible sencillamente mediante la edición de un archivo que contenga las cadenas a traducir.
- Crear un child theme en WordPress. Este paso no es extrictamente necesario, pero puede ser muy útil para aligerar el mantenimiento de los diferentes sitios. Al ser cada sitio una traducción, es lógico pensar que todos usarán el mismo theme, aunque quizás necesitemos mínimas diferencias entre ellos (colores por motivos culturales, archivos de configuración por motivos de programación…). Un parent theme y child themes para cada sitio nos permitirá gestionar estas diferencias sin necesidad de duplicar temas, código y mantenimiento.
6 comentarios
¿Y usar el plugin qTranslate? A mí me funciona bastante bien. Tengo mis dudas a nivel de SEO, pero por lo demás, puedes traducir hasta los tags.
Cuando probé el plugin qTranslate, hace años, le faltaban muchas opciones. Además la manera de gestionar contenido traducido era confusa ya que funcionaba mediante short codes, conviviendo varios idiomas en la caja de contenido de un post.
Jorge me comenta fuera del hilo que el plugin ha mejorado, solucionando estos inconvenientes.
Tengo mis dudas además sobre la «modularidad» de cada idioma, es decir, si en base de datos las traducciones se siguen guardando dentro del mismo registro, si siguen siendo varias partes del mismo post. Si es así, sería imposible, en el caso de necesitarse, separar el contenido por idiomas, por ejemplo para migrar a otro CMS.
En cuanto al SEO, ¿deja qTranslate configurar etiquetas meta y cosas así para cada idioma? Si no deja, efectivamente puede no ser la solución optima.
Permite traducir el nombre de las categorías y las etiquetas según el idioma, y parece ser que Google lee ambas, de modo que si buscas en un idioma, te aparece la versión del post en ese idioma.
También me parece que gestiona bien el contenido no consistente, p. ej. cuando un post está solo en un idioma, te añade un mensaje (personalizable) en el otro idioma diciendo «este post no está traducido».
Si quieres puedes ver cómo se comporta en sociarq.net
Las etiquetas de la izquierda se traducen al cambiar de idioma, pero son las mismas (misma id, mismo slug). Yo uso en la sidebar el campo de descripción de cada tag, y eso también se traduce.
Y sí, cada post es una sola entrada en la base de datos. Puede ser un rollo a la hora de exportar pero a nivel de uso no le he visto ningún inconveniente, y te ahorras el lío de enlazar unos posts con otros, de gestionar dobles (o triples, o…) entradas, etc.
Gracias por la explicción. Dudando entre el multisite que propones y el wpml (pagando).
Las pegas que se ponen por ahí al qTranslate son precisamente esas: que dependes del plugin: a la hora de la portabilidad estás vendido. Para webs sencillas es muy útil y fácil de usar (pfccommons.org creo que tiene este mismo plugin).
En http://pune2012.globalrec.org/wiki/index/ he probado polylang y va bien para un tipo de página así de sencilla: incluso soporte para ‘custom post types’ y todo.
Con este plugin ¿qué pasa cuando no hay contenido traducido? ¿te deja elegir qué pasa?
Para globalrec.org estoy pensando en hacer algún tipo de sistema para permitir colaborativamente la traducción… entre wiki y blog colaborativo.
numeroteca, el plugin Multisite Language Switcher te deja elegir el comportamiento cuando no hay traducción disponible, sí.
Jorge, es cierto que a enlazar las distintas traducciones hay que dedicarle tiempo, pero como dice numeroteca, todo sea por depender de plugins lo menos posible. Aunque bien es cierto que un plugin ampliamente extendido como qtranslate no parece que vaya a parar su desarrollo.