Sie müssen sich nicht entscheiden: i18next und inlang, zusammen

Wenn Sie i18next nutzen, wurde Ihnen das inlang-Ökosystem vermutlich als Ziel präsentiert: Setup migrieren, neues Format übernehmen, Workflow wechseln. Und so haben die meisten i18next-Teams Tools wie die Sherlock-VS-Code-Erweiterung, den Fink-Web-Editor oder den Paraglide-Compiler nie angefasst, selbst wenn eines davon wirklich nützlich gewesen wäre.

Dieses Entweder-oder war nie nötig. Ihre Übersetzungsdateien sind die Schnittstelle: Wenn inlang-Tools i18next-JSON originalgetreu lesen und schreiben können, können Sie beide Ökosysteme im selben Projekt nutzen. Seit dieser Woche können sie es. Verifiziert, repariert wo es kaputt war, und einen Befehl entfernt:

npx i18next-cli init --inlang

Ein Befehl, keine Migration

init --inlang (neu in i18next-cli 1.63, auch als Frage im normalen init-Wizard) scaffoldet ein fertiges inlang-Projekt neben Ihrer i18next-Konfiguration:

{
  "$schema": "https://inlang.com/schema/project-settings",
  "baseLocale": "en",
  "locales": ["en", "de", "fr", "it"],
  "modules": ["https://cdn.jsdelivr.net/npm/@inlang/plugin-i18next@6.2.1/dist/index.js"],
  "plugin.inlang.i18next": {
    "pathPattern": {
      "common": "./public/locales/{locale}/common.json",
      "app": "./public/locales/{locale}/app.json"
    }
  }
}

Alles wird aus dem abgeleitet, was i18next-cli ohnehin weiß: baseLocale und locales aus Ihrer Konfiguration, das pathPattern aus Ihrem extract.output-Layout, inklusive der Namespace-Form, wobei die Namespace-Namen aus den vorhandenen Dateien Ihrer Primärsprache erkannt werden. Zusätzlich wird die Sherlock-Erweiterung in die Empfehlungen Ihrer .vscode/extensions.json eingetragen (kommentarschonend gemerged, nie etwas überschrieben), und eine bestehende project.inlang/settings.json wird niemals überschrieben.

Entscheidend ist, was nicht passiert: keine Konvertierung, kein Export, kein zweiter Katalog, der ab dem Moment seiner Erstellung auseinanderläuft. Das i18next-JSON in Ihrem Repository bleibt die einzige Quelle der Wahrheit.

Was das freischaltet

• Sherlock (VS Code): Übersetzungen inline dort sehen und bearbeiten, wo die Schlüssel verwendet werden, auf Ihren echten Dateien.
• Fink (Browser): Geben Sie einem Übersetzer einen Link; die Änderungen landen via git im selben JSON.
• Paraglide (Compiler): Dieselben Dateien zu tree-shakable, voll typisierten Message-Funktionen kompilieren, zum Beispiel für eine neue SvelteKit- oder SolidStart-App neben Ihrem bestehenden i18next-Produkt:

npx @inlang/paraglide-js compile --project ./project.inlang

import * as m from './src/paraglide/messages.js'

m['common:friend']({ count: 1, context: 'male' }) // "A boyfriend"

Plurale, Kontext (einzeln und kombiniert mit Pluralen), _zero, Ordinal-Schlüssel, Namespaces und {{count, number}}-Formatierung verhalten sich genau so, wie i18next sie definiert. Warum wir das so selbstbewusst sagen können, steht weiter unten.

Warum das jetzt funktioniert: sechs Bugs, in wenigen Stunden behoben

„Interop"-Behauptungen sind billig, also haben wir zuerst den kompletten Pfad Ende-zu-Ende getestet: i18next-v4-JSON durch das inlang-i18next-Plugin, das SDK und den Paraglide-Compiler, dazu den Schreibpfad zurück, denn Editier-Tools wie Sherlock und Fink müssen speichern können.

Der Kern hielt gut stand, und die rauen Kanten waren real. Sechs Bugs über Plugin, SDK und Compiler: Kontext-Schlüssel, die stillschweigend zur Basis-Variante auflösten, Kontext-Projekte, die sich gar nicht speichern ließen, Namespace-Projekte, die beim Zurückschreiben scheiterten, stillschweigend verworfene {{count, number}}-Formatierung, _zero, das bei count: 0 nie zog, und Ordinal-Schlüssel, die als Kontext fehlinterpretiert wurden.

Was dann geschah, ist der Teil, über den es sich zu schreiben lohnt: Wir haben alle sechs mit Reproduktionen gemeldet, und Samuel Stroschein und das inlang-Team haben ihre Hälfte innerhalb weniger Stunden umgedreht, unsere Plugin-Fixes genauso schnell reviewt und gemerged und alles released: @inlang/plugin-i18next 6.2.0, @inlang/sdk 2.10.0, @inlang/paraglide-js 2.19.0. Das Plugin wird auf ihrer Seite erstklassig gepflegt. Dieses Commitment, plus die Geschwindigkeit, macht eine Brücke darauf zu einer sicheren Wette. Anschließend haben wir die komplette Testmatrix gegen die veröffentlichten Pakete erneut verifiziert: 15/15 grün, mit dem Plugin vom CDN geladen, exakt so, wie Ihr Projekt es laden wird. Das inlang-Team hat eine eigene Ankündigung der Integration veröffentlicht.

Das Muster wiederholte sich noch einmal beim Schreiben dieses Beitrags: Beim Aufnehmen des Sherlock-Screenshots oben kam ein siebter Bug zum Vorschein (Sherlock zeigte für i18next-Projekte stillschweigend gar keine Annotationen an, und das schon lange). Gemeldet mit einem Einzeiler-Fix, innerhalb von Stunden gemerged und als Plugin 6.2.1 released. Der Screenshot zeigt das korrigierte Verhalten.

Wo Locize hineinpasst

Dieselben Dateien, die Sherlock und Paraglide jetzt lesen, sind die Dateien, die Locize als Ihr gehostetes TMS synchronisiert:

npx i18next-cli locize-sync

Damit bleibt die Arbeitsteilung sauber. Entwickler arbeiten im Repo, mit Sherlock inline oder Paraglide-kompiliert. Übersetzer arbeiten, wo es ihnen passt: Fink für schnelle git-basierte Änderungen, Locize für den vollständigen Workflow mit Review-Schritten, KI-Übersetzung mit Konfidenzwerten, Translation Memory, Glossar, Versionierung und CDN-Auslieferung, damit Übersetzungskorrekturen ohne Redeploy live gehen. Ein Satz Dateien, und jedes Tool liest und schreibt ihn direkt.

Ehrliche Details

• Die Plugin-Version ist absichtlich gepinnt. Das Scaffold schreibt @inlang/plugin-i18next@6.2.1, kein schwebendes @6: jsDelivr liefert Range-Aliase aus Edge-Caches aus, die Releases um Tage hinterherhinken und sich je nach Standort unterscheiden können. Wir haben beobachtet, wie @6 nach dem 6.2.0-Release ein zwei Releases altes Plugin auslieferte. Eine gepinnte URL bedeutet: Jedes Teammitglied und jeder CI-Lauf bekommt dasselbe, verifizierte Plugin. Erhöhen Sie die modules-URL in der settings.json bewusst, wenn neuere Versionen erscheinen.
• Nur settings.json wird gescaffoldet, mit Absicht. project.inlang/ ist inlangs unpacked (git-freundliche) Projektform; die übrigen Dateien (.gitignore, README.md, cache/) erzeugen und verwalten die inlang-Tools bei der ersten Nutzung selbst. Erwarten Sie also ein paar neue Dateien dort, nachdem Sie das Projekt mit Sherlock oder Paraglide geöffnet haben.
• Namespaces werden zum Scaffold-Zeitpunkt erkannt. Wenn Sie später einen Namespace hinzufügen, ergänzen Sie seine Zeile im pathPattern der settings.json; ein erneuter init-Lauf rührt eine bestehende Datei bewusst nicht an.
• Nur JSON-Ressourcendateien. Das inlang-i18next-Plugin liest JSON; YAML/JS-Layouts werden mit einem Hinweis übersprungen.

Loslegen

In einem Projekt mit i18next-cli-Konfiguration (oder lassen Sie den Wizard eine erstellen):

npx i18next-cli init --inlang

Öffnen Sie den Ordner in VS Code und installieren Sie die empfohlene Sherlock-Erweiterung, schicken Sie einem Übersetzer den Fink-Link oder richten Sie den Paraglide-Compiler auf ./project.inlang. Und synchronisieren Sie weiterhin genau dieselben Dateien mit Locize für das gemanagte Ende des Workflows. Die vollständige Optionsreferenz steht im i18next-cli-README, das Plugin lebt auf dem inlang-Marketplace.

Zwei Ökosysteme, ein Satz Dateien. Sie müssen sich wirklich nicht entscheiden.