WordPress no tiene soporte nativo para múltiples idiomas. Llevamos años esperándolo, hay propuestas en marcha dentro del proyecto, pero a día de hoy si quieres un sitio multiidioma en WordPress tienes que recurrir a plugins. Y ahí empieza el problema.
Este post repasa algunas opciones disponibles, sus diferencias arquitectónicas fundamentales, y por qué algunas de ellas pueden dejarte el sitio roto de formas que no son fáciles de reparar.
No pretendo sentar cátedra, pero es que estoy en varios proyectos que tratan con distintos idiomas, y organizar todo está siendo un lío monumental para que no se rompa nada.
WordPress y la deuda pendiente del multiidioma
El core de WordPress lleva años con propuestas para soporte nativo de idiomas a nivel de contenido. Hay trabajo hecho en torno al Translate Team, hay conversaciones en Make WordPress, pero ninguna solución definitiva integrada en el core. Todo lo que existe hoy es a nivel de plugin.
Esto ha generado un ecosistema fragmentado donde cada solución toma decisiones arquitectónicas muy distintas, con consecuencias muy distintas para la integridad de tus datos.
Las dos grandes arquitecturas
Antes de hablar de plugins concretos, hay que entender la diferencia fundamental entre los dos enfoques posibles:
Arquitectura A: un WordPress, una base de datos, metadatos para separar idiomas
Todos los idiomas viven en la misma instalación de WordPress. Las traducciones se guardan como posts adicionales (o como metadatos) vinculados entre sí. El plugin gestiona qué contenido mostrar según el idioma activo.
Ejemplos: WPML, Polylang.
Arquitectura B: instalaciones independientes, una por idioma
Cada idioma tiene su propia instalación de WordPress (o al menos su propia base de datos). Pueden compartir dominio mediante subdirectorios o subdominios, pero los datos están separados. WordPress Multisite puede ser la base de esto.
Ejemplos: MultilingualPress.
Los plugins más usados
WPML
El más extendido históricamente. De pago. Lleva muchos años en el mercado y tiene integraciones con casi todo.
Usa la arquitectura A: todo en una sola base de datos. Cada post traducido es un post adicional en la tabla wp_posts, y las relaciones entre idiomas se guardan en tablas propias del plugin (icl_translations, etc.). Los archivos de media también se duplican y se asocian a las traducciones mediante metadatos.
El problema real con WPML no es solo técnico, es operativo: desinstalar WPML o eliminar idiomas es destructivo si no sabes exactamente lo que estás haciendo. Al borrar un idioma, el plugin puede eliminar los posts asociados a ese idioma, y con ellos los archivos de media que estaban vinculados, aunque esos mismos archivos sean referenciados por el contenido del idioma principal. El resultado: páginas del idioma principal con imágenes rotas o directamente sin contenido.
Esto no es un bug puntual. Es una consecuencia directa de la arquitectura: cuando los datos de varios idiomas están entrelazados en la misma base de datos usando metadatos como pegamento, cualquier operación de borrado tiene efectos colaterales difíciles de predecir y de revertir.
Polylang
Similar en concepto a WPML pero con versión gratuita. También usa la arquitectura A. Las traducciones se gestionan como posts relacionados mediante taxonomías personalizadas.
Más liviano que WPML, pero comparte el mismo problema estructural: los datos de todos los idiomas están mezclados en la misma base de datos. Separar idiomas a posteriori es complejo y propenso a pérdida de datos.
MultilingualPress
Usa WordPress Multisite como base. Cada idioma es un sitio independiente dentro de la red, con su propia base de datos (o esquema separado en la misma instancia de MySQL). Las relaciones entre traducciones se guardan en tablas de la red, pero el contenido en sí está aislado.
Esto cambia radicalmente el perfil de riesgo: si quieres eliminar un idioma, simplemente eliminas ese sitio de la red. El resto de sitios no se ve afectado. Los archivos de media de cada idioma son independientes.
La contrapartida es que requiere Multisite, lo que añade complejidad operativa en hosting, backups, actualizaciones y gestión de plugins/temas.
Por qué mezclar idiomas en una sola base de datos es mala idea
Si estás evaluando opciones o asesorando a alguien, este punto merece atención especial.
Acoplamiento de datos entre idiomas
Cuando las traducciones son posts relacionados en la misma base de datos, una operación que afecta a un idioma puede afectar a otro. Borrar, migrar o exportar un idioma no es una operación limpia: hay que entender y respetar todas las relaciones que el plugin ha creado, muchas de ellas no documentadas de forma clara.
Dependencia total del plugin
Con WPML o Polylang, si el plugin deja de funcionar (conflicto, versión incompatible, decides desinstalarlo), tienes una base de datos llena de posts duplicados sin una forma nativa de WordPress de entender qué es qué. La estructura de datos es propiedad del plugin, no de WordPress.
Con instalaciones independientes, WordPress entiende perfectamente los datos de cada sitio sin necesidad del plugin de multiidioma. El plugin solo añade las relaciones entre sitios.
Migraciones y splits son pesadillas
Separar un sitio multiidioma (construido con WPML o Polylang) en dos sitios independientes es uno de los trabajos más delicados que existen en el mundo WordPress. Hay que exportar contenidos por idioma, reimportar, reasignar media, reconstruir relaciones, limpiar metadatos residuales. Y todo esto con riesgo real de pérdida de datos si no se hace con cuidado quirúrgico.
El problema de los archivos de media
Los archivos subidos en WordPress se registran como posts de tipo attachment en la base de datos. Con WPML, las traducciones de páginas y entradas pueden tener sus propios attachments «duplicados» o simplemente referencias al mismo archivo. Cuando se eliminan traducciones, el plugin puede eliminar esos attachments, y con ellos los archivos físicos del servidor, aunque sean necesarios para el idioma principal.
Esto no es teórico. Es exactamente lo que pasa al intentar limpiar una instalación con WPML mal configurada o al intentar reducir idiomas después de años de contenido acumulado.
Recomendación según escenario
Sitio nuevo, presupuesto para hosting Multisite:
MultilingualPress. Datos limpios, arquitectura sana, riesgo operativo bajo.
Sitio nuevo, restricciones de hosting (no Multisite), poco presupuesto:
Polylang. Más ligero que WPML, gratuito en su versión base. Asume las limitaciones de la arquitectura desde el principio.
Sitio existente con WPML, funcionando bien:
No toques nada que no sea necesario. WPML en modo «crucero» es manejable. Los problemas aparecen cuando intentas hacer cambios estructurales.
Sitio existente con WPML, necesitas quitar idiomas o migrar:
Haz un backup completo (base de datos + archivos) antes de cualquier operación. Considera hacerlo en un entorno de staging. Si necesitas separar idiomas en sitios independientes, es un proyecto en sí mismo, no una tarea de tarde.
El futuro: soporte nativo en WordPress
El proyecto WordPress avanza (lentamente) hacia soporte nativo de idiomas en el contenido. La iniciativa más concreta en los últimos años ha sido la de los «content translations» dentro del contexto del editor Gutenberg y el Full Site Editing, pero sin fecha de entrega definida.
Hasta que eso llegue, no hay solución perfecta. Solo soluciones con distintos perfiles de riesgo. Y conocer esos perfiles antes de elegir puede ahorrarte semanas de trabajo de recuperación.
Escrito desde la experiencia directa (y la frustración) de trabajar con instalaciones WordPress en producción y de participar en el WordPress Hosting Team.
Deja una respuesta