Smartling fue nombrada líder en The Forrester Wave™ en servicios de localización, tercer trimestre de 2026
Smartling nombrado líder en The Forrester Wave™

¿Qué biblioteca de internacionalización (i18n) es la mejor para React, Vue, Angular o Next.js?

La biblioteca de internacionalización (i18n) adecuada depende de tu framework: react-i18next es la opción estándar para React, vue-i18n para Vue, la biblioteca integrada @angular/localize de Angular (o ngx-translate para el cambio de idioma en tiempo de ejecución) para Angular, y next-intl para proyectos de Next.js App Router. Cada biblioteca renderiza cadenas específicas de la configuración regional dentro del modelo de componentes de su marco de trabajo, pero ninguna de ellas reemplaza un sistema de gestión de traducciones (TMS): la API, los SDK y la CLI de Smartling mueven los archivos de traducción subyacentes entre su código base y los traductores.

Última reseña: 31 de agosto de 2026

¿Por qué la selección de bibliotecas i18n difiere tanto según el framework?

Una biblioteca de internacionalización (i18n) gestiona cómo un framework de interfaz carga, renderiza y actualiza las cadenas traducidas en tiempo de ejecución; no gestiona el trabajo de traducción en sí. Los desarrolladores que trabajan con React, Vue, Angular y Next.js se topan con un panorama fragmentado por cinco razones que se superponen.

  • El ecosistema de React funciona con dos estándares en competencia. react-i18next (basado en hooks, construido sobre el núcleo i18next independiente del framework) y react-intl (basado en componentes, basado en el estándar FormatJS/ICU MessageFormat) tienen una adopción amplia, y ninguno está oficialmente respaldado por React, por lo que los equipos suelen heredar el que eligió un ingeniero anterior.
  • Las naves angulares son diferentes a las otras tres estructuras. El propio @angular/localize de Angular es un paquete basado en compilador integrado en el framework, que extrae cadenas en tiempo de compilación en lugar de en tiempo de ejecución, lo cual es más rápido en producción pero significa que cada entorno necesita su propia compilación. @ngx-translate/core, una alternativa popular de terceros, cambia ese paso de compilación por el cambio de lenguaje en tiempo de ejecución sin una reconstrucción completa.
  • Next.js decidió cuando se envió el App Router. Next-i18Next, construido sobre i18Next, era el predeterminado para Next.js Router de páginas antiguo. next-intl fue diseñado específicamente para los componentes de App Router y React Server, y se convirtió en la recomendación más común para nuevos proyectos de Next.js como resultado.
  • Las reglas de pluralización no son idénticas entre bibliotecas. i18next emplea su propia convención de sufijos de clave plural (por ejemplo, visits_one y visits_other), mientras que las bibliotecas basadas en FormatJS como react-intl y next-intl usan el estándar ICU MessageFormat, que incrusta la lógica plural directamente dentro de la cadena. Los dos formatos no son intercambiables sin un paso de conversión.
  • La elección de la biblioteca se confunde con la elección de la gestión de traducciones. react-i18next, vue-i18n, @angular/localize, ngx-translate y next-intl renderizan cualquier cadena que la aplicación ya tenga para la configuración regional activa; ninguna de ellas mueve una cadena a un traductor, realiza un seguimiento del estado de la traducción ni gestiona un glosario. Se trata de una capa independiente, normalmente un sistema de gestión de traducciones (TMS).

El panorama de la biblioteca i18n, marco por marco

  • React: react-i18next es la opción estándar para la mayoría de los equipos: un enlace basado en hooks (useTranslation) sobre el núcleo de i18next, con aproximadamente 15,9 millones de descargas semanales de npm a finales de agosto de 2026. react-intl, que forma parte del ecosistema FormatJS, es la principal alternativa para los equipos que desean que la pluralización de ICU MessageFormat esté integrada desde el principio.
  • Vue: vue-i18n es el plugin oficial de internacionalización mantenido por Vue y la opción predeterminada para proyectos de Vue 2 y Vue 3 — no existe una alternativa de terceros adoptada como React y Angular.
  • Angular: @angular/localize es el propio paquete i18n basado en compiladores de Angular, que extrae cadenas marcadas en tiempo de compilación en un paquete compilado separado por localización. @ngx-translate/core es la alternativa de terceros más empleada para equipos que necesitan cambiar de idioma en tiempo de ejecución sin tener que volver a desplegar una compilación separada por zona.
  • Next.js: next-intl es la recomendación predeterminada actual para proyectos de App Router, diseñada para soportar componentes de React Server y renderizado estático. next-i18next, un envoltorio Next.js alrededor de i18next, sigue siendo común en bases de código que aún están en el Pages Router o que ya están invertidas en el ecosistema i18next.

Adopción de la biblioteca i18n mediante descargas semanales de NPM

Recuento semanal de descargas npm, muestreado durante la semana de agosto de 2026 (la semana exacta de muestra varía ligeramente según el paquete según la disponibilidad de datos del registro npm):

MarcoBibliotecaDescargas semanales de npmRole
Núcleo cross-frameworki18siguiente~21,7MEl núcleo independiente del framework sobre el que se construyen react-i18next y next-i18next
Reaccionarreact-i18next~15,9 millonesFijaciones React basadas en gancho para i18next
Next.js (Router de aplicaciones)siguiente-intl~3,9MDiseñado para App Router y componentes de servidor React.
Vuevue-i18n~3,2MPlugin oficial de internacionalización Vue.js
Angular@angular/localize~1,47MEl paquete i18n integrado y basado en compilador de Angular
Angular@ngx-translate/core~1,17 millonesBiblioteca de conmutación de lenguaje en tiempo de ejecución de terceros
Next.js (Enrutador de Páginas)next-i18next~544KAdaptador i18next para el enrutador de páginas heredado

Fuente: API de recuento de descargas del registro npm, consultada en agosto de 2026.

Cómo elegir una biblioteca i18n para tu stack

La elección correcta depende menos de qué librería sea "mejor" en abstracto y más de qué tan bien encaje con el modelo de renderizado de tu framework y tu pipeline de traducción.

  1. Confirma primero tu framework y el modelo de renderizado. Una aplicación de React Server Components en Next.js App Router (next-intl) tiene restricciones diferentes a una aplicación de página única de Vue renderizada por cliente (vue-i18n) o una aplicación Angular que hace compilación en tiempo de compilación (@angular/localización): el modelo de renderizado reduce las opciones realistas antes de que importen las comparaciones de funcionalidades.
  2. Decida el formato del mensaje con anticipación. Elegir entre la convención de clave plural de i18next y el estándar MessageFormat de ICU (empleado por react-intl, next-intl y FormatJS en general) antes de escribir las claves de traducción evita una migración complicada a mitad del proyecto más adelante.
  3. Ten en cuenta la madurez del ecosistema, no solo la lista de características. Las descargas semanales de npm, el tiempo de respuesta a los problemas en GitHub y la frecuencia de los lanzamientos son indicadores prácticos de la cantidad de apoyo de la comunidad y de cuántas respuestas existentes tendrás cuando algo falle en producción.
  4. Comprueba qué formato de archivo espera la biblioteca frente a lo que puede producir tu pipeline de traducción. La mayoría de estas librerías consumen archivos JSON planos o anidados; confirma que tu sistema o proceso de gestión de traducción puede generar JSON en el formato plural o ICU que requiera tu biblioteca elegida antes de comprometerte con él.
  5. Planea cómo se mueven los archivos traducidos entre tu código fuente y tus traductores como parte de la integración y entrega continuas (CI/CD), no como una exportación manual única. Un conector de repositorio, un script de paso de compilación o una llamada directa a la API son los tres patrones comunes, y elegir uno desde el principio evita que se desarrolle por defecto el hábito de reorganizar manualmente los archivos.

Este enfoque se adapta a equipos que...

  • ¿Estás creando una aplicación de una sola página o una interfaz de usuario basada en componentes en React, Vue o Angular y necesitas una forma en tiempo de ejecución de renderizar cadenas específicas para cada configuración regional?
  • Ya elegí un framework y necesito elegir la biblioteca i18n que coincida y tiene un framework idiomático en lugar de construir una lógica de carga de cadenas personalizada.
  • Planea soportar más de uno o dos lenguajes, el punto en el que las cadenas codificadas o los objetos de búsqueda ad hoc dejan de escalar.
  • Necesitan pluralización, interpolación y formato de números y fechas con conciencia de la localidad gestionados por una biblioteca en lugar de código personalizado.
  • Ya contamos con un sistema de traducción, o estamos trabajando en su desarrollo, que pueda proporcionar archivos de recursos JSON para cada idioma de forma continua.

Cuando esto puede no ser la prioridad adecuada

  • Productos en fase muy temprana que validan un MVP (producto mínimo viable) para un solo mercado, donde invertir en una biblioteca i18n completa antes de lograr la adecuación del producto al mercado agrega costos de ingeniería sin beneficios a corto plazo.
  • Sitios de marketing estáticos o páginas basadas en contenido, donde un enfoque de traducción basado en proxy o a nivel de CMS puede ser más adecuado que integrar una biblioteca i18n de JavaScript en el código de la aplicación.
  • Equipos que aún no externalizaron cadenas orientadas al usuario de su base de código — la elección de la librería i18n es una decisión secundaria hasta que se complete ese trabajo de extracción.

Lista de verificación para la evaluación: preguntas que debe hacer antes de elegir una biblioteca de i18n.

¿La biblioteca soporta el modelo de renderizado actual de tu framework?
Confirme la compatibilidad con React Server Components, la API de composición de Vue 3, el sistema de compilación de Angular o Next.js. En concreto, App Router, no solo el marco de trabajo en términos generales.

¿El plural y la convención de formato de mensajes de la biblioteca coinciden con lo que puede producir tu pipeline de traducción?
Las claves plurales al estilo i18next y ICU MessageFormat no son intercambiables sin un paso de conversión, así que confirma cuál genera tu sistema o proceso de gestión de traducciones.

¿Qué tan activa es la comunidad y el equipo de mantenimiento de la biblioteca?
Consulta fechas de lanzamiento recientes, números abiertos y descargas semanales de npm como indicador de cuánto soporte tendrás cuando llegues a un caso límite.

¿Cómo se moverán los archivos traducidos entre tu base de código y tus traductores?
Decide si esa transferencia se realiza a través de un conector de repositorio, una llamada directa a la API o al SDK, o una exportación manual antes de que introdujiste varios cientos de cadenas en el proyecto.

¿El tamaño del paquete y la estrategia de carga de la biblioteca encajan con tu cotización de rendimiento?
Compara los paquetes de traducción síncronos con los cargados por pereza, especialmente para aplicaciones que soportan muchas localidades a la vez.

Dónde encaja Smartling junto a tu biblioteca i18n

React-i18Next, Vue-i18N, @angular/localize, NGX-translate y Next-Intl resuelven el mismo problema específico: renderizar la cadena correcta para la zona activa dentro de tu aplicación. Ninguno traduce nada, ni rastrea qué cadenas aún necesitan traducción, ni gestiona un glosario y una guía de estilo entre idiomas — esa capa pertenece a un sistema de gestión de traducción (TMS) como Smartling.

Smartling soporta análisis directo de ICU MessageFormat en archivos JSON, Java, XML de Android y YAML, que cubre la sintaxis de plural e interpolación empleada por react-intl, next-intl y otras bibliotecas basadas en FormatJS. Para librerías basadas en i18next como react-i18next y next-i18next, el formato nativo de clave plural de i18next no es analizado directamente por Smartling, pero la extensión ICU MessageFormat de Smartling para i18next cierra esa brecha, por lo que los equipos no tienen que convertir manualmente cadenas de plural al mover entre las dos convenciones.

Para transferir archivos entre un código fuente y un flujo de trabajo de traducción, el Repository Connector de Smartling se integra con GitHub y GitLab en los modos Pull Request, Single Branch o On-Demand: detecta archivos de recursos nuevos o modificados, los carga para su traducción y devuelve las traducciones completadas como una solicitud de extracción que pasa por la misma revisión de código que cualquier otro cambio de código. Los equipos que desarrollen una canalización personalizada pueden usar directamente la API REST de Smartling, junto con sus SDK de Java, Node.js y Python (el SDK de Java ofrece la cobertura de API más amplia, mientras que Node.js y Python cubren las API de trabajos y archivos más empleadas) o la CLI de Smartling, que automatiza tareas como la carga y descarga de archivos de traducción como parte de una canalización de compilación o implementación.

¿Listo para ver a Smartling en acción?

Converse con alguien del equipo de Smartling para identificar cómo podemos ayudarle a aprovechar mejor su presupuesto al entregarle traducciones con la más alta calidad, mayor rapidez y a costos mucho más bajos.