Traducción con Pods de WordPress y WPML

Plugins incompatibles con WPML

En algunas ocasiones nos encontramos sitios WordPress que se han realizado con ayuda de plugins para la construcción de contenidos, bloques, etc… qué no son compatibles con traductores de site, como por ejemplo el WPML, no suponen ningún problema mientras el site está en un solo idioma, pero, si se necesita ampliar los idiomas nos vemos con en una situación complicada, al menos en lo que se refiere al coste en tiempo.

Hay tres soluciones, pero no siempre todas funcionan.

1. Solución simple y rápida que exponemos en este post.
2. Rehacer el site con plugins que si sean compatibles con WPML
3. Hacer el sitio MultiSite e usar el MultilingualPress
   

1. Solución simple y rápida

Lo exponemos a continuación: en el caso de que se estén empleando plugins para el desarrollo de una solución WordPress que no sean compatibles con WPML, por ejemplo PODS, una solución interesante, es duplicar el mismo post o tipo de contenido, que ha sido creado con elementos del plugin incompatible y aprovechar cada versión para cada uno de los idiomas que hemos configurado para nuestro sitio, diferenciando cada post con una nomenclatura, por ejemplo con el diminutivo (_en, _es, _fr) del idioma en el slug o (-EN, -ES, -FR) en el nombre del mismo.

Para que luego WordPress distnga cual de esos bloques o contenidos pertenece al idioma concreto, utilizamos la constante ICL_LANGUAGE_CODE, definida por WPML, que se pueden emplear como parte del nuestro tema, para poder invocar el contenido de un post u otro en dependencia del idioma actual con el que se está navegando en nuestro sitio, idioma almacenado en la constante antes mencionada.

De esta manera un ejemplo podría ser:

<?php if (ICL_LANGUAGE_CODE == 'en') { ?>

…se invoca el contenido o con el contenido en idioma inglés

<?php } else { ?>

…se invoca el contenido o con el contenido en un idioma que no sea el inglés    

<?php }?>

2. Rehacer el site con plugins que si sean compatibles con WPML

Esta solución va a llevar más tiempo: habrá que revisar el sitio y ver en que partes se está usando este plugin, para que bloques i contenidos y rehacer el trabajo, es como un refactoring, que puede llevar más o menos tiempo, pero siempre será unvolumen de tiempo elevado que se incluso se puede acercar al tiempo total de desarrollo web, si la persona que está creando el site tiene que usar un plugin que no conoce para la construcción del site, dado que seguramente si el site lo ha hecho él mismo con el plugin incompatible es porqué dominaba ese plugin incompatible en lugar de otros. Así que en el nuevo desarrollo deberá sumar la curva de aprendizage al desarrollo.

3. Hacer el sitio MultiSite e usar el MultilingualPress

Esta solución es una buena solución pero puede dar problemas, dado que a veces la instalación Multisite se puede complicar e incluso ser casi imposible. Sobre todo si el site es complejo y han pasado varias manos y ya se ha instalado plugins de traducción. Sin embargo si es posible, es una solución intermedia, rápida y sólida.

En un proceso lógico de desarrollo, suponiendo que no podemos tener todo el tiempo del mundo, podríamos aconsejar, instalar el Multisite en WordPress y el Multilingual, y si se complica ir a por la solución simple y rápida expuesta. Idealmente

Con todo el tiempo del mundo, el refactoring de la web hacia plugins compatibles con WPML, es la solución ideal.