Comment choisir la bonne bibliothèque i18n pour React

React ne fournit aucune primitive i18n. La bibliothèque que vous choisissez dès le premier jour détermine la manière dont les traductions sont stockées, comment elles arrivent dans le bundle, et la charge de maintenance qui vous incombera pour les années à venir. La plupart des équipes choisissent par popularité, puis découvrent les compromis une fois arrivées à 2 000 clés.

Ce guide adopte l'approche inverse : répondez d'abord à quelques questions sur votre projet, puis associez ces réponses aux bibliothèques correspondantes. Il se concentre sur React pur (Vite, React Router, TanStack Start). Next.js a ses propres contraintes, détaillées dans le comparatif Next.js.

Table of Contents

Six questions à se poser avant de comparer les bibliothèques

Un tableau de fonctionnalités est inutile si vous ne savez pas quelles lignes comptent pour vous. Commencez par répondre à celles-ci.

1. Comment l'application est-elle rendue ? SPA uniquement, SSR avec hydratation, ou React Server Components. Les hooks basés sur le contexte fonctionnent partout dans une SPA. Avec RSC, un hook impose "use client" sur chaque composant qui affiche du texte, vous aurez donc également besoin d'une API côté serveur.
2. Qui rédige les traductions ? Les développeurs, une équipe interne utilisant un TMS, une agence livrant des fichiers ICU, ou un pipeline IA. Cela dicte le format de catalogue bien plus que n'importe quel détail d'API.
3. Combien de locales et de pages ? Deux locales et cinq pages peuvent se permettre de tout inclure dans le bundle. Dix locales et cinquante routes ne le peuvent pas, et la stratégie de chargement devient alors le coût principal.
4. Avez-vous besoin du typage sur les clés ? Une faute de frappe dans t("checkout.totl") compile dans toutes les bibliothèques basées sur des clés, à moins de configurer le typage vous-même. Décidez si cela est acceptable.
5. Que contient la chaîne de caractères ? Du texte brut, des pluriels, ou des phrases avec un composant <Link> au milieu. Le contenu riche est le point où la plupart des API deviennent peu pratiques.
6. Combien de temps vivra le projet ? Un prototype de trois mois et un produit de cinq ans ne nécessitent pas la même quantité d'outillage de build.

Notez vos réponses. Tout ce qui suit y fait référence.

Le paysage en une image

Quinze ans d'i18n JavaScript se résument en quatre vagues architecturales, et les bibliothèques React que vous allez comparer sont issues de vagues différentes.

L'histoire de l'i18n JavaScript détaille la manière dont chaque vague a répondu aux problèmes de la précédente.

La décision la plus importante : où vit le contenu et quand il se charge

Toutes les bibliothèques React i18n partagent la même structure : un store, un provider, un hook. Tout ce que le provider reçoit se retrouve dans le bundle client ou dans le payload d'hydratation. Les deux choix structurels sont donc :

• Contenu centralisé ou scopé. Un seul en.json pour toute l'application, ou une déclaration par composant (ou par namespace).
• Import statique ou dynamique. Tout est packagé au démarrage, ou bien la locale active et la route sont récupérées à la demande.

Le graphique ci-dessous estime le payload pour une application théorique de 1 à 10 pages, traduite en 1 à 10 locales, avec environ 30 Ko de texte par page.

Le contenu centralisé avec imports statiques augmente sur les deux axes : 10 pages multipliées par 10 locales représentent 300 Ko de texte sur chaque page. Les imports dynamiques suppriment l'axe des locales. Le scoping supprime l'axe des pages. Seule la combinaison des deux permet de maintenir un payload constant.

Ce n'est pas une propriété intrinsèque de la bibliothèque, mais une question de discipline. react-i18next peut être scopé avec des namespaces et des backends asynchrones. use-intl peut être découpé par route. Mais rien ne l'impose, et un simple <Button> partagé appelant t("common:cta") transforme discrètement common en une dépendance de chaque route. Le benchmark mesure cela sous les termes de « fuite depuis d'autres routes » et « fuite depuis d'autres locales », et c'est de là que provient la majeure partie des écarts entre les bibliothèques.

Si votre réponse à la question 3 était « beaucoup de locales, beaucoup de pages », accordez plus d'importance à cette section qu'à toute préférence d'API. L'article i18n par composant vs centralisée approfondit l'impact sur la maintenance de ce même choix.

Les candidats

La taille des bibliothèques provient du benchmark TanStack Start : provider et hook dans un composant vide, après bundling, tree-shaking et minification, pour 10 pages et 10 locales. Le contenu est mesuré séparément.

Les chiffres correspondent à un instantané basé sur les versions du benchmark et évoluent au fil des publications. Exécutez le benchmark sur votre propre application avant de vous décider uniquement sur la taille.

Deux éléments que le tableau ne montre pas. Paraglide n'embarque presque aucune bibliothèque car il génère du code directement dans votre codebase, ce qui implique une étape de régénération avant chaque commit et de potentiels conflits de fusion sur les fichiers générés. De son côté, Intlayer nécessite un plugin de bundler (vite-intlayer ou équivalent), et ne peut donc pas fonctionner dans une configuration sans étape de build.

Associer vos réponses à une bibliothèque

Les limites de chaque bibliothèque

Des limites en toute transparence, car chaque option en présente.

• react-i18next : la plus lourde de l'ensemble, format de pluriel propriétaire, typage à configurer et maintenir soi-même, accumulation silencieuse de clés mortes.
• react-intl : DX verbeuse (useIntl() puis formatMessage({ id })), instance globale liée à de nombreux nœuds.
• use-intl : simple pour débuter, complexe à optimiser. Les namespaces, le chargement dynamique et le typage combinés ralentissent nettement le développement.
• Lingui : étape de build supplémentaire (extract / compile), plusieurs syntaxes concurrentes (t(), template taggé, i18n.t(), <Trans>) qui créent de la confusion tant pour les humains que pour les assistants IA.
• Paraglide : fichiers générés dans la codebase, le tree-shaking n'a pas été effectif lors du benchmark React, et la locale est lue depuis le storage sur chaque nœud plutôt qu'à partir d'un store.
• Tolgee : aucun typage des clés, intégration plus difficile, l'édition in-context est son principal atout commercial.
• Intlayer : plugin de build obligatoire, écosystème plus restreint, support partiel d'ICU, contenu réparti dans la codebase par conception nécessitant un outillage pour exporter un JSON unique à un traducteur.
• gt-react, lingo.dev : non recommandés dans le benchmark : erreurs de quota lors du build, verrouillage propriétaire (vendor lock-in), et problèmes de réactivité nécessitant de forcer le re-rendu du provider.

À quoi ressemble chaque option en code

Le même composant, un récapitulatif de panier avec un titre et un pluriel, écrit avec chaque candidat. L'aspect intéressant n'est pas le composant lui-même, mais l'endroit où réside le contenu et les informations dont dispose le vérificateur de types.

{
  "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({ fr: "Votre panier", en: "Your cart", es: "Tu carrito" }),
    items: t({
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
    }),
  },
} 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>
  );
};

Vous utilisez déjà react-i18next, react-intl ou Lingui ? Les adaptateurs de compatibilité (react-i18next, react-intl, Lingui) créent des alias d'imports au niveau du bundler pour que l'API existante continue de fonctionner pendant votre migration composant par composant. Le guide de migration couvre le reste.

Avant de faire votre choix

Un tableau de fonctionnalités indique ce qu'une bibliothèque propose aujourd'hui. Les points suivants expliquent ce que sera son utilisation au quotidien.

Vérifiez l'activité du dépôt.

Commits, temps de réponse sur les issues et date de la dernière version mineure. Une architecture solide sans mainteneur est une future migration programmée.

Ne choisissez pas selon les téléchargements npm.

La bibliothèque la plus installée est celle qui est sortie en premier, pas nécessairement celle qui convient à une codebase React en 2026. Les téléchargements mesurent l'antériorité, pas la pertinence.

Demandez-vous qui finance le mainteneur et ce qu'il vend.

i18next est soutenu par Locize. next-intl / use-intl, vue-i18n, svelte-i18n et Lingui sont soutenus par Crowdin. Tolgee, Paraglide (inlang) et Intlayer exploitent chacun leur propre plateforme. Un fournisseur dont le modèle économique repose sur l'hébergement des traductions a peu d'intérêt à rendre la traduction gratuite au sein de votre chaîne d'outils. Intlayer est le seul du groupe à intégrer la traduction par IA via la CLI avec votre propre clé d'API, ainsi qu'un CMS auto-hébergeable.

Est-elle prête pour les agents IA ?

Les agents rencontrent encore des difficultés avec l'i18n : ils oublient des locales, inventent des clés et mélangent les syntaxes de messages. La bibliothèque fournit-elle des Agent Skills ou un serveur MCP afin que l'agent puisse lister, compléter et tester le contenu ? Et le chargement du contenu est-il optimisé par défaut, ou bien quelqu'un doit-il auditer les namespaces et les imports asynchrones chaque trimestre ?

Sûreté de typage prête à l'emploi.

Pas simplement « peut être typé avec une configuration supplémentaire », mais « une clé invalide fait échouer tsc dès l'installation initiale ». Vérifiez le comportement en cas de clé inexistante et lorsqu'une locale omet une traduction.

Détection du contenu inutilisé.

Les catalogues ne font que grossir. Le build d'Intlayer purge les champs inutilisés et les consigne dans les logs (build.purge). Paraglide y parvient par son architecture, puisqu'une fonction de message non appelée est éliminée par tree-shaking. Toutes les autres solutions vous laissent gérer ce nettoyage manuellement.

Expérience développeur.

Temps de configuration avant la première chaîne traduite, présence d'un LSP ou d'une extension VS Code affichant la traduction au survol et permettant d'accéder à la déclaration, une CLI pour compléter (fill), tester et publier (push), et un moyen pour les non-développeurs d'éditer le contenu (éditeur visuel ou CMS) sans passer par une pull request.

Foire aux questions

Pour aller plus loin

• Benchmark des bibliothèques i18n : bundle size, fuites et temps de basculement de locale et le rapport TanStack Start
• React i18n : fonctionnement du modèle provider et ses coûts
• react-i18next vs react-intl vs Intlayer, fonctionnalité par fonctionnalité
• next-i18next vs next-intl vs Intlayer
• L'histoire de l'i18n JavaScript
• Compilateur vs i18n déclarative
• i18n par composant vs centralisée
• Comment fonctionne l'optimisation de bundle au moment du build
• Configurer l'i18n dans une application Vite + React
• Même guide pour Vue, Svelte et Solid