Internacionalización de Next.js: config i18n vs traducción automática (2026)
Next.js te ofrece dos caminos fundamentalmente distintos hacia una app multilingüe: enrutamiento i18n integrado combinado con una librería de traducción, y traducción automática basada en el DOM con una sola etiqueta de script. Esta guía explica ambos: qué hace cada uno realmente, qué cuesta y cuándo elegirlo.
Enrutamiento i18n de Next.js: qué te ofrece
Next.js incluye una capa de enrutamiento i18n integrada, configurada en next.config.ts. Se encarga de dos cosas: enrutamiento de URL (prefijos /fr/, /de/) y detección del idioma del navegador mediante la cabecera Accept-Language.
Lo que no hace: traducir ningún contenido. La configuración de enrutamiento i18n es pura infraestructura — establece la estructura de URL y la detección de idioma, y ahí se detiene. Para tener texto realmente traducido en tus componentes, añades una librería de traducción encima: next-intl, react-i18next o LinguiJS.
La configuración de enrutamiento por sí sola sí hace que visitar tuapp.com/fr/dashboard funcione como una URL distinta — útil para SEO y enlaces compartibles — pero sin una librería de traducción, la página sigue renderizándose en inglés.
El stack i18n completo para Next.js
Una configuración i18n completa de Next.js con next-intl implica las siguientes piezas:
- 1Bloque i18n en
next.config.tsque declara los idiomas soportados y el predeterminado. - 2Archivos de mensajes por idioma:
messages/en.json,messages/fr.json, etc., incluidos en el repositorio y actualizados con cada cadena de UI nueva. - 3Claves de mensaje con tipado seguro generadas a partir del archivo fuente en inglés para que TypeScript detecte claves faltantes o mal escritas en tiempo de compilación.
- 4Los Server Components cargan los mensajes mediante
getTranslations(); los Client Components se envuelven con<NextIntlClientProvider>. - 5Los idiomas RTL (árabe, hebreo) requieren trabajo de CSS aparte:
dir="rtl"en el elemento raíz, utilidades de propiedades lógicas y espejado de iconos.
Un bloque i18n mínimo de next.config.ts:
Y un messages/en.json correspondiente:
Cada clave en en.json debe duplicarse en cada uno de los demás archivos de idioma, traducirse y mantenerse sincronizada a medida que el producto evoluciona.
El coste a escala
El coste por cadena de envolver en t() es pequeño. El coste agregado se acumula rápido:
Acoplamiento entre contenido y código
Cada cadena de UI nueva requiere una clave nueva en el archivo fuente y la entrada correspondiente en cada archivo de idioma de destino. Una función lanzada el lunes significa que los archivos en francés y alemán deben actualizarse antes de que los usuarios franceses y alemanes vean algo distinto de una clave sin traducir.
Reglas de pluralización por idioma
El inglés tiene dos formas plurales. El árabe tiene seis. El polaco tiene cuatro con reglas complejas. El formato de mensajes ICU se encarga de esto, pero cada cadena plural requiere una definición aparte por idioma — el enfoque ingenuo de una sola cadena con un contador falla en muchos idiomas.
Interpolación para valores dinámicos
Cadenas como “Welcome, {name}!” o “You have {count}items” necesitan una sintaxis de interpolación que varía según la librería, requiere pruebas en todos los idiomas y puede producir un resultado gramaticalmente incorrecto en idiomas cuyo orden de palabras difiere del inglés.
Sobrecarga de TypeScript
Las claves con tipado seguro requieren un archivo de tipos generado a partir del archivo fuente en inglés. Este paso de generación debe ejecutarse en CI, añade tiempo de build y hace fallar el build si el archivo de idioma fuente tiene problemas estructurales — útil, pero no gratis.
RTL es un proyecto aparte
next-intl y react-i18next traducen texto; no invierten la dirección del layout. El soporte para árabe y hebreo requiere trabajo aparte: definir dir="rtl", auditar cada componente en busca de propiedades CSS físicas (margin-left → margin-inline-start), y probar el layout completo en modo RTL.
Cuándo la configuración i18n de Next.js es la decisión correcta
Hay contextos específicos donde el stack completo de librerías está justificado o es necesario:
Apps de código abierto con traducciones de la comunidad
Cuando las traducciones son aportadas por la comunidad en GitHub (como archivos JSON o PO), un formato de librería estándar es la interfaz correcta para los colaboradores. La traducción automática no encaja en este modelo.
Contenido regulado por cumplimiento normativo
Las industrias reguladas (legal, médica, financiera) pueden requerir que cada cadena de UI sea revisada y aprobada explícitamente. Una librería i18n convierte cada cadena en un artefacto discreto auditable con historial de versiones.
Formato intensivo de números, fechas y monedas
Los dashboards de analítica y las herramientas contables que formatean números, fechas y monedas en toda la UI se benefician de la integración con la API Intl sensible al idioma que FormatJS y next-intl ofrecen de fábrica.
Apps con capacidad offline
Las PWA con soporte offline completo necesitan archivos de traducción empaquetados en tiempo de build porque no pueden llamar a una API de traducción sin conexión. El i18n basado en librería es la única opción aquí.
Traducción automática: cómo funciona con Next.js
La alternativa es una etiqueta de script en tu app/layout.tsx raíz, colocada dentro del elemento <body>. Sin cambios en next.config.ts, sin configuración de enrutamiento de idiomas, sin archivos JSON.
El script usa un MutationObserver para vigilar el DOM después de que Next.js renderiza. Esto cubre:
- El HTML inicial de Server Components — el contenido de la página renderizado en el servidor y transmitido al navegador.
- Contenido posterior a la hidratación — cambios de estado de Client Components, datos de
useEffect, componentes cargados de forma diferida. - Navegación del lado del cliente — las transiciones de ruta de Next.js activan el observador para el nuevo contenido de página renderizado.
- Layout RTL —
document.documentElement.dirse define automáticamente al cambiar a árabe, hebreo u otro idioma RTL.
El enfoque funciona tanto con App Router como con Pages Router. El modelo de renderizado (servidor o cliente) es irrelevante — solo importa el resultado final en el DOM.
Comparación de configuración
La diferencia en complejidad de configuración es notable. Aquí está el camino de next-intl frente al de la etiqueta de script de Lingvit:
Configuración de next-intl (~8 archivos, ~200 líneas de configuración)
Configuración de Lingvit (1 línea)
Lo que la traducción automática no cubre
La traducción basada en el DOM tiene limitaciones reales que conviene entender antes de elegirla:
Cadenas de correo del lado del servidor
Los correos transaccionales construidos a partir de constantes de cadena en código de servidor nunca se renderizan en un DOM del navegador. Necesitan un manejo de traducción aparte — un sistema de plantillas de correo multilingüe o plantillas de correo por idioma.
Cadenas nunca renderizadas al DOM
Las cadenas fijas usadas solo para logging, las respuestas de API consumidas por clientes que no son navegadores, o el contenido procesado únicamente en el servidor no son visibles para el MutationObserver y no se traducirán.
Pluralización ICU compleja
Las aplicaciones que necesitan pluralización gramaticalmente correcta en árabe (seis formas plurales) o polaco (cuatro formas con excepciones) para valores contados dinámicamente requieren soporte de formato de mensajes ICU — que es una función de librería, no algo que la traducción a nivel de DOM maneje automáticamente.
Preguntas frecuentes
- ¿Funciona Lingvit con los Server Components de App Router?
- Sí. Los Server Components producen HTML que el navegador recibe e inserta en el DOM exactamente igual que cualquier otro HTML. El script de Lingvit detecta este contenido con normalidad mediante el MutationObserver. No se necesita ningún manejo especial para Server Components.
- ¿Puedo usar Lingvit junto con next-intl?
- Sí. Si tienes next-intl para algunas cadenas y quieres traducción automática para el resto, ambos pueden coexistir. Lingvit traducirá los nodos de texto que estén en el DOM en el momento del renderizado, incluidas las cadenas renderizadas por next-intl si aún no están traducidas en tus archivos de idioma.
- ¿Y el SEO? ¿La traducción automática crea URLs de idioma indexables?
- No, no como capacidad general de lanzamiento. Usa el enrutamiento de idiomas de Next.js y metadatos renderizados en el servidor para páginas de idioma indexables de forma independiente; Lingvit gestiona la traducción en tiempo de ejecución soportada en el navegador.
Guías relacionadas
Añade idiomas a tu app de Next.js
Funciona con App Router y Pages Router. No necesita cambios en next.config.