Pseudolokalisierung heißt, jede übersetzbare Zeichenkette im Build durch eine maschinell erzeugte Fassung ihrer selbst zu ersetzen: länger, mit Akzenten, in sichtbaren Klammern, und das Produkt dann zu benutzen wie eine Anwenderin. Nichts wird übersetzt. Nichts muss es.
Es kostet einen Build und einen Nachmittag und findet die Fehlerklasse, die später am teuersten zu entdecken ist: die, die gar nicht in der Übersetzung steckt, sondern im Code, der sie anzeigt.
Die Rechnung ist das ganze Argument. Eine vor der Übersetzung gefundene fest verdrahtete Zeichenkette kostet eine Entwicklerin zehn Minuten. Dieselbe Zeichenkette danach kostet eine Rückfrage, einen erneuten Export, eine Teilübersetzung, einen neuen Build und eine zweite Testrunde: in vier Sprachen, denn es war nie nur eine.
Wie die falsche Locale aussehen sollte
Eine brauchbare Pseudo-Locale tut vier Dinge gleichzeitig, und Teams, die sich eine bauen, hören meist nach dem ersten auf.
Sie klammert jede Zeichenkette, damit die Grenze sichtbar ist. „Save“ wird zu ⟦Šâvé⟧, und eine fehlende Klammer ist eine Kürzung, nach der man sonst hätte suchen müssen.
Sie verlängert, üblich um dreißig bis vierzig Prozent, was Deutsch und Finnisch annähert. Sie akzentuiert jeden Buchstaben, den sie kann, was Schrift und Kodierung prüft. Und sie lässt Platzhalter und Auszeichnungen unangetastet und sichtbar, damit alles, was die Pipeline verstümmelt, sich sofort meldet statt drei Wochen nach dem Start still in einem Markt zu scheitern.
Die meisten Lokalisierungs-Frameworks liefern irgendeine Pseudo-Locale mit. Tut Ihres das nicht, ist das Ganze eine Transformation von dreißig Zeilen über der Zeichenkettentabelle: weniger Aufwand als der erste Fehler, den sie findet.
Was sie findet
Fest verdrahtete Zeichenketten, als Erstes und Wertvollstes. Steht ein Label nach dem Durchlauf noch auf Englisch da, hat es die Übersetzerinnen nie erreicht, und keine Übersetzungsqualität repariert eine Zeichenkette, die nie extrahiert wurde.
Kürzungen, als Zweites. Vierzig Prozent Polsterung nähert Deutsch an und legt jeden Container fester Breite offen, jede Auslassung mitten im Wort, jede Schaltfläche, deren Beschriftung nun unter ihrem eigenen Rand sitzt.
Kodierung und Schriftabdeckung, als Drittes. Akzentuierte und nichtlateinische Zeichen zeigen fehlende Glyphen, verstümmelte Byte-Behandlung und Schriften, die nie für die Märkte subsettet wurden, in die Sie gleich eintreten.
Und ein Viertes, nach dem niemand sucht: alles, was nicht die Oberfläche ist. E-Mail-Vorlagen, PDF-Exporte, Push-Nachrichten, Fehlerseiten, Text in Diagrammen, Dateinamen von Downloads. Das lebt meist außerhalb der Haupttabelle, und genau dort blamiert sich ein Start.
Was sie nicht findet
Sie sagt nichts darüber, ob eine Übersetzung gut ist. Pseudolokalisierung ist eine technische Prüfung, keine sprachliche, und einen sauberen Durchlauf als Qualitätsbeleg zu nehmen ist ein Kategorienfehler.
Sie sieht von sich aus auch keine Verkettungen. Ein aus drei Bruchstücken zusammengesetzter Satz pseudolokalisiert sich tadellos und bleibt ins Japanische unübersetzbar. Die zu finden braucht eine Person, die die Zeichenkettentabelle liest: eine eigene Stunde, die man einplanen sollte.
Drei weitere Dinge bleiben ihr verborgen. Pluralregeln: eine Sprache mit sechs Formen bricht erst, wenn eine echte Übersetzung eintrifft. Sortierung und Kollation, die der Locale folgen und nicht der Zeichenkette. Und bidirektionales Layout: Eine Pseudo-Locale, die nur lateinische Buchstaben akzentuiert, sagt nichts darüber, ob Ihre Oberfläche das Spiegeln übersteht. Stehen Arabisch oder Hebräisch auf der Landkarte, fügen Sie eine zweite Pseudo-Locale mit umgekehrter Leserichtung hinzu und finden Sie es jetzt heraus.
Wann man sie laufen lässt
Zweimal. Einmal, sobald die Extraktion überhaupt funktioniert, wenn fest verdrahteter Text billig herauszulösen ist und noch niemand ein Layout um eine englische Wortlänge gebaut hat. Und noch einmal am Release Candidate, denn der zweite Durchlauf fängt alles ab, was in den Wochen hinzukam, in denen Lokalisierung niemandem im Kopf war.
Besser als zweimal ist fortlaufend. Eine Pseudo-Locale in der Build-Matrix und ein Screenshot-Abgleich der Hauptwege machen daraus statt eines Ereignisses eine Prüfung, und die Prüfung schlägt bei dem Pull Request fehl, der die fest verdrahtete Zeichenkette eingeführt hat, und nicht in der Woche vor dem Start.
Teams, die das übernehmen, haben keine Lokalisierungsphase mehr, sondern eine Lokalisierungsgewohnheit. Der Unterschied zeigt sich an Releases, die in jedem Markt am selben Tag erscheinen, statt zuerst auf Englisch und danach entschuldigend.