Drupal multiidioma: contenidos para mercados globales

Por qué Drupal lleva años jugando otra liga en multiidioma

He montado portales en WordPress, Sitecore, AEM y un par de CMS propietarios que mejor no nombrar. En casi todos, el soporte multiidioma era un parche: plugin, módulo de pago, puente entre sistemas que no se hablaban. Drupal eligió otro camino hace bastantes versiones, y la jugada está en que el multilingüismo es parte del núcleo desde la 8, no un añadido.

La diferencia se nota el día que abres un sitio a su tercer mercado sin pelearte con compatibilidades. Cuatro módulos del core cubren las cuatro capas que importan. Para una organización que opera con contenidos Drupal multiidioma para mercados internacionales, esa arquitectura nativa significa menos horas de mantenimiento y menos dolores de cabeza en auditoría.

Los cuatro módulos del subsistema multilingüe

El truco aquí está en entender que cada módulo cubre un trozo del problema, no en activarlos todos sin pensar.

Language: la base sobre la que se apoya el resto

Sin Language habilitado, los demás módulos no sirven. Se configura en /admin/config/regional/language/add y Drupal trae más de cien idiomas predefinidos con códigos ISO, dirección de escritura y reglas de plurales. La mayoría de equipos lo activa, añade dos o tres idiomas y se olvida. Hace bien.

Content Translation: traducir nodos, taxonomías y entidades

Aquí marcas qué tipos de contenido, vocabularios y bloques son traducibles. Cada traducción comparte ID de entidad con el original, así que la relación entre versiones queda guardada sin inventar tablas paralelas.

El detalle que más me gusta: decides campo por campo qué se traduce y qué se comparte. Una imagen de cabecera puede ser la misma en las cinco versiones, mientras que el cuerpo de texto se traduce. No duplicas archivos ni obligas al equipo editorial a subir la misma foto cinco veces.

Configuration Translation: localizar menús, vistas y bloques

Cubre todo lo que muestra texto y no es contenido editorial: etiquetas de menú, títulos de vistas, mensajes de formularios. Se gestiona desde /admin/config/regional/config-translation.

Es el módulo que más equipos olvidan. Lanzan el sitio en inglés y el menú principal sigue mostrando "Inicio" en lugar de "Home". Pequeño detalle, mala imagen.

Interface Translation: la interfaz de usuario en cada idioma

Las cadenas del CMS y de los módulos contribuidos se descargan automáticamente desde localize.drupal.org al añadir un idioma. Si una traducción oficial no encaja con el tono del sitio, la sobrescribes en /admin/config/regional/translate sin tocar código. Para un cliente del sector legal cambiamos "Enviar" por "Remitir" en todos los formularios desde ahí. Cinco minutos.

Cómo decide Drupal qué idioma mostrar

La negociación se configura por prioridad en /admin/config/regional/language/detection. La respuesta corta sobre qué método usar es que depende de quién visita y para qué, pero hay patrones que funcionan casi siempre.

URL: prefijo de ruta o dominio

El método más habitual cuando importa el SEO. Añades un prefijo (/es/, /en/, /fr/) o usas subdominios. El prefijo de ruta es lo más sencillo y lo más compatible con CDNs y proxies inversos. Si trabajas con dominios de país (.es, .co.uk, .de), la negociación por dominio asigna un idioma a cada hostname.

Navegador, cookie y sesión

La cabecera Accept-Language sirve como fallback razonable para el primer aterrizaje, pero no como método principal: Google indexa URLs, no preferencias de navegador. La cookie tiene sentido en intranets o áreas privadas donde el usuario vuelve autenticado y quiere que se respete su elección.

Orden que recomiendo

Para un sitio público orientado a SEO internacional, lo que mejor funciona casi siempre:

1. URL con prefijo de ruta como método principal.
2. Navegador como fallback en la primera visita.
3. Idioma por defecto como red de seguridad.

Hreflang y SEO multilingüe

Google usa las etiquetas hreflang para entender que /es/servicios y /en/services son la misma página en distinto idioma. Una implementación sucia provoca contenido duplicado en los resultados y reparte mal el tráfico.

Drupal genera estas etiquetas automáticamente cuando Content Translation está habilitado. En el <head> de cada página traducida aparecen las referencias a las demás versiones:

<link rel="alternate" hreflang="es" href="https://ejemplo.com/es/servicios" />
<link rel="alternate" hreflang="en" href="https://ejemplo.com/en/services" />
<link rel="alternate" hreflang="x-default" href="https://ejemplo.com/es/servicios" />

Para afinar, el módulo contribuido Hreflang permite ajustar el comportamiento por defecto y declarar el x-default de forma explícita, algo que casi siempre acabas necesitando.

Detalles SEO que conviene cuidar

• Sitemap multilingüe: Simple XML Sitemap genera un sitemap por idioma e incluye las etiquetas hreflang dentro del XML. Google recomienda esta doble señalización (HTML + sitemap) y reduce errores de indexación.
• Metatags por idioma: con Metatag, cada traducción lleva su propio meta title y meta description. No es lo mismo posicionar "consultoría tecnológica" en España que "technology consulting" en UK.
• Canonical y traducción: la canónica de cada versión apunta a sí misma, no al idioma por defecto. Drupal lo hace bien de serie, pero si has tocado Metatag conviene revisar.
• Slugs traducidos: los alias de Pathauto se configuran por idioma. /es/servicios-consultoria y /en/consulting-services pueden apuntar al mismo nodo.

Qué campos traducir y cuáles compartir

Una de las primeras decisiones al configurar un tipo de contenido traducible es qué campos viajan con la traducción y cuáles se quedan compartidos. Impacta directamente en el tiempo del equipo de traducción.

Lo que casi siempre se traduce

• Título y cuerpo de texto.
• Resúmenes, extractos, copy de cabecera.
• Meta description y meta title (vía Metatag).
• Texto alternativo de imágenes.
• Alias de URL.

Lo que conviene compartir

• Imágenes y archivos, salvo que el visual cambie por mercado (pasa en e-commerce con modelos diferentes).
• Fechas de publicación.
• Referencias a taxonomía cuando las categorías son las mismas.
• Campos numéricos: precios, códigos de producto, SKUs.
• Estado de publicación. Si despublicas en español, se despublica en todos los idiomas: evita huérfanos publicados en alemán cuando ya retiraste la pieza.

Separar bien estos dos grupos ahorra horas de traducción al mes.

Flujos de traducción con TMGMT

El módulo Translation Management Tool (TMGMT) convierte Drupal en una plataforma de gestión de traducciones de verdad. Añade flujo de trabajo entre el original y sus traducciones: estados (solicitada, en progreso, revisada, aceptada) y roles diferenciados. Para equipos pequeños puede parecer overkill al principio. En cuanto pasas de tres idiomas y dos traductores, imprescindible.

Fuentes de traducción

TMGMT acepta varias fuentes y se pueden combinar:

• Manual: el traductor trabaja directamente en la interfaz de Drupal.
• Servicios externos: conectores con DeepL, Google Translate, Microsoft Translator, Gengo. Generan una primera versión automática que el equipo editorial revisa. Con DeepL y un dominio técnico acotado, la pos-edición es razonablemente rápida.
• XLIFF: el formato estándar de la industria. Exportas el paquete, lo envías a una agencia que trabaja con Trados, MemoQ o Memsource, y reimportas el resultado.

Flujo de trabajo tipo

1. El editor crea o actualiza contenido en el idioma fuente.
2. Desde la pestaña "Translate", solicita traducción a los idiomas objetivo.
3. TMGMT genera un trabajo con los campos pendientes.
4. El traductor (humano o servicio) procesa el trabajo.
5. El revisor compara original y traducción campo a campo.
6. Al aceptar, la traducción se publica.

Lo que aporta este flujo es trazabilidad: quién tradujo qué, cuándo, qué cambió el revisor y por qué. El día que aparezca un texto problemático en alemán y haya que rastrear su origen, lo agradecerás.

Soporte RTL: árabe, hebreo y otros sistemas de escritura

Drupal gestiona de forma nativa la dirección derecha-a-izquierda. Al añadir un idioma RTL como árabe o hebreo, el sistema invierte el layout automáticamente si el tema lo soporta, carga hojas -rtl.css cuando existen y ajusta alineaciones de textos, tablas y formularios.

Los temas modernos con CSS Grid o Flexbox y propiedades lógicas (margin-inline-start en lugar de margin-left) cubren RTL casi sin duplicar reglas. Si apuntas a Oriente Medio o Norte de África, valida el tema con contenido real en árabe antes de avanzar. He visto proyectos descubrir a tres semanas del lanzamiento que los iconos quedan al revés y los formularios pierden el foco al escribir. Arreglarlo tarde sale caro.

Organizar el equipo de traducción sin morir en el intento

Con varios idiomas y varios traductores, la coordinación se vuelve un problema propio. Algunas prácticas que repito en cada proyecto:

Roles y permisos por idioma

Drupal permite crear roles como "Traductor francés" o "Revisor alemán" con permisos limitados a su idioma. El traductor de francés no toca las traducciones al portugués, lo que previene errores cruzados y conflictos de versiones.

Glosarios compartidos

Mantén un glosario centralizado con los términos técnicos del sector y su traducción aprobada para cada idioma. TMGMT puede importarlo y asistir al traductor mientras trabaja. En proyectos con vocabulario específico (legal, médico, fintech) es lo que separa una traducción profesional de una literal.

Priorización y métricas

No todo necesita traducción inmediata. Landing pages y fichas de producto primero, posts del blog después. Establece SLAs por tipo de contenido y comunica plazos al equipo de marketing. Las vistas de administración te dejan montar dashboards con el porcentaje traducido por idioma y los trabajos pendientes; ayudan a dimensionar el equipo y a detectar cuellos de botella antes de que se conviertan en incidencia.

Rendimiento y caché cuando el sitio crece

Cada idioma multiplica las variantes de caché: cinco idiomas son cinco entradas por página. Drupal lo gestiona con languages:language_content, pero hay que tenerlo presente para no pillarse los dedos:

• Varnish o CDN: configura la capa para variar por prefijo de idioma o por cookie. Si usas Cloudflare o Fastly, revisa que las reglas distinguen variantes lingüísticas. Un cliente sirvió durante semanas la versión inglesa a usuarios españoles porque la cache key no incluía el prefijo. Mal trago.
• Precalentamiento: el primer visitante de cada combinación idioma-página paga el coste de renderizado. El módulo Warmer recorre las URLs de todos los idiomas tras un despliegue.

Decidir bien antes de programar

Implementar contenidos Drupal multiidioma para mercados internacionales no se reduce a activar módulos y traducir cadenas. Hay decisiones de arquitectura (qué se comparte y qué se separa), de flujo editorial (quién traduce y revisa, en qué plazos) y de SEO (cómo posicionas cada versión en su mercado). Tomadas al principio, marcan los seis meses siguientes.

La ventaja de Drupal es que la maquinaria viene integrada y probada. No ensamblas piezas de cinco proveedores ni rezas por la compatibilidad entre plugins. El subsistema del core y módulos maduros como TMGMT cubren desde el blog bilingüe hasta el portal corporativo con quince idiomas.

Si tu organización planifica expansión y necesita una plataforma preparada para escalar en idiomas, ponte en contacto con Tangram Consulting para que analicemos juntos la arquitectura multiidioma que mejor se adapta a tu caso.