next-intl vs. react-i18next vs. Lingui: welche Bibliothek 2026?

Für ein Next.js-App-Router-Projekt nimmst du next-intl. Für eine React-SPA oder alles, was über ein einzelnes Framework hinauswachsen könnte, nimmst du react-i18next. Wenn dir Extraktion zur Build-Zeit und schlanke Bundles wichtiger sind als Ökosystemgröße, nimmst du Lingui. Alle drei sind Runtime-i18n-Bibliotheken: Sie liefern Übersetzungen an deine Komponenten aus, und keine von ihnen schreibt dir deine Keys oder Übersetzungsdateien. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die diese Keys und Kataloge aus deiner Codebase erzeugt, und funktioniert mit allen drei Bibliotheken.

Was machen diese drei Bibliotheken eigentlich?

Sie lösen alle dasselbe Runtime-Problem: Gegeben ein Key und ein Locale, liefere den richtigen String, korrekt pluralisiert und formatiert. Das umfasst Interpolation, Datums- und Zahlenformatierung sowie Pluralregeln über ICU-artige Nachrichten.

Was keine von ihnen macht: die Übersetzungen erzeugen. Eine Runtime-Bibliothek konsumiert einen Katalog, der bereits existiert. Jemand muss trotzdem jeden nutzersichtbaren String in deinen Komponenten finden, ihn durch einen Key ersetzen und pro Sprache eine Übersetzungsdatei füllen. Das ist eine eigene Ebene im Stack, und die beiden Ebenen getrennt zu halten ist der schnellste Weg, diesen Vergleich einzuordnen: Du wählst genau eine Runtime-Bibliothek, und die steht nicht in Konkurrenz zum Tooling, das ihre Kataloge füllt. Unsere Entwicklerdokumentation beschreibt diese Trennung im Detail.

Wann solltest du next-intl verwenden?

Wenn du auf Next.js mit dem App Router setzt. next-intl ist von den dreien die einzige Bibliothek, die um App-Router-Primitiven herum gebaut ist: asynchrone Server Components, locale-bewusste Navigations- und Routing-Helfer sowie Metadata-APIs. Stand September 2026 liegt sie bei Version 4 und kommt auf etwa fünf Millionen npm-Downloads pro Woche, was sie in der Praxis — nicht nur in der Theorie — zur Standardwahl für neue Next.js-Projekte macht.

Nachrichten folgen dem ICU-MessageFormat, sodass Plurale, Genus und Interpolation demselben Standard folgen, den der Rest der Branche verwendet. Falls dir ICU-Syntax neu ist: Wir haben eine verständliche Einführung ins ICU-MessageFormat geschrieben. Der Trade-off ist die Kopplung: next-intl ist eine Next.js-Bibliothek. Verlässt du Next.js, migrierst du deine i18n-Ebene mit.

Wann solltest du react-i18next verwenden?

Wenn du nicht auf Next.js setzt oder das größte Ökosystem im Rücken haben willst. react-i18next ist das React-Binding für i18next und mit rund vierzehn Millionen npm-Downloads pro Woche mit deutlichem Abstand die meistgenutzte React-i18n-Bibliothek. Der i18next-Core wird seit über einem Jahrzehnt gepflegt und hat Plugins für fast alles: Backends, die Kataloge über HTTP laden, Spracherkennung, Caching-Ebenen, Framework-Bindings über React hinaus.

Das ist die Bibliothek, zu der die meisten KI-Coding-Tools standardmäßig greifen. Bitte Cursor oder Lovable, „Übersetzungen“ zu einer Vite-+-React-App hinzuzufügen, und du bekommst fast immer ein i18next-Setup. Diese Standardwahl ist nachvollziehbar: Sie funktioniert überall, und ihr JSON-Katalogformat ist das, was im Ökosystem einer Lingua franca am nächsten kommt. Der Trade-off: Sie stammt aus der Zeit vor Server Components, braucht auf dem App Router also mehr Verdrahtung als next-intl, und die meiste Übersetzungsarbeit passiert clientseitig, sofern du nicht anders vorsorgst.

Wann ist Lingui die richtige Wahl?

Wenn Bundle-Größe und Ergonomie im Quellcode für dich Priorität haben. Lingui, Stand September 2026 bei Major-Version 6, verfolgt einen Compiler-first-Ansatz: Du schreibst Nachrichten inline mit Makros, und die CLI extrahiert sie zur Build-Zeit in Kataloge. Kompilierte Kataloge werden ohne Runtime-Parsing-Overhead ausgeliefert, was die i18n-Kosten in deinem Bundle niedrig hält.

Lingui setzt außerdem konsequent auf gettext-PO-Dateien als Katalogformat, mit dem professionelle Übersetzer:innen seit Jahrzehnten arbeiten. Die wöchentlichen Downloads liegen bei rund anderthalb Millionen, eine Größenordnung unter react-i18next – erwarte also weniger Stack-Overflow-Antworten und weniger Third-Party-Plugins. Lingui funktioniert generell mit React, nicht nur mit Next.js, ist aber wie react-i18next nicht so eng um App-Router-Primitiven herum gebaut wie next-intl.

Wie schneiden sie im Überblick ab?

Welche solltest du für eine KI-generierte Codebase wählen?

Wähle nach Framework, wie oben — aber wisse, dass die Bibliothekswahl nicht der Punkt ist, an dem KI-gebaute Apps scheitern. Cursor, Claude Code und Lovable erzeugen standardmäßig alle hartcodierte englische Strings, egal welche i18n-Bibliothek installiert ist, und ein Agent, der eine Komponente bearbeitet, fügt weiterhin welche hinzu, nachdem du die Bibliothek eingerichtet hast.

Die eigentliche Reihenfolge lautet also: Wähle die Runtime-Bibliothek, die dein Framework will, und löse dann Extraktion und Katalogpflege als eigenständiges Problem. Für den Next.js-Fall haben wir das vollständige Setup unter i18n zu einer mit Cursor gebauten Next.js-App hinzufügen dokumentiert, und die Next.js-Integrationsseite beschreibt, wie globalize.now Keys und Übersetzungsdateien für next-intl vorbereitet, bevor überhaupt Runtime-Verdrahtung stattfindet.

Brauchst du mit einer Runtime-Bibliothek trotzdem noch Lokalisierungsinfrastruktur?

Ja, denn die Bibliothek liest nur Kataloge — sie zu erzeugen und zu pflegen ist der Teil, der Zeit frisst. globalize.now sitzt genau auf dieser Ebene: Verbinde dein Repository, und es konvertiert die Codebase einmalig, ersetzt hartcodierte Strings durch Keys und erzeugt die Übersetzungsdateien. Nach dieser einmaligen Konvertierung übersetzen Push-Jobs die neuen Katalogeinträge, die deine Commits einbringen.

Der Output ist JSON oder PO — JSON für next-intl- und i18next-Setups, PO für Linguis natives Format —, sodass die Kataloge in genau der Form landen, die deine Runtime-Bibliothek bereits konsumiert. Falls deine App schon ein teilweises i18n-Setup hat, ist auch das kein Problem: globalize.now arbeitet mit bestehendem i18n, statt es zu ersetzen. Pläne und Nutzungssätze findest du auf der Preisseite.

Keine der drei Bibliotheken ist eine falsche Wahl. next-intl, wenn du auf dem App Router bist, react-i18next, wenn du das größte Ökosystem willst, Lingui, wenn du Extraktion zur Build-Zeit und PO-Kataloge willst. Wähle eine, halte deine Strings aus deinen Komponenten heraus, und lass die Katalogebene den Rest erledigen.