Drupal multilingüe para una web corporativa en España

Una empresa española rara vez opera en un único idioma. Una consultora de Bilbao atiende a clientes en euskera y castellano; una marca de moda de Barcelona quiere presencia en catalán y, a la vez, vender en inglés a mercados europeos; una bodega de la Ribera del Duero exporta a Alemania y necesita su catálogo en alemán. La pregunta no es si la web debe ser multilingüe, sino cómo construirla para que no se convierta en un quebradero de cabeza de mantenimiento dentro de dos años.

Drupal resuelve este escenario mejor que casi cualquier otro CMS porque el multilingüe forma parte de su núcleo desde la versión 8, no es un parche añadido. En este artículo desgranamos cómo funciona, qué módulos intervienen, cómo se diseña la arquitectura de idiomas y qué hace falta para que el SEO internacional no se rompa cuando Google indexa cinco versiones de la misma página.

El contexto real del multilingüe en España

España es uno de los mercados europeos donde el multilingüe deja de ser una opción cosmética para volverse una exigencia legal y comercial. Cuatro lenguas cooficiales (catalán, euskera, gallego y valenciano, además del castellano) marcan la realidad de comunidades autónomas con administraciones, clientes y usuarios que esperan ser atendidos en su lengua. Una web institucional en Galicia o en el País Vasco que solo ofrezca castellano transmite una desconexión evidente con su entorno.

A esto se suma la dimensión exportadora. Según los datos del ICEX, el número de empresas exportadoras regulares en España supera las 50.000, y para casi todas ellas el inglés es el idioma puente con sus mercados de destino. Una pyme industrial valenciana que vende maquinaria a Francia, Italia y Polonia necesita, como mínimo, castellano e inglés, y con frecuencia añade el idioma de su principal mercado europeo.

El resultado es una matriz de combinaciones habituales:

• Castellano + lengua cooficial (catalán, euskera o gallego) para el mercado interno.
• Castellano + inglés para internacionalización básica.
• Castellano + cooficial + inglés + uno o dos idiomas de exportación para empresas con vocación europea.

Diseñar la web pensando en esa matriz desde el principio evita rehacer la arquitectura cuando llega el cuarto idioma. Y ahí es donde Drupal saca ventaja.

Por qué Drupal destaca frente a WordPress

La diferencia de fondo es arquitectónica. En WordPress, el multilingüe depende de plugins de terceros como WPML o Polylang: capas que se montan sobre un sistema que originalmente pensaba en un solo idioma. Funcionan, pero arrastran limitaciones, costes de licencia, conflictos con otros plugins y un riesgo real de quedarse sin soporte.

Drupal integra la traducción en el modelo de datos. Cada entidad (un nodo, un término de taxonomía, un bloque, un menú) es traducible de forma nativa, campo a campo. No existe una tabla paralela de "traducciones" pegada con cinta adhesiva: el idioma es un atributo de primera clase dentro del propio sistema de entidades. Esto tiene consecuencias prácticas concretas:

• La traducción de la interfaz de administración y de cualquier módulo contribuido viene de un repositorio comunitario centralizado, ya traducido a docenas de idiomas, incluidas las lenguas cooficiales españolas.
• La configuración del sitio (nombres de campos, vistas, formularios) se traduce con el mismo motor, no con un apaño.
• La negociación de idioma forma parte del enrutamiento del núcleo, así que no hay que reescribir URLs a mano.

Para una web corporativa que va a crecer, esa solidez de base es la que marca la diferencia entre un proyecto mantenible y uno que se degrada con cada actualización.

Los cuatro módulos del core de internacionalización

Drupal organiza el multilingüe en cuatro módulos que vienen en el núcleo y que se activan según lo que necesites traducir. Cada uno cubre una capa distinta del sistema.

Módulo del core	Qué traduce / función
Language	Define los idiomas del sitio, su orden y la negociación. Es la base: sin él no hay multilingüe.
Interface Translation	Traduce las cadenas de la interfaz: textos del núcleo, de módulos y de temas (botones, etiquetas, mensajes).
Content Translation	Permite traducir el contenido editorial: nodos, términos de taxonomía, bloques personalizados, comentarios.
Configuration Translation	Traduce los elementos de configuración: nombres de vistas, formularios, menús, textos de campos.

Conviene entender qué hace cada uno antes de activarlos todos por inercia.

Language e Interface Translation

El módulo Language es el punto de partida. Aquí declaras los idiomas del sitio (por ejemplo, castellano como predeterminado, más catalán e inglés), defines su prioridad y configuras cómo se detecta el idioma de cada visita. Sin este módulo activo, el resto no tiene sentido.

Interface Translation se encarga de todo el texto que no es contenido editorial: el "Leer más", el "Enviar", los mensajes de error, las etiquetas del panel de administración. Drupal descarga estas traducciones automáticamente desde su servidor comunitario (localize.drupal.org), de modo que activar el inglés o el catalán trae ya traducida la mayor parte de la interfaz. Para una empresa esto significa que el back office se ve en el idioma del editor sin trabajo manual, y que las cadenas propias del sitio se pueden ajustar una a una cuando hace falta matizar un término.

Content Translation y Configuration Translation

Content Translation es el módulo que toca a diario el equipo editorial. Activa la traducción campo a campo de las entidades de contenido. Una página "Quiénes somos" tiene su versión en castellano, su versión en catalán y su versión en inglés, todas vinculadas a la misma entidad pero con textos independientes. Puedes decidir qué campos son traducibles y cuáles se comparten: una imagen corporativa puede ser común a todos los idiomas mientras que el titular y el cuerpo cambian.

Configuration Translation cubre la zona que muchos proyectos olvidan hasta que un usuario se queja. Los nombres de los menús, las etiquetas de un formulario de contacto, el título de una vista que lista noticias, el texto de ayuda de un campo: todo eso es configuración, no contenido, y necesita su propia traducción. Sin este módulo, un sitio puede tener el contenido perfectamente traducido pero mostrar el menú principal en castellano sobre una página en inglés.

Arquitectura de idiomas: idioma por defecto y negociación

Toda web multilingüe en Drupal parte de un idioma por defecto. En el caso español lo habitual es el castellano, salvo proyectos institucionales de una comunidad concreta donde la lengua cooficial puede llevar la prioridad. Ese idioma por defecto es el que se sirve cuando no hay otra señal que indique las preferencias del visitante.

Lo interesante es la negociación de idioma: el mecanismo por el que Drupal decide en qué idioma mostrar cada página. El núcleo ofrece varios métodos y permite ordenarlos por prioridad. Los dos que importan para una web corporativa son la detección por URL y la asignación por dominio.

Detección por URL: prefijo o dominio

La opción más extendida es el prefijo de ruta. Cada idioma cuelga de un segmento en la URL:

• ejemplo.es/es/servicios
• ejemplo.es/ca/serveis
• ejemplo.es/en/services

El castellano, como idioma por defecto, puede ir sin prefijo o con él, según se configure. Este modelo es sencillo de gestionar, no requiere infraestructura adicional y concentra toda la autoridad de dominio en un único host, lo que ayuda al SEO.

La alternativa es la negociación por dominio, en la que cada idioma vive en un dominio o subdominio distinto:

• ejemplo.es para castellano
• ejemplo.cat para catalán
• ejemplo.com para inglés

Este enfoque tiene sentido cuando hay marcas o mercados claramente separados, o cuando el negocio quiere segmentar la analítica y la gestión por país. A cambio, exige administrar varios certificados, varias entradas DNS y reparte la autoridad SEO entre dominios. Para la mayoría de las webs corporativas españolas, el prefijo de ruta es la opción más razonable; el dominio se reserva para casos con una estrategia internacional muy marcada.

Detección por sesión, usuario y navegador

Drupal también puede negociar el idioma por la preferencia guardada en la cuenta de usuario, por la cabecera del navegador o por una selección manual almacenada en sesión. Estos métodos se usan como complemento, normalmente con prioridad inferior a la URL, para no romper el principio de que cada idioma tenga su dirección estable e indexable. Una URL que cambia de idioma según el navegador es un problema para el buscador y para cualquiera que comparta el enlace.

Traducir contenido, interfaz y configuración: tres planos distintos

Una confusión habitual en los proyectos es tratar toda la traducción como si fuera lo mismo. No lo es, y separar los tres planos ahorra muchos errores.

• Traducción de contenido: es lo que escribe el equipo editorial. Páginas, artículos, fichas de producto, bloques con texto. Cambia con frecuencia y la gestiona el cliente.
• Traducción de interfaz: los textos del sistema y del tema. Se traduce mayoritariamente solo gracias al repositorio comunitario y solo se toca para ajustar cadenas concretas del proyecto.
• Traducción de configuración: la estructura del sitio. Menús, vistas, formularios, etiquetas de campo. Se traduce una vez al construir el sitio y se revisa cuando se añade una funcionalidad nueva.

Diferenciarlos permite asignar responsabilidades claras: el desarrollador deja lista la interfaz y la configuración durante la implantación, y el cliente se ocupa del contenido en su día a día sin tropezar con textos del sistema que aparecen en el idioma equivocado.

SEO internacional: que Google entienda tu web multilingüe

Aquí es donde un multilingüe mal montado destruye posicionamiento. Tener la misma página en tres idiomas puede generar problemas de contenido duplicado o de versiones compitiendo entre sí si no se le dan al buscador las señales correctas.

Etiquetas hreflang y URLs por idioma

La pieza central es la etiqueta hreflang. Indica a Google qué versión de una página corresponde a cada idioma y región, de modo que muestre la adecuada según el usuario. Drupal puede generar estas etiquetas de forma automática para cada nodo traducido, enlazando todas las versiones entre sí. Un ejemplo de marcado en una página con castellano, catalán e inglés:

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

El valor x-default señala la versión que se sirve cuando ninguna coincide con la preferencia del usuario. Para el mercado español tiene sentido distinguir es-ES de un genérico, y conviene usar el código de región en las lenguas cooficiales (ca-ES, gl-ES, eu-ES) para que el buscador entienda el ámbito.

Que cada idioma tenga su propia URL estable (mediante el prefijo de ruta) es la base sobre la que se apoya todo lo demás. Sin URLs diferenciadas no hay hreflang posible.

Sitemap por idioma y contenido duplicado

El sitemap XML debe incluir todas las versiones idiomáticas con sus anotaciones hreflang correspondientes. El módulo Simple XML Sitemap, muy habitual en proyectos Drupal, genera esta estructura de forma nativa, listando cada URL con sus alternativas de idioma. Esto refuerza el mensaje que ya envían las etiquetas en el HTML.

Para evitar el contenido duplicado, la regla es no dejar páginas sin traducir accesibles bajo un prefijo de idioma con el texto del idioma por defecto. Si una página solo existe en castellano, lo correcto es no exponerla bajo /en/ con el mismo contenido. Drupal permite controlar qué pasa cuando falta una traducción, y la decisión debe ser consciente: ocultar la versión inexistente o redirigir, nunca duplicar.

Flujos de trabajo de traducción

Traducir diez páginas a mano es viable. Traducir un catálogo de doscientos productos a cuatro idiomas, con actualizaciones mensuales, necesita un proceso.

TMGMT y la traducción gestionada

El módulo TMGMT (Translation Management Tool) industrializa el flujo. Permite crear "trabajos" de traducción, enviarlos a un proveedor y recibir el resultado de vuelta dentro del propio Drupal, sin exportar e importar archivos a mano. TMGMT se conecta con conectores de servicios profesionales de traducción y con motores de traducción automática, y mantiene el estado de cada pieza (pendiente, en proceso, revisada, publicada).

Para una empresa con volumen alto de contenido, este flujo evita el caos de las hojas de cálculo y los correos: el editor lanza el contenido nuevo a traducir, la agencia trabaja sobre la plataforma y la versión vuelve lista para revisar.

Traducción humana frente a automática

La traducción automática (DeepL, motores neuronales integrables vía TMGMT) ha mejorado mucho y resuelve bien borradores y contenido de baja exposición. Pero para la página de inicio, los servicios principales y los mensajes de marca de una web corporativa, la traducción humana profesional sigue siendo la opción que protege la imagen de la empresa. El enfoque sensato es híbrido: traducción automática como primer paso y revisión humana sobre lo que importa. En las lenguas cooficiales conviene contar con traductores nativos: el catalán de un buscador automático no siempre transmite la cercanía que un cliente catalán espera.

Rendimiento, caché y mantenimiento

Servir varios idiomas multiplica el número de páginas, así que la caché importa todavía más. Drupal cachea por idioma: cada versión idiomática se almacena de forma independiente en el cache de página y en el render cache, de modo que un visitante en inglés no recibe fragmentos en castellano. Con una capa de caché de página completa (Internal Page Cache para anónimos, o un proxy inverso como Varnish por delante), el coste de servir tres o cuatro idiomas es marginal frente al de uno solo, porque cada combinación se calcula una vez y se reutiliza.

El mantenimiento tiene un punto que conviene vigilar: la sincronización entre versiones. Cuando se actualiza la página en castellano, las traducciones quedan desfasadas hasta que alguien las revisa. Drupal marca las traducciones como "pendientes de actualizar" cuando cambia el original, lo que ayuda a no olvidarlas. Establecer un protocolo claro (quién actualiza qué y en qué plazo) es tan importante como la tecnología. Una web multilingüe descuidada, con el inglés tres versiones por detrás del castellano, da peor imagen que una web monolingüe bien cuidada.

La gestión de las traducciones de interfaz también requiere atención al actualizar módulos: las cadenas nuevas se descargan del repositorio comunitario, pero las personalizadas del proyecto hay que revisarlas tras cada cambio relevante.

Planificar antes de construir

El error más caro en un proyecto multilingüe es decidir los idiomas a mitad de camino. Activar un segundo idioma sobre una web Drupal ya en producción es perfectamente posible, pero conlleva revisar qué campos son traducibles, regenerar el sitemap, configurar el hreflang y traducir la configuración existente. Es más trabajo que haberlo previsto desde el modelado de contenido.

Por eso la conversación correcta antes de empezar es sencilla: qué idiomas hoy, qué idiomas en dos años, qué mercados de exportación están en el horizonte, qué partes del sitio se traducen siempre y cuáles se comparten. Con esas respuestas, la arquitectura de Drupal se configura una vez y escala sin sobresaltos.

Si tu empresa necesita una web corporativa multilingüe en Drupal pensada para crecer, en Tangram Consulting podemos ayudarte a diseñarla y construirla con criterio. Cuéntanos tu proyecto y te asesoramos sin compromiso.