Cómo elegir la librería de i18n adecuada para React

React no incluye ninguna primitiva de i18n. La librería que elijas el primer día decide cómo se almacenan las traducciones, cómo llegan al bundle y cuánto trabajo seguirá siendo tuyo durante los próximos años. La mayoría de los equipos eligen por popularidad y luego descubren las desventajas al llegar a las 2.000 claves.

Esta guía sigue el camino inverso: responde primero a unas pocas preguntas sobre tu proyecto y luego asigna las respuestas a las librerías adecuadas. Se centra en React puro (Vite, React Router, TanStack Start). Next.js tiene sus propias restricciones, cubiertas en la comparativa de Next.js.

Tabla de contenidos

Seis preguntas a responder antes de comparar librerías

Una tabla de características no sirve de nada si no sabes qué filas te importan. Revisa estas primero.

1. ¿Cómo se renderiza la app? Solo SPA, SSR con hidratación o React Server Components. Los hooks basados en Context funcionan en cualquier lugar de una SPA. Con RSC, un hook fuerza "use client" en cada componente que renderiza texto, por lo que también necesitarás una API del lado del servidor.
2. ¿Quién escribe las traducciones? Desarrolladores, un equipo interno que utiliza un TMS, una agencia que entrega archivos ICU o un pipeline de IA. Esto dicta el formato del catálogo más que cualquier detalle de la API.
3. ¿Cuántos locales y páginas? Dos locales y cinco páginas pueden permitirse enviar todo. Diez locales y cincuenta rutas no pueden, y la estrategia de carga se convierte en el coste principal.
4. ¿Necesitas tipado en las claves? Un error tipográfico en t("checkout.totl") compila en todas las librerías basadas en claves a menos que configures los tipos tú mismo. Decide si eso es aceptable.
5. ¿Qué contiene la cadena de texto? Texto plano, plurales o frases con un <Link> en medio. El contenido enriquecido es donde la mayoría de las API se vuelven incómodas.
6. ¿Cuánto durará el proyecto? Un prototipo de tres meses y un producto a cinco años no necesitan la misma cantidad de herramientas de build.

Anota las respuestas. Todo lo que sigue hace referencia a ellas.

El panorama en una imagen

Quince años de i18n en JavaScript caben en cuatro olas arquitectónicas, y las librerías de React que vas a comparar provienen de diferentes olas.

La historia de la i18n en JavaScript detalla cómo cada ola respondió a los problemas de la anterior.

La decisión más importante: dónde reside el contenido y cuándo se carga

Cada librería de i18n para React tiene la misma estructura: un store, un provider, un hook. Todo lo que recibe el provider termina en el bundle del cliente o en el payload de hidratación. Por lo tanto, las dos opciones estructurales son:

• Contenido centralizado o acotado (scoped). Un en.json para toda la app, o una declaración por componente (o por namespace).
• Importación estática o dinámica. Todo empaquetado al inicio, o el locale activo y la ruta cargados bajo demanda.

El gráfico siguiente estima el payload para una app teórica de 1 a 10 páginas, traducida a entre 1 y 10 locales, con unos 30 KB de texto por página.

El contenido centralizado con importaciones estáticas crece en ambos ejes: 10 páginas multiplicadas por 10 locales son 300 KB de texto en cada página. Las importaciones dinámicas eliminan el eje de los locales. El scoping elimina el eje de las páginas. Solo la combinación de ambos se mantiene plana.

Esto no es una propiedad de la librería, es una propiedad de la disciplina. react-i18next se puede acotar con namespaces y backends diferidos (lazy). use-intl se puede dividir por ruta. Pero nada lo fuerza, y un <Button> compartido que acceda a t("common:cta") convierte silenciosamente a common en una dependencia de cada ruta. El benchmark mide esto como "fuga desde otras rutas" y "fuga desde otros locales", y de ahí proviene la mayor parte de la diferencia entre librerías.

Si tu respuesta a la pregunta 3 fue "muchos locales, muchas páginas", dale más peso a esta sección que a cualquier preferencia de API. El artículo i18n por componente vs. centralizado profundiza en el aspecto de mantenimiento de esta misma elección.

Las candidatas

Los tamaños de las librerías provienen del benchmark de TanStack Start: provider más hook en un componente vacío, tras bundling, tree-shaking y minificación, 10 páginas y 10 locales. El contenido se mide por separado.

Las cifras son una instantánea en las versiones del benchmark y cambian con las releases. Ejecuta el benchmark en tu propia app antes de decidirte solo por el tamaño.

Dos cosas que la tabla no muestra. Paraglide casi no incluye librería porque genera código directamente en tu repo, lo que implica un paso de regeneración antes de cada commit y conflictos de fusión en archivos generados. E Intlayer requiere un plugin para el bundler (vite-intlayer o equivalente), por lo que no puede ejecutarse en un entorno sin build.

Asigna tus respuestas a una librería

Dónde se queda corta cada librería

Límites honestos, ya que todas las opciones los tienen.

• react-i18next: la más pesada del conjunto, su propio formato de plurales, los tipos son una configuración manual que debes mantener tú mismo, las claves obsoletas se acumulan en silencio.
• react-intl: DX verbosa (useIntl() y luego formatMessage({ id })), instancia global vinculada a muchos nodos.
• use-intl: simple al empezar, dolorosa al optimizar. Los namespaces, la carga dinámica y los tipos juntos ralentizan bastante el desarrollo.
• Lingui: paso extra de build con extract / compile, varias sintaxis superpuestas (t(), tagged template, i18n.t(), <Trans>) que confunden tanto a humanos como a asistentes de IA.
• Paraglide: archivos generados en el repositorio, el tree-shaking no tuvo efecto en el benchmark de React, y el locale se lee desde el almacenamiento en cada nodo en lugar de desde un store.
• Tolgee: sin tipos en claves, onboarding más difícil, la edición in-context es su principal propuesta de valor.
• Intlayer: plugin de build obligatorio, ecosistema más pequeño, soporte parcial de ICU, contenido repartido por la codebase por diseño, por lo que exportar un único JSON para un traductor requiere herramientas específicas.
• gt-react, lingo.dev: no recomendadas en el benchmark: errores de cuota en el build, vendor lock-in y problemas de reactividad que requerían forzar re-renders del provider.

Cómo se ve cada opción en código

El mismo componente, un resumen del carrito con un título y un plural, escrito con cada candidata. La parte interesante no es el componente, sino dónde reside el contenido y qué sabe el verificador de tipos sobre él.

{
  "title": "Your cart",
  "items_one": "{{count}} item",
  "items_other": "{{count}} items"
}

import type { FC } from "react";
import { useTranslation } from "react-i18next";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const { t } = useTranslation("cart");

  return (
    <section>
      <h2>{t("title")}</h2>
      <p>{t("items", { count })}</p>
    </section>
  );
};

{
  "cart.title": "Your cart",
  "cart.items": "{count, plural, one {# item} other {# items}}"
}

import type { FC } from "react";
import { FormattedMessage, useIntl } from "react-intl";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const intl = useIntl();

  return (
    <section>
      <h2>
        <FormattedMessage id="cart.title" />
      </h2>
      <p>{intl.formatMessage({ id: "cart.items" }, { count })}</p>
    </section>
  );
};

{
  "Cart": {
    "title": "Your cart",
    "items": "{count, plural, one {# item} other {# items}}"
  }
}

import type { FC } from "react";
import { useTranslations } from "use-intl";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const t = useTranslations("Cart");

  return (
    <section>
      <h2>{t("title")}</h2>
      <p>{t("items", { count })}</p>
    </section>
  );
};

msgid "Your cart"
msgstr "Votre panier"

msgid "{count, plural, one {# item} other {# items}}"
msgstr "{count, plural, one {# article} other {# articles}}"

import type { FC } from "react";
import { Plural, Trans } from "@lingui/react/macro";

export const CartSummary: FC<{ count: number }> = ({ count }) => (
  <section>
    <h2>
      <Trans>Your cart</Trans>
    </h2>
    <p>
      <Plural value={count} one="# item" other="# items" />
    </p>
  </section>
);

{
  "cart_title": "Your cart",
  "cart_items": "{count} items"
}

import type { FC } from "react";
import { m } from "../paraglide/messages.js";

export const CartSummary: FC<{ count: number }> = ({ count }) => (
  <section>
    <h2>{m.cart_title()}</h2>
    <p>{m.cart_items({ count })}</p>
  </section>
);

import { plural, t, type Dictionary } from "intlayer";

const cartSummaryContent = {
  key: "cart-summary",
  content: {
    title: t({ es: "Tu carrito", en: "Your cart", fr: "Votre panier" }),
    items: t({
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
    }),
  },
} satisfies Dictionary;

export default cartSummaryContent;

import type { FC } from "react";
import { useIntlayer } from "react-intlayer";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const { title, items } = useIntlayer("cart-summary");

  return (
    <section>
      <h2>{title}</h2>
      <p>{items(count)}</p>
    </section>
  );
};

¿Ya estás usando react-i18next, react-intl o Lingui? Los adaptadores de compatibilidad (react-i18next, react-intl, Lingui) crean alias de las importaciones a nivel de bundler para que la API existente siga funcionando mientras migras componente por componente. La guía de migración cubre el resto.

Antes de comprometerte

Una tabla de características te indica lo que hace una librería hoy. Estos puntos te dicen cómo será convivir con ella.

Comprueba la actividad del repositorio.

Commits, tiempo de respuesta a issues y si la última release menor fue este año. Un diseño sólido sin mantenedor es una migración garantizada a futuro.

No elijas por descargas de npm.

La librería más instalada es la que se publicó primero, no la que mejor encaja en una codebase de React en 2026. Las descargas miden historia, no adecuación.

Pregunta quién financia al mantenedor y qué vende.

i18next está respaldada por Locize. next-intl / use-intl, vue-i18n, svelte-i18n y Lingui están respaldadas por Crowdin. Tolgee, Paraglide (inlang) e Intlayer operan cada una su propia plataforma. Un proveedor cuyos ingresos provienen de la traducción alojada tiene pocos incentivos para que la traducción sea gratuita dentro de tu toolchain. Intlayer es la única del grupo que incluye traducción por IA a través de la CLI con tu propia clave de API y un CMS que puedes autoalojar (self-host).

¿Está preparada para agentes de IA?

Los agentes todavía tienen dificultades con i18n: olvidan locales, inventan claves y mezclan sintaxis de mensajes. ¿Ofrece la librería Agent Skills o un servidor MCP para que el agente pueda listar, rellenar y probar el contenido? ¿Y la carga de contenido está optimizada por defecto, o alguien tiene que revisar namespaces e importaciones perezosas cada trimestre?

Seguridad de tipos de fábrica.

No "se puede tipar con configuración adicional", sino "una clave incorrecta falla tsc en una instalación limpia". Comprueba qué sucede con una clave que no existe y con un locale al que le falta una traducción.

Detección de contenido no utilizado.

Los catálogos solo crecen. El build de Intlayer purga los campos no utilizados y los registra en logs (build.purge). Paraglide lo logra por arquitectura, ya que una función de mensaje no llamada es eliminada por tree-shaking. Las demás te dejan esa limpieza a ti.

Experiencia de desarrollo (Developer experience).

Tiempo de configuración hasta la primera cadena traducida, un LSP o extensión de VS Code que muestre la traducción al pasar el cursor y salte a la declaración, una CLI para rellenar, probar y hacer push, y una forma para que perfiles no técnicos editen contenido (editor visual o CMS) sin necesidad de una pull request.

Preguntas frecuentes

Para ir más lejos

• Benchmark de librerías de i18n: tamaño del bundle, fugas y tiempos de cambio de locale y el informe de TanStack Start
• React i18n: cómo funciona el modelo de providers y cuánto cuesta
• react-i18next vs react-intl vs Intlayer, característica por característica
• next-i18next vs next-intl vs Intlayer
• La historia de la i18n en JavaScript
• Compilador vs i18n declarativa
• i18n por componente vs. centralizado
• Cómo funciona la optimización del bundle en tiempo de build
• Configurar i18n en una app Vite + React
• Misma guía para Vue, Svelte y Solid