Polylang rompe traducciones, reparar WordPress

Cuando toca reparar traducciones Polylang, lo importante no es asumir que el plugin ha fallado por sí solo, sino identificar qué parte de la configuración multidioma se ha desajustado. En la práctica, reparar este tipo de incidencia suele implicar revisar la relación entre idiomas, slugs, taxonomías, cadenas traducibles, URLs, caché y posibles conflictos con el tema, constructores visuales o plugins activos.

Los síntomas más comunes son conocidos: páginas que desaparecen en un idioma, entradas que apuntan a la traducción equivocada, categorías sin equivalencia, cadenas del tema sin traducir o URLs multidioma que devuelven errores extraños. El fallo visible, sin embargo, no siempre coincide con la causa real. Por eso conviene diagnosticar primero y tocar después, especialmente si la web está en producción.

Qué suele pasar cuando hay que reparar traducciones Polylang

Normalmente, la incidencia aparece tras una actualización, una migración, un cambio de tema, una modificación en la estructura de enlaces permanentes o la instalación de un plugin que también interviene en URLs, SEO, caché o campos personalizados. A veces el contenido sigue existiendo, pero se ha perdido la asociación entre versiones de idioma; otras veces el problema está en cómo se muestra, no en los datos guardados.

• Una traducción existe, pero Polylang no muestra traducciones en el selector de idioma.
• Los slugs traducidos dejan de coincidir y generan rutas incorrectas.
• Las taxonomías traducidas no se sincronizan con entradas o productos.
• Las cadenas del tema o de un plugin aparecen en el idioma equivocado.
• La caché o una redirección ocultan el estado real del contenido.

En otras palabras: una web puede parecer “rota” por fuera y, aun así, conservar una base recuperable si se revisa con método tras una actualización.

Primeras comprobaciones antes de tocar contenido o base de datos

Antes de editar traducciones, desactivar plugins o tocar la base de datos, conviene hacer una copia de seguridad completa y, si es posible, trabajar en un entorno de staging. Esto es especialmente importante si la web tiene tráfico, ventas, formularios o campañas activas.

Mini checklist seguro de diagnóstico

• Comprobar si el problema afecta a todo el sitio o solo a un tipo de contenido.
• Revisar si el fallo empezó tras una actualización, migración o cambio reciente.
• Vaciar caché de plugin, servidor y CDN antes de sacar conclusiones.
• Verificar ajustes de idioma por URL, directorio o dominio según la configuración activa.
• Guardar de nuevo los enlaces permanentes sin hacer cambios adicionales, solo si hay copia previa y el problema apunta a reglas de reescritura.

Estas comprobaciones ayudan a separar un error de traducciones en WordPress de un problema de visualización, caché o enrutado.

Conflictos habituales que pueden desajustar las traducciones

Muchas traducciones rotas WordPress no se originan en Polylang, sino en integraciones alrededor del sitio. Un constructor visual puede guardar contenido en campos propios; un plugin SEO puede modificar slugs o metadatos por idioma; una capa de caché puede servir páginas del idioma equivocado; y ciertas redirecciones automáticas pueden interferir con las URLs multidioma WordPress.

También conviene revisar personalizaciones en el tema, snippets, hooks o funciones que alteren consultas, taxonomías o plantillas. Si además hay campos personalizados o CPT registrados por código, cualquier cambio en nombres, slugs o argumentos de registro puede romper la relación entre contenido e idioma sin que el editor lo muestre claramente.

Si sospechas de un conflicto entre plugins WordPress, no desactives componentes críticos a ciegas en producción. Haz la prueba en una copia o staging y documenta el orden exacto de cambios.

Cómo revisar entradas, páginas, taxonomías y cadenas traducibles

Empieza por una muestra pequeña: una página, una entrada y una taxonomía afectadas. Comprueba si cada elemento tiene idioma asignado y si mantiene su vínculo con la versión traducida. Después revisa los slugs por idioma, porque una traducción correcta con un slug desajustado puede seguir fallando en la URL.

En taxonomías, el problema suele aparecer cuando categorías o etiquetas se duplican, se importan sin relación entre idiomas o cambian sus términos tras una migración. En ese punto, conviene revisar las taxonomías traducidas Polylang una por una antes de rehacer contenido manualmente.

Con las cadenas traducibles WordPress, la lógica es distinta: no siempre están en entradas o páginas, sino en el tema, widgets, opciones o plugins. Si una cadena se ha perdido tras una actualización, puede deberse a un cambio en el texto original, al contexto o al dominio de traducción, no necesariamente a una corrupción de datos.

Si vas a revisar tablas o relaciones en base de datos, hazlo solo con copia reciente y criterio técnico claro. Tocar datos multidioma sin mapa previo de relaciones puede empeorar la instalación.

Cuándo conviene restaurar, clonar o escalar la reparación

No siempre interesa seguir probando sobre la web activa. Si el fallo afecta a varias taxonomías, a muchos contenidos, a URLs indexadas o a funcionalidades de negocio, suele ser mejor clonar la instalación y trabajar fuera de producción. Restaurar una copia también puede ser razonable si la incidencia tiene un punto de inicio claro y el impacto posterior compensa la pérdida de cambios recientes.

Conviene escalar la reparación cuando hay mezcla de factores: migración reciente, tema personalizado, constructor visual, SEO plugin, redirecciones y contenido multidioma extenso. En esos casos, el tiempo perdido en pruebas parciales suele salir más caro que un diagnóstico técnico ordenado.

Cómo evitar que el problema vuelva a repetirse

La prevención pasa por actualizar con control, probar cambios en staging y documentar cómo está montado el multidioma: estructura de URLs, tipos de contenido, taxonomías, cadenas del tema y plugins implicados. También ayuda limitar personalizaciones improvisadas y revisar compatibilidades antes de tocar el tema o cambiar un constructor visual.

Como referencia oficial, la documentación de Polylang puede orientar sobre ajustes, traducciones de contenido y cadenas según la versión instalada. Aun así, cada caso depende de la configuración real de la web y de cómo se integran el resto de componentes.

El error más común es corregir el síntoma visible —por ejemplo, rehacer una traducción o cambiar un slug— sin localizar la causa real. Así es como se duplican contenidos, se rompen relaciones entre idiomas o se generan nuevas inconsistencias.

Si necesitas reparar traducciones Polylang con seguridad, el siguiente paso razonable es hacer un diagnóstico técnico previo, separar fallo visible de causa raíz y aplicar la corrección en un entorno controlado. Cuando la web ya mezcla varios plugins, caché, redirecciones y contenido crítico, una reparación WordPress bien planteada evita perder más tiempo y reduce el riesgo de dañar la instalación.