WordPace in 28 Sprachen: die App-Store-Seite der Lokalisierung

Im Beitrag vom August war die Oberfläche von WordPace in elf Sprachen lokalisiert, während der Spracherkenner bereits 45 Vortrags-Locales beherrschte. Mit Version 1.3 ist diese Lücke geschlossen: 28 Oberflächensprachen und 27 App-Store-Listings. Die Übersetzung der 139 Oberflächentexte mit einem Sprachmodell war dabei der kleinste Teil der Arbeit, und es ist der Teil, den die meisten meinen, wenn sie sagen, eine App sei lokalisiert. Den größeren Teil macht aus, was der App Store pro Sprache erwartet: ein Listing aus sechs Textfeldern mit eigenen Zeichenlimits, Keywords, die in diesem Markt funktionieren, ein Screenshot-Satz in der richtigen Pixelgröße und ein Upload, der sich prüfen lässt, bevor er eine Produktseite verändert. Das einmal für zwei Sprachen von Hand zu machen, ist ein Nachmittag. Für 27 Sprachen, und bei jedem Update erneut, braucht es einen Prozess. Dieser Beitrag beschreibt, was dieser Prozess abdecken muss, und die Entscheidungen, die vorher nicht offensichtlich waren.

Woher die Sprachliste kommt

Den Umfang habe ich nicht ausgesucht. WordPace fragt das Betriebssystem, welche Locales der On-Device-Erkenner unterstützt, unter macOS 27 sind das 45, und jede davon muss von einer Oberflächensprache und einem App-Store-Listing bedient werden. Beides passt weniger gut zusammen, als man hoffen würde. Regionale Varianten fallen zusammen: österreichisches, schweizerisches und deutsches Deutsch teilen sich eine Oberfläche und ein Listing, irisches, indisches und südafrikanisches Englisch laufen auf das britische Listing, entsprechend der Sprache, die Apple im jeweiligen Storefront anzeigt. Vier erkannte Sprachen haben gar keine App-Store-Lokalisierung: Kaschmiri, Maithili, Nepali und Kantonesisch bekommen eine übersetzte Oberfläche, ihre Store-Seite fällt aber auf die Standardsprache des Storefronts zurück. App Store Connect kennt genau einen Code für Urdu und einen für Bangla, beide im indischen Storefront verfügbar, also werden die indischen Erkenner-Locales dorthin gemappt. Chinesisch braucht ein explizit benanntes Schriftsystem, weil das Framework einen nackten Kantonesisch-Code zu vereinfachtem Chinesisch auflöst. Und ein Eintrag des Erkenners ist gar keine Sprache, sondern ein Code-Switching-Modell für indisches Englisch und Hindi, das weder Übersetzung noch Listing bekommt.

Nichts davon ist schwierig, sobald man es weiß, aber es hat einige Umwege gebraucht, es herauszufinden, und es geht leicht wieder kaputt. Die Zuordnung liegt deshalb in einer einzigen Tabelle mit einer Notiz zu jeder Ausnahme, und alles Weitere wird daraus erzeugt: die Sprachliste des String Catalog, die Known Regions des Projekts, der Ordner je Listing, die Tabelle, die die Screenshot-Tests verwenden. Selbst die Locale-Codes sind aus Apples veröffentlichter Tabelle kopiert und nicht aus dem Gedächtnis getippt, und ein Check schlägt fehl, wenn die Kopie von der Locale-Liste abweicht, die fastlane mitbringt. Beide Seiten können falsch sein; die Abweichung ist das Signal, bei Apple nachzusehen.

Übersetzen gegen ein Briefing

Die Oberfläche übersetzt ein Sprachmodell, headless aufgerufen und mit einem Schema für die Antwort, und für 26 Sprachen würde ich es nicht anders machen wollen. Verlässlich wurde das nicht durch das Modell, sondern durch zwei Dinge drumherum. Erstens sind die Anweisungen ein schriftliches Briefing, kein spontan getippter Prompt, und jede Regel darin geht auf etwas zurück, das in einer der ersten Sprachen schiefging. Format-Spezifizierer müssen exakt erhalten bleiben; ändert eine Sprache die Wortstellung, muss sie auf positionale wechseln. Jede Sprache legt einmal fest, wie sie Wörter pro Minute abkürzt (WPM im Deutschen, PPM im Spanischen und Italienischen, MPM im Französischen, 語/分 im Japanischen, 단어/분 im Koreanischen), und jeder andere Text muss diese Einheit verwenden. Ziffern bleiben westlich, weil die App ihre Zahlen so zeichnet. Standard-Menüeinträge und der Pfad zur Mikrofonberechtigung müssen exakt so lauten, wie macOS und iOS sie in dieser Sprache anzeigen. Pluralformen folgen den Unicode-Kategorien: Arabisch braucht sechs, Russisch vier, Japanisch und Koreanisch eine. Zweitens wird die Antwort strukturell geprüft, bevor sie übernommen wird: Spezifizierer gegen die Quelle, die Einheit gegen die der Sprache, die Begriffe eines kleinen Glossars gegen die Texte, die sie festlegen, die Pluralkategorien gegen die Sprache.

Die Anweisung im Briefing, die ich für die nützlichste halte, ist die letzte: Kann das Modell eine Sprache nicht auf muttersprachlichem Niveau schreiben, soll es das sagen und nicht raten. Eine markierte Schwachstelle ist Information, ein selbstbewusst falscher Satz nicht. Für menschliche Übersetzer lässt sich derselbe Auftrag als Datei schreiben und über dieselben Prüfungen wieder zusammenführen.

Ein Listing wird für einen Markt geschrieben

App Store Connect erwartet pro Sprache sechs Textfelder: Name und Untertitel mit je 30 Zeichen, Keywords mit 100, Werbetext mit 170, Beschreibung und Versionshinweise mit je 4000. Das englische Listing ist die Faktenbasis, und ein zweites Briefing legt fest, was behauptet werden darf und was nicht. Bei den Keywords wäre Übersetzen das falsche Werkzeug. Das Briefing fragt, was jemand in diesem Markt vor einer Verteidigung der Abschlussarbeit oder einer Hochzeitsrede in die App-Store-Suche tippt, in der eigenen Schrift und in den lateinischen oder englischen Formen, die dort üblich sind. Die Hindi-Keywords mischen Devanagari und Englisch, die japanischen enthalten 卒論 (Abschlussarbeit) und 就活 (Jobsuche), Begriffe, die in keiner englischen Liste stünden. Zwei Regeln ergeben sich aus der Indexierung des Stores: kein Leerzeichen nach dem Komma und kein Wort, das bereits im Namen oder Untertitel vorkommt, denn diese Felder werden ohnehin indexiert und eine Wiederholung verbraucht nur Budget. Längen werden in UTF-16-Code-Units gezählt, der konservativsten der plausiblen Zählweisen von Apple. Ein Markt hat die Regel gebrochen, dass der Name immer der unübersetzte Produktname ist: In Japan war der nackte Name in App Store Connect bereits vergeben, und das japanische Listing trägt einen Zusatz.

189 Screenshots

Jedes Listing bekommt fünf iPhone-Motive und zwei Mac-Motive, insgesamt 189 Bilder. Die iPhone-Ansichten nimmt ein UI-Test auf einem Simulator in der Sprache des Listings auf, die Mac-Ansichten ein Aufnahmemodus der App selbst, da fastlanes Screenshot-Werkzeug für macOS keinen funktionierenden Pfad hat. Aufgenommen wird die echte Oberfläche in einem präparierten Zustand: Der Simulator bringt keine Sprachmodelle mit, ein Debug-Seed versetzt die App darum in eine repräsentative Sitzung mit festen Werten. Das Artwork um die Ansichten rendert ein Skript, das die Headlines je Listing setzt, und diese Headlines schreibt ein drittes Briefing. Die Vorgaben dort sind visuell: zwei Zeilen mit höchstens 14 Zeichen für den Titel, weil der Renderer zu langen Text verkleinert und eine verkleinerte Headline schwach wirkt, und das Register der Werbesprache dieses Marktes, weshalb die deutschen und italienischen Screenshots du und tu sagen, obwohl die App selbst siezt.

Für nichtlateinische Schriften brauchte der Renderer zwei Anpassungen. Die Kampagnenschrift ist eine Monospace und deckt nur Latein ab; in jeder anderen Schrift ersetzt das System Glyphe für Glyphe, und die monospaced Leerzeichen zwischen den ersetzten Glyphen wirken wie Lücken. Diese Headlines werden in der Systemschrift gesetzt, Urdu in Nastaliq, wie es seine Leser erwarten. Ein Listing mit Rechts-nach-links-Schrift behält das Layout mit dem Screen rechts, sein Text richtet sich aber am rechten Rand seiner Spalte aus, und dieser Rand muss vom Screen frei bleiben. Vor jedem Upload wird jede Datei auf exakte Pixelmaße, 8-Bit-RGB, eine sRGB-Kennzeichnung und das Fehlen eines Alphakanals geprüft. Die Aufnahmen kommen mit einem vollständig deckenden Alphakanal, den App Store Connect trotzdem ablehnt.

Upload mit Diff

Der Upload läuft über fastlane, mit zwei Änderungen gegenüber dem, was es von Haus aus tut. Ein Trockenlauf liest die editierbare Version aus App Store Connect und gibt pro Listing und Feld aus, was ein Push ändern würde, ohne etwas zu senden. Der Push zeigt dasselbe Diff, fragt nach und lädt dann Listings und Screenshots hoch. Keiner der beiden Schritte reicht zur Prüfung ein, lädt eine Binary hoch oder legt eine Version an, und ein Push läuft nur, wenn die Version in einem Zustand ist, der sich bearbeiten lässt, ohne etwas aus dem Review zu ziehen. Die Screenshots sind der Teil, der danach Aufmerksamkeit braucht: Ein hochgeladenes Asset kann beliebig lange in der Verarbeitung hängen. Eine Status-Lane liest deshalb den Zustand jedes Assets auf beiden Plattformen, und eine Reparatur-Lane ersetzt die hängenden aus den lokalen Originalen und wartet, bis der Ersatz fertig verarbeitet ist, bevor sie das alte Asset löscht.

Was eine neue Sprache jetzt kostet

Lernt der Erkenner mit einem OS-Update eine neue Locale, führt sie ein einziger Befehl durch: Er bestätigt über die API, dass die Locale wirklich erkannt wird, mappt sie, übersetzt die Oberfläche, schreibt Listing und Headlines, erzeugt die abgeleiteten Dateien neu und lässt jeden Check laufen. Zwei weitere Befehle rendern die Screenshots und zeigen das Diff gegen App Store Connect. Die Checks tragen den Prozess, 77 Tests decken das Tooling selbst ab, und die Ausgabe ist kurz, wenn alles stimmt:

OK: 45 recognition locales, 28 interface languages, 27 App Store listings, 139 strings.
OK: metadata for 27 listings.

Was die Checks nicht können, ist lesen. Für die Sprachen, die ich nicht spreche, sind die strukturellen Prüfungen die einzige Durchsicht, die der Text bekommt: Spezifizierer, Einheiten, Glossarbegriffe, Längen, Pluralformen. Ein falscher, aber wohlgeformter Satz geht durch. Genau für diesen Schritt hätte ich gern muttersprachliche Prüfer, und dafür gibt es den Exportpfad für menschliche Übersetzer.