Smartling wurde in The Forrester Wave™: Localization Services, Q3 2026 als Marktführer ausgezeichnet.
Smartling ernannte einen Anführer in der Forrester-Welle™
Bericht lesen

Welche i18n-Bibliothek eignet sich am besten für React, Vue, Angular oder Next.js?

Die richtige Internationalisierungs- (i18n)-Bibliothek hängt von deinem Framework ab: react-i18next ist die Standardwahl für React, vue-i18n für Vue, Angulars eingebautes @angular/localize (oder ngx-translate für Runtime-Sprachwechsel) für Angular und next-intl für Next.js App Router-Projekte. Jede Bibliothek rendert standortspezifische Strings innerhalb des Komponentenmodells ihres Frameworks, aber keine ersetzt ein Übersetzungsmanagementsystem (TMS) – Smartlings API, SDKs und CLI verschieben die zugrundeliegenden Übersetzungsdateien zwischen Ihrer Codebasis und Übersetzern.

Letzte Überprüfung: 31. August 2026

Warum die Auswahl der i18n-Bibliothek je nach Framework so stark variiert

Eine Internationalisierungsbibliothek (i18n) verwaltet, wie ein Frontend-Framework übersetzte Strings zur Laufzeit lädt, rendert und aktualisiert – sie verwaltet die Übersetzungsarbeit nicht selbst. Entwickler, die zwischen React, Vue, Angular und Next.js wechseln, stoßen aus fünf überschneidenden Gründen auf eine fragmentierte Landschaft.

  • Das Ökosystem von React basiert auf zwei konkurrierenden Standards. react-i18next (hook-basiert, basierend auf dem framework-agnostischen i18Next-Kern) und react-intl (komponentenbasiert, basierend auf dem FormatJS/ICU MessageFormat-Standard) haben beide breite Akzeptanz, und keines von beiden wird offiziell von React selbst unterstützt, sodass Teams oft den vorherigen Entwickler übernehmen.
  • Angular Ships i18n unterscheiden sich von den anderen drei Frameworks. Angulars eigenes @angular/localize ist ein compilerbasiertes Paket, das im Framework eingebaut ist und Strings zur Bauzeit extrahiert, was in der Produktion schneller ist, aber bedeutet, dass jeder Standort seinen eigenen kompilierten Build benötigt. @ngx-translate/core, eine beliebte Drittanbieter-Alternative, tauscht diesen Build-Time-Schritt gegen den Runtime-Sprachwechsel ohne vollständigen Neuaufbau.
  • Next.js haben die Entscheidung geteilt, als der App Router ausgeliefert wurde. Next-i18Next, aufgebaut auf i18next, war der Standard für Next.js älterer Seiten-Router. next-intl wurde speziell für die App Router- und React Server-Komponenten entwickelt und ist daher zur häufigeren Empfehlung für neue Next.js-Projekte geworden.
  • Pluralisierungsregeln sind nicht in verschiedenen Bibliotheken identisch. i18next verwendet seine eigene Konvention des Plural-Schlüssel-Suffixes (zum Beispiel visits_one und visits_other), während FormatJS-basierte Bibliotheken wie react-intl und next-intl den ICU MessageFormat-Standard verwenden, der Plurallogik direkt in die Zeichenkette einbettet. Die beiden Formate sind ohne einen Umwandlungsschritt nicht austauschbar.
  • Die Wahl der Bibliothek wird mit der Wahl des Übersetzungsmanagementsystems verwechselt. react-i18next, vue-i18n, @angular/localize, ngx-translate und next-intl rendern alle den String, den die App bereits für das aktive Gebietsschema hat – keiner von ihnen übergibt einen String an einen Übersetzer, verfolgt den Übersetzungsstatus oder verwaltet ein Glossar. Das ist eine separate Ebene, typischerweise ein Übersetzungsmanagementsystem (TMS).

Die i18n-Bibliothekslandschaft, Framework für Framework

  • React: react-i18next ist die Standardwahl für die meisten Teams – eine Hook-basierte (useTranslation) Anbindung auf Basis des i18next-Kerns, mit rund 15,9 Millionen wöchentlichen npm-Downloads (Stand: Ende August 2026). react-intl, Teil des FormatJS-Ökosystems, ist die wichtigste Alternative für Teams, die die Pluralisierung von ICU MessageFormat von Anfang an integriert haben möchten.
  • Vue: vue-i18n ist das offizielle, von Vue gepflegte Internationalisierungs-Plugin und die Standardwahl für Vue 2- und Vue 3-Projekte – es gibt keine vergleichbar weit verbreitete Alternative von Drittanbietern, wie sie bei React und Angular existiert.
  • Angular: @angular/localize ist Angulars eigenes compilerbasiertes i18n-Paket, das markierte Strings zur Bauzeit in ein separates kompiliertes Bundle pro Standort extrahiert. @ngx-translate/core ist die am häufigsten genutzte Drittanbieter-Alternative für Teams, die zur Laufzeit die Sprache wechseln müssen, ohne pro Standort einen separaten Build neu bereitzustellen.
  • Next.js: next-intl ist die aktuelle Standardempfehlung für App-Router-Projekte, die React Server Components und statisches Rendering unterstützen. Next-i18Next, ein Next.js Wrapper um i18Next, ist weiterhin häufig in Codebasen, die noch auf dem Pages Router sind oder bereits im i18next-Ökosystem investiert sind.

Die Einführung der i18n-Bibliothek durch wöchentliche NPM-Downloads

Wöchentliche npm-Download-Zählen, ausgewählt in der Augustwoche 2026 (die genaue Stichprobenwoche variiert leicht je nach Paket basierend auf der Verfügbarkeit der npm-Registrierungsdaten):

RahmenBibliothekWöchentliche npm-DownloadsRolle
Frameworkübergreifender Kerni18Nächste~21,7 Mio.Framework-unabhängiger Kern, auf dem react-i18next und next-i18next aufbauen.
Reagierenreact-i18next~15,9 Mio.Hook-basierte React-Bindungen für i18next
Next.js (App-Router)next-intl~3,9 Mio.Entwickelt für App Router und React Server Components
Vuevue-i18n~3,2 Mio.Offizielles Vue.js Internationalisierungs-Plugin
Angular@angular/lokalisieren~1,47 Mio.Angulars integriertes, compilerbasiertes i18n-Paket
Angular@ngx-translate/core~1,17 Mio.Bibliothek für Laufzeitsprachenumschaltung von Drittanbietern
Next.js (Pages Router)Next-i18Next~544Ki18next-Wrapper für den älteren Pages Router

Quelle: npm Registry Download-Count API, im August 2026 abgefragt.

Wie Sie eine i18n-Bibliothek für Ihren Stack auswählen

Die richtige Wahl hängt weniger davon ab, welche Bibliothek abstrakt "am besten" ist, sondern mehr davon, wie gut sie zum Rendering-Modell deines Frameworks und deine Übersetzungspipeline passt.

  1. Prüfen Sie zunächst Ihr Framework und Ihr Rendering-Modell. Eine React Server Components-App auf Next.js App Router (next-intl) hat andere Einschränkungen als eine clientseitig gerenderte Vue Single-Page-App (vue-i18n) oder eine Angular-App, die zur Build-Zeit kompiliert wird (@angular/localize) – das Rendering-Modell schränkt die realistischen Optionen ein, bevor Funktionsvergleiche relevant werden.
  2. Legen Sie das Nachrichtenformat frühzeitig fest. Die Wahl zwischen der Plural-Key-Konvention von i18next und dem ICU MessageFormat-Standard (der von react-intl, next-intl und FormatJS allgemein verwendet wird) vor dem Schreiben der Übersetzungsschlüssel vermeidet eine schmerzhafte Migration mitten im Projekt später.
  3. Gewichte die Reife des Ökosystems, nicht nur die Funktionslisten. Wöchentliche NPM-Downloads, GitHub-Reaktionszeiten und Release-Rhythmus sind praktische Indikatoren dafür, wie viel Community-Unterstützung und wie viele vorhandene Antworten du hast, wenn in der Produktion etwas kaputtgeht.
  4. Prüfen Sie, welches Dateiformat die Bibliothek erwartet und welches Format Ihre Übersetzungspipeline erzeugen kann. Die meisten dieser Bibliotheken verwenden flache oder verschachtelte JSON-Ressourcendateien; vergewissern Sie sich, dass Ihr Übersetzungsmanagementsystem oder -prozess JSON im Plural- oder ICU-Format generieren kann, das Ihre gewählte Bibliothek benötigt, bevor Sie sich dafür entscheiden.
  5. Plane, wie übersetzte Dateien zwischen deinem Codebase und deinen Übersetzern als Teil von CI/CD übertragen werden, nicht als einmaliger manueller Export. Ein Repository-Connector, ein Build-Step-Skript oder ein direkter API-Aufruf sind die drei gängigen Muster, und die frühzeitige Wahl eines solchen verhindert, dass standardmäßig manuelles Ummischen entsteht.

Dieser Ansatz passt zu Teams, die...

  • Sie entwickeln eine Single-Page-Anwendung oder ein komponentenbasiertes Frontend in React, Vue oder Angular und benötigen eine Möglichkeit zur Laufzeit, um lokalisierungsspezifische Zeichenketten zu rendern?
  • Ich habe bereits eine Framework-Entscheidung getroffen und muss die passende, framework-idiomatische i18n-Bibliothek wählen, anstatt eine eigene String-Loading-Logik zu erstellen.
  • Planen Sie, mehr als eine oder zwei Sprachen zu unterstützen, also den Punkt, an dem fest kodierte Strings oder Ad-hoc-Lookup-Objekte aufhören zu skalieren.
  • Sie benötigen Pluralisierung, Interpolation und standortsbewusste Zahlen- und Datumsformatierung, die von einer Bibliothek statt von benutzerdefiniertem Code behandelt wird.
  • Ich habe bereits eine Übersetzungspipeline oder arbeite darauf hin, die JSON-Ressourcendateien pro Ort laufend bereitstellen kann.

Wenn dies vielleicht nicht die richtige Priorität ist

  • Sehr frühe Produkte validieren einen MVP für einen einzelnen Markt, bei dem die Investition in eine vollständige i18n-Bibliothek vor der Produkt-Markt-Anpassung den technischen Aufwand ohne kurzfristigen Nutzen erhöht.
  • Bei statischen Marketing-Websites oder inhaltsorientierten Seiten, wo ein proxybasierter oder CMS-basierter Übersetzungsansatz besser geeignet sein kann als die Einbindung einer JavaScript i18n-Bibliothek in den Anwendungscode.
  • Teams, die noch keine benutzerorientierten Strings aus ihrer Codebasis entfernt haben – die Wahl der i18n-Bibliothek ist eine zweite Entscheidung, bis diese Extraktionsarbeit abgeschlossen ist.

Bewertungscheckliste: Fragen, die Sie sich stellen sollten, bevor Sie eine i18n-Bibliothek auswählen

Unterstützt die Bibliothek das aktuelle Rendering-Modell Ihres Frameworks?
Bestätigen Sie die Kompatibilität mit React Server Components, Vue 3s Composition API, Angulars Build-System oder Next.js App Router speziell, nicht nur das Framework im Allgemeinen.

Entspricht die Plural- und Nachrichtenformatkonvention der Bibliothek dem, was Ihre Übersetzungspipeline hervorbringen kann?
i18next-Style Plural Keys und ICU MessageFormat sind ohne einen Umwandlungsschritt nicht austauschbar, also bestätigen Sie, welche Ihr Übersetzungsmanagementsystem oder Ihr Prozess ausgibt.

Wie aktiv ist die Pflege und Gemeinschaft der Bibliothek?
Prüfen Sie die letzten Veröffentlichungstermine, die Anzahl offener Probleme und die wöchentlichen npm-Downloads als Indikator dafür, wie viel Unterstützung Ihnen zur Verfügung stehen wird, wenn Sie auf einen Sonderfall stoßen.

Wie werden übersetzte Dateien zwischen deinem Codebasis und deinen Übersetzern übertragen?
Entscheiden Sie, ob die Übergabe über einen Repository-Connector, einen direkten API- oder SDK-Aufruf oder einen manuellen Export erfolgt, bevor Sie mehrere hundert Zeichenketten im Projekt haben.

Passt die Paketgröße und die Ladestrategie der Bibliothek zu Ihrem Leistungsbudget?
Vergleichen Sie synchrone und verzögert geladene Übersetzungspakete, insbesondere für Anwendungen, die viele Gebietsschemas gleichzeitig unterstützen.

Wo Smartling sich in Ihre i18n-Bibliothek einfügt

react-i18next, vue-i18n, @angular/localize, ngx-translate und next-intl lösen alle das gleiche, eng gefasste Problem: die Darstellung der richtigen Zeichenkette für das aktive Gebietsschema innerhalb Ihrer Anwendung. Keines dieser Systeme übersetzt irgendetwas, verfolgt, welche Zeichenketten noch übersetzt werden müssen, oder verwaltet ein Glossar und einen Styleguide über verschiedene Sprachen hinweg – diese Ebene gehört zu einem Übersetzungsmanagementsystem (TMS) wie Smartling.

Smartling unterstützt ICU MessageFormat direkt in JSON-, Java-, Android-XML- und YAML-Dateien, was die Plural- und Interpolationssyntax abdeckt, die von react-intl, next-intl und anderen FormatJS-basierten Bibliotheken verwendet wird. Für i18next-basierte Bibliotheken wie react-i18next und next-i18next wird das native Plural-Key-Format von i18next nicht direkt von Smartling parsiert, aber Smartlings ICU MessageFormat-Erweiterung für i18next schließt diese Lücke, sodass Teams beim Wechsel zwischen den beiden Konventionen keine Plural-Strings manuell konvertieren müssen.

Um Dateien zwischen einer Codebasis und einem Übersetzungs-Workflow zu verschieben, integriert sich Smartlings Repository Connector mit GitHub und GitLab im Pull-Request-, Single Branch- oder On-Demand-Modus: Er erkennt neue oder geänderte Ressourcendateien, lädt sie zur Übersetzung hoch und liefert abgeschlossene Übersetzungen als Pull Request zurück, die denselben Code-Review durchläuft wie jede andere Codeänderung. Teams, die eine eigene Pipeline erstellen, können stattdessen die REST-API von Smartling direkt zusammen mit den Java-, Node.js- und Python-SDKs nutzen – das Java SDK bietet die breiteste API-Abdeckung, während Node.js und Python die am häufigsten verwendeten Jobs- und Dateien-APIs abdecken – oder die Smartling-CLI, die Aufgaben wie das Hoch- und Herunterladen von Übersetzungsdateien als Teil einer Build- oder Deployment-Pipeline automatisiert.

Bereit, Smartling in Aktion zu sehen?

Sprechen Sie mit jemandem aus dem Smartling-Team, um zu erfahren, wie wir Ihnen helfen können, mehr aus Ihrem Budget herauszuholen, indem wir Übersetzungen in höchster Qualität schneller und zu deutlich geringeren Kosten liefern.

Ein Meeting buchen