Wie man die richtige React i18n-Bibliothek auswählt

React liefert keine native i18n-Primitive mit. Die Bibliothek, für die Sie sich an Tag eins entscheiden, bestimmt, wie Übersetzungen gespeichert werden, wie sie in das Bundle gelangen und wie viel Arbeit in den nächsten Jahren bei Ihnen verbleibt. Die meisten Teams wählen nach Popularität und entdecken die Kompromisse erst bei 2.000 Schlüsseln.

Dieser Leitfaden wählt den umgekehrten Weg: Beantworten Sie zuerst einige Fragen zu Ihrem Projekt und ordnen Sie die Antworten dann den passenden Bibliotheken zu. Er konzentriert sich auf reines React (Vite, React Router, TanStack Start). Next.js hat eigene Einschränkungen, die im Next.js-Vergleich behandelt werden.

Inhaltsverzeichnis

Sechs Fragen vor dem Vergleich von Bibliotheken

Eine Feature-Tabelle ist nutzlos, wenn man nicht weiß, welche Zeilen für einen relevant sind. Gehen Sie diese Punkte zuerst durch.

1. Wie wird die App gerendert? Reine SPA, SSR mit Hydration oder React Server Components. Kontextbasierte Hooks funktionieren überall in einer SPA. Bei RSC erzwingt ein Hook "use client" für jede Komponente, die Text rendert, sodass Sie auch eine serverseitige API benötigen.
2. Wer schreibt die Übersetzungen? Entwickler, ein internes Team mit einem TMS, eine Agentur, die ICU-Dateien liefert, oder eine KI-Pipeline. Dies bestimmt das Katalogformat weit mehr als jedes API-Detail.
3. Wie viele Sprachen und Seiten? Zwei Sprachen und fünf Seiten können es sich leisten, alles auf einmal auszuliefern. Zehn Sprachen und fünfzig Routen können das nicht, und die Ladestrategie wird zum Hauptkostenfaktor.
4. Benötigen Sie Typisierung für Schlüssel? Ein Tippfehler in t("checkout.totl") kompiliert in jeder schlüsselbasierten Bibliothek, es sei denn, Sie richten die Typen selbst ein. Entscheiden Sie, ob das akzeptabel ist.
5. Was enthält der String? Reinen Text, Pluralformen oder Sätze mit einem <Link> in der Mitte. Bei Rich Content werden die meisten APIs unhandlich.
6. Wie lange wird das Projekt leben? Ein Drei-Monats-Prototyp und ein Fünf-Jahres-Produkt benötigen nicht denselben Umfang an Build-Tooling.

Schreiben Sie die Antworten auf. Alles Folgende bezieht sich darauf.

Die Landschaft auf einen Blick

Fünfzehn Jahre JavaScript-i18n lassen sich in vier architektonische Wellen unterteilen, und die React-Bibliotheken, die Sie vergleichen werden, stammen aus unterschiedlichen Epochen.

Die Geschichte von JavaScript i18n beschreibt detailliert, wie jede Welle auf die Probleme der vorherigen reagierte.

Die wichtigste Entscheidung: Wo Inhalte liegen und wann sie laden

Jede React i18n-Bibliothek besitzt die gleiche Grundstruktur: ein Store, ein Provider, ein Hook. Was immer der Provider empfängt, landet im Client-Bundle oder im Hydration-Payload. Die beiden strukturellen Entscheidungen lauten daher:

• Zentralisierter oder abgegrenzter (scoped) Inhalt. Eine en.json für die gesamte App oder eine Deklaration pro Komponente (bzw. pro Namespace).
• Statischer oder dynamischer Import. Alles beim Start gebündelt oder die aktive Sprache und Route bei Bedarf nachgeladen.

Die folgende Grafik schätzt den Payload für eine theoretische App mit 1 bis 10 Seiten, übersetzt in 1 bis 10 Sprachen, mit etwa 30 KB Text pro Seite.

Zentralisierter Inhalt mit statischen Importen wächst entlang beider Achsen: 10 Seiten mal 10 Sprachen ergeben 300 KB Text auf jeder einzelnen Seite. Dynamische Importe eliminieren die Sprachachse. Scoping eliminiert die Seitenachse. Nur die Kombination aus beidem bleibt konstant flach.

Dies ist keine reine Eigenschaft der Bibliothek, sondern eine Frage der Disziplin. react-i18next kann mit Namespaces und Lazy-Backends aufgeteilt werden. use-intl lässt sich pro Route splitten. Aber nichts erzwingt es, und ein geteilter <Button>, der auf t("common:cta") zugreift, macht common unbemerkt zu einer Abhängigkeit jeder Route. Der Benchmark misst dies als "Leakage von anderen Routen" und "Leakage von anderen Sprachen", und genau hier entsteht der größte Unterschied zwischen den Bibliotheken.

Wenn Ihre Antwort auf Frage 3 "viele Sprachen, viele Seiten" war, gewichten Sie diesen Abschnitt höher als jede API-Präferenz. Der Beitrag Per-Komponente vs. Zentralisiertes i18n geht tiefer auf die Wartungsseite derselben Entscheidung ein.

Die Kandidaten

Die Bibliotheksgrößen stammen aus dem TanStack Start-Benchmark: Provider plus Hook in einer leeren Komponente nach Bundling, Tree-Shaking und Minifizierung bei 10 Seiten und 10 Sprachen. Der Inhalt wird separat gemessen.

Die Zahlen sind eine Momentaufnahme der Benchmark-Versionen und ändern sich mit neuen Releases. Führen Sie den Benchmark für Ihre eigene Anwendung aus, bevor Sie sich allein aufgrund der Größe entscheiden.

Zwei Aspekte, die die Tabelle nicht zeigt: Paraglide liefert kaum eigenen Bibliothekscode aus, da es Code direkt in Ihr Repository generiert. Das bedeutet einen Regenerierungsschritt vor jedem Commit und potenzielle Merge-Konflikte in generierten Dateien. Und Intlayer benötigt ein Bundler-Plugin (vite-intlayer oder ein Äquivalent), weshalb es nicht in einem No-Build-Setup laufen kann.

Ordnen Sie Ihre Antworten einer Bibliothek zu

Wo die Schwachstellen der einzelnen Bibliotheken liegen

Ehrliche Einschränkungen, denn jede Option hat Kompromisse.

• react-i18next: schwerstes Paket der Auswahl, eigenes Pluralformat, Typen müssen manuell konfiguriert und gepflegt werden, verwaiste Schlüssel sammeln sich unbemerkt an.
• react-intl: ausführliche Developer Experience (useIntl(), dann formatMessage({ id })), globale Instanz ist an viele Knoten gekoppelt.
• use-intl: einfacher Einstieg, mühsam zu optimieren. Namespaces, dynamisches Laden und Typen verlangsamen in Kombination die Entwicklung spürbar.
• Lingui: zusätzlicher extract / compile Build-Schritt, mehrere überlappende Syntaxen (t(), Tagged Templates, i18n.t(), <Trans>), die sowohl Menschen als auch KI-Assistenten verwirren können.
• Paraglide: generierte Dateien im Repository, Tree-Shaking griff im React-Benchmark nicht wie erwartet, und die Sprache wird an jedem Knoten aus dem Storage statt aus einem zentralen Store gelesen.
• Tolgee: keine Schlüssel-Typen, steilere Einarbeitung, In-Context-Bearbeitung ist das Hauptargument.
• Intlayer: verpflichtendes Build-Plugin, kleineres Ökosystem, partielle ICU-Unterstützung, Inhalte sind per Design über die Codebase verteilt, sodass der Export einer einzelnen JSON-Datei für Übersetzer zusätzliches Tooling erfordert.
• gt-react, lingo.dev: im Benchmark nicht empfohlen: Quota-Fehler beim Build, Vendor-Lock-in und Reaktivitätsprobleme, die erzwungene Provider-Re-Renders erforderten.

Wie die Optionen im Code aussehen

Die gleiche Komponente, eine Warenkorb-Zusammenfassung mit Titel und Pluralform, umgesetzt mit jedem Kandidaten. Der interessante Teil ist nicht die Komponente selbst, sondern wo der Inhalt liegt und was die Typprüfung darüber weiß.

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

Nutzen Sie bereits react-i18next, react-intl oder Lingui? Die Compat-Adapter (react-i18next, react-intl, Lingui) vergeben Alias-Namen für Importe auf Bundler-Ebene, sodass die bestehende API weiterfunktioniert, während Sie Komponente für Komponente migrieren. Der Migrationsleitfaden deckt die weiteren Schritte ab.

Vor Ihrer endgültigen Entscheidung

Eine Feature-Tabelle zeigt, was eine Bibliothek heute leistet. Die folgenden Punkte zeigen, wie sich der Alltag damit anfühlt.

Überprüfen Sie die Aktivität im Repository.

Commits, Antwortzeiten bei Issues und ob das letzte Minor-Release in diesem Jahr stattfand. Ein solides Konzept ohne aktiven Maintainer ist eine vorprogrammierte Migration.

Wählen Sie nicht rein nach npm-Downloadzahlen.

Die am häufigsten installierte Bibliothek ist diejenige, die zuerst veröffentlicht wurde, nicht zwingend diejenige, die zu einer React-Codebase im Jahr 2026 passt. Downloadzahlen spiegeln Historie wider, nicht Passgenauigkeit.

Hinterfragen Sie, wer die Maintainer finanziert und was verkauft wird.

i18next wird von Locize unterstützt. next-intl / use-intl, vue-i18n, svelte-i18n und Lingui werden von Crowdin unterstützt. Tolgee, Paraglide (inlang) und Intlayer betreiben jeweils eine eigene Plattform. Ein Anbieter, dessen Umsatz auf gehosteter Übersetzung basiert, hat wenig Interesse daran, Übersetzungen innerhalb Ihrer eigenen Toolchain kostenlos zu machen. Intlayer ist die einzige Option im Feld, die KI-Übersetzungen über die CLI mit Ihrem eigenen API-Schlüssel bereitstellt sowie ein CMS bietet, das Sie selbst hosten können.

Ist die Lösung bereit für KI-Agenten?

Agenten haben nach wie vor Schwierigkeiten mit i18n: Sie vergessen Sprachen, erfinden Schlüssel und vermischen Nachrichtensyntaxen. Bietet die Bibliothek Agent Skills oder einen MCP-Server, damit der Agent Inhalte auflisten, auffüllen und testen kann? Und ist das Laden von Inhalten standardmäßig optimiert, oder muss vierteljährlich jemand Namespaces und Lazy-Imports manuell überprüfen?

Typsicherheit out of the box.

Nicht "kann mit zusätzlichem Konfigurationsaufwand typisiert werden", sondern "ein falscher Schlüssel lässt tsc bei einer Neuinstallation fehlschlagen". Prüfen Sie das Verhalten bei einem Schlüssel, der nicht existiert, sowie bei einer Sprache, in der eine Übersetzung fehlt.

Erkennung ungenutzter Inhalte.

Kataloge wachsen meist nur an. Der Build von Intlayer bereinigt ungenutzte Felder und protokolliert diese (build.purge). Paraglide erreicht dies durch seine Architektur, da eine nicht aufgerufene Nachrichtenfunktion dem Tree-Shaking zum Opfer fällt. Alle anderen Optionen überlassen das Aufräumen Ihnen.

Developer Experience.

Einrichtungszeit bis zum ersten übersetzten String, ein LSP oder eine VS Code-Erweiterung, die Übersetzungen beim Hovern anzeigt und zur Deklaration springt, eine CLI zum Befüllen, Testen und Pushen sowie eine Möglichkeit für Nicht-Entwickler, Inhalte über einen visuellen Editor oder ein CMS ohne Pull Request zu bearbeiten.

Häufig gestellte Fragen (FAQ)

Weiterführende Links

• i18n-Bibliotheken-Benchmark: Bundle-Größe, Leakage und Sprachwechsel-Timings und der TanStack Start-Bericht
• React i18n: Wie das Provider-Modell funktioniert und was es kostet
• react-i18next vs. react-intl vs. Intlayer, Feature für Feature
• next-i18next vs. next-intl vs. Intlayer
• Die Geschichte von JavaScript i18n
• Compiler vs. deklarative i18n
• Per-Komponente vs. Zentralisiertes i18n
• Wie Bundle-Optimierung zur Build-Zeit funktioniert
• i18n in einer Vite + React-App einrichten
• Der gleiche Leitfaden für Vue, Svelte und Solid