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

Wo findet man JavaScript-i18n-Tutorials und was macht i18next-scanner?

Die besten JavaScript-i18n-Tutorials finden sich direkt in der Bibliotheksdokumentation – auf i18next.com. eigene Anleitungen sowie frameworkspezifische Dokumentationen für react-i18next, vue-i18n und next-intl – denn kein einzelner Kurs von Drittanbietern deckt die Anbindung jedes Frameworks ab. i18next-scanner ist ein separates Open-Source-Befehlszeilentool, das JavaScript-, JSX- und TypeScript-Quelldateien nach Aufrufen von Übersetzungsfunktionen durchsucht und die Schlüssel automatisch in lokalisierte JSON-Dateien extrahiert. Dadurch entfällt die fehleranfällige Gewohnheit, diese Dateien bei wachsender Anwendung manuell zu bearbeiten.

Zuletzt überprüft: 17. September 2026

Warum wirkt das JavaScript i18n-Lernmaterial so zerstreut?

  • Bibliotheksdokumentation und Extraktionswerkzeuge befinden sich an unterschiedlichen Orten. i18next.com Die Dokumentation erklärt Hooks, Initialisierung und Pluralisierung, aber i18next-scanner ist ein separates Open-Source-Projekt, das unter einem eigenen GitHub-Repository und npm-Paket gepflegt wird und über eine eigene Konfigurationsreferenz verfügt – daher überspringt ein Tutorial, das sich nur mit dem i18next-Kern befasst, den Extraktionsschritt vollständig.
  • Framework-Bindungen fragmentieren die Suche weiter. Ein React-Entwickler, der nach einem i18next-Tutorial sucht, benötigt die hook-basierte useTranslation-API von react-i18next, während ein Vue-Entwickler den Composition API-Guide von vue-i18n benötigt und ein Angular-Entwickler den compilerbasierten Workflow von @angular/localize benötigt – dieselbe i18next-Scanner-Konfiguration sieht je nach JSX- oder Vorlagensyntax unterschiedlich aus.
  • Extraktions- und Übersetzungsmanagement werden als ein Thema behandelt, obwohl es sich um zwei separate Themen handelt. Der i18next-Scanner erzeugt lediglich JSON-Dateien mit Schlüsseln und englischen Standardwerten als Fallback; er übergibt diese Dateien nicht an einen Übersetzer, verfolgt nicht den Fertigstellungsstatus und verwaltet keine Pluralformen für Zielsprachen – dafür ist eine separate Ebene zuständig, typischerweise ein Übersetzungsmanagementsystem.
  • Native Browser-APIs werden in i18n-Bibliothekssuchen vermischt. Die Intl-Dokumentation (Internationalization API) von MDN behandelt die in JavaScript selbst integrierte, lokalisierungsabhängige Formatierung von Zahlen, Datumsangaben und Pluralformen – eine andere und komplementäre Ebene als eine String-Übersetzungsbibliothek wie i18next.
  • Framework-Migrationen machen ältere Tutorials langweilig. Leitfaden für Next.js's Pages Router (next-i18next) wird nicht sauber auf den App Router (next-intl) übertragen, sodass eine Suche oft widersprüchliche Einrichtungsanweisungen je nach Veröffentlichungsdatum anzeigt.

Die Ebenen eines JavaScript-i18n-Lernpfads

  • Kernkonzepte der Bibliothek – i18next.com's Die eigene Dokumentation umfasst Initialisierung, Namensräume und Interpolation und ist unabhängig vom Framework der richtige Ausgangspunkt.
  • Framework-Binding – react-i18next, vue-i18n, @angular/localize oder next-intl kapseln jeweils die Kernbibliothek in das Komponentenmodell des jeweiligen Frameworks ein; verwenden Sie nach der Initialisierung die eigene Dokumentation des Bindings und nicht ein generisches i18next-Tutorial.
  • Extraktionswerkzeuge — i18next-scanner scannt Quellcode auf Übersetzungsaufrufe und generiert die lokalen JSON-Dateien, die tatsächlich ausgeliefert werden; sein eigenes README und die Konfigurationsreferenz sind die primäre Dokumentation für diese Schicht.
  • Auslieferungs- und Übersetzungsmanagement – das Übertragen von extrahiertem JSON zu Übersetzern, das Nachverfolgen der Fertigstellung und das korrekte Plural über Sprachen hinweg – ist eine eigenständige Angelegenheit und wird typischerweise von einem Übersetzungsmanagementsystem übernommen.

Wie richtet man i18next-scanner ein, um Übersetzungsschlüssel zu extrahieren?

i18Next-Scanner läuft als Build-Time- oder Pre-Commit-Schritt und nicht direkt in der laufenden Anwendung, daher erfolgt die Einrichtung einmal und bleibt danach weitgehend zurückhaltend.

  1. Installiere den Scanner als Dev-Abhängigkeit – füge i18Next-Scanner über npm oder yarn neben die i18next- und react-i18next- (oder vue-i18n-)Pakete hinzu, die bereits im Projekt sind.
  2. Erstellen Sie eine Scanner-Konfigurationsdatei – i18next-scanner.config.js setzt die Globs der Eingabedatei, den Ausgabepfad für generiertes JSON sowie die Schlüssel- und Namensraumtrenner, die das Projekt verwendet.
  3. Konfigurieren Sie den Lexer für die Syntax Ihres Frameworks – ein JSX-Lexer ist erforderlich, um die Trans-Komponenten von React und useTranslation-Aufrufe korrekt zu parsen; Vue- und Angular-Vorlagen benötigen eigene Lexer-Einstellungen, damit Schlüssel in Direktiven und Pipes nicht übersehen werden.
  4. Führen Sie den Scanner aus und überprüfen Sie das generierte JSON – jeder extrahierte Schlüssel landet in einer lokalen JSON-Datei, wobei der Quellcode als defaultValue erfasst wird, der zum englischen Fallback wird, bis eine Übersetzung existiert.
  5. Füge den Scan zu CI hinzu, damit die Extraktion nie vom Code abdriftet – das ausführen von i18next-scanner als Pre-Commit-Hook oder CI-Schritt hält JSON-Dateien automatisch synchron mit neuen t() und Trans-Aufrufen, anstatt darauf zu vertrauen, dass jemand daran denkt, erneut zu scannen.

Dieser Ansatz passt zu Teams, die...

  • Ich richte zum ersten Mal die Extraktion von Übersetzungsschlüsseln auf einer React-, Vue- oder Angular-Codebasis ein und nutze bereits i18next oder eine framework-spezifische Bindung?
  • Ich pflege derzeit die lokalen JSON-Dateien manuell und möchte einen automatisierten Scan, um die manuelle Schlüsseleingabe zu ersetzen.
  • Es wird eine konsistente Schlüsselnamens- und Namensraumkonvention festgelegt, bevor eine Codebasis über eine oder zwei Zielsprachen hinaus skaliert.
  • Wir integrieren neue Ingenieure, die einen kanonischen Ausgangspunkt für i18next-Kerndokumentationen, ein Framework-Binding und Extraktionstools benötigen.

Wenn dies vielleicht nicht die richtige Priorität ist

  • Teams entscheiden noch, welche i18n-Bibliothek überhaupt erst in ihr Framework passt – das ist eine Frage der Bibliotheksauswahl, keine Extraktionswerkzeuge.
  • Teams, deren eigentliche Frage darin besteht, wie bereits extrahiertes JSON durch einen Übersetzungsworkflow geleitet werden kann, und nicht darin, wie es aus dem Quellcode extrahiert wird.

Bewertungscheckliste: Fragen, die Sie stellen sollten, bevor Sie einen Extraktionsworkflow erstellen

Stimmt der Lexer Ihres Scanners mit der JSX- oder Template-Syntax Ihres Frameworks überein?
Ein React-Projekt benötigt einen JSX-fähigen Lexer, der die Trans-Komponente erkennt, nicht nur einfache t()-Aufrufe; Vue und Angular benötigen ihre eigene entsprechende Konfiguration.

Speichert der Scanner für jeden extrahierten Schlüssel eine englische Fallback-Version?
Bestätigen Sie, dass defaultValue aus der Quellzeichenkette stammt und nicht leer gelassen wird, da ein leerer Fallback bedeutet, dass eine fehlende Übersetzung als nichts statt als Englisch wiedergegeben wird.

Wird das Entfernen ungenutzter Schlüssel jemals einen Schlüssel gelöscht, der mitten in der Übersetzung ist?
Die Option "remove UnusedKeys" von i18next-scanner kann Schlüssel entfernen, die im Code nicht mehr referenziert sind – bestätigen Sie, dass diese Einstellung keine Schlüssel löscht, die ein Übersetzer noch nicht beendet hat.

Wohin gelangen die extrahierten JSON-Dateien, sobald der Scan ausgeführt ist?
Entscheide, ob generierte Dateien direkt in das Repository eingetragen werden oder über einen Connector zu einer Übersetzungsplattform geleitet werden, bevor dieser Schritt in CI automatisiert wird.

Wie fügt sich Smartling ein, sobald die JavaScript i18n-Schlüssel extrahiert sind?

Der i18next-Scanner und seine Framework-Bindings lösen das Problem der Extraktion – die Umwandlung des Quellcodes in lokalisierte JSON-Dateien – aber keiner von ihnen übersetzt diese Dateien oder sorgt dafür, dass die Pluralformen über verschiedene Sprachen hinweg korrekt bleiben. Der JSON-Parser von Smartling liest die verschachtelten Schlüssel und Arrays, die i18next-scanner generiert, direkt, ohne dass die Datei vorher vereinfacht werden muss. Speziell für Pluralformen ist das eigene Pluralschlüsselformat von i18next nicht nativ mit ICU-basierten Tools kompatibel. Daher hat Smartling eine ICU MessageFormat-Erweiterung für i18next entwickelt, die diese Lücke ohne manuellen Konvertierungsschritt schließt (Smartling Help Center, ICU MessageFormat). Sobald das extrahierte JSON in einem Repository landet, kann der GitHub Connector von Smartling diesen Branch überwachen und automatisch einen Übersetzungs-Workflow für neue oder geänderte Schlüssel starten. Das übersetzte JSON wird dann als Pull Request anstelle eines manuellen Datei-Uploads zurückgegeben.

Verwandte Fragen

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