Traducir plantillas de Elementor y Divi sin estropear los diseños

Hiciste todo bien. Compraste un tema premium, encontraste el archivo .po, lo tradujiste con cuidado y subiste el .mo a tu carpeta de idiomas. Las cadenas del encabezado del tema se actualizan correctamente. El pie de página se lee en español. Tu proceso de pago de WooCommerce está localizado. Pero luego abres la página de inicio y cada título, botón y bloque de texto creado con Elementor sigue estando en inglés.

Revisas el archivo .po. Puedes ver las cadenas en inglés en el código. Vuelves a traducir. Nada cambia. Borras las cachés. Nada cambia. Te convences de que algo está roto hasta que alguien en un foro te señala amablemente: Elementor (y Divi, y Beaver Builder, y Bricks) no almacenan contenido en archivos .po. Nunca lo han hecho. Has estado luchando contra un problema que no es soluble con el enfoque que estás utilizando.

Esta guía explica por qué el contenido de los constructores de páginas es arquitectónicamente diferente del contenido de temas y plugins, los dos caminos para traducirlo, y cómo mantener el marcado de los widgets intacto durante la traducción para que tus diseños cuidadosamente elaborados no se desmoronen.

Por qué Elementor y Divi no usan archivos .po

Los archivos .po almacenan cadenas que residen en el código, llamadas como __( 'Shop', 'mytheme' ) dispersas por las plantillas PHP. La herramienta de construcción WP-CLI puede extraer estas cadenas en una plantilla .pot, los traductores trabajan en archivos .po, y los archivos .mo compilados se cargan en tiempo de ejecución.

El contenido del constructor de páginas es diferente. Cuando escribes "Welcome to our store" en un widget de encabezado de Elementor, ese texto no está en ningún archivo PHP. Se guarda como JSON (Elementor) o como un blob de shortcode (Divi) en la tabla wp_postmeta, asociado con la entrada donde lo colocaste.

Dónde reside realmente el contenido del constructor de páginas

Elementor almacena el árbol de widgets de cada página en postmeta bajo la clave _elementor_data. Abre cualquier entrada en la base de datos y encontrarás un array JSON que describe cada sección, columna y widget, con configuraciones y contenido en línea:

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi almacena el contenido de su página como shortcodes incrustados en post_content:

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder y Oxygen siguen el mismo patrón con su propio formato. Ninguno de estos contenidos es tocado jamás por los archivos .po / .mo.

Qué reside en los archivos .po

El propio plugin del constructor de páginas tiene cadenas de interfaz de usuario: etiquetas de botones en el editor, mensajes de error, avisos de administración. Esas están en archivos .po y sí son traducidas por tus archivos .mo en wp-content/languages/plugins/. Esta es usualmente la razón por la que la gente se confunde: traducen las cadenas de "Elementor" y ven la interfaz de usuario del editor en español, pero el contenido real que construyeron con esos widgets permanece en inglés.

Esta distinción es también la causa raíz de la mitad de los tickets en nuestra guía de solución de problemas para traducciones que no aparecen - el lector espera que los archivos .mo afecten el contenido que ve en el frontend, pero el contenido está en la base de datos, no en el código.

Qué cubren realmente los archivos .po en un sitio con constructor de páginas

Déjame trazar una línea clara entre los dos para que sepas exactamente qué maneja cada tipo de archivo.

Los archivos .po / .mo traducen

• Las cadenas de plantilla del tema: get_template_part, texto codificado directamente en header.php, footer.php, functions.php.
• Cadenas de UI de plugins: proceso de pago de WooCommerce, etiquetas de administración de Yoast, etiquetas de campo de Contact Form 7.
• UI del plugin constructor de páginas: botones del editor de Elementor, mensajes de confirmación de guardado de Divi.
• Cadenas dinámicas que los plugins muestran en el frontend: WooCommerce "Añadir al carrito", "Sin existencias", totales del carrito.

Los archivos .po / .mo NO traducen

• Texto de encabezados, párrafos, botones introducido en widgets de Elementor.
• Subtítulos de imágenes, efectos hover, títulos de acordeón dentro de módulos de Divi.
• Contenido en plantillas reutilizables, secciones globales, bloques guardados.
• Etiquetas CSS personalizadas o scripts inline dentro de widgets del constructor.

Esta es la razón por la que la documentación de los autores de temas sobre traducción es técnicamente correcta, pero a menudo inútil para los usuarios finales. Nuestra guía sobre cómo localizar cualquier tema de WordPress cubre el lado del tema a fondo; esta publicación continúa donde termina aquella.

Dos caminos para la localización de constructores de páginas

Hay exactamente dos formas de traducir el contenido de los constructores de páginas, y ambas tienen ventajas y desventajas reales.

Camino uno: Duplicar páginas por idioma

Utiliza un plugin multilingüe como WPML, Polylang o TranslatePress. Crea una copia de cada página por idioma. En Elementor, duplicas todo el diseño e intercambias el texto en cada copia. En Divi, copias el blob de shortcode y traduces el texto entre las etiquetas.

Pros: Cada idioma puede tener diseños creados de forma independiente (útil cuando el texto traducido es más largo y rompe tu diseño original). Compatibilidad total con el editor visual del constructor de páginas.

Contras: Escalado lineal: 5 idiomas significan 5 veces el trabajo de diseño. Cualquier cambio de diseño debe aplicarse 5 veces. La base de datos crece rápidamente. El almacenamiento en caché se vuelve más difícil.

Camino dos: Capa de traducción de cadenas

Algunos plugins (Polylang Pro, el módulo de String Translation de WPML, TranslatePress) pueden exponer cadenas individuales dentro de los widgets de los constructores de páginas para su traducción, y luego las intercambian en el momento de la renderización. Mantienes un solo diseño y el plugin traduce las cadenas en su lugar.

Pros: Fuente única de verdad para el diseño. Los cambios de diseño se aplican en todas partes.

Contras: Menor flexibilidad cuando la longitud del texto traducido cambia drásticamente. Algunos widgets (complejos con contenido anidado, listas dinámicas, formularios) no exponen las cadenas limpiamente. Costo de rendimiento por renderización.

Nuestra comparación de Polylang vs WPML vs TranslatePress cubre las ventajas y desventajas de cada plugin con más detalle.

Mantener el marcado de los widgets seguro durante la traducción

Sea cual sea el camino que elijas, el contenido traducido debe preservar el marcado estructural del constructor. Si tu traductor elimina un shortcode de Elementor, reemplaza un atributo de datos o reordena etiquetas anidadas, el widget se renderizará roto.

Zonas de peligro de Elementor

Los widgets de Elementor incrustan shortcodes y etiquetas dinámicas dentro de las configuraciones de texto. El campo de título de un widget de encabezado puede contener:

Welcome to <strong>our</strong> [user_name] store

Ese [user_name] es una etiqueta dinámica: Elementor lo reemplaza con el nombre del usuario conectado al renderizar. Si la traducción lo estropea, los usuarios verán "[user_name]" literalmente.

Los iconos dentro de los botones usan atributos de clase que no deben traducirse. El texto alternativo de la imagen se almacena por separado de la URL de la imagen. Los diseños de columnas usan configuraciones específicas de puntos de interrupción (title_mobile, title_tablet) que requieren un manejo individual.

Anidamiento de Shortcodes de Divi

Los shortcodes de Divi se anidan profundamente: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Un traductor que trate el blob como texto plano codificará los corchetes, traducirá los valores de los atributos o perderá las etiquetas de cierre. Cualquiera de estas acciones corrompe el módulo y Divi se niega a renderizarlo.

El patrón seguro

Para cualquiera de los dos constructores, la traducción debe:

1. Analizar el formato del widget (JSON para Elementor, AST de shortcode para Divi).
2. Recorrer el árbol identificando solo los campos de texto visibles para el usuario.
3. Bloquear shortcodes, etiquetas dinámicas, atributos HTML y CSS en línea.
4. Enviar solo las superficies de texto al traductor con contexto.
5. Reinsertar el texto traducido en la estructura original.

Este es el mismo principio que nuestro motor aplica a los archivos .po. La guía para traducir archivos .po sin romper variables de código detalla los patrones de %s y marcadores de posición; el equivalente en el constructor de páginas son los shortcodes y las etiquetas dinámicas.

Un flujo de trabajo híbrido que realmente funciona

Para la mayoría de los equipos, la respuesta práctica es combinar ambos enfoques.

Paso 1: Traducir la interfaz de usuario del tema y los plugins a través de archivos .po

Exporta archivos .pot de tu tema y plugins clave (WooCommerce, Yoast, UI del constructor de páginas). Tradúcelos una vez a través de un traductor en la nube que respete el formato .po. Suelta los archivos .mo compilados en wp-content/languages/. Esto maneja el 80% de las cadenas de interfaz de tu sitio con un mantenimiento continuo casi nulo.

Paso 2: Elige un plugin multilingüe para contenido dinámico

Instala Polylang o WPML para contenido de entradas, páginas y productos. Configura la estructura de URL (/es/, /fr/) y las etiquetas hreflang. Esto te proporciona la infraestructura para el contenido de la base de datos por idioma.

Paso 3: Duplica tus plantillas de constructor de páginas de forma selectiva

Para páginas de destino de alto tráfico, páginas de inicio y contenido de marketing fundamental, duplica la página en cada idioma y traduce los widgets manualmente. Obtienes control total del diseño donde realmente importa.

Paso 4: Usa la traducción de cadenas para bloques repetidos

Para secciones globales, plantillas reutilizables y CTA del pie de página que aparecen en cada página, usa la función de traducción de cadenas de tu plugin multilingüe. Actualiza en un solo lugar, intercambia al renderizar.

Paso 5: Realiza controles de calidad

El contenido traducido del constructor de páginas debe renderizarse sin cambios en el diseño. Idiomas más largos (alemán, ruso) rompen los anchos de los botones. Idiomas más cortos (chino, japonés) dejan espacios en blanco incómodos. Prueba cada plantilla por idioma antes de lanzarla.

Errores comunes y cómo evitarlos

Algunas trampas que aparecen en cada proyecto de localización de constructores de páginas.

El texto alternativo de las imágenes no se traduce

Tanto Elementor como Divi almacenan el texto alternativo por instancia de widget, no en la Biblioteca de Medios. Traducir la imagen original no traduce el texto alternativo en cada widget que la usa. Actualiza el texto alternativo en cada página duplicada.

Formularios y campos personalizados

Los formularios de contacto incrustados en los widgets de los constructores de páginas tienen sus propias cadenas (etiquetas, marcadores de posición, mensajes de validación). Consulta nuestra guía sobre cómo traducir Gravity Forms y Contact Form 7 para el lado de los formularios.

Widgets y plantillas globales

Los cambios en una plantilla global se propagan a cada página que la usa, incluidas las copias traducidas. Esto puede ser útil o catastrófico dependiendo de si deseas contenido compartido o separado. Decide explícitamente por plantilla.

Caducidad de la caché de traducción

Los constructores de páginas almacenan en caché el HTML renderizado de forma agresiva. Después de traducir, purga todas las cachés, incluida la caché CSS de Elementor (Elementor > Herramientas > Regenerar CSS) y la caché CSS estática de Divi.

Recopilando todo

Traducir un sitio construido con Elementor o Divi no es más difícil que traducir un tema estático, solo requiere el modelo mental correcto. Las cadenas de temas y plugins residen en archivos .po y se mueven a través de archivos .mo. El contenido del constructor de páginas reside en la base de datos y se mueve a través de plugins multilingües o duplicación manual. Confundir los dos caminos es la fuente más común de frustración del tipo "¿por qué no funcionan mis traducciones?".

El flujo de trabajo que funciona es aburrido: archivos .mo estáticos para todo lo que reside en el código, plugin multilingüe para el contenido de la página y curación manual para páginas de destino de alto valor. Ninguna herramienta única maneja los tres, y cualquiera que te prometa lo contrario te está vendiendo algo.

¿Listo para traducir tus archivos .po de temas y plugins sin romper el marcado de los widgets? Prueba SimplePoTranslate gratis - no se requiere tarjeta de crédito. Sube tu .po, descarga traducciones seguras, suéltalas en wp-content/languages/.