i18n ohne Übersetzungsdateien? Das geht mit i18next, heute schon

"Übersetzungsdateien sind das Problem." Das ist 2026 ein beliebter Pitch: Ihre Komponenten sind die Source of Truth, also Schluss mit handgepflegtem JSON pro Sprache, Tooling generiert die Übersetzungen, und Locale-Dateien sind nur noch Build-Artefakte. Eine neue Welle von i18n-Tools baut auf genau diesem Argument auf.

Die Diagnose stimmt zum Teil. Siebzehn JSON-Dateien von Hand zu editieren, um einen Satz zu ergänzen, macht niemandem Freude. Was der Pitch meist verschweigt: Das i18next-Ökosystem unterstützt genau diesen Workflow seit Jahren, mit schlichten Open-Source-Bibliotheken, und es geht sogar einen Schritt weiter, denn mit CDN-Auslieferung liegen überhaupt keine Übersetzungsdateien in Ihrem Repo, auch keine generierten. Hier ist das Rezept, gefolgt von den ehrlichen Trade-offs.

Schritt 1: der Code wird zur Source of Truth

Zwei Konfigurationszeilen machen aus i18next ein System mit natürlichsprachigen Keys:

i18next.init({
  keySeparator: false,
  nsSeparator: false
})

Jetzt ist der englische Text der Key:

t('Add to cart')

Dahinter steht kein en.json-Eintrag. Existiert keine Übersetzung, fällt i18next auf den Key zurück, und der Key ist der Quelltext, die App rendert also von der ersten Sekunde an korrekt. Rich Text funktioniert genauso über die Trans-Komponente, die ihre JSX-Kinder samt Markup in den Key serialisiert:

<Trans>Hello <strong>{{name}}</strong>, you have {{count}} unread messages.</Trans>

Übersetzer sehen Hello <1>{{name}}</1>, you have {{count}} unread messages. und ordnen das Markup pro Sprache frei an; die eigentlichen Tags gehören weiter Ihren Komponenten. Plural- und Kontext-Suffixe funktionieren auf natürlichen Keys weiterhin, denn sie sind Key-Dekorationen, keine separaten Dateien.

Schritt 2: neue Strings melden sich selbst

Das ist das Stück, das "Dateien pflegen" ersetzt: saveMissing. Mit saveMissing: true und i18next-locize-backend wird jeder String, den Ihre App zum ersten Mal rendert, automatisch an Locize gemeldet, üblicherweise auf die Entwicklung begrenzt, damit die Produktion read-only bleibt:

i18next.init({
  saveMissing: process.env.NODE_ENV === 'development'
})

Auf der Locize-Seite greift die automatische Übersetzung jeden neuen Quellstring auf und füllt alle Zielsprachen, auf Ihrem eigenen OpenAI-, Gemini-, Mistral- oder DeepL-Key, wenn Sie einen mitbringen, mit Ihrem Glossar und Styleguide in jedem Request. Quality Estimation bewertet jedes Ergebnis von 0 bis 1: sichere Übersetzungen werden direkt gespeichert, zweifelhafte landen im Review.

Sie schreiben t('Your trial ends tomorrow'), laden die Seite neu, und der String existiert Sekunden später in jeder Sprache, mit Score. Niemand hat eine JSON-Datei geöffnet.

Schritt 3: ausliefern ohne Dateien (oder mit, generiert)

Zur Laufzeit lädt dasselbe Backend die Übersetzungen vom Locize-CDN. Das heißt: Die stärkste Version von "Übersetzungsdateien sind Build-Artefakte" gibt es hier auch, und mehr: In Ihrem Repository liegen überhaupt keine Locale-Dateien. Eine im Editor veröffentlichte Korrektur ist live, ohne Commit, Build oder Redeploy.

Sie bevorzugen eine statische Pipeline oder brauchen Dateien für SSR/SSG? Dann nehmen Sie den CI-Weg: i18next-cli extrahiert dieselben Strings statisch (es versteht t()-Scopes und serialisiert Trans-Kinder exakt wie react-i18next), und die kostenlose locize/translate GitHub Action führt Extract, Sync, Auto-Translate und Download bei jedem Push aus. Die heruntergeladenen Dateien sind generierte Artefakte: committen Sie sie, oder setzen Sie sie auf gitignore und laden beim Build. Ihre App ist noch gar nicht instrumentiert? npx i18next-cli localize bringt sie in einem Befehl von hartkodierten Strings zu lokalisiert, und npx i18next-cli localize --print-agent-prompt gibt denselben Ablauf als Runbook für Ihren AI-Coding-Agenten aus.

Die ehrlichen Trade-offs

Natürlichsprachige Keys sind ein Tausch, kein Gratis-Upgrade, und man sollte wissen, was man zahlt. (Das vollständige Entscheidungsraster zu Key-Strategien, inklusive wann Content-as-Key die richtige Wahl ist und wann nicht, steht in unserem Guide zur i18n-Key-Benennung.)

• Textänderungen erzeugen neue Keys. Wird aus "Add to cart" ein "Add to basket", ist das ein neuer Key: frisch übersetzt, der alte wird beim nächsten Sync entfernt. Das Translation Memory dämpft das, frühere geprüfte Übersetzungen kommen als Treffer mit hohem Score zurück, aber für Texte, die wöchentlich rotieren, sind stabile Keys mit defaultValue das bessere Werkzeug. i18next erlaubt beide Stile im selben Projekt; viele Teams nutzen natürliche Keys für stabile UI-Texte und stabile Keys für Marketing-Copy.
• Langer Text macht lange Keys. Ein dreiabsätziger AGB-Hinweis als eigener Key ist in jedem Tool unangenehm, das Keys anzeigt. Geben Sie solchen Strings einen stabilen Key und einen defaultValue.
• Mehrdeutigkeit braucht Kontext. Das englische "Open" als Verb und als Adjektiv braucht womöglich zwei Übersetzungen. i18nexts Kontext-Feature (t('Open', { context: 'button' })) deckt das ab, aber Sie müssen die Mehrdeutigkeit bemerken; ein dateizentrierter Workflow schützt davor genauso wenig.

Was "keine Dateien" nicht löst

Wer die Dateipflege abschafft, schafft eine lästige Aufgabe ab. Die wirklich harten Probleme der Lokalisierung schafft er nicht ab, und genau hier endet der "Ihr Code ist die Source of Truth"-Pitch stillschweigend: Terminologie, die nicht driften darf, Anrede, die nicht mitten in der App kippen darf, juristische Strings, die menschliche Augen brauchen, und die Frage "wer hat diese Übersetzung freigegeben?", die eine Pipeline aus ungeprüftem Bot-Output mit einem Commit-Hash beantwortet. Wir haben aufgeschrieben, was in KI-only-Pipelines wirklich kaputtgeht, und keiner der Fehlermodi hat mit Dateiformaten zu tun.

Das ist der echte Unterschied zwischen den Workflows, mit oder ohne Dateien: ob übersetzter Output in einer governten Schicht landet, mit glossar-erzwungener Konsistenz, Quality-Scores, selektivem menschlichem Review und Audit-Historie, oder direkt in der Produktion. Keyless rein plus ungeprüft raus ist nur schnellerer Drift.

Den ganzen Loop an einem Nachmittag testen

Richten Sie natürlichsprachige Keys und saveMissing in einem Branch ein, erstellen Sie ein kostenloses Locize-Projekt, aktivieren Sie die automatische Übersetzung, und sehen Sie zu, wie neue Strings übersetzt und bewertet auftauchen, während Sie durch Ihre App klicken. Wenn Sie bereits eine KI-in-CI-Pipeline betreiben und wissen wollen, in welchem Zustand Ihre Locale-Dateien sind: Der kostenlose i18n-Health-Check läuft komplett im Browser und zeigt fehlende Keys, Duplikate und Interpolations-Abweichungen, bevor Sie irgendetwas ändern.

Übersetzungsdateien waren nie der Punkt. Vertrauenswürdige Übersetzungen in der Produktion sind es, ob es die Dateien nun gibt oder nicht.