Warum Übersetzte Lokalisierungsdateien Apps Lahmlegen (und Was Unangetastet Bleiben Muss)

Eine Lokalisierungsdatei Ist Code mit Sätzen Darin

Sprachdateien in PO, YAML, .properties, RESX, XLIFF und JSON sehen aus wie Listen von Sätzen, doch nur die Werte sind Fließtext. Die Schlüssel sind Bezeichner, nach denen der Code sucht; die Platzhalter sind Lücken, die der Code zur Laufzeit füllt; Escapes und Markup sind Syntax, auf die sich der Parser verlässt. Wer die ganze Zeile als Text behandelt, erzeugt eine Datei, die sich wunderbar liest und sich nicht laden lässt – oder die lädt und dann abstürzt, sobald ein Bildschirm zum ersten Mal eine Zahl formatiert. Der Fehler zeigt sich meist nur in einer Sprache, und genau das macht ihn zur am schwersten zu entdeckenden Fehlerart im Review.

Fünf Dinge, die die Übersetzung Unverändert Überstehen Müssen

• Schlüssel und Ressourcennamen — der Code sucht Strings über ihren Schlüssel, ein übersetzter Schlüssel ist also schlicht ein fehlender String.
• Platzhalter — %s, %1$d, {0}, {name} und ICU-Argumente werden vom Code befüllt; wer einen davon umbenennt oder weglässt, zerstört die Formatierung oder löst zur Laufzeit einen Fehler aus.
• Escapes und Kodierungsregeln — eine .properties-Datei, die mit der klassischen Methode Properties.load(InputStream) gelesen wird, gilt als Latin-1, andere Zeichen werden als \uXXXX-Escapes geschrieben, sodass roher nicht-lateinischer Text zu Mojibake werden kann.
• Markup in Strings — HTML-Tags, XLIFF-Inline-Codes und Markdown müssen ausgeglichen bleiben, sonst zerstört der gerenderte String die Seite um ihn herum.
• Dateistruktur — YAML-Einrückung, Blockskalare, Anker und Aliase sowie XML-Verschachtelung sind Syntax; eine verschobene Einrückung oder ein übersetzter Ankername ändert, was die Datei bedeutet.

Plural Ist Nicht Einfach Singular Plus ein "s"

Englisch hat zwei Pluralformen, daher liegt die Annahme nahe, dass jede Sprache zwei hat. Das GNU-gettext-Handbuch zeigt, warum das nicht funktioniert: Jede Sprache deklariert ihre eigene Plural-Forms-Regel, Englisch verwendet nplurals=2, und Russisch braucht drei Formen, die nach den letzten Ziffern der Zahl gewählt werden. Eine ins Russische übersetzte PO-Datei, in der nur zwei Formen ausgefüllt sind, kompiliert, läuft und gibt für jede Anzahl, die auf 2, 3 oder 4 endet, die falsche Grammatik aus. Korrekte Pluralbehandlung bedeutet, so viele msgstr-Einträge zu erzeugen, wie die Zielsprache verlangt – nicht so viele, wie die Ausgangssprache zufällig hatte.

Platzhalter Müssen Manchmal Wandern

Die Wortstellung unterscheidet sich zwischen Sprachen, daher muss ein Satz mit zwei Werten diese oft in umgekehrter Reihenfolge bringen. Positionale Platzhalter wie %1$s und %2$s oder benannte wie {count} und {user} gibt es genau dafür: Die Übersetzung darf sie umstellen, aber jeder muss weiterhin genau einmal vorkommen. Anonyme Platzhalter wie ein bloßes %s lassen sich nicht sicher umstellen – ein Problem, das man besser vor der Übersetzung in den Quelltexten behebt als danach.

Formatregeln, die Sie vor dem Übersetzen Kennen Sollten

Jedes Format hat seine eigenen Tücken. In YAML gibt die Spezifikation einem Literal-Block (|) und einem gefalteten Block (>) unterschiedliches Zeilenumbruchverhalten, und Anker (&) und Aliase (*) lassen einen Knoten einen anderen wiederverwenden – beides muss also unangetastet durchkommen. XLIFF 2.1 verpackt die ursprüngliche Formatierung in Inline-Elemente wie <ph> und <pc>, die eine Übersetzung an ihrer Stelle um die richtigen Wörter herum halten muss. In .NET werden RESX-Ressourcen zur Laufzeit per Name für die aktuelle UI-Kultur gesucht, sodass ein umbenanntes data-Element stillschweigend auf die Standardsprache zurückfällt. Und eine Java-.properties-Datei behandelt das erste nicht maskierte =, : oder Leerzeichen als Schlüsseltrenner, sodass ein verirrter Doppelpunkt in einem übersetzten Schlüssel diesen in zwei Teile spaltet.

Eine Review-Checkliste, die die Meisten Fehler Findet

1. Zählen Sie die Platzhalter in jedem Quell- und Zielstring — die Multimenge muss übereinstimmen, auch wenn die Reihenfolge es nicht tut.
2. Vergleichen Sie die Schlüssel, nicht die Werte — jeder Schlüssel, der in der Quelle vorhanden ist und im Ziel fehlt oder umbenannt wurde, ist ein Fehler.
3. Laden Sie die übersetzte Datei vor der Auslieferung mit dem echten Parser (msgfmt, einem YAML-Loader, ResXResourceReader).
4. Prüfen Sie Pluraleinträge gegen die Regel der Zielsprache, nicht gegen die der Ausgangssprache.
5. Rendern Sie die längste Übersetzung im engsten UI-Element — Text in anderen Sprachen ist oft länger als der englische.