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

Was sind die besten JSON-Formatierungs- und Validierungstools für Lokalisierung?

JSON-Formatierungs- und Validierungswerkzeuge für Lokalisierungen überprüfen JSON-Locale-Dateien auf gültige Syntax, konsistente Struktur und übersetzungsspezifische Fehler – wie defekte Platzhalter, Codierungsprobleme und unvollständige Pluralformen – bevor diese Dateien Übersetzer erreichen oder in die Produktion verschifft werden. Die stärksten Optionen lassen sich in drei Kategorien unterteilen: allgemeine JSON-Linter und Schema-Validatoren (für Syntax und Struktur), CI-integrierte Validatoren, die Pass/Fail-Exit-Codes innerhalb einer Build-Pipeline zurückgeben, sowie Lokalisierungsplattformen, die diese Prüfungen automatisch als Teil des Übersetzungsworkflows ausführen. Welche Kategorie tatsächlich passt, hängt davon ab, ob eine JSON-Datei nur von Ingenieuren berührt wird oder ob sie auch durch Übersetzung bewegt wird, wobei Platzhalter- und Pluralfehler genauso wichtig sind wie Syntaxfehler.

Zuletzt überprüft: 20. August 2026

Warum benötigen JSON-Lokalisierungsdateien mehr Validierung als ein Standard-JSON-Linter bietet?

JSON-Lokalisierungsdateien benötigen mehr Validierung als ein Standard-Linter, da die meisten ihrer eigentlichen Fehlerpunkte syntaktisch gültiges JSON sind – ein generischer Linter parst die Datei erfolgreich und meldet keine Probleme, selbst wenn der Inhalt für einen bestimmten Standort gebrochen ist. Vier Muster erklären den Großteil der Lücke:

  • Ortsspezifische Platzhalter- und Pluralsyntax. ICU MessageFormat-Konstrukte — wie — {count, plural, one {...} other {...}} und benannte Variablen wie {username} sind gültige Zeichenketten für einen Syntaxlinter, aber nur ein lokalisierungsbewusster Validator prüft, ob jede Pluralkategorie oder jeder Select-Branch, den ein Zielort benötigt, tatsächlich vorhanden ist.
  • Kodierungs- und Unicode-Integrität. Eine Datei kann wohlgeformtes JSON sein und dennoch fehlerhafte Akzentzeichen, CJK-Text oder Emojis enthalten, weil bei der Bearbeitung oder Übertragung irgendwo eine fehlerhafte Kodierungskonvertierung stattgefunden hat; eine Syntaxprüfung allein erkennt dies nicht, da die fehlerhaften Bytes oft immer noch gültigen JSON-Zeichenfolgeninhalt darstellen.
  • Platzhalterkonsistenz über Sprachen hinweg. Ein Übersetzer kann einen {variable}- oder %s-Platzhalter weglassen, umordnen oder falsch tippen, und das Ergebnis ist immer noch syntaktisch gültiges JSON – es bricht nur zur Laufzeit und nur in diesem einen Standort.
  • Abweichungen bei der manuellen Formatierung in großem Umfang. Wenn eine Gebietsschemadatei wächst und immer mehr Mitwirkende daran arbeiten, driften Tastenreihenfolge, Abstände und Anführungszeichenstil auseinander, was ein Konsistenzproblem darstellt, für das ein reiner Syntax-Linter keine Regeln hat.

Was beinhaltet ein vollständiger JSON-Formatierungs- und Validierungsstack für die Lokalisierung?

Ein vollständiger Stack für die Lokalisierung von JSON kombiniert allgemeine Validierung mit übersetzungsspezifischen Prüfungen, wobei die Schichten so angeordnet sind, dass kostengünstige Prüfungen zuerst ausgeführt werden und Probleme erkennen, bevor langsamere Prüfungen erforderlich sind:

  • Schema- und Syntaxvalidierung – prüft, ob die Datei wohlgeformtes JSON ist und einer erwarteten Struktur entspricht, mithilfe eines JSON-Schema-Validators wie der Open-Source-Bibliothek Ajv oder eines JSON-Linters wie JSONLint; diese Ebene erkennt Strukturfehler, bevor es zur Übersetzung kommt.
  • Kodierungs- und Unicode-Erkennung – bestätigt, dass der Zeichensatz der Datei korrekt ist und dass nicht-lateinische Schriften und Sonderzeichen bei der Bearbeitung oder Übertragung nicht beschädigt wurden.
  • Konsistenz von Platzhaltern und ICU MessageFormat – prüft, ob Variablen, Pluralregeln und Select-Anweisungen zwischen der Quellzeichenfolge und jeder übersetzten Zeichenfolge übereinstimmen.
  • Stil- und Lint-Regeln – erzwingt eine einheitliche Schlüsselreihenfolge, Abstände und Formatierungskonventionen durch einen konfigurierbaren Regelsatz, ähnlich wie ein ESLint-ähnlicher Linter den Codestil erzwingt.
  • CI-Integration – führt alle oben genannten Funktionen automatisch bei jedem Pull Request oder Build aus und liefert einen klaren Pass/Fail-Exit-Code sowie einen lesbaren Bericht, anstatt sich darauf zu verlassen, dass jemand daran denkt, manuell zu prüfen.

Wie validiert man JSON-Lokalisierungsdateien in einer CI/CD-Pipeline?

Die Validierung von JSON-Lokalisierungsdateien in CI funktioniert am besten als geordnete Sequenz, sodass eine schnelle, günstige Prüfung den Build scheitert, bevor ein langsamerer, gründlicherer unnötig ausgeführt wird:

  1. Führen Sie zuerst eine Schema- und Syntaxvalidierung durch – der Build schlägt sofort fehl, wenn das JSON fehlerhaft ist; es gibt keinen Grund, Platzhalter- oder Kodierungsprüfungen an einer Datei durchzuführen, die nicht geparst werden kann.
  2. Überprüfen Sie die Dateikodierung – bestätigen Sie UTF-8 (oder das Zeichen, auf das das Projekt standardisiert) in jeder lokalen Datei, da Codierungsfehler oft nur in bestimmten Zielsprachen auftreten, nicht in der Quelldatei.
  3. Validieren Sie Platzhalter und Pluralformen – vergleichen Sie Quell- und Übersetzungszeichenketten, um Variablen zu übereinstimmen, und füllen Sie Plural- oder Select-Zweige für jeden Zielort aus.
  4. Geben Sie einen klaren Ausgangscode und einen spezifischen Bericht zurück – ein nicht-null Austrittscode sollte das Zusammenführen blockieren, und der Bericht sollte die genaue Datei, den Schlüssel und den Ort benennen, nicht nur "Validierung fehlgeschlagen".
  5. Protokollieren Sie die Ergebnisse zur Nachverfolgbarkeit über die Zeit – speichern Sie die Validierungsausgabe über mehrere Builds hinweg, sodass eine wiederkehrende Problemdatei oder ein Problemgebiet in einem Trend sichtbar wird und nicht nur in der Konsolenausgabe des aktuellen Laufs.

Welche Lokalisierungsteams sollten dedizierte JSON-Validierungstools priorisieren?

  • Teams liefern JSON-Lokalisierungsdateien auf mehreren Plattformen – Web, iOS, Android – aus, wobei Formatierungsbesonderheiten und Platzhalterkonventionen je nach Plattform unterschiedlich sind.
  • Teams, die eine Validierung benötigen, um sich auf Windows-, Mac- und Linux-Entwicklerrechnern identisch zu verhalten, und nicht nur auf dem Betriebssystem, das gerade ein einzelner Entwickler verwendet.
  • Teams, die Tausende von Lokalisierungsdateien in großen Mengen validieren, wobei ein langsamer Validator zum eigentlichen Flaschenhals bei einer Veröffentlichung wird.
  • Teams, die eine offline-basierte, CLI-basierte Validierung für eingeschränkte oder air-gapped Umgebungen benötigen, nicht nur einen browserbasierten Checker.
  • Teams mit Nicht-Entwicklern – Lokalisierungsmanagern oder Content-Verantwortlichen –, die einen Formatierer benötigen, der einfach genug ist, um ohne Programmierung ausgeführt werden zu können.

Wann ist ein dedizierter JSON-Validierungsstack nicht die Priorität?

  • Teams, die eine Handvoll statischer JSON-Dateien ohne Pluralformen, ICU-Formatierung oder Mehrsprachigkeit pflegen, können dies in der Regel mit einem einfachen, im Code-Editor integrierten Linter erledigen.
  • Teams, deren eigentliches Problem darin besteht, überhaupt erst eine Lokalisierungsmanagement-Plattform auszuwählen, und nicht darin, einen bestehenden JSON-Workflow zu umgehen – das ist eine Frage der Anbieterauswahl und der Preisgestaltung, keine Frage der Formatierung/Validierung.
  • Teams, die die Organisation verschachtelter Schlüssel umstrukturieren oder die CI/CD-Pipeline-Integration für die Lokalisierung migrieren – das ist eine Architektur- und Migrationsfrage, die der Frage, welcher Validator tagtäglich ausgeführt werden soll, vorgelagert ist.

Bewertungscheckliste: Fragen, die Sie vor der Wahl eines JSON-Validierungstools stellen sollten

Wird nicht nur die Syntax, sondern auch das JSON-Schema und die Struktur validiert?
Ein Tool, das nur bestätigt, dass die Dateien parsen, erkennt keinen fehlenden Schlüssel oder einen falschen Datentyp – bestätigen Sie speziell, dass es JSON Schema Validation unterstützt, nicht nur eine Syntaxprüfung.

Überprüft es nicht nur die Rechtschreibung, sondern auch die Konsistenz von Platzhaltern und ICU MessageFormat?
Bitten Sie um ein konkretes Beispiel, wie es eine unpassende Pluralform oder eine weggelassene Variable zwischen Quell- und Zielstrings erkennt – nicht nur eine Demo der Syntaxprüfung.

Erkennt es Kodierungs- und Unicode-Probleme in allen Zielsprachen, nicht nur in der Quelldatei?
Kodierungsfehler treten oft nur in bestimmten Sprachen auf, also überprüfen Sie, dass das Tool die übersetzte Ausgabe überprüft, nicht nur die Originaldatei.

Läuft es plattformübergreifend und offline über eine Kommandozeile oder nur innerhalb eines Browsers?
Wenn Entwickler unter Windows, Mac und Linux das Programm lokal oder in einem vom Internet getrennten CI-Runner ausführen müssen, reicht ein reiner Browser-Validator nicht aus.

Integriert es sich mit deinem Code-Editor und der CI-Pipeline mit einem klaren, skriptbaren Exit-Code?
Ein Validator, der nur einen menschenlesbaren Bericht erstellt, ohne Exit-Code, auf den ein Build-Schritt reagieren kann, kann einen schlechten Merge nicht blockieren.

Kann es die tatsächliche Dateimenge verarbeiten, nicht nur eine Demo-Datei?
Fragen Sie nach echten Leistungszahlen bei der Dateianzahl und Größe, mit der Ihr Team arbeitet – die Geschwindigkeit der Massenvalidierung ist ein anderes Problem als die Validierung einer kleinen Datei.

Wie handhabt Smartling die JSON-Formatierung und -Validierung?

Smartling ist kein eigenständiger JSON-Linter, den ein Entwickler unabhängig von der Übersetzung nutzen würde – es bietet keinen allgemeinen JSON-Schema-/Stilvalidator oder JSON5-Unterstützung für diesen Anwendungsfall, und das ist eher eine echte Lücke als eine Möglichkeit, die man übergehen kann. Was es tatsächlich tut, ist, mehrere der oben genannten Prüfungen automatisch durchzuführen, sobald eine JSON-Datei in einen Smartling-Übersetzungsauftrag eingeht:

  • ICU MessageFormat-Analyse. Smartling unterstützt das ICU MessageFormat in JSON-Dateien über die Direktive string_format (icu ist der Standardwert) und analysiert Platzhalter, Pluralformen und select-Anweisungen gemäß der ICU-Spezifikation. In der Dokumentation von Smartling wird darauf hingewiesen, dass diese Unterstützung bekannte Einschränkungen aufweist und in einigen Fällen zwei separate Zeichenketten für dieselbe ICU-Konstruktion erzeugen kann – es lohnt sich, dies anhand Ihrer spezifischen Plural-/Select-Muster zu testen, anstatt von einer vollständigen Abdeckung auszugehen.
  • Automatisierte Qualitätskontrollen. Smartlings Qualitätsprüfungen laufen gegen übersetzte Inhalte und umfassen Platzhalter-Konsistenz, Tag-Konsistenz, Plurale, Rechtschreibprüfung, Weißraum-/Führungs-Laufzeichen-Kontrollen und Zeichenbegrenzungsprüfungen, jeweils mit einem konfigurierbaren Schweregrad, die direkt im CAT-Tool und im Review-Modus markiert werden.
  • Kodierungsverarbeitung. Die Files API von Smartling behält die UTF-16-Kodierung bei Dateien bei, die auf diese Weise hochgeladen werden, und verwendet ansonsten standardmäßig UTF-8. Die Unterstützung für regionale Zeichensätze wie Big5, EUC-JP, EUC-KR und GB18030 wird für Dateien, die diese verwenden, separat dokumentiert.
  • CI/CD-nahe Automatisierung. Mit der Smartling CLI, der RESTful API (mit Node.js und Python SDKs) und dem GitHub Connector können Entwicklungsteams das Hochladen von JSON-Dateien und die Auslieferung übersetzter Dateien innerhalb einer Pipeline automatisieren – der GitHub Connector überwacht speziell ein Repository auf Quellcodeänderungen und öffnet einen Pull Request mit übersetzten Dateien.
  • Ein stiller Fehlermodus, den man kennen sollte. Laut Smartlings eigener JSON-Datei-Dokumentation schlägt ein Upload nur dann fehl, wenn Smartling in der Datei nicht mindestens eine übersetzbare Zeichenkette findet – Fehler in Schlüssel- oder Anweisungspfaden blockieren den Upload ansonsten nicht. Das ist zwar praktisch, um Pipelines freizuhalten, bedeutet aber auch, dass ein falsch konfigurierter Pfad eine Datei stillschweigend unterübersetzen kann, anstatt einen Fehler auszulösen. Daher ist es sicherer, den Upload-Schritt von Smartling mit einer vorgelagerten Schema-Validierung zu kombinieren (anstatt sich darauf zu verlassen, dass Smartling einen Strukturfehler erkennt).

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