Lokalisierung, wie sie sein sollte (oder zumindest fast)

Lokalisierung gehört zu den Dingen, die zunächst wie ein Konfigurationsschalter in der IDE aussehen, sich dann aber als sechsmonatige Diskussion mit Fremden über das Geschlecht von Substantiven entpuppen.

Für ein kleines Studio ist dies zudem eine der besten Investitionen, die wir tätigen können. Ein Tipptrainer, ein Gartenplaner oder ein Migräne-Tracker ist in Lissabon genauso nützlich wie in London, und die Nutzer vertrauen einer App viel eher, wenn sie in ihrer eigenen Sprache mit ihnen kommuniziert. Der Haken daran ist, dass es viel mehr Arbeit ist, dies richtig umzusetzen, als es zunächst den Anschein hat.

Unser Aufbau

Wir veröffentlichen zunächst die englische Version und fügen im Laufe der Lebensdauer einer App weitere Sprachen hinzu. Jede Übersetzung wird im Kontext anhand von Screenshots der tatsächlichen Benutzeroberfläche überprüft, und wir korrigieren alle Ungereimtheiten, bevor die App veröffentlicht wird.

Der Schritt der kontextbezogenen Überprüfung ist derjenige, den die meisten Teams überspringen, und genau hier treten die meisten Probleme auf. Eine Übersetzung kann in einer Tabellenkalkulation vollkommen korrekt sein und auf dem Bildschirm dennoch falsch wirken: eine Schaltflächenbeschriftung, die zwar korrekt ist, aber doppelt so lang wie der dafür vorgesehene Platz, oder ein Wort, das im Allgemeinen die richtige Bedeutung hat, neben einem bestimmten Symbol jedoch falsch wirkt. Deshalb erstellen wir Screenshots von jedem Bildschirm in jeder Sprache und sehen sie uns nacheinander an.

Außerdem verfassen wir die englischen Texte mit Blick auf die Übersetzung. Kurze Sätze, keine Redewendungen, keine Witze, die auf Wortspielen beruhen. Bei Textstellen, die einen Kontext erfordern – ist “Clear” hier ein Verb oder ein Adjektiv? –, fügen wir einen Hinweis für den Übersetzer hinzu. Dadurch wird der englische Text zwar etwas schlichter, aber wir sind der Meinung, dass er dadurch besser wird.

Die nicht offensichtlichen Teile

Datums- und Zahlenformate sind wichtiger als übersetzte Texte. Pluralformen sind sprachspezifisch, was Englischsprachige regelmäßig unterschätzen (in manchen Sprachen gibt es bis zu sechs). Layouts von rechts nach links sind kein einfacher CSS-Trick – sie beeinflussen, wie jedes Pfeilsymbol, jede Zurück-Schaltfläche und jeder Fortschrittsbalken dargestellt wird.

Ein paar weitere, auf die wir inzwischen achten gelernt haben:

• Texterweiterung. Deutsche und finnische Beschriftungen können deutlich länger sein als englische, daher muss das Layout genügend Platz bieten, damit der Text entweder erweitert oder elegant umgebrochen werden kann.
• Einheiten. Eine Angelvorhersage, in der die Windgeschwindigkeit in einer unbekannten Einheit angegeben ist, ist nicht nur seltsam, sondern auch nutzlos.
• Shop-Einträge. Die App ist nur die halbe Miete – Beschreibungen, Screenshots und Bildunterschriften müssen ebenfalls lokalisiert werden, und zwar separat für jeden Shop.
• Tastaturen. Bei einem Tipptrainer geht es bei der Lokalisierung nicht nur um Wörter, sondern auch um Tastaturlayouts, Zeichen und die Art und Weise, wie Menschen in dieser Sprache tatsächlich tippen.

Was wir falsch gemacht haben

Jeden dieser Fehler haben wir mindestens einmal gemacht. Der kostspieligste war, die Lokalisierung als letzten Schritt zu betrachten – wir haben die gesamte Benutzeroberfläche auf Englisch erstellt und dann festgestellt, dass die Hälfte der Bildschirme in Sprachen mit mehr Wörtern nicht mehr richtig angezeigt wurde. Die Layouts nachträglich zu korrigieren bedeutete, Bildschirme neu zu gestalten, die wir bereits als fertiggestellt betrachtet hatten.

Der Kompromiss, den wir nun eingehen, sind langsamere Erstveröffentlichungen: Eine neue Funktion gilt erst dann als fertig, wenn sie in jeder von der App unterstützten Sprache funktioniert. Unsere Checkliste beginnt nun mit der Behebung dieser Fehler, sodass sie seltener auftreten. „Meistens fast richtig“ ist die ehrliche Version des Titels.