CMS multilingüe: gestionar el contenido entre idiomas

Un CMS multilingüe es un sistema de gestión de contenido construido para almacenar y servir el mismo sitio en más de un idioma, de modo que un editor publique una página en español y sus versiones en inglés y francés desde un solo sitio, y cada visitante reciba la correcta de forma automática.

Traducir las cadenas de la interfaz es la parte fácil. Eso lo hace cualquier framework. Lo que se rompe es el contenido: artículos, descripciones de producto, textos de página que deben existir en cada idioma, seguir enlazados como versiones unos de otros, y llegar bien a los buscadores. Un sistema de gestión de traducción mueve las palabras. El CMS decide cómo se modelan, se almacenan y se sirven, y esas son justo las decisiones que toma nuestra práctica de desarrollo de software multilingüe en cada proyecto. Fállalas y sumar un mercado se convierte en un proyecto en vez de una semana de trabajo.

Qué vuelve multilingüe a un CMS

Muchas herramientas dicen admitir varios idiomas y no significan lo mismo. La pregunta que hay que hacer es si el CMS trata una traducción como una versión enlazada de un contenido, o como una segunda página sin enlace que da la casualidad de decir lo mismo.

Una identidad, muchas versiones de idioma, todas conectadas. Esa conexión es lo que deja al sistema generar enlaces entre idiomas correctos, publicar una locale nueva sin duplicar el árbol de contenido, y decirle a un traductor exactamente qué piezas faltan o están caducadas. Guarda cada idioma como una copia desconectada y esos enlaces se vuelven una hoja de cálculo mantenida a mano, mal, hasta que nadie la mantiene.

Mira entonces cómo la herramienta separa el contenido traducible de los datos estructurales. Las palabras a un lado, la maqueta y las relaciones al otro. Mantener la estructura compartida y variar solo lo que depende del idioma es el mismo principio de internacionalización (i18n) que rige el código.

Campos localizados o árboles de sitio separados

Dos formas de estructurar el contenido multilingüe. La elección es cara de revertir: corresponde a la fase de arquitectura, no al después del lanzamiento.

Los campos localizados mantienen un solo elemento de contenido con un valor traducible por idioma para cada campo. Un producto, una identidad, con un título y una descripción que llevan cada uno un valor en español, inglés y francés. Añade un idioma y cada elemento gana un hueco nuevo, listo para rellenar. Las traducciones siguen estrechamente enlazadas, "¿qué falta en francés?" pasa a ser una consulta que el sistema responde, y el contenido estructuralmente idéntico entre mercados encaja solo. Es el modelo sobre el que funciona nuestro propio sitio.

Los árboles de sitio separados dan a cada idioma su propio sitio completo, copias paralelas enlazadas por arriba. Úsalos donde los mercados divergen de verdad, donde Alemania necesita páginas distintas, una estructura distinta y productos distintos de Francia, no solo traducidos. El coste es la deriva. Los árboles paralelos se desincronizan a menos que alguien los alinee de forma activa, y esa tarea rara vez tiene un nombre asignado.

Muchos proyectos con contenido estructuralmente similar entre idiomas pueden beneficiarse de campos localizados; cuando los mercados divergen, los árboles separados pueden ser más adecuados.

CMS headless o tradicional para el contenido multilingüe

Un CMS tradicional almacena el contenido y renderiza las páginas él mismo, plantilla incluida. Un CMS headless almacena el contenido y lo sirve vía una API, dejando la presentación a un front-end separado.

Para el multilingüe esa diferencia se vuelve práctica enseguida. Una sola API de contenido limpia puede alimentar un sitio web, una app móvil y una interfaz integrada en el producto, cada uno pidiendo la locale que necesita, así que la misma descripción de producto en español sirve a cada canal sin reintroducirla en ningún sitio. El front-end gestiona el enrutado de locale y el formato.

Las plataformas tradicionales ganan en tiempo de montaje y en ecosistema. Según W3Techs, WordPress se utiliza en el 40,7 % de todos los sitios web y en el 59,0 % de los sitios cuyo CMS se conoce, cifras que la propia fuente actualiza a diario. Construimos sobre un CMS headless porque nuestros clientes suelen necesitar contenido en más sitios que un solo sitio web. Para algunos sitios que solo necesitan una web, una pila a base de plugins puede resultar más económica y suficiente, pero la elección depende del alcance, los canales y los requisitos de mantenimiento.

Conectar el CMS a un flujo de traducción

Un CMS multilingüe sin ruta hacia los traductores es un conjunto de huecos de idioma vacíos. Alguien acaba pegando texto entre una hoja de cálculo y el panel de administración, y suele ser quien menos tiempo tiene para eso.

La conexión tiene que funcionar en ambos sentidos. El contenido creado o cambiado en el CMS sale hacia los traductores sin que nadie tenga que acordarse, y las traducciones terminadas vuelven al hueco de idioma correcto sin un paso de copiar y pegar. Las plataformas maduras lo exponen vía una API o un conector de traducción, para que un sistema de gestión de traducción pueda tirar del contenido origen, aplicar memoria de traducción y glosarios, y devolver el resultado.

Decide cómo una página recién publicada llega a un traductor antes de publicar la primera. Si lo dejas para después, ya hay una locale retrasada. Si un mercado dado necesita traducción completa o localización más profunda es una pregunta de presupuesto aparte, cubierta en localización o traducción.

Lograr hreflang y URL correctos desde el CMS

El último tramo de un CMS multilingüe es la búsqueda. Publicar contenido en varios idiomas no garantiza por sí solo que cada usuario vea la versión que prefiere; la estructura de URL y las señales internacionales ayudan a Google a interpretar las variantes.

El hreflang es la anotación HTML que dice a los buscadores qué versión de idioma de una página servir a cada usuario. Google recomienda utilizar URLs diferentes para cada versión lingüística y añadir anotaciones hreflang para ayudar a mostrar la versión adecuada en los resultados de búsqueda, y esas versiones localizadas pueden declararse mediante hreflang en HTML, encabezados HTTP o sitemaps: son métodos que Google considera equivalentes. El CMS ya conoce cada versión de idioma de cada página, así que puede generar esas anotaciones por programa, una señal recomendada por encima de mantenerlas a mano. Mantener las anotaciones hreflang manualmente puede aumentar el riesgo de incoherencias en cuanto se añade o quita una página, por lo que conviene automatizar su generación y validarla.

La estructura de las URL es la otra mitad. Google permite utilizar palabras localizadas en las URL y recomienda una URL distinta para cada versión lingüística. Slugs traducidos bajo una ruta clara por locale (/es/precios/, no /es/pricing/) señalan el idioma a usuarios y buscadores y se leen como nativos en lugar de pegados. Nuestro propio sitio genera su hreflang y sus alternativas de idioma a partir de las locales publicadas de cada página, nunca a mano, justo por la razón de arriba.

El flujo editorial cuando cada página tiene versiones

El contenido multilingüe multiplica el trabajo editorial. Un cambio publicado en el idioma origen se vuelve una tarea de traducción en cada otro, y sin manera de seguirlo, los idiomas se quedan obsoletos en silencio.

Tres funciones lo mantienen manejable: estado por locale, para ver qué versiones están publicadas, en borrador o caducadas; una señal cuando una página origen cambia y sus traducciones se quedan por detrás; y permisos para que un editor en francés trabaje en francés sin tocar el original en inglés.

"Publica y olvida" es el modo de fallo. Traducidas una vez en el lanzamiento, nunca actualizadas mientras el origen avanza, hasta que el sitio en francés describe un producto que el sitio en inglés dejó de vender hace dos años. Un CMS que hace aflorar "esta traducción va ahora por detrás de su origen" convierte ese deterioro silencioso en una tarea que alguien puede ver.

Preguntas frecuentes sobre el CMS multilingüe

¿Qué es un CMS multilingüe?

Un CMS multilingüe es un sistema de gestión de contenido que almacena y sirve el mismo sitio en varios idiomas, manteniendo cada traducción enlazada como versión de un solo contenido. Permite a los editores publicar y gestionar cada versión de idioma desde un sitio, y sirve la correcta a cada visitante de forma automática.

¿Cuál es la diferencia entre campos localizados y árboles de sitio separados?

Los campos localizados mantienen un elemento de contenido con un valor traducible por idioma para cada campo, ideal cuando el contenido se proyecta limpio entre mercados. Los árboles de sitio separados dan a cada idioma su sitio completo, mejor cuando los mercados necesitan estructuras y páginas de verdad distintas. Los campos localizados siguen enlazados; los árboles separados arriesgan deriva.

¿Necesito un CMS headless para un sitio multilingüe?

Usa headless cuando el contenido deba alimentar más de un canal (un sitio web, una app móvil, una interfaz integrada en el producto), porque una sola API de contenido por locale los sirve todos. Un CMS tradicional a base de plugins es más rápido y barato para un sitio que nunca será más que un sitio web. La elección es flexibilidad contra comodidad.

¿Cómo gestiona un CMS multilingüe el hreflang?

Uno bueno lo genera de forma automática, porque ya conoce cada versión de idioma de cada página. Google trata ese enfoque como una señal recomendada, junto con encabezados HTTP o sitemaps; mantener el hreflang a mano, en cambio, aumenta el riesgo de errores en cuanto se añade o quita una página. También debería producir slugs de URL traducidos bajo una ruta clara por locale.

¿Cómo entran las traducciones en un CMS multilingüe?

Vía una conexión a un flujo de traducción: el contenido origen sale de forma automática hacia los traductores, y las traducciones terminadas vuelven al hueco de idioma correcto sin copiar y pegar a mano. Las plataformas maduras lo exponen vía una API o un conector, dejando a un sistema de gestión de traducción aplicar memoria de traducción y glosarios en medio.

Construye un sistema de contenido que hable el idioma de cada mercado

Cuéntanos en cuántos idiomas debe vivir tu contenido, y dónde tiene que aparecer (sitio web, app, integrado en el producto). Cerramos el modelo de contenido, la conexión de traducción y la configuración de hreflang como un solo desarrollo a precio cerrado, entregado en semanas, para que ninguna locale se quede atrás respecto a su origen. Se ve en marcha en nuestro desarrollo de ecommerce a medida.

Pide un presupuesto cerrado →