Hace un tiempo, en este mismo blog, hablé de las mejores prácticas para diseñar sitios web multilingües: investigación de mercado, arquitectura de URLs, hreflang, localización cultural. Era un artículo correcto, pero puramente conceptual. No decía una palabra sobre cómo se implementa nada de eso en un generador estático real.
Voy a ser honesto antes de empezar: esta web que estás leyendo ahora mismo es monolingüe. Todo el contenido está en español y no hay ni una línea de configuración de idiomas en el _config.ts de Lume. Así que este no es el relato de una migración que he hecho, como sí lo fue el cambio de Eleventy a Lume. Es el planteamiento honesto de cómo lo resolvería si un proyecto lo necesitara, con las herramientas que uso hoy.
Cómo se resuelve i18n en un generador estático
La primera diferencia con un CMS tradicional es que aquí no hay una tabla traducciones en una base de datos. En Lume, como en la mayoría de generadores estáticos modernos, cada idioma es un conjunto de archivos que conviven en el mismo repositorio.
El patrón habitual es nombrar los archivos con el código de idioma como parte del nombre: contacto.es.md y contacto.en.md, por ejemplo, comparten un identificador común y se tratan como versiones del mismo contenido en idiomas distintos. Lume trae un plugin de multilenguaje pensado exactamente para esto: detecta esos pares de archivos, genera una página por cada uno en su ruta correspondiente (/es/contacto/, /en/contact/) y, lo más útil, construye automáticamente la lista de "alternates" de cada página: las URLs de las versiones en otros idiomas de ese mismo contenido.
Esa lista de alternates es la pieza que, en el artículo de 2023, describía como "las etiquetas hreflang". Aquí no las escribes a mano página por página: el plugin las calcula, y en la plantilla solo tienes que recorrer ese array para generar los <link rel="alternate" hreflang="..."> en el <head>. Lo mismo aplica al sitemap: en lugar de mantener un sitemap por idioma a mano, lo generas recorriendo todas las páginas y añadiendo sus alternates.
Lo que cambia respecto a un CMS tradicional es dónde vive la complejidad. En WordPress con un plugin de traducción, la complejidad vive en tiempo de ejecución: cada petición tiene que averiguar en qué idioma responder. En un generador estático, la complejidad se resuelve una vez, en el build. El visitante nunca paga ese coste: recibe HTML ya generado en su idioma, servido desde una CDN, exactamente igual de rápido que la versión monolingüe.
La alternativa ligera que casi nadie plantea
Aquí viene la parte que normalmente no se dice en los artículos de estrategia sobre multiidioma: la mayoría de las pymes que preguntan "¿debería traducir mi web?" no necesitan una arquitectura i18n completa.
Traducir un sitio entero —cada entrada de blog, cada página de servicio, cada aviso legal— tiene un coste de mantenimiento que crece con cada publicación nueva. Cada vez que actualizas un texto en español, tienes una versión en otro idioma que se queda desactualizada hasta que alguien se acuerde de tocarla también. Con el tiempo, casi todos los sitios "multiidioma" de pymes pequeñas acaban teniendo una versión en inglés que quedó congelada hace dos años.
La alternativa que suele funcionar mejor para un negocio pequeño con clientes ocasionales en otro idioma es traducir un subconjunto deliberado: la home, la página de contacto y quizá una o dos páginas de servicio clave. No todo el blog. No los avisos legales, que en la mayoría de los casos ni siquiera aplican igual en otra jurisdicción. Ese subconjunto se mantiene con esfuerzo razonable y cubre el propósito real: que alguien que no lee español pueda entender qué ofreces y cómo contactarte.
Lo que hay que evitar activamente es la traducción automática servida en el navegador —esos widgets que traducen el DOM al vuelo—. No generan URLs indexables por idioma, no mejoran el SEO internacional, y la calidad de la traducción suele ser lo bastante mala como para transmitir justo lo contrario de profesionalidad. Si vas a traducir, que sea contenido real, revisado por alguien, y con su propia URL.
Las trampas técnicas reales
Como en toda migración o feature nueva, hay detalles que solo se descubren montándolo:
Los slugs también se traducen, y eso rompe cosas si no lo planeas. Una URL en inglés no debería ser una traducción literal de la URL en español (/es/como-funciona-un-despliegue-web-moderno/ no debería convertirse en /en/how-funciona-a-despliegue-web-moderno/). Cada idioma necesita su propio slug, pensado en ese idioma, y el plugin de multilenguaje necesita saber que ambos archivos son la misma página pese a tener URLs distintas.
El contenido duplicado sin hreflang es un problema de SEO real, no teórico. Si tienes contenido muy similar en dos idiomas y no declaras la relación entre ambas versiones, los buscadores pueden interpretar una como duplicado de la otra y penalizar el posicionamiento de ambas. El hreflang no es un adorno: es la forma en que le dices a Google "esto no es contenido repetido, son versiones para audiencias distintas".
Los formatos de fecha, moneda y número no son solo una cuestión estética. 04/07/2026 significa el 4 de julio en formato español y el 7 de abril en formato estadounidense. Si tu sitio muestra fechas de publicación, precios o cualquier dato numérico, ese formato tiene que adaptarse al idioma de cada versión, no quedarse fijo en el formato con el que escribiste el código originalmente.
El selector de idioma tiene que enlazar a la página equivalente, no a la home del otro idioma. Es un detalle pequeño pero que se nota: si alguien está leyendo un artículo concreto y cambia de idioma, debería aterrizar en la traducción de ese artículo, no en la portada del sitio en el otro idioma. Es exactamente para esto para lo que sirve la lista de alternates que genera el plugin.
¿Vale la pena para ti?
Depende, y la respuesta honesta pasa por hacerte una pregunta antes que ninguna técnica: ¿cuánta gente que no lee español visita realmente tu web, y qué necesitan encontrar cuando llegan?
Si tienes clientes internacionales de verdad, o vendes un producto que puede interesar fuera de España, invertir en una arquitectura i18n completa —con el plugin, los alternates, el sitemap multiidioma— tiene sentido y no es especialmente costoso de mantener una vez montado, precisamente porque el generador estático resuelve la complejidad en el build y no en cada visita.
Si lo que tienes es una intuición de que "estaría bien tener la web en inglés también", probablemente te sirve mejor el subconjunto deliberado de páginas clave que un despliegue completo. Vas a mantenerlo mejor, va a costar menos, y va a transmitir más profesionalidad que un blog entero traducido a medias y desactualizado.
Si algún día un proyecto de Idenautas necesita de verdad ser multiidioma, ya sé por dónde empezaría: por el plugin de multilenguaje de Lume, por un subconjunto de contenido bien pensado antes que por la traducción íntegra, y por comprobar cada alternate a mano antes de dar nada por bueno. Que sea la teoría y no la práctica no le quita seriedad al planteamiento; simplemente significa que, cuando llegue el caso real, ya sabré qué preguntas hacer primero.
