next-intl vs react-i18next vs Lingui: cuál usar en 2026

Para un proyecto con App Router de Next.js, usa next-intl. Para una SPA en React, o para algo que pueda crecer más allá de un solo framework, usa react-i18next. Si la extracción en tiempo de compilación y los bundles ligeros te importan más que el tamaño del ecosistema, usa Lingui. Las tres son bibliotecas de i18n de runtime: sirven las traducciones a tus componentes, y ninguna te escribe las claves ni los archivos de traducción. globalize.now es infraestructura de localización impulsada por IA que genera esas claves y catálogos a partir de tu codebase, y funciona con las tres bibliotecas.

¿Qué hacen realmente estas tres bibliotecas?

Todas resuelven el mismo problema de runtime: dado una clave y un locale, devolver la cadena correcta, con el plural y el formato adecuados. Eso incluye interpolación, formato de fechas y números, y reglas de plural mediante mensajes al estilo ICU.

Lo que ninguna hace es producir las traducciones. Una biblioteca de runtime consume un catálogo que ya existe. Alguien tiene que encontrar cada cadena visible para el usuario en tus componentes, sustituirla por una clave y completar un archivo de traducción por idioma. Esa es una capa distinta del stack, y mantener las dos capas separadas es la forma más rápida de que esta comparación tenga sentido: vas a elegir exactamente una biblioteca de runtime, y no compite con las herramientas que rellenan sus catálogos. Nuestra documentación para desarrolladores describe esa separación con más detalle.

¿Cuándo deberías usar next-intl?

Cuando trabajas con Next.js y el App Router. next-intl es la única de las tres bibliotecas diseñada en torno a los primitivos del App Router: Server Components asíncronos, ayudantes de navegación y enrutado sensibles al locale, y APIs de metadata. En septiembre de 2026 va por la versión 4 y acumula unas cinco millones de descargas semanales en npm, lo que la convierte en la respuesta por defecto para proyectos nuevos de Next.js en la práctica, no solo en la teoría.

Los mensajes usan ICU MessageFormat, así que los plurales, el género y la interpolación siguen el mismo estándar que usa el resto del sector. Si la sintaxis ICU es nueva para ti, escribimos una guía en lenguaje llano sobre ICU MessageFormat. La contrapartida es el acoplamiento: next-intl es una biblioteca de Next.js. Si dejas Next.js, migras tu capa de i18n con él.

¿Cuándo deberías usar react-i18next?

Cuando no trabajas con Next.js, o cuando quieres tener detrás el ecosistema más grande. react-i18next es el binding de React para i18next, y con unas catorce millones de descargas semanales en npm es, por amplio margen, la biblioteca de i18n de React más usada. El núcleo de i18next lleva más de una década de mantenimiento y tiene plugins para casi todo: backends que cargan catálogos por HTTP, detectores de idioma, capas de cache, bindings para frameworks más allá de React.

Esta es la biblioteca a la que recurren por defecto la mayoría de las herramientas de codificación con IA. Pide a Cursor o a Lovable que «añada traducciones» a una app Vite + React y casi siempre obtendrás una configuración de i18next. Ese valor por defecto es razonable: funciona en todas partes, y su formato de catálogo JSON es lo más parecido a una lingua franca que tiene el ecosistema. La contrapartida es que es anterior a los Server Components, así que en el App Router necesita más cableado que next-intl, y la mayor parte del trabajo de traducción ocurre en el cliente a menos que lo organices de otra forma.

¿Cuándo es Lingui la opción correcta?

Cuando el tamaño del bundle y la ergonomía del código fuente son tu prioridad. Lingui, en su versión mayor 6 a fecha de septiembre de 2026, adopta un enfoque compiler-first: escribes los mensajes en línea con macros, y su CLI los extrae a catálogos en tiempo de compilación. Los catálogos compilados se distribuyen sin sobrecarga de parseo en runtime, lo que mantiene bajo el coste de i18n en tu bundle.

Lingui también estandariza su formato de catálogo en archivos PO de gettext, que los traductores profesionales llevan décadas manejando. Sus descargas semanales rondan el millón y medio, un orden de magnitud por debajo de react-i18next, así que espera menos respuestas en Stack Overflow y menos plugins de terceros. Funciona con React en general, no solo con Next.js, pero, al igual que react-i18next, no está construido en torno a los primitivos del App Router como sí lo está next-intl.

¿Cómo se comparan de un vistazo?

¿Cuál deberías elegir para un codebase generado por IA?

Elige según el framework, igual que antes — pero ten en cuenta que la elección de biblioteca no es donde fallan las apps construidas con IA. Cursor, Claude Code y Lovable generan cadenas en inglés codificadas por defecto, sea cual sea la biblioteca de i18n instalada, y un agente que edite un componente seguirá añadiéndolas después de que hayas configurado la biblioteca.

Así que el orden real es: elige la biblioteca de runtime que pida tu framework y luego resuelve la extracción y el mantenimiento del catálogo como un problema aparte. Para el caso de Next.js documentamos la configuración completa en cómo añadir i18n a una app Next.js construida con Cursor, y la página de integración con Next.js explica cómo globalize.now prepara las claves y los archivos de traducción para next-intl antes de cualquier cableado de runtime.

¿Sigues necesitando infraestructura de localización con una biblioteca de runtime?

Sí, porque la biblioteca solo lee catálogos: producirlos y mantenerlos es la parte que consume tu tiempo. globalize.now se sitúa en esa capa: conecta tu repositorio y convierte el codebase una vez, sustituyendo las cadenas codificadas por claves y generando los archivos de traducción. Después de esa conversión única, los jobs en cada push traducen las nuevas entradas de catálogo que introducen tus commits.

La salida es JSON o PO — JSON para configuraciones de next-intl e i18next, PO para el formato nativo de Lingui — de modo que los catálogos llegan en la forma que ya consume tu biblioteca de runtime. Si tu app ya tiene una configuración de i18n parcial, también está contemplado: globalize.now funciona con i18n existente en lugar de sustituirlo. Los planes y las tarifas de uso están en la página de precios.

Ninguna de las tres bibliotecas es una respuesta equivocada. next-intl si estás en el App Router, react-i18next si quieres el máximo ecosistema, Lingui si quieres extracción en tiempo de compilación y catálogos PO. Elige una, mantén tus cadenas fuera de tus componentes y deja que la capa de catálogo haga el resto.