Lingui VS Intlayer | Benchmark d'Internationalization (i18n) React & Next.js

Lingui et Intlayer sont les deux bibliothèques de ce benchmark qui s'appuient sur un compilateur plutôt que sur un runtime pur. Lingui extrait les messages des macros au moment de la compilation et compile les catalogues par locale. Intlayer compile les dictionnaires par composant et les tree-shake par locale. Sur le papier, ils devraient être proches. Les chiffres montrent où ils divergent.

Les données proviennent de Benchmark Bloom, une suite open-source qui construit la même application avec chaque bibliothèque et enregistre ce que le navigateur télécharge et exécute réellement.

tl;dr: Lingui est le plus proche d'Intlayer en termes de JavaScript brut par page : 115-120 KB vs 118.6 KB sur TanStack Start une fois le chargement différé configuré, 148.6 KB vs 141.3 KB sur Next.js. L'écart s'élargit ailleurs : un composant Lingui compilé isolément pèse 58-153 KB contre 6-8 KB pour Intlayer, l'hydratation prend 28-34 ms contre 11-14 ms, le fallback pour la locale source fuit 3-15% des chaînes de caractères en dans les pages fr dans chaque setup optimisé, et atteindre ce setup optimisé signifie extraire, compiler et sélectionner manuellement les catalogs par route. Intlayer y arrive sans aucune configuration.

En résumé

• Lingui - Basé sur des macros ( t`...` , <Trans>, msg), ICU MessageFormat, catalogues .po / JSON, workflow lingui extract + lingui compile. Compile les IDs de message en hashes courts, supporte le chargement dynamique de catalogues par locale. Bien établi, framework-agnostique, forte histoire de tooling pour traducteurs autour de .po.
• Intlayer - Modèle de contenu centré sur les composants. Les dictionnaires .content.ts se situent à côté du composant qu'ils servent, un compilateur au moment du build tree-shake et lazy-load par composant et par locale, les types TypeScript stricts sont générés à partir de votre contenu, et les traductions manquantes échouent au moment du build. Livré avec middleware, helpers SEO, un Éditeur Visuel / CMS et traduction assistée par IA.

Afficher tout le contenu du tableau

Afficher tout le contenu du tableau

Ouvrir le tableau dans une fenêtre modale pour voir tout le contenu clairement

Bibliothèque	Étoiles GitHub	Commits Totaux	Dernier Commit	Première Version	Version NPM	Téléchargements NPM
aymericzip/intlayer				Avril 2024
lingui/js-lingui				Dec 2016

Les badges se mettent à jour automatiquement. Les snapshots varieront au fil du temps.

Comparaison des fonctionnalités côte à côte

Le benchmark

Ce qui a été mesuré

La suite Benchmark Bloom construit la même application avec chaque bibliothèque : 10 pages (accueil, à propos, blog, carrières, contact, FAQ, tarification, produits, paramètres, équipe), 10 locales (en, fr, es, de, it, pt, zh, ja, ko, ru), composants identiques et contenu identique. Les pages sont mesurées en en et fr. Chaque bibliothèque est implémentée dans jusqu'à quatre stratégies de chargement, de la configuration naïve à la configuration optimale :

Intlayer n'a pas de variante "scoped" : le compilateur scope le contenu par composant automatiquement, donc ses lignes static et dynamic sont déjà scopées.

Pour chaque build, la suite enregistre :

• Lib size: taille gzip d'un composant vide qui importe uniquement la bibliothèque i18n. Le coût fixe du runtime.
• Page JS: JavaScript gzip téléchargé par page, moyenné sur toutes les pages et locales.
• Locale leak %: part des chaînes traduites trouvées dans le JS téléchargé qui appartiennent à une locale que l'utilisateur n'est pas en train de consulter (empreinte digitale sur en et fr, donc 50% signifie "l'autre locale mesurée est entièrement présente"; avec 10 locales bundlées, le gaspillage réel est plus élevé).
• Page leak %: part des chaînes traduites trouvées dans le JS téléchargé qui appartiennent à une page sur laquelle l'utilisateur n'est pas.
• Component avg: taille gzip moyenne de chaque composant compilé isolément. Montre combien de runtime i18n et de catalog un seul composant entraîne.
• E2E réactivité : temps écoulé entre la sélection d'une nouvelle locale et la mise à jour de html[lang] dans le DOM (Playwright, 5 itérations).
• Hydratation : durée de la phase d'hydratation de React.

Les chiffres ci-dessous proviennent de l'exécution datée du 12-09-2026 avec @lingui/react 6.6.0 et intlayer 9.5.1. L'application de test est volontairement petite (quelques dizaines de chaînes par locale), donc les pourcentages de fuite décrivent un motif : ils augmentent avec votre contenu tandis que le coût d'exécution reste fixe.

Résultats sur Next.js

Comment le lire

• Coût d'exécution. Un composant vide coûte 11.9 KB gzip avec Lingui, 5.5 KB avec Intlayer. Sur la page complète, la meilleure configuration de Lingui se situe à +7.3 KB par rapport à Intlayer (148.6 vs 141.3 KB) ; Intlayer se situe à +0.3 KB par rapport à l'app de base.
• La configuration naïve est coûteuse. Charger chaque catalog compilé en avant donne 207.4 KB par page, +66 KB par rapport à l'app de base. La moitié des chaînes empreintes appartiennent à la mauvaise locale, 90% à la mauvaise page.
• Le chargement dynamique corrige la locale, pas la page. Avec un catalog par locale, la fuite de page reste à ~90% : l'intégralité du catalog fr se charge sur chaque page française. Atteindre 0% de fuite de page requiert la configuration scoped-dynamic : un catalog par route, extrait et compilé séparément, sélectionné manuellement dans chaque page.
• La source-locale fallback fuit. Même dans les configurations optimisées, 3-15% des chaînes en sont incluses dans les pages fr. Les macros Lingui conservent le message source disponible comme fallback, ce qui se retrouve dans le bundle à côté de la traduction. Intlayer résout les fallbacks au moment de la compilation et ne livre que la locale active.
• La taille du composant explose en scoped-dynamic. Chaque composant compilé isolément fait en moyenne 152.6 KB, car le catalog de chaque route est accessible depuis le composant qui l'importe. Le même composant avec useIntlayer() fait en moyenne 6.9 KB.

Résultats sur TanStack Start

Comment le lire

• Sur le JavaScript par page, Lingui gagne de justesse. Le dynamic de Lingui s'élève à 115.2 KB, 3.4 KB sous les 118.6 KB d'Intlayer. Les catalogues compilés de Lingui avec des IDs hachés sont compacts, et le routeur TanStack Start divise les routes suffisamment bien pour que la fuite de page soit déjà à 0% dans la ligne dynamic.
• Tout ce qui concerne la taille de la page va dans l'autre sens. L'hydratation prend 28-34 ms avec Lingui contre 11-14 ms avec Intlayer : i18n.load() + i18n.activate() s'exécutent sur le client avant que React puisse hydrater. Les composants compilés isolément pèsent 58-148 KB contre 6-8 KB. La fuite de locale n'atteint jamais 0% (4-9%) en raison du fallback de locale source.
• Le changement de locale dans la configuration optimisée est lent. scoped-dynamic Lingui prend 42 ms pour mettre à jour html[lang] : le nouveau catalogue de route doit être récupéré, chargé et activé avant que le changement soit visible. Intlayer bascule en 3-4 ms dans les deux modes.
• La ligne static d'Intlayer a déjà 0% de fuite de page car seuls les dictionnaires importés par les composants de la page sont regroupés. Une ligne de config (importMode: 'dynamic') supprime aussi la fuite de locale.
• @intlayer/lingui conserve la syntaxe des macros de Lingui et les sert à partir des dictionnaires Intlayer. Il échange une taille de page plus importante (137 KB, puisque le runtime des macros reste) pour des composants plus petits (12.8 KB) et une hydratation plus rapide que Lingui natif. C'est une étape de migration, pas la destination.

Pourquoi l'écart ? Deux compilateurs, deux unités de travail

Les deux bibliothèques compilent. La différence est ce qu' elles compilent.

Lingui compile des catalogues. Les macros dans votre source sont extraites dans un fichier .po par locale, puis compilées dans un module JS par locale. L'unité est la locale. Diviser davantage, par route ou par composant, signifie créer plusieurs catalogues, configurer lingui.config.ts pour extraire chacun d'un ensemble différent de fichiers, et charger le bon dans chaque route. L'instance I18n au runtime est globale ; chaque appel useLingui() souscrit le composant à celle-ci.

.
├── lingui.config.ts
└── src
    ├── i18n.ts                          # setupI18n(), load(), activate()
    ├── locales
    │   ├── en
    │   │   ├── messages.po
    │   │   └── messages.mjs             # lingui compile output
    │   └── fr
    │       ├── messages.po
    │       └── messages.mjs
    ├── components
    │   └── Counter.tsx                  # const { t } = useLingui(); t`Increment`
    └── routes
        └── $locale
            └── about.tsx                # await import(`../locales/${locale}/messages.mjs`)

Intlayer compile les dictionnaires. Chaque fichier .content.ts est un dictionnaire lié à une clé ; le compilateur résout quel composant importe quelle clé et émet, par dictionnaire et par locale, exactement le JSON dont ce composant a besoin. L'unité est le composant. La portée de la route est une conséquence : une page n'importe que les dictionnaires des composants qu'elle rend.

.
├── intlayer.config.ts
└── src
    ├── components
    │   └── Counter
    │       ├── index.tsx                # useIntlayer("counter")
    │       └── index.content.ts
    └── routes
        └── $locale
            ├── about.tsx
            └── about.content.ts

C'est pourquoi le pattern scoped-dynamic est une sortie de build pour Intlayer et une configuration de projet pour Lingui.

Pour obtenir les numéros de la ligne dynamic, définissez dictionary.importMode: 'dynamic' dans intlayer.config.ts. Voir la documentation d'optimisation du bundle.

Expérience développeur

Configuration

Lingui

import { defineConfig } from "@lingui/cli";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "fr"],
  catalogs: [
    {
      path: "<rootDir>/src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

import { setupI18n } from "@lingui/core";

export const loadCatalog = async (locale: string) => {
  const { messages } = await import(`./locales/${locale}/messages.mjs`);
  const i18n = setupI18n();
  i18n.load(locale, messages);
  i18n.activate(locale);
  return i18n;
};

Puis ajoutez @lingui/babel-plugin-lingui-macro (ou @lingui/swc-plugin) au bundler, exécutez lingui extract après avoir modifié la source, lingui compile avant de construire, et enveloppez l'arborescence dans <I18nProvider i18n={i18n}>.

Intlayer

import { type IntlayerConfig, Locales } from "intlayer";

const config: IntlayerConfig = {
  internationalization: {
    locales: [Locales.ENGLISH, Locales.FRENCH],
    defaultLocale: Locales.ENGLISH,
  },
};

export default config;

Ajoutez intlayer() à vite.config.ts (ou withIntlayer() à next.config.ts) et enveloppez l'arborescence dans <IntlayerProvider>. Aucune étape d'extraction ou de compilation : les dictionnaires sont construits lors de l'exécution du bundler.

Composant

Lingui

import { useState } from "react";
import { useLingui } from "@lingui/react/macro";
import { Trans } from "@lingui/react/macro";

export const Counter = () => {
  const { t, i18n } = useLingui();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{i18n.number(count)}</p>
      <button aria-label={t`Counter`} onClick={() => setCount((c) => c + 1)}>
        <Trans>Increment</Trans>
      </button>
    </div>
  );
};

Le texte anglais se trouve dans le composant ; le texte français se trouve dans src/locales/fr/messages.po sous un ID haché, après l'exécution de lingui extract. Oublier de l'exécuter ou d'exécuter compile bascule silencieusement vers l'anglais.

Intlayer

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

const counterContent = {
  key: "counter",
  content: {
    label: t({ fr: "Compteur", en: "Counter" }),
    increment: t({ fr: "Incrémenter", en: "Increment" }),
  },
} satisfies Dictionary;

export default counterContent;

import { useState } from "react";
import { useIntlayer } from "react-intlayer";
import { useNumber } from "react-intlayer/format";

export const Counter = () => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label} onClick={() => setCount((c) => c + 1)}>
        {increment}
      </button>
    </div>
  );
};

Les deux locales se trouvent dans un seul fichier à côté du composant. Une valeur fr manquante est une erreur de build, une clé incorrecte est une erreur TypeScript.

En dehors des composants

Métadonnées, loaders, fonctions serveur : partout sans arborescence React.

Lingui

import { setupI18n } from "@lingui/core";
import { msg } from "@lingui/core/macro";

const title = msg`À propos de nous`;

export const loader = async ({ params }: { params: { locale: string } }) => {
  const { messages } = await import(
    `../../locales/${params.locale}/messages.mjs`
  );
  const i18n = setupI18n({
    locale: params.locale,
    messages: { [params.locale]: messages },
  });

  return { title: i18n._(title) };
};

Une nouvelle instance I18n par appel, le bon catalogue chargé manuellement, et msg + i18n._() au lieu de t. Comme le benchmark le note, savoir quand utiliser t, t` ` , i18n.t(), msg ou <Trans> « n'est pas intuitif ».

Intlayer

import { getIntlayer } from "intlayer";

export const loader = async ({ params }: { params: { locale: string } }) => {
  const { title } = getIntlayer("about-metadata", params.locale);

  return { title };
};

Conservez les macros Lingui, obtenez les dictionnaires Intlayer

@intlayer/lingui est un adaptateur prêt à l'emploi pour @lingui/core et @lingui/react. Les macros continuent de se compiler comme avant ; le runtime i18n._() qu'elles compilent est servi à partir des dictionnaires Intlayer, avec des plugins de synchronisation .po qui maintiennent vos catalogues existants comme source de vérité. Les pluriels et sélections ICU s'affichent de manière identique.

import { defineConfig } from "vite";
import { lingui } from "@intlayer/lingui/plugin";

export default defineConfig({
  plugins: [lingui()],
});

Conservez @lingui/babel-plugin-lingui-macro / @lingui/swc-plugin dans la build, exécutées avant le compilateur Intlayer. Consultez la documentation de compatibilité Lingui.

Quand choisir quoi ?

• Choisir Lingui si vous voulez ICU MessageFormat avec des macros typées, vos traducteurs travaillent en .po avec un pipeline TMS existant, vous préférez les chaînes source inline en JSX, et votre équipe est à l'aise avec la gestion du workflow extract / compile / catalog-splitting. Son JS par page est compétitif une fois le lazy loading configuré.
• Choisir Intlayer si vous voulez du contenu scoped au composant, du TypeScript strict, des erreurs de clés manquantes au build-time, du tree-shaking et lazy loading sans effort, de petits composants, une hydratation rapide, un changement de locale instantané, et des outils éditoriaux intégrés (Visual Editor, CMS, traduction IA, serveur MCP). Particulièrement pertinent pour les grandes codebases modulaires et les design systems.
• Choisir @intlayer/lingui si vous êtes sur Lingui et souhaitez migrer progressivement vers les dictionnaires Intlayer sans modifier les macros.

Comparaisons associées

• next-intl vs Intlayer (même benchmark)
• i18next vs Intlayer (même benchmark)
• vue-i18n vs Intlayer benchmark (même benchmark)
• Compiler vs declarative i18n

Étoiles GitHub

Les stars GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien que ce ne soit pas une mesure directe de la qualité technique, ils reflètent le nombre de développeurs qui trouvent le projet utile, suivent sa progression et sont susceptibles de l'adopter.

Conclusion

Lingui est la plus forte bibliothèque runtime-plus-compiler dans ce benchmark. Ses catalogs compilés et hashés lui donnent du JavaScript par page dans quelques KB de Intlayer, et même légèrement en dessous sur TanStack Start. Si les bytes par page étaient la seule métrique, ce serait une égalité.

Ce n'est pas le cas. Le compilateur de Lingui s'arrête à la locale ; tout ce qui est en dessous (catalogs par route, chargement différé, exclusion de la fallback du bundle) est configuration, et le benchmark montre le coût de cette limite : composants 10-20x plus volumineux, hydratation 2-3x plus lente, 3-15% de fuite de locale qui ne disparaît jamais, et un changement de locale de 42 ms dans la configuration optimisée. Le compilateur d'Intlayer fonctionne au niveau du composant, donc ces chiffres sont 6-8 KB, 11-14 ms, 0% et 3-4 ms sans aucune configuration.

Toutes les données brutes, les applications de test et les scripts se trouvent dans le référentiel Benchmark Bloom. Exécutez-le vous-même.

Consultez le document 'Pourquoi Intlayer ?' pour plus de détails.