Translation QA: Was in Übersetzungen wirklich kaputtgeht, und wie man es automatisch findet

Translation QA (Qualitätssicherung für Übersetzungen) ist die Praxis, übersetzte Inhalte auf Fehler zu prüfen, bevor sie Nutzer erreichen. Sie hat zwei Ebenen: die mechanische Ebene, also alles, was sich zwischen einem Quelltext und seiner Übersetzung objektiv vergleichen lässt (Platzhalter, HTML-Tags, Zahlen, Interpunktion, Leerzeichen, Terminologie-Konsistenz), und die Urteilsebene, also die Frage, ob die Übersetzung im richtigen Ton das Richtige sagt. Die erste Ebene lässt sich vollständig automatisieren. Die zweite nicht, und so zu tun als ob, ist der Weg, auf dem kaputte Releases ausgeliefert werden.

Dieser Beitrag handelt von der ersten Ebene: was in echten Übersetzungsdaten tatsächlich kaputtgeht, warum manuelles Review es immer wieder übersieht, und was automatische linguistische Checks dagegen tun können und was nicht.

Was in Übersetzungen wirklich kaputtgeht

Fragt man Menschen, wie ein Übersetzungsfehler aussieht, beschreiben sie eine Fehlübersetzung: einen Satz, der das Falsche sagt. Schaut man in echte Übersetzungsdaten von Software-Produkten, findet man etwas weniger Glamouröses. Die Defekte, die es bis in die Produktion schaffen, sind ganz überwiegend strukturell, und sie gruppieren sich in eine kleine Taxonomie.

Platzhalter und Markup

Die schädlichste Klasse. Ein Interpolations-Platzhalter wie {{count}}, den ein Übersetzer (oder eine Maschine) umbenannt, übersetzt oder verloren hat, rendert nicht als leicht falscher Text, sondern als wörtliches {{Anzahl}} auf dem Bildschirm, oder lässt den Formatter abstürzen. Dasselbe gilt für HTML- und Komponenten-Tags: die <0>…</0>-Marker von react-i18next, ein <strong> ohne schließendes Tag, ein Link, der in einer Sprache verschwunden ist. Ein zerbrochenes Tag rendert üblicherweise als roher Text, und zwar genau für die Nutzer, die diese Sprache lesen, und für niemanden im Büro.

Zahlen

Eine Zahl, die im Quelltext steht und in der Übersetzung fehlt ("30 Tage" übersetzt als "Tage"), verändert die Bedeutung lautlos. Die Feinheit: Zahlen ändern ihre Form zwischen Locales völlig legitim. Lokale Zahlenformate, ostarabische Ziffern und Vollbreite-Ziffern, und die Umrechnung von 12-Stunden- auf 24-Stunden-Zeit ("9pm" wird "21 Uhr") sind alle korrekt. Ein brauchbarer Check muss das als gleich behandeln und trotzdem die wirklich fehlende Menge melden.

Interpunktion, Groß-/Kleinschreibung, Klammern

Ein verlorener Doppelpunkt am Ende zerstört ein Label, das die Oberfläche mit einem Wert zusammensetzt. Ein verschwundenes Fragezeichen macht aus einer Sicherheitsabfrage eine Feststellung. Spanisch erwartet das umgekehrte ¿, wenn der Satz mit einem Fragezeichen endet. Klammern sind eine eigene Kategorie: Eine Übersetzung, deren ()-Anzahl vom Quelltext abweicht, oder eine unbalancierte Klammer, die der Quelltext nicht hat, ist meistens ein abgeschnittener oder halb editierter Wert. Und die Groß-/Kleinschreibung des ersten Buchstabens unterscheidet sich legitim zwischen Sprachen (Deutsch schreibt Substantive groß; Überschriften-Fragmente unterscheiden sich pro Sprache), ein naiver Vergleich erzeugt also Rauschen statt Befunden.

Leerzeichen

Unsichtbar und deshalb beliebt: doppelte Leerzeichen innerhalb eines Werts, oder führende und abschließende Leerzeichen, die vom Quelltext abweichen. Abschließende Leerzeichen werden in dem Moment relevant, in dem Ihre Anwendung übersetzte Fragmente zusammensetzt. Die französische Typografie liefert die Pointe: Ein geschütztes Leerzeichen vor Satzzeichen ist korrektes Französisch und darf nicht als Doppel gezählt werden.

Wiederholungen

"Die die" passiert in jeder Sprache, meist als Überbleibsel einer Bearbeitung. Der Haken: Manche Doppelungen sind grammatikalisch korrekt, etwa französische Reflexivkonstruktionen ("nous nous retrouvons") oder deutsche Artikelfolgen. Ein Check, der das nicht weiß, flutet Reviewer mit Fehlalarmen, bis sie ihn abschalten.

Inkonsistente Terminologie

Der leiseste Defekt, und in unseren Daten der am weitesten verbreitete: derselbe Quellwert, über Keys hinweg unterschiedlich übersetzt. Ein "Save"-Button sagt "Speichern", ein anderer "Sparen". Ein Begriff ist selten überall falsch übersetzt, aber oft irgendwo, und in diesen Abweichungen verstecken sich die Fehlübersetzungen. Das ist kein Check pro Wert; er braucht den gesamten Korpus einer Sprache.

Gefährliches Markup

Der Sicherheits-Ausläufer desselben Problems: Übersetzungswerte sind Inhalte, die Ihre Anwendung rendert. Ein Wert mit <script>, einem onclick=-Handler oder einer javascript:-URL ist kein Qualitätsproblem, sondern ein Injektionsvektor, denn Übersetzer-Accounts und schreibberechtigte API-Keys gehören zu Ihrer Angriffsfläche, ob Sie sie so betrachten oder nicht.

Wie häufig ist das wirklich?

Gemessen über Projekte auf Locize im August 2026: Rund 2,3% der übersetzten Segmente lösen mindestens einen der obigen mechanischen Checks aus, angeführt von Leerzeichen, End-Interpunktion und Zahlenabweichungen. Konsistenz über Keys hinweg ist noch breiter: Etwa 3,9% der Segmente haben mindestens einen Geschwister-Key, der denselben Quellwert anders übersetzt, und 87% der untersuchten Projekte enthalten mindestens eine solche Abweichung.

Eines von vierzig Segmenten klingt klein, bis man es mit einem Produkt mit zwanzigtausend Segmenten in acht Sprachen multipliziert. Es konzentriert sich außerdem genau in den Inhalten, die sich kürzlich geändert haben, also in den Inhalten, die Ihr nächstes Release ausliefert.

Wie Teams Translation QA heute machen

Die meisten Teams, die Übersetzungsqualität ernst nehmen, kombinieren einige der folgenden Ansätze:

• Ein menschlicher Review-Durchgang pro Sprache, durch einen zweiten Übersetzer, eine Kollegin im Zielmarkt oder eine LQA-Runde der Agentur. Das ist das richtige Werkzeug für Bedeutung und Ton, und das falsche für Platzhalter: Menschen überlesen mechanische Details, und ein Reviewer, der 4.000 Strings auf Klammeranzahlen prüft, hört auf, Linguist zu sein, und wird zu einem sehr teuren Regex.
• Stichproben in Tabellen: exportieren, filtern, draufschauen. Findet, was man zufällig anschaut, an dem Tag, an dem man es anschaut.
• Eigene Skripte in der CI: eine Sammlung von Regexen, die jemand an einem Nachmittag geschrieben hat, fängt fehlende Interpolationen in einem Dateiformat, in den Sprachen, an die der Autor gedacht hat. Nützlich, ungewartet, und blind für alles Key-übergreifende (Konsistenz) und alles Sprachspezifische (das ¿, das geschützte Leerzeichen, die Substantiv-Großschreibung).
• Styleguides und Glossare als Dokumente: Die korrekte Terminologie lebt in einem PDF, an das sich Reviewer erinnern sollen, während der tatsächliche Korpus driftet.

Das Muster über alle vier: Die mechanische Ebene wird gelegentlich und teilweise geprüft, von Menschen oder Skripten, die für etwas anderes gebaut wurden. Die Defekte kommen unterdessen kontinuierlich herein, mit jedem neuen Key, jedem maschinell übersetzten Batch und jedem schnellen Fix direkt in der Datei.

Was automatische linguistische Checks ändern

Ein automatischer Check führt den Vergleich, in dem Reviewer nie gut waren, auf jedem Wert aus, in jeder Sprache, bei jeder Änderung. Die Anforderungen, die eine nützliche Implementierung von einem Rauschgenerator trennen:

1. Sprachbewusstsein. Jeder Check oben hat legitime Ausnahmen pro Sprache. Ein Checker, der deutsche Substantiv-Großschreibung als Casing-Fehler meldet oder französische geschützte Leerzeichen als Doppel, trainiert Reviewer innerhalb einer Woche darauf, ihn zu ignorieren.
2. Korpus-Reichweite. Konsistenzdefekte sind auf der Ebene eines einzelnen Werts unsichtbar. Der Check muss über alle Keys einer Sprache vergleichen.
3. Kontinuierlich per Default. Ein QA-Durchlauf, an den jemand denken muss, ist eine Tabelle mit besserer Oberfläche. Checks gehören auf den Speicherpfad und in den Editor, mit Befunden am Key, nicht in einen Bericht, den niemand wieder öffnet.
4. Ein Notausgang pro Befund. Manchmal ist die Abweichung Absicht: Dasselbe Quellwort braucht in zwei Kontexten wirklich zwei Übersetzungen. Wenn das Ignorieren eines Befunds keine punktgenaue Ein-Klick-Aktion ist, schalten Teams stattdessen den ganzen Check ab.
5. Eine klare Grenze zum menschlichen Urteil. Checks beantworten die Frage "Ist das strukturell konsistent mit Quelle und Korpus?". Sie beantworten nicht "Ist das eine gute Übersetzung?". Das bleibt Review-Arbeit, gestützt durch Glossare und Styleguides, und für maschinell erzeugte Übersetzungen durch Quality Estimation, die bewertet, was Checks nicht vergleichen können.

Wie das in Locize funktioniert

Locize betreibt diese Ebene eingebaut, standardmäßig aktiv, ohne Konfiguration:

• Zehn sprachbewusste linguistische Checks vergleichen jede Übersetzung mit ihrem Quelltext: End-Interpunktion, Groß-/Kleinschreibung des ersten Buchstabens, Zahlen, Klammeranzahlen, unbalancierte Klammern, Leerzeichen, doppelte Wörter, Sonderzeichen, URL-Anzahlen sowie HTML- und Komponenten-Tags, jeweils mit den oben beschriebenen Ausnahmen pro Sprache.
• Konsistenz-Checks arbeiten korpusweit: Sie finden denselben Quellwert mit unterschiedlichen Übersetzungen über Keys hinweg (die abweichenden Keys werden direkt am Befund gelistet), doppelte Quellwerte, Glossar-Verstöße und i18n-Syntax-Inkonsistenzen.
• Die Erkennung gefährlichen Markups meldet skript-ausführende Inhalte in Werten und blockiert deren Speicherung per Default, im Editor wie über die API, damit ein kompromittierter Übersetzer-Account kein <script> über eine Übersetzung in Ihre Anwendung einschleusen kann.
• Befunde erscheinen inline im Editor am Key, aggregieren in der Übersetzungsstatistik des Projekts, und jeder Befund lässt sich pro Key ignorieren, wo die Abweichung Absicht ist. Sie können außerdem alle Checks über das gesamte Projekt laufen lassen, in einer Aktion:

Alle Checks eines Projekts in Locize ausführen

Der Sinn des Defaults ist derselbe wie der Sinn dieses Beitrags: Die mechanische Ebene ist nicht der Ort, an den menschliche Aufmerksamkeit gehört. Lassen Sie die Checks diese Linie halten, geben Sie Reviewern das Glossar, den Styleguide und den Review-Workflow, und investieren Sie die Menschen in den Teil, den Maschinen nicht beurteilen können.

Wenn Sie sehen möchten, was die Checks in Ihren eigenen Inhalten finden: Erstellen Sie ein Projekt, importieren Sie Ihre bestehenden Übersetzungsdateien und lassen Sie die Checks laufen. Die Befunde sind meistens nicht die, die Sie erwartet haben.

Häufig gestellte Fragen

Was ist Translation QA? Translation QA (Qualitätssicherung für Übersetzungen) ist die Praxis, übersetzte Inhalte vor der Auslieferung auf Fehler zu prüfen. Sie umfasst die mechanische Ebene (Platzhalter, Tags, Zahlen, Interpunktion, Leerzeichen, Konsistenz) und die Urteilsebene (Bedeutung, Ton, Flüssigkeit). Die mechanische Ebene lässt sich automatisieren; die Urteilsebene braucht Menschen, gestützt durch Glossare, Styleguides und Review-Workflows.

Was sind die häufigsten Fehler in Übersetzungen? Mechanische Defekte dominieren: veränderte oder verlorene Interpolations-Platzhalter und HTML-Tags, Zahlen, die vom Quelltext abweichen, fehlende End-Interpunktion, beschädigte Leerzeichen bei zusammengesetzten Werten, doppelte Wörter und derselbe Begriff, inkonsistent über Keys hinweg übersetzt.

Kann Translation QA automatisiert werden? Die mechanische Ebene lässt sich deterministisch bei jedem Speichern prüfen, in jeder Sprache. Die Urteilsebene nicht: Maschinelle Übersetzungen kann Quality Estimation bewerten, menschliches Review entscheidet. Funktionierende Setups kombinieren beides.

Was ist der Unterschied zwischen QA-Checks und Quality Estimation (QE)? QA-Checks sind deterministische Vergleiche mit Quelle und Korpus; sie finden strukturelle Defekte und sind immer reproduzierbar. QE ist ein modellbasierter Score, der die Qualität einer Übersetzung ohne Referenz vorhersagt. QE priorisiert die Review-Aufmerksamkeit für neue maschinelle Übersetzungen; QA-Checks bewachen den gesamten Korpus kontinuierlich.

Ersetzen automatische Checks das menschliche Review? Nein. Sie entfernen das mechanische Rauschen, damit die Review-Zeit in Bedeutung, Terminologie und Ton fließt. Ein Reviewer, der keine Klammern mehr zählen muss, ist ein besserer Linguist, kein arbeitsloser.