Next.js-Internationalisierung: i18n-Konfiguration vs. automatische Übersetzung (2026)
Next.js bietet zwei grundlegend unterschiedliche Wege zu einer mehrsprachigen App: integriertes i18n-Routing kombiniert mit einer Übersetzungsbibliothek und DOM-basierte automatische Übersetzung mit einem einzigen Script-Tag. Dieser Leitfaden erklärt beide Ansätze — was jeder davon tatsächlich leistet, was er kostet und wann Sie ihn wählen sollten.
Next.js-i18n-Routing: Was es bietet
Next.js bringt eine integrierte i18n-Routing-Schicht mit, die in next.config.ts konfiguriert wird. Sie übernimmt zwei Dinge: URL-Routing (/fr/, /de/-Präfixe) und Browser-Spracherkennung über den Accept-Language-Header.
Was sie nicht tut: Inhalte übersetzen. Die i18n-Routing-Konfiguration ist reine Infrastruktur — sie richtet die URL-Struktur und die Spracherkennung ein und übergibt dann. Für tatsächlich übersetzten Text in Ihren Komponenten fügen Sie zusätzlich eine Übersetzungsbibliothek hinzu: next-intl, react-i18next oder LinguiJS.
Die Routing-Konfiguration allein sorgt bereits dafür, dass der Aufruf von yourapp.com/fr/dashboard als eigenständige URL funktioniert — nützlich für SEO und teilbare Links — aber ohne Übersetzungsbibliothek wird die Seite weiterhin auf Englisch dargestellt.
Der vollständige i18n-Stack für Next.js
Eine vollständige Next.js-i18n-Einrichtung mit next-intl umfasst folgende Bausteine:
- 1Einen
next.config.ts-i18n-Block, der unterstützte Sprachen und die Standardsprache deklariert. - 2Sprachspezifische JSON-Nachrichtendateien:
messages/en.json,messages/fr.jsonusw., die im Repository verwaltet und bei jeder neuen UI-Zeichenkette aktualisiert werden. - 3Typsichere Nachrichtenschlüssel, generiert aus der englischen Quelldatei, damit TypeScript fehlende oder falsch geschriebene Schlüssel bereits zur Kompilierzeit erkennt.
- 4Server Components laden Nachrichten über
getTranslations(); Client Components werden mit<NextIntlClientProvider>umschlossen. - 5RTL-Sprachen (Arabisch, Hebräisch) erfordern zusätzlich separate CSS-Arbeit:
dir="rtl"am Wurzelelement, logische Property-Utilities und Icon-Spiegelung.
Ein minimaler next.config.ts-i18n-Block:
Und eine passende messages/en.json:
Jeder Schlüssel in en.json muss in jeder weiteren Sprachdatei dupliziert, übersetzt und mit der Weiterentwicklung des Produkts synchron gehalten werden.
Die Kosten in großem Maßstab
Der Mehraufwand pro Zeichenkette beim Einbetten in t() ist gering. Die Gesamtkosten summieren sich jedoch schnell:
Kopplung von Inhalt und Code
Jede neue UI-Zeichenkette erfordert einen neuen Schlüssel in der Quelldatei und einen entsprechenden Eintrag in jeder Zielsprachdatei. Ein am Montag ausgeliefertes neues Feature bedeutet, dass die französischen und deutschen Dateien aktualisiert werden müssen, bevor französische und deutsche Nutzer mehr als einen Schlüssel-Fallback sehen.
Pluralregeln pro Sprache
Englisch hat zwei Pluralformen. Arabisch hat sechs. Polnisch hat vier mit komplexen Regeln. Das ICU-Nachrichtenformat löst dies, aber jede Pluralzeichenkette benötigt eine separate Definition pro Sprache — der naive Ansatz einer einzelnen Zeichenkette mit einer Anzahl scheitert bei vielen Sprachen.
Interpolation für dynamische Werte
Zeichenketten wie “Welcome, {name}!” oder “You have {count}items” benötigen eine Interpolationssyntax, die je nach Bibliothek variiert, in allen Sprachen getestet werden muss und in Sprachen mit abweichender Wortstellung grammatikalisch falsche Ergebnisse liefern kann.
TypeScript-Mehraufwand
Typsichere Schlüssel erfordern eine generierte Typdatei, die aus der englischen Quelldatei abgeleitet wird. Dieser Generierungsschritt muss in der CI laufen, verlängert die Build-Zeit und lässt den Build fehlschlagen, wenn die Quellsprachdatei strukturelle Probleme hat — nützlich, aber nicht kostenlos.
RTL ist ein eigenes Projekt
next-intl und react-i18next übersetzen Text; sie kehren nicht die Layoutrichtung um. Unterstützung für Arabisch und Hebräisch erfordert separate Arbeit: das Setzen von dir="rtl", die Prüfung jeder Komponente auf physische CSS-Eigenschaften (margin-left → margin-inline-start) und das Testen des gesamten Layouts im RTL-Modus.
Wann die Next.js-i18n-Konfiguration die richtige Wahl ist
Es gibt konkrete Kontexte, in denen der vollständige Bibliotheks-Stack gerechtfertigt oder erforderlich ist:
Open-Source-Apps mit Community-Übersetzungen
Wenn Übersetzungen von der Community auf GitHub beigetragen werden (als JSON- oder PO-Dateien), ist ein Standard-Bibliotheksformat die richtige Schnittstelle für Mitwirkende. Automatische Übersetzung bedient dieses Modell nicht.
Regulierte, compliance-pflichtige Inhalte
Regulierte Branchen (Recht, Medizin, Finanzen) können verlangen, dass jede UI-Zeichenkette explizit geprüft und freigegeben wird. Eine i18n-Bibliothek macht jede Zeichenkette zu einem prüfbaren, diskreten Artefakt mit Versionshistorie.
Umfangreiche Zahlen-, Datums- und Währungsformatierung
Analyse-Dashboards und Buchhaltungstools, die durchgängig Zahlen, Daten und Währungen formatieren, profitieren von der sprachbewussten Intl-API-Integration, die FormatJS und next-intl von Haus aus bieten.
Offline-fähige Apps
PWAs mit vollständiger Offline-Unterstützung benötigen zur Build-Zeit gebündelte Übersetzungsdateien, da sie im Offline-Zustand keine Übersetzungs-API aufrufen können. Bibliotheksbasiertes i18n ist hier die einzige Option.
Automatische Übersetzung: So funktioniert sie mit Next.js
Die Alternative ist ein Script-Tag in Ihrem Root- app/layout.tsx, platziert innerhalb des <body>-Elements. Keine Änderungen an next.config.ts, keine Locale-Routing-Konfiguration, keine JSON-Dateien.
Das Script nutzt einen MutationObserver, um den DOM nach dem Rendern durch Next.js zu beobachten. Das deckt Folgendes ab:
- Anfängliches Server-Component-HTML — der auf dem Server gerenderte und an den Browser gestreamte Seiteninhalt.
- Inhalte nach der Hydration — Zustandsänderungen von Client Components, Daten aus
useEffect, lazy geladene Komponenten. - Client-seitige Navigation — Next.js-Routenwechsel lösen den Observer für den neu gerenderten Seiteninhalt aus.
- RTL-Layout —
document.documentElement.dirwird beim Wechsel zu Arabisch, Hebräisch oder einer anderen RTL-Sprache automatisch gesetzt.
Der Ansatz funktioniert sowohl mit App Router als auch mit Pages Router. Das Rendering-Modell (Server oder Client) spielt keine Rolle — nur die endgültige DOM-Ausgabe zählt.
Vergleich der Einrichtung
Der Unterschied in der Einrichtungskomplexität ist erheblich. Hier ist der next-intl-Weg im Vergleich zum Lingvit-Script-Tag-Weg:
next-intl-Einrichtung (~8 Dateien, ~200 Zeilen Konfiguration)
Lingvit-Einrichtung (1 Zeile)
Was automatische Übersetzung nicht abdeckt
DOM-basierte Übersetzung hat reale Grenzen, die Sie vor der Entscheidung kennen sollten:
Serverseitige E-Mail-Texte
Transaktions-E-Mails, die aus Zeichenketten-Konstanten im Servercode aufgebaut werden, werden nie in einen Browser-DOM gerendert. Sie benötigen eine separate Übersetzungslösung — ein mehrsprachiges E-Mail-Vorlagensystem oder sprachspezifische E-Mail-Vorlagen.
Zeichenketten, die nie in den DOM gerendert werden
Fest codierte Zeichenketten, die nur für Logging, API-Antworten für Nicht-Browser-Clients oder ausschließlich serverseitig verarbeitete Inhalte verwendet werden, sind für den MutationObserver nicht sichtbar und werden nicht übersetzt.
Komplexe ICU-Pluralisierung
Anwendungen, die für dynamisch gezählte Werte eine grammatikalisch korrekte Pluralisierung in Arabisch (sechs Pluralformen) oder Polnisch (vier Formen mit Ausnahmeregeln) benötigen, erfordern Unterstützung für das ICU-Nachrichtenformat — das ist ein Bibliotheksfeature und keine Fähigkeit, die DOM-basierte Übersetzung automatisch bereitstellt.
Häufig gestellte Fragen
- Funktioniert Lingvit mit App-Router-Server-Components?
- Ja. Server Components erzeugen HTML, das der Browser empfängt und genau wie jedes andere HTML in den DOM einfügt. Das Lingvit-Script erfasst diesen Inhalt normal über den MutationObserver. Eine spezielle Behandlung für Server Components ist nicht nötig.
- Kann ich Lingvit zusammen mit next-intl verwenden?
- Ja. Wenn Sie next-intl für manche Zeichenketten nutzen und für den Rest automatische Übersetzung möchten, können beide koexistieren. Lingvit übersetzt alle zur Renderzeit im DOM vorhandenen Textknoten, einschließlich von next-intl gerenderter Zeichenketten, sofern diese in Ihren Sprachdateien noch nicht übersetzt sind.
- Was ist mit SEO — erzeugt automatische Übersetzung indexierbare Sprach-URLs?
- Nein, nicht als allgemeine Funktion zum Start. Nutzen Sie Next.js-Locale-Routing und serverseitig gerenderte Metadaten für unabhängig indexierbare Sprachseiten; Lingvit übernimmt die unterstützte Laufzeitübersetzung im Browser.
Weitere Anleitungen
Fügen Sie Ihrer Next.js-App Sprachen hinzu
Funktioniert mit App Router und Pages Router. Keine next.config-Änderungen nötig.