better-i18n i18n Health Check: Automatisches Übersetzungsqualitäts-Monitoring

Ihre Anwendung ist in zwölf Sprachen verfügbar. Aber woher wissen Sie, dass jeder Bildschirm, jede Fehlermeldung, jeder Tooltip übersetzt wurde? Woher wissen Sie, dass ein Platzhalter wie {count} auf Englisch nicht versehentlich als {nombre} auf Französisch geschrieben wurde? Woher wissen Sie, dass die Keys, die Sie vor drei Sprints aus dem Codebase gelöscht haben, nicht noch immer in Ihren Übersetzungsdateien liegen und Unordnung und Verwirrung verursachen?

Die meisten Teams erfahren von Übersetzungsproblemen durch Nutzer. Ein Kunde in Tokio sieht einen rohen Key wie dashboard.welcome_message statt einer Begrüßung. Ein deutscher Nutzer meldet, dass ein Preis {amount} anzeigt statt der eigentlichen Zahl. Ein QA-Ingenieur vergleicht JSON-Dateien manuell und entdeckt, dass der spanischen Übersetzung 47 Keys fehlen, die letzten Monat hinzugefügt wurden.

better-i18n Doctor ist ein automatisierter i18n Health Check, der Ihren Codebase und Ihre Übersetzungsdateien scannt, jede Kategorie von Übersetzungsproblemen identifiziert und einen Gesundheitsscore von 0–100 erzeugt. Er läuft lokal über die CLI, integriert sich in Ihre CI/CD-Pipeline und meldet Ergebnisse an die better-i18n-Plattform zur zeitlichen Verfolgung.

Wie der Health Score funktioniert

Doctor erzeugt eine einzige Zahl: einen Health Score von 0 bis 100. Dieser Score ist ein gewichteter Durchschnitt aus vier Kategorien, die jeweils eine andere Dimension Ihrer i18n-Qualität bewerten.

Die vier Kategorien

Coverage misst, ob jeder in Ihrem Code verwendete Key in jeder Zielsprachdatei vorhanden ist. Ein Key, der auf Englisch vorhanden, aber im Japanischen fehlt, ist eine Coverage-Lücke. Coverage ist die häufigste Quelle von Übersetzungsproblemen — neue Features werden mit Keys ausgeliefert, die nie zur Übersetzung gesendet wurden, oder ein Entwickler fügt einen Key zu einem Namespace hinzu und vergisst, ihn zu den anderen hinzuzufügen.

Quality prüft den Inhalt von Übersetzungen auf strukturelle Korrektheit. Platzhalter-Abweichungen sind das Hauptproblem — wenn der englische String {count} und {name} enthält, muss die deutsche Übersetzung genau dieselben Platzhalter enthalten. Quality prüft auch auf leere Übersetzungen (Keys, die existieren, aber leere Werte haben), übermäßig lange Übersetzungen, die UI-Layouts zerstören könnten, und Strings, die identisch mit der Quellsprache sind (was auf unübersetzten Inhalt hinweisen kann, der aus dem Englischen kopiert wurde).

Structure bewertet die Organisation Ihrer Übersetzungsdateien. Es prüft auf verwaiste Keys (Orphan Keys) — Keys, die in Übersetzungsdateien vorhanden sind, aber nirgendwo im Quellcode referenziert werden. Orphan Keys sind harmlos, verursachen aber Wartungsaufwand: Übersetzer verbringen Zeit damit, Strings zu aktualisieren, die kein Nutzer je sehen wird, und Entwickler verschwenden Zeit beim Überprüfen von Übersetzungen für nicht verwendete Features. Structure prüft auch auf konsistente Key-Benennung, doppelte Keys und Namespace-Organisation.

Code verwendet AST-Analyse, um Ihren Quellcode auf hartcodierte Strings zu scannen, die internationalisiert werden sollten. Es erkennt benutzerseitige Strings in JSX-Komponenten, Template Literals, die an UI-Funktionen übergeben werden, und String-Konstanten, die in Fehlermeldungen oder Benachrichtigungen verwendet werden. Diese Kategorie erfasst die häufigste Quelle von i18n-Schulden: Ein Entwickler schreibt <p>Loading...</p> statt <p>{t('common.loading')}</p>, weil es schneller geht, und plant, es später zu korrigieren. Doctor findet diese Strings, bevor sie ausgeliefert werden.

Score-Berechnung

Jede Kategorie erzeugt einen Teilscore von 0 bis 100, basierend auf dem Verhältnis bestandener Prüfungen zur Gesamtzahl der Prüfungen. Der Gesamt-Health-Score ist ein gewichteter Durchschnitt:

Kategorie	Gewichtung	Was gemessen wird
Coverage	40%	Fehlende Übersetzungs-Keys in allen Sprachen
Quality	30%	Platzhalter-Abweichungen, leere Werte, verdächtiger Inhalt
Structure	20%	Orphan Keys, Benennungskonsistenz, Duplikate
Code	10%	Hartcodierte Strings im Quellcode

Coverage wird am höchsten gewichtet, da fehlende Übersetzungen die direkteste Auswirkung auf Nutzer haben — sie führen dazu, dass rohe Keys oder die Fallback-Sprache angezeigt werden. Code-Analyse wird am niedrigsten gewichtet, da hartcodierte Strings technische Schulden sind, die die Nutzererfahrung nicht sofort beeinträchtigen, obwohl sie im Laufe der Zeit behoben werden sollten.

Bestanden/Nicht bestanden-Schwellenwert

Ein Scan gilt als bestanden, wenn der Gesamtscore 80 oder höher ist und null Fehler vorliegen (im Gegensatz zu Warnungen). Fehler sind Probleme, die Nutzer direkt betreffen — fehlende Übersetzungen für vollständige Features, Platzhalter-Abweichungen, die Runtime-Fehler verursachen, oder Keys, die auf nicht existierende Namespaces verweisen. Warnungen sind Probleme, die behoben werden sollten, aber die Nutzererfahrung nicht beeinträchtigen — Orphan Keys, inkonsistente Benennung oder hartcodierte Strings.

Sie können den Bestanden-Schwellenwert entsprechend den Standards Ihres Teams konfigurieren:

bi18n doctor --threshold 90

Doctor lokal ausführen

Basis-Scan

Führen Sie einen vollständigen Health Check aus Ihrem Projektstammverzeichnis aus:

bi18n doctor

Doctor erkennt Ihre Übersetzungsdateien automatisch basierend auf Ihrer better-i18n.yml-Konfiguration oder durch Erkennen gängiger Verzeichnisstrukturen (locales/, messages/, i18n/, lib/l10n/). Es scannt Ihre Quelldateien nach Key-Verwendung und vergleicht alles, um den Health-Bericht zu erstellen.

Die Ausgabe ist ein strukturierter Bericht, der den Gesamtscore, Kategorie-Aufschlüsselungen und einzelne Regelergebnisse zeigt:

i18n Doctor Report
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Gesamtscore: 87/100 ✓ BESTANDEN

Coverage     92/100  ██████████████████░░  3 fehlende Keys
Quality      85/100  █████████████████░░░  2 Platzhalter-Abweichungen
Structure    78/100  ███████████████░░░░░  12 Orphan Keys
Code         90/100  ██████████████████░░  4 hartcodierte Strings

Fehler: 0  Warnungen: 21
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Gezielte Scans

Überspringen Sie Kategorien, die für Ihren unmittelbaren Bedarf nicht relevant oder zu langsam sind:

# Code-Analyse überspringen (schnellerer Scan)
bi18n doctor --skip-code

# Health/Quality-Prüfungen überspringen (nur Coverage und Structure)
bi18n doctor --skip-health

# Sync-Status-Prüfungen überspringen
bi18n doctor --skip-sync

# Ausführliche Ausgabe — alle Regelergebnisse anzeigen, nicht nur Fehler
bi18n doctor --verbose

Einzelne Prüfbefehle

Doctor bündelt mehrere Prüfungen, die auch unabhängig ausgeführt werden können:

# Auf fehlende Übersetzungs-Keys in allen Sprachen prüfen
bi18n check:missing

# Auf Orphan Keys prüfen, die nicht im Quellcode referenziert werden
bi18n check:unused

# Alle Prüfungen ausführen (entspricht Doctor ohne Code-Analyse)
bi18n check

# Quellcode auf hartcodierte Strings scannen
bi18n scan

# Sync-Status — lokale Dateien mit Plattformzustand vergleichen
bi18n sync --dry-run

Jeder Befehl liefert fokussierte Ausgaben für sein spezifisches Anliegen, was nützlich ist, wenn Sie an der Behebung einer bestimmten Kategorie von Problemen arbeiten.

CI/CD-Integration

GitHub Actions

Doctor ist darauf ausgelegt, als CI-Check bei jedem Pull Request zu laufen. Das --ci-Flag gibt Ergebnisse in einem Format aus, das GitHub Actions versteht, und erstellt Inline-Annotierungen für die Dateien mit Problemen:

# .github/workflows/i18n-doctor.yml
name: i18n Health Check

on:
  pull_request:
    paths:
      - "locales/**"
      - "src/**"
      - "messages/**"

jobs:
  doctor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Bun
        uses: oven-sh/setup-bun@v2

      - name: Abhängigkeiten installieren
        run: bun install

      - name: i18n Doctor ausführen
        run: bunx @better-i18n/cli doctor --ci --threshold 80
        env:
          BETTER_I18N_API_KEY: ${{ secrets.BETTER_I18N_API_KEY }}

Wenn das --ci-Flag gesetzt ist, Doctor:

Beendet mit Code 1, wenn der Scan fehlschlägt (Score unter Schwellenwert oder Fehler vorhanden), wodurch die GitHub Actions-Prüfung fehlschlägt
Gibt Annotierungen im GitHub Actions-Format aus, sodass Probleme als Inline-Kommentare im PR-Diff erscheinen
Erzeugt eine Zusammenfassung, die in der GitHub Actions-Prüfungsausgabe erscheint

Automatisch generierter GitHub Actions-Workflow

Wenn Sie die Workflow-Datei nicht manuell schreiben möchten, kann better-i18n sie für Sie erstellen. Navigieren Sie im Plattform-Dashboard zu Integrationen und dann GitHub Actions und klicken Sie auf Doctor-Workflow erstellen. Dies erstellt einen Pull Request in Ihrem Repository mit einer vorkonfigurierten Workflow-Datei, die auf Ihre Projekteinstellungen zugeschnitten ist.

Der automatisch generierte Workflow umfasst:

Pfadfilter, die Ihren Übersetzungsdatei-Speicherorten entsprechen
Ihren konfigurierten Schwellenwert
Anweisungen zur API-Key-Einrichtung
Optionale Slack-Benachrichtigung bei Fehler

An die Plattform melden

Wenn Doctor mit dem --report-Flag und einem API-Key läuft, übermittelt es den vollständigen Bericht an die better-i18n-Plattform:

bi18n doctor --report --api-key $BETTER_I18N_API_KEY

Der Bericht umfasst:

Score und Bestanden/Nicht bestanden-Status
Fehler- und Warnungsanzahl pro Kategorie
Einzelne Regelergebnisse mit betroffenen Keys und Dateien
Metadaten: Commit-SHA, Branch-Name, Anzahl der gescannten Dateien, Anzahl der geprüften Keys, Zeitstempel

An die Plattform übermittelte Berichte werden gespeichert und im Projekt-Dashboard angezeigt. Sie können Score-Trends über die Zeit anzeigen, Berichte zwischen Branches vergleichen und verfolgen, welche Kategorien sich verbessern oder verschlechtern.

CI-Berichtsübermittlung

Kombinieren Sie in CI-Umgebungen --ci und --report, um sowohl den PR zu validieren als auch den Bericht zu übermitteln:

- name: i18n Doctor ausführen
  run: bunx @better-i18n/cli doctor --ci --report --threshold 85
  env:
    BETTER_I18N_API_KEY: ${{ secrets.BETTER_I18N_API_KEY }}

Dadurch erhalten Sie zwei Feedback-Schleifen:

Sofort: Die PR-Prüfung wird bestanden oder nicht, und Entwickler sehen Inline-Annotierungen
Historisch: Der Bericht wird auf der Plattform für Trendanalysen und Team-Sichtbarkeit gespeichert

Regeldetails

Doctor bewertet eine Reihe von Regeln innerhalb jeder Kategorie. Hier sind die wirkungsvollsten Regeln und was sie erkennen.

Coverage-Regeln

missing-keys: Für jeden in Ihrem Quellcode verwendeten Key wird geprüft, ob eine Übersetzung in jeder Zielsprachdatei vorhanden ist. Fehlende Keys sind das häufigste i18n-Problem und das sichtbarste für Nutzer — sie führen dazu, dass rohe Key-Namen oder die Fallback-Sprache angezeigt werden.

namespace-coverage: Prüft, ob jeder in Ihrem Code referenzierte Namespace entsprechende Übersetzungsdateien für alle Zielsprachen hat. Ein Entwickler könnte t('checkout.confirm_order') hinzufügen, aber die checkout-Namespace-Datei existiert nicht für Koreanisch.

Quality-Regeln

placeholder-mismatch: Vergleicht Platzhalter zwischen Quell- und Zielübersetzungen. Wenn en: "Hello {name}, you have {count} items" vorhanden ist, wird geprüft, dass jede andere Sprachübersetzung genau {name} und {count} enthält. Zusätzliche oder fehlende Platzhalter verursachen Runtime-Fehler oder zeigen rohe Platzhalter-Syntax an.

empty-translation: Markiert Keys, die in einer Zielsprache vorhanden sind, aber leere String-Werte haben. Leere Übersetzungen entstehen oft durch programmgesteuerte Key-Hinzufügung ohne tatsächlichen übersetzten Inhalt.

source-identical: Markiert Übersetzungen, die Zeichen für Zeichen identisch mit der Quellsprache sind. Obwohl einige Strings (Markennamen, URLs, technische Begriffe) legitim sprachübergreifend identisch sind, deutet eine hohe Anzahl quellidentischer Strings normalerweise auf unübersetzten Inhalt hin.

Structure-Regeln

orphan-keys: Identifiziert Keys in Übersetzungsdateien, die nirgendwo im Quellcode referenziert werden. Orphan Keys häufen sich an, wenn Features entfernt, aber Übersetzungsdateien nicht bereinigt werden. Sie verschwenden Übersetzeraufwand und verursachen Verwirrung darüber, was aktiv verwendet wird.

duplicate-keys: Erkennt denselben Key, der mehrmals innerhalb einer einzelnen Datei oder eines Namespace definiert ist. Duplikate verursachen unvorhersehbares Verhalten — die Übersetzungs-Engine verwendet einen davon, aber welchen, hängt von Implementierungsdetails ab.

naming-consistency: Prüft, ob Key-Namen konsistenten Mustern folgen. Wenn die meisten Keys snake_case verwenden, wird ein Key mit camelCase markiert. Inkonsistente Benennung erschwert das Finden und Pflegen von Keys.

Code-Regeln

hardcoded-jsx: Verwendet AST-Parsing, um String-Literale in JSX-Elementen zu erkennen. <h1>Welcome</h1> wird markiert; <h1>{t('welcome')}</h1> nicht. Diese Regel versteht JSX und ignoriert nicht benutzerseitige Strings wie CSS-Klassennamen und Data-Attribute.

hardcoded-template: Erkennt String-Literale, die an Funktionen übergeben werden, die typischerweise benutzerseitige Ausgaben erzeugen — Toast-Benachrichtigungen, Alert-Dialoge, Fehlermeldungen. showToast("Operation successful") wird markiert.

hardcoded-constant: Identifiziert String-Konstanten, die Variablen mit benutzerseitigen Namen zugewiesen werden (wie errorMessage, label, title, placeholder), die nicht in Übersetzungsfunktionen eingebettet sind.

Plattform-Dashboard

Über --report übermittelte Berichte werden im better-i18n-Plattform-Dashboard visualisiert.

Score-Trends

Ein Zeitreihenchart zeigt Ihren Health Score über die Zeit. Jeder Punkt repräsentiert einen Doctor-Bericht, nach Datum aufgetragen. Sie können nach Branch filtern, um die Gesundheitsentwicklung von main gegenüber Feature-Branches zu sehen. Die Trendlinie zeigt deutlich, ob Ihre i18n-Qualität sich verbessert, stabil bleibt oder sich verschlechtert.

Kategorie-Aufschlüsselung

Vertiefen Sie sich in jede Kategorie, um zu sehen, welche Regeln bestanden werden und welche nicht. Für jede fehlschlagende Regel können Sie die spezifischen Keys und Dateien sehen. Klicken Sie auf einen Key, um ihn im Übersetzungseditor zu öffnen; klicken Sie auf eine Datei, um sie im Kontext Ihres Repositorys zu sehen.

Projektübergreifender Vergleich

Für Organisationen mit mehreren Projekten zeigt das Dashboard Health Scores für alle Projekte an. Dies ist nützlich, um zu identifizieren, welche Projekte i18n-Aufmerksamkeit benötigen, und um organisationsweite Qualitätsstandards festzulegen.

Benachrichtigungen

Konfigurieren Sie Benachrichtigungen, um informiert zu werden, wenn Ihr Health Score unter einen Schwellenwert fällt:

E-Mail: Wöchentliche Zusammenfassung der Health-Score-Änderungen
Slack: Sofortige Benachrichtigung, wenn ein Bericht fehlschlägt
Webhook: Benutzerdefinierte Integration für Ihren Monitoring-Stack

Praktische Beispiele

Beispiel 1: Fehlende Übersetzungen vor dem Release erkennen

Ihr Team hat einen neuen Checkout-Flow mit 30 neuen Übersetzungs-Keys hinzugefügt. Der Entwickler hat alle Keys zur englischen Datei hinzugefügt. Französische und deutsche Übersetzungen wurden angefordert, aber noch nicht abgeschlossen. Ohne Doctor wird dies mit rohen Keys für französische und deutsche Nutzer ausgeliefert.

Mit Doctor in CI:

Coverage     60/100  ████████████░░░░░░░░  30 fehlende Keys (fr, de)

Fehler: 30 Keys fehlen in Zielsprachen
  checkout.confirm_order — fehlt in: fr, de
  checkout.payment_method — fehlt in: fr, de
  checkout.shipping_address — fehlt in: fr, de
  ... (27 weitere)

Ergebnis: NICHT BESTANDEN (Score 60, Schwellenwert 80)

Der PR wird blockiert. Der Entwickler sieht die Inline-Annotierungen, fordert Übersetzungen an, und der PR wird erst nach Abschluss der Übersetzungen gemergt.

Beispiel 2: Platzhalter-Abweichungen erkennen

Ein Übersetzer aktualisiert die deutsche Übersetzung für einen Benachrichtigungs-String. Die englische Quelle hat You have {count} new messages from {sender}. Die deutsche Übersetzung verwendet versehentlich {anzahl} statt {count}.

Doctor erkennt dies:

Quality      75/100  ███████████████░░░░░  1 Platzhalter-Abweichung

Fehler: Platzhalter-Abweichung in notifications.new_messages (de)
  Quell-Platzhalter: {count}, {sender}
  Ziel-Platzhalter: {anzahl}, {sender}
  Fehlend: {count}
  Extra: {anzahl}

Beispiel 3: Nach Feature-Entfernung aufräumen

Ihr Team hat das Legacy-Dashboard vor sechs Monaten entfernt. Der Code ist weg, aber die Übersetzungsdateien enthalten noch immer 85 Keys im legacy_dashboard-Namespace. Übersetzer aktualisieren diese Strings gelegentlich bei Massen-Übersetzungsdurchläufen und verschwenden Aufwand für Inhalte, die niemand sieht.

Doctor findet die Orphan Keys:

Structure    65/100  █████████████░░░░░░░  85 Orphan Keys

Warnung: 85 Keys im Namespace "legacy_dashboard" werden nicht im Quellcode referenziert
  legacy_dashboard.welcome — nicht referenziert
  legacy_dashboard.stats_header — nicht referenziert
  legacy_dashboard.chart_title — nicht referenziert
  ... (82 weitere)

Beispiel 4: Hartcodierte Strings finden

Ein neuer Entwickler tritt dem Team bei und schreibt ein Feature ohne das Übersetzungssystem zu verwenden. Er kodiert alle Strings direkt in JSX:

// Vor Doctor
<div>
  <h2>Account Settings</h2>
  <p>Manage your account preferences below.</p>
  <button>Save Changes</button>
</div>

Doctor markiert jeden hartcodierten String:

Code         40/100  ████████░░░░░░░░░░░░  3 hartcodierte Strings

Warnung: Hartcodierter String in JSX-Element (src/pages/Settings.tsx:15)
  <h2>Account Settings</h2>
  Vorschlag: <h2>{t('settings.account_title')}</h2>

Warnung: Hartcodierter String in JSX-Element (src/pages/Settings.tsx:16)
  <p>Manage your account preferences below.</p>

Warnung: Hartcodierter String in JSX-Element (src/pages/Settings.tsx:17)
  <button>Save Changes</button>

Vergleich mit Alternativen

Manuelles JSON-Diffing: Teams, die Übersetzungsdateien manuell vergleichen, erkennen Coverage-Probleme, verpassen aber alles andere — Platzhalter-Abweichungen, Orphan Keys, hartcodierte Strings. Manuelle Prüfungen sind auch fehleranfällig und skalieren nicht über eine Handvoll Sprachen hinaus.

ESLint i18n-Plugins: Linting-Regeln wie eslint-plugin-i18next erkennen hartcodierte Strings in JSX, prüfen aber nicht die Übersetzungsdateiqualität, Coverage über Sprachen hinweg oder strukturelle Probleme. Doctor umfasst Code-Analyse als eine von vier Kategorien und deckt das vollständige Spektrum von i18n-Problemen ab.

Phrase QPS (Quality Performance Score): Phrase bietet einen Übersetzungsqualitäts-Score, konzentriert sich aber auf linguistische Qualität (Grammatik, Terminologie) statt auf technische Qualität (fehlende Keys, Platzhalter-Abweichungen, Orphan Keys). Doctor konzentriert sich auf die technische Dimension — die Probleme, die Runtime-Fehler und fehlerhafte UIs verursachen.

Keine automatisierten Prüfungen: Viele Teams haben überhaupt keine automatisierten i18n-Prüfungen. Probleme werden von Nutzern oder QA-Ingenieuren entdeckt. Doctor bietet umfassende automatisierte Abdeckung, die Probleme erkennt, bevor sie eine Umgebung erreichen.

Häufig gestellte Fragen

Wie lange dauert ein Doctor-Scan? Ein typischer Scan eines Projekts mit 10.000 Keys, 8 Sprachen und 200 Quelldateien ist in unter 10 Sekunden abgeschlossen. Code-Analyse (AST-Parsing) ist die langsamste Kategorie — verwenden Sie --skip-code für schnellere Scans, wenn Sie nur Coverage- und Quality-Prüfungen benötigen.

Kann ich Doctor ohne Verbindung zur better-i18n-Plattform ausführen? Ja. Doctor läuft standardmäßig vollständig lokal. Das --report-Flag ist optional und wird nur benötigt, wenn Sie Ergebnisse zur Plattform zur Trend-Verfolgung übermitteln möchten.

Welche Frameworks unterstützt die Code-Analyse? Die Code-Analyse unterstützt derzeit React (JSX/TSX), Vue (SFC-Templates) und Svelte-Komponenten. Angular-Unterstützung ist geplant. Framework-Erkennung erfolgt automatisch basierend auf den Abhängigkeiten Ihres Projekts.

Kann ich benutzerdefinierte Regeln hinzufügen? Benutzerdefinierte Regeln sind auf der Roadmap. Aktuell können Sie die Regelpriorität (Fehler vs. Warnung) konfigurieren und spezifische Regeln deaktivieren, die für Ihr Projekt nicht relevant sind.

Funktioniert Doctor mit Monorepos? Ja. Doctor unterstützt workspace-bewusstes Scannen. Es erkennt Workspace-Grenzen und scannt jedes Paket unabhängig, erzeugt einen Pro-Paket-Bericht und einen aggregierten Gesamtscore.

Wie funktioniert die GitHub Actions-Workflow-Erstellung? Im better-i18n-Dashboard verwendet die Aktion Doctor-Workflow erstellen die GitHub-API, um einen Pull Request in Ihrem Repository mit einer vorkonfigurierten .github/workflows/i18n-doctor.yml-Datei zu erstellen. Sie überprüfen und mergen den PR, um den Workflow zu aktivieren.

Beginnen Sie mit dem Monitoring Ihrer i18n-Gesundheit

Übersetzungsprobleme sollten im CI erkannt werden, nicht von Nutzern. better-i18n Doctor gibt Ihrem Team einen kontinuierlichen, automatisierten Health Check, der jede Dimension Ihrer i18n-Qualität bewertet und verhindert, dass fehlerhafte Übersetzungen ausgeliefert werden.

Starten Sie Ihre kostenlose Testversion und führen Sie Ihren ersten Doctor-Scan in unter fünf Minuten durch.