- React
- i18n
- Guía
React i18n vs traducción automática: ¿qué enfoque es el adecuado para tu app? (2026)
10 min de lectura
Los equipos de React tienen dos caminos fundamentalmente distintos hacia el soporte multilingüe: librerías de i18n que instrumentan tu código fuente, y traducción automática que funciona a nivel del DOM. Ninguno es universalmente mejor. Esta guía traza cuándo tiene sentido cada enfoque.
El enfoque tradicional de i18n en React
Las librerías estándar para internacionalizar React son react-i18next, react-intl (parte de FormatJS) y LinguiJS. A pesar de sus diferencias, comparten el mismo flujo de trabajo básico:
- Sustituir cada cadena de tus componentes por una llamada a
t():<p>Submit</p>pasa a ser<p>{t('form.submit')}</p>. - Crear un archivo de traducción JSON por locale:
en.json,fr.json,de.json, etc. Cada clave mapea a una cadena traducida. - Gestionar la pluralización por idioma: las reglas de plural en polaco o árabe son considerablemente más complejas que en inglés.
- Añadir definiciones de claves con tipado seguro para que TypeScript detecte en tiempo de compilación las claves de traducción que faltan o están mal escritas (mediante
typescript-i18no el soporte de tipado propio de i18next). - Configurar el build o el runtime para cargar el paquete de locale correcto, y montar un proceso para que las cadenas nuevas añadidas durante el desarrollo aparezcan automáticamente en el flujo de traducción.
En un proyecto con App Router de Next.js, añade next-intl o next-i18next para el enrutamiento por locale y las traducciones renderizadas en SSR.
El coste real de las librerías de i18n
El coste por unidad de cada cadena envuelta en t() es pequeño. El coste agregado es considerable:
Migración inicial: 2–5 días de ingeniería
Para una aplicación React existente con un año o más de desarrollo de interfaz, auditar cada componente en busca de cadenas fijas, envolverlas en t(), crear la estructura inicial de namespaces de traducción y configurar el provider de i18n es un proyecto de varios días, incluso antes de traducir ninguna cadena.
Mantenimiento continuo por cada cadena nueva
Cada cadena nueva de interfaz requiere: una definición de clave, una entrada en inglés en el archivo de locale de origen y una actualización en cada archivo de idioma de destino. Si la cadena se añade en un PR el martes, los archivos de traducción para francés y alemán tienen que publicarse antes de que la funcionalidad sea visible para esos usuarios.
Gestión de contexto y namespaces
A medida que los archivos de traducción crecen hasta cientos o miles de claves, la gestión de namespaces se convierte en una disciplina propia. Las claves necesitan prefijos, los namespaces necesitan estrategias de carga, y el riesgo de colisión de claves o de acumulación de claves sin usar aumenta con el tiempo.
RTL requiere trabajo de maquetación aparte
Las librerías de i18n gestionan la traducción de cadenas, pero no la dirección del diseño. Dar soporte a árabe o hebreo requiere trabajo de CSS adicional sobre la configuración de la librería: propiedades lógicas, reflejo de iconos y pruebas con dir="rtl".
Cuándo las librerías de i18n son la opción correcta
Hay situaciones concretas en las que el coste adicional de una librería está justificado o incluso es obligatorio:
- Proyectos de código abierto Cuando los archivos de traducción son aportados por la comunidad en GitHub, un formato de librería de i18n estándar (JSON o archivos PO) es la interfaz adecuada para los colaboradores. La traducción automática no funciona para proyectos que quieren contribuciones humanas de la comunidad.
- Revisión de cadenas por cumplimiento normativo Los sectores regulados (legal, médico, financiero) pueden exigir que cada cadena de interfaz se revise y apruebe explícitamente antes de publicarse. Una librería de i18n hace esto auditable: cada cadena es un artefacto discreto con historial de versiones.
- Formato intensivo de números, fechas y moneda Si tu app muestra números, fechas e importes de moneda formateados por toda la interfaz (por ejemplo, un panel de analítica o una herramienta de contabilidad), librerías como FormatJS ofrecen formato con reconocimiento de locale a través de la API
Intlque la traducción basada en el DOM no ofrece. - Aplicaciones offline-first Las apps que deben funcionar sin conexión (PWA con soporte offline completo) necesitan archivos de traducción incluidos en el paquete, porque no pueden llamar a una API de traducción cuando no hay red. Las librerías de i18n empaquetan las traducciones en tiempo de build.
Cuándo la traducción automática es mejor
El enfoque basado en el DOM se adapta mejor a otro conjunto de limitaciones:
- Añadir localización a una app existente sin reescribirla El caso más sólido para la traducción automática. Si tienes una aplicación React en funcionamiento y quieres añadir cinco idiomas sin tocar 200 componentes, la traducción basada en el DOM es la única opción práctica.
- Equipos sin un ingeniero de i18n dedicado Configurar y mantener bien un sistema de i18n basado en librerías requiere experiencia en la librería, en el flujo de traducción y en los casos límite de pluralización. Un enfoque de etiqueta de script no requiere nada de eso.
- Interfaz que evoluciona rápidamente Cuando el producto publica interfaz nueva cada semana, mantener la paridad de los archivos de traducción es una fricción constante. La traducción automática gestiona las cadenas nuevas en la primera visita a la página, sin pasos adicionales.
- La velocidad de salida al mercado importa más que la perfección Una traducción automática de alta calidad en producción en una semana supera a una integración perfecta con una librería de i18n que tarda tres meses en publicarse. Para muchos mercados internacionales, la diferencia de calidad de traducción no es el factor decisivo: la presencia sí lo es.
Cómo funciona la traducción basada en el DOM en React
Lingvit usa un enfoque basado en MutationObserver que se integra de forma natural con el modelo de renderizado de React:
- En la carga inicial, el script recorre todos los nodos de texto existentes en el DOM y los envía a traducir. El DOM virtual y el mecanismo de renderizado de React son invisibles para este proceso: solo importa el HTML final renderizado.
- Un MutationObserver vigila las mutaciones posteriores del DOM: nodos nuevos añadidos por cambios de estado de React, transiciones de ruta (navegación del lado del cliente en Next.js), componentes con carga diferida y contenido dinámico procedente de respuestas de API.
- Las traducciones almacenadas se obtienen a través de la API. Cambiar de idioma no requiere recargar la página porque las cadenas traducidas se sustituyen en el sitio.
- Para los idiomas RTL,
document.documentElement.dirse configura automáticamente, invirtiendo cualquier propiedad lógica de CSS en tu diseño.
Comparación de configuración
| Paso | Librería de i18n | Lingvit |
|---|---|---|
| Instalación | npm install react-i18next i18next | 1 etiqueta de script |
| Configuración | Instancia de i18n + provider + configuración de namespaces (~100 líneas) | Panel: elige idiomas |
| Instrumentar cadenas | Envolver cada cadena en t() en todos los componentes | Sin cambios de código |
| Archivos de traducción | Archivo JSON por idioma, mantenido en el repo | Generado automáticamente, almacenado en Lingvit |
| Seguridad de tipos | Opcional mediante typescript-i18n (~50 líneas de configuración) | No aplica |
| Cadena de UI nueva | Añadir clave + actualizar todos los archivos de locale | Traducida en la primera visita a la página |
| Soporte RTL | Requiere trabajo de CSS aparte | Automático para árabe, hebreo, persa y urdu |
Desplázate horizontalmente para ver todas las columnas.
Preguntas frecuentes
¿Funciona Lingvit con el modo concurrente de React 18/19 y el SSR en streaming?
Sí. El enfoque basado en MutationObserver es independiente de la versión de React: observa la salida final del DOM sin importar cómo la renderice React. El modo concurrente, Suspense y el SSR en streaming acaban produciendo nodos del DOM, y el observer los gestiona con normalidad. No hay ninguna API específica de versión de React implicada.
¿Funciona con el App Router de Next.js y los server components?
Sí. Los Server Components generan HTML que se envía al navegador y se inserta en el DOM igual que cualquier otro HTML. La etiqueta de script en tu layout.tsx raíz recoge este contenido con normalidad. La navegación del lado del cliente gestionada por Next.js activa el MutationObserver para el contenido recién renderizado.
¿Y los traductores profesionales? ¿Pueden seguir revisando las cadenas?
Sí. El panel de Lingvit ofrece un explorador de traducciones donde los traductores profesionales pueden revisar, editar y aprobar cada cadena por idioma. Las sustituciones se almacenan de forma permanente y tienen prioridad sobre las traducciones automáticas. Esto te da el flujo de revisión de una librería de i18n sin mantener archivos de traducción en tu repositorio.