- React
- i18n
- Leitfaden
React-i18n vs. automatische Übersetzung: Welcher Ansatz passt zu Ihrer App? (2026)
10 Min. Lesezeit
React-Teams haben zwei grundlegend unterschiedliche Wege zu mehrsprachiger Unterstützung: i18n-Bibliotheken, die Ihren Quellcode instrumentieren, und automatische Übersetzung, die auf DOM-Ebene arbeitet. Keiner der beiden ist grundsätzlich besser. Dieser Leitfaden zeigt, wann welcher Ansatz die richtige Wahl ist.
Der traditionelle React-i18n-Ansatz
Die Standardbibliotheken für React-Internationalisierung sind react-i18next, react-intl (Teil von FormatJS) und LinguiJS. Trotz ihrer Unterschiede teilen sie denselben Kern-Workflow:
- Jede Zeichenkette in Ihren Komponenten durch einen
t()-Aufruf ersetzen:<p>Submit</p>wird zu<p>{t('form.submit')}</p>. - Eine JSON-Übersetzungsdatei pro Sprache anlegen:
en.json,fr.json,de.jsonusw. Jeder Schlüssel verweist auf eine übersetzte Zeichenkette. - Pluralisierung pro Sprache handhaben — die Regeln für Plurale in Polnisch oder Arabisch sind deutlich komplexer als im Englischen.
- Typsichere Schlüsseldefinitionen hinzufügen, damit TypeScript fehlende oder falsch geschriebene Übersetzungsschlüssel bereits zur Kompilierzeit erkennt (über
typescript-i18noder i18nexts eigene Typunterstützung). - Build oder Laufzeit so konfigurieren, dass das passende Sprachbündel geladen wird, und einen Prozess einrichten, damit neue, während der Entwicklung hinzugefügte Zeichenketten automatisch im Übersetzungsworkflow auftauchen.
Für ein Next.js-App-Router-Projekt fügen Sie next-intl oder next-i18next für Locale-Routing und SSR-gerenderte Übersetzungen hinzu.
Die tatsächlichen Kosten von i18n-Bibliotheken
Der Aufwand pro Einheit für jede in t() eingebettete Zeichenkette ist gering. Die Gesamtkosten sind erheblich:
Erstmigration: 2–5 Entwicklertage
Bei einer bestehenden React-Anwendung mit einem Jahr oder mehr UI-Entwicklung ist die Prüfung jeder Komponente auf fest codierte Zeichenketten, deren Einbettung in t(), das Anlegen der anfänglichen Übersetzungs-Namensraumstruktur und die Einrichtung des i18n-Providers ein mehrtägiges Projekt — noch bevor überhaupt Zeichenketten übersetzt sind.
Laufende Pflege pro neuer Zeichenkette
Jede neue UI-Zeichenkette erfordert: eine Schlüsseldefinition, einen englischen Eintrag in der Quellsprachdatei und eine Aktualisierung jeder Zielsprachdatei. Wird die Zeichenkette am Dienstag in einem PR hinzugefügt, müssen die französischen und deutschen Übersetzungsdateien ausgeliefert werden, bevor das Feature für diese Nutzer sichtbar wird.
Kontext- und Namensraum-Verwaltung
Wenn Übersetzungsdateien auf Hunderte oder Tausende von Schlüsseln anwachsen, wird die Namensraum-Verwaltung zu einer eigenen Disziplin. Schlüssel brauchen Präfixe, Namensräume brauchen Ladestrategien, und das Risiko von Schlüsselkollisionen oder ungenutzten Schlüsseln steigt mit der Zeit.
RTL erfordert separate Layout-Arbeit
i18n-Bibliotheken übersetzen Zeichenketten, aber nicht die Layoutrichtung. Unterstützung für Arabisch oder Hebräisch erfordert zusätzlich zur Bibliothekseinrichtung separate CSS-Arbeit — logische Eigenschaften, Icon-Spiegelung und Tests unter dir="rtl".
Wann i18n-Bibliotheken die richtige Wahl sind
Es gibt konkrete Situationen, in denen der Mehraufwand einer Bibliothek gerechtfertigt oder sogar erforderlich ist:
Open-Source-Projekte
Wenn Übersetzungsdateien von der Community auf GitHub beigetragen werden, ist ein Standard-i18n-Bibliotheksformat (JSON- oder PO-Dateien) die richtige Schnittstelle für Mitwirkende. Automatische Übersetzung funktioniert nicht für Projekte, die menschliche Community-Beiträge wollen.
Compliance-getriebene Zeichenkettenprüfung
Regulierte Branchen (Recht, Medizin, Finanzen) können verlangen, dass jede UI-Zeichenkette vor der Veröffentlichung explizit geprüft und freigegeben wird. Eine i18n-Bibliothek macht dies prüfbar — jede Zeichenkette ist ein diskretes Artefakt mit Versionshistorie.
Umfangreiche Zahlen-, Datums- und Währungsformatierung
Wenn Ihre App durchgängig formatierte Zahlen, Daten und Währungsbeträge anzeigt (z. B. ein Analyse-Dashboard oder Buchhaltungstool), bieten Bibliotheken wie FormatJS sprachbewusste Formatierung über die
Intl-API, die DOM-basierte Übersetzung nicht bereitstellt.Offline-first-Apps
Apps, die offline funktionieren müssen (PWAs mit vollständiger Offline-Unterstützung), benötigen gebündelte Übersetzungsdateien, da sie ohne Netzwerk keine Übersetzungs-API aufrufen können. i18n-Bibliotheken bündeln Übersetzungen zur Build-Zeit.
Wann automatische Übersetzung besser ist
Der DOM-basierte Ansatz eignet sich besser für andere Rahmenbedingungen:
Lokalisierung zu einer bestehenden App hinzufügen, ohne sie neu zu schreiben
Der stärkste Anwendungsfall für automatische Übersetzung. Wenn Sie eine funktionierende React-Anwendung haben und fünf Sprachen hinzufügen möchten, ohne 200 Komponenten anzufassen, ist DOM-basierte Übersetzung die einzig pragmatische Option.
Teams ohne dedizierten i18n-Entwickler
Ein bibliotheksbasiertes i18n-System gut einzurichten und zu pflegen erfordert Fachwissen über die Bibliothek, den Übersetzungsworkflow und Pluralisierungs-Randfälle. Ein Script-Tag-Ansatz erfordert nichts davon.
Sich schnell weiterentwickelnde UI
Wenn das Produkt jede Woche neue UI ausliefert, ist die Pflege der Parität von Übersetzungsdateien eine ständige Reibung. Automatische Übersetzung behandelt neue Zeichenketten bereits beim ersten Seitenaufruf ohne zusätzliche Schritte.
Geschwindigkeit bis zur Markteinführung wichtiger als Perfektion
Eine hochwertige automatische Übersetzung, die innerhalb einer Woche live ist, schlägt eine perfekte i18n-Bibliotheksintegration, die erst in drei Monaten ausgeliefert wird. Für viele internationale Märkte ist der Unterschied in der Übersetzungsqualität nicht entscheidend — Präsenz ist es.
Wie DOM-basierte Übersetzung in React funktioniert
Lingvit nutzt einen MutationObserver-basierten Ansatz, der sich natürlich in das Rendering-Modell von React einfügt:
- Beim ersten Laden durchläuft das Script alle vorhandenen Textknoten im DOM und sendet sie zur Übersetzung. Reacts virtueller DOM und Rendering-Mechanismus sind für diesen Prozess unsichtbar — nur das endgültig gerenderte HTML zählt.
- Ein MutationObserver überwacht nachfolgende DOM-Mutationen — neue, durch React-Zustandsänderungen hinzugefügte Knoten, Routenwechsel (clientseitige Navigation in Next.js), lazy geladene Komponenten und dynamische Inhalte aus API-Antworten.
- Gespeicherte Übersetzungen werden über die API abgerufen. Ein Sprachwechsel erfordert kein Neuladen der Seite, da übersetzte Zeichenketten direkt ausgetauscht werden.
- Für RTL-Sprachen wird
document.documentElement.dirautomatisch gesetzt, wodurch alle logischen CSS-Eigenschaften in Ihrem Layout umgekehrt werden.
Vergleich der Einrichtung
| Schritt | i18n-Bibliothek | Lingvit |
|---|---|---|
| Installation | npm install react-i18next i18next | 1 Script-Tag |
| Konfiguration | i18n-Instanz + Provider + Namensraum-Konfiguration (~100 Zeilen) | Dashboard: Sprachen auswählen |
| Zeichenketten instrumentieren | Jede Zeichenkette in allen Komponenten in t() einbetten | Keine Codeänderungen |
| Übersetzungsdateien | JSON-Datei pro Sprache, im Repository gepflegt | Automatisch generiert, bei Lingvit gespeichert |
| Typsicherheit | Optional über typescript-i18n (~50 Zeilen Konfiguration) | Nicht zutreffend |
| Neue UI-Zeichenkette | Schlüssel hinzufügen + alle Sprachdateien aktualisieren | Beim ersten Seitenaufruf übersetzt |
| RTL-Unterstützung | Separate CSS-Arbeit erforderlich | Automatisch für Arabisch, Hebräisch, Persisch, Urdu |
Zum Anzeigen aller Spalten horizontal scrollen.
Häufig gestellte Fragen
Funktioniert Lingvit mit React 18/19 Concurrent Mode und Streaming-SSR?
Ja. Der MutationObserver-Ansatz ist unabhängig von der React-Version — er beobachtet die endgültige DOM-Ausgabe unabhängig davon, wie React sie rendert. Concurrent Mode, Suspense und Streaming-SSR erzeugen alle letztlich DOM-Knoten, und der Observer behandelt sie normal. Es sind keine reactversionsspezifischen APIs beteiligt.
Funktioniert es mit Next.js App Router und Server Components?
Ja. Server Components erzeugen HTML, das an den Browser gesendet und genau wie jedes andere HTML in den DOM eingefügt wird. Das Script-Tag in Ihrem Root-layout.tsx erfasst diesen Inhalt normal. Client-seitige, von Next.js gehandhabte Navigation löst den MutationObserver für den neu gerenderten Inhalt aus.
Was ist mit professionellen Übersetzern — können sie Zeichenketten trotzdem prüfen?
Ja. Das Lingvit-Dashboard bietet einen Übersetzungsbrowser, in dem professionelle Übersetzer jede Zeichenkette pro Sprache prüfen, bearbeiten und freigeben können. Überschreibungen werden dauerhaft gespeichert und haben Vorrang vor automatischen Übersetzungen. So erhalten Sie den Prüf-Workflow einer i18n-Bibliothek, ohne Übersetzungsdateien in Ihrem Repository zu pflegen.