Sieben Sprachen: Warum Lokalisierung eine Zuverlaessigkeitsfunktion ist

Tactic Remote wird jetzt mit vollstaendiger Unterstuetzung fuer sieben Sprachen ausgeliefert: Englisch, Chinesisch (vereinfacht), Japanisch, Koreanisch, Spanisch, Deutsch und Franzoesisch. Dies ist keine Ankuendigung nach dem Motto "wir haben die Strings durch eine Uebersetzungs-API gejagt". Lokalisierung in einem Entwicklertool, das Netzwerkkonfiguration, Terminalausgabe und Operationen auf Systemebene behandelt, erfordert einen anderen Standard als die Uebersetzung von Consumer-Apps.

Dieser Artikel behandelt unseren technischen Ansatz, die Bugs die uns gelehrt haben Lokalisierung als Zuverlaessigkeits-Engineering zu behandeln, und was wir bei der internationalen Akzeptanz beobachten.

Die sieben Sprachen

Unsere Sprachauswahl wurde durch Nutzerdaten und Anfragevolumen waehrend der privaten Beta bestimmt:

Wir haben Sprachen priorisiert, bei denen wir sowohl Nutzernachfrage als auch Zugang zu Muttersprachlern unter den Entwicklern hatten, die technische Genauigkeit validieren konnten. Lokalisierung von Entwicklertools erfordert Domainexpertise — "session", "tunnel" oder "hook" ins Japanische zu uebersetzen erfordert das Verstaendnis der technischen Bedeutung des Begriffs, nicht nur seiner Woerterbuchdefinition.

Ueber String-Uebersetzung hinaus

Der Standardansatz fuer iOS-Lokalisierung ist unkompliziert: Benutzersichtbare Strings in .strings- oder .xcstrings-Dateien extrahieren, Uebersetzungen bereitstellen und das System die Anzeige uebernehmen lassen. Das machen wir auch, aber das interessante Engineering liegt in den Schichten unterhalb der String-Ersetzung.

Locale-bewusste Eingabeverarbeitung

Der Bug, der unsere Lokalisierungsphilosophie veraenderte: Benutzer mit deutschem Locale konnten waehrend des Setups keine IP-Adressen eingeben.

Die iOS-Tastatur im deutschen Locale verwendet standardmaessig ein Komma als Dezimaltrennzeichen. Wenn ein Benutzer mit deutschem Locale den "."-Tastenbereich auf der numerischen Tastatur tippt, erhaelt er ein Komma. Eine IPv4-Adresse wie 192.168.1.100 wurde als 192,168,1,100 eingegeben — was unsere Validierung als fehlerhaft ablehnte.

Das ist kein Uebersetzungsbug. Es ist ein Locale-Verhaltensbug. Die UI-Strings waren korrekt uebersetzt, aber der Eingabemechanismus war durch eine Tastaturlayout-Annahme defekt. Wir haben dies behoben, indem wir in IP-Adress-Eingabefeldern Komma zu Punkt normalisieren und eine benutzerdefinierte Tastaturkonfiguration praesentieren, die fuer Netzwerkadressen-Eingaben immer eine Punkt-Taste anzeigt.

Dieser einzelne Bug verursachte geschaetzte 23% der Setup-Fehler bei Benutzern mit deutschem Locale vor dem Fix. Nach dem Deployment entsprach die Erststart-Abschlussrate bei deutschem Locale innerhalb eines Release-Zyklus der englischen Baseline.

Pluralisierung und grammatische Uebereinstimmung

String-Interpolation mit Zahlen ist eine klassische Lokalisierungsfalle. Englisch handhabt es einfach: "1 session" vs. "2 sessions." Andere Sprachen haben komplexere Pluralregeln:

• Japanisch und Koreanisch haben keinen grammatischen Plural — die gleiche Form wird unabhaengig von der Anzahl verwendet.
• Franzoesisch pluralisiert die meisten Substantive ab 2, aber einige Ausdruecke verhalten sich anders.
• Deutsche Zusammensetzungen koennen ihre Form basierend auf grammatischem Kasus und Mehrzahl aendern.

Wir verwenden das stringsdict-Pluralregelsystem von iOS, das die CLDR-Pluralkategorien (zero, one, two, few, many, other) unterstuetzt. Jeder benutzersichtbare String, der eine Zahl enthaelt, durchlaeuft pluralbewusste Formatierung statt naiver String-Verkettung.

Vorbereitung fuer Rechts-nach-Links

Keine unserer aktuellen sieben Sprachen erfordert RTL-Layout, aber unsere UI-Architektur beruecksichtigt es. Alle Layout-Constraints verwenden Leading/Trailing-Anker statt Left/Right. Die Textausrichtung ist auf .natural gesetzt. Das bedeutet, dass wenn wir Arabisch oder Hebraeisch hinzufuegen — beides Sprachen mit aktiven Entwickler-Communities — der Layout-Aufwand minimal sein wird.

MDX-Inhaltslokalisierung

Die TacticRemote-Website und Dokumentation sind mit MDX gebaut. Die Lokalisierung von Dokumentationsinhalten erforderte eine andere Strategie als die Lokalisierung von App-Strings.

Jedes MDX-Dokument kann Locale-spezifische Varianten mit einer Dateinamen-Suffix-Konvention haben: product-update.mdx (englischer Standard), product-update.zh-CN.mdx (Chinesisch), product-update.ja.mdx (Japanisch) und so weiter. Der Content-Router erkennt die bevorzugte Sprache des Benutzers und liefert die passende Variante, mit Fallback auf Englisch wenn keine lokalisierte Version existiert.

Dieser Ansatz hat einen bewussten Kompromiss: Wir uebersetzen nicht jede Dokumentationsseite in jede Sprache. Technische Setup-Anleitungen und API-Referenzen bleiben auf Englisch, weil sie Code-Beispiele, Kommandozeilen-Anweisungen und Konfigurationswerte enthalten, die sprachunabhaengig sind. Wir fokussieren den Lokalisierungsaufwand auf Inhalte, bei denen Sprachbarrieren tatsaechlich das Verstaendnis blockieren: Produktankuendigungen, konzeptuelle Uebersichten und Onboarding-Flows.

Derzeit haben 34% unserer MDX-Inhalte mindestens eine nicht-englische Variante. Wir priorisieren basierend auf Seitenverkehr und Korrelation mit Support-Tickets — wenn eine Seite ueberproportional viele Supportfragen aus einer bestimmten Sprachgruppe generiert, wird diese Seite als naechstes lokalisiert.

Das Zuverlaessigkeits-Argument

Wir behandeln Lokalisierung als Zuverlaessigkeitsfunktion aus einem bestimmten Grund: Ein Entwickler, der das Setup aufgrund eines locale-bedingten Eingabefehlers nicht abschliessen kann, befindet sich im gleichen Zustand wie ein Entwickler, der sich aufgrund eines Netzwerkfehlers nicht verbinden kann. Das Produkt ist fuer ihn defekt. Ob die Ursache "wir haben ein englisches Tastaturlayout angenommen" oder "wir haben einen TCP-Bug" ist, aendert nichts an der Nutzererfahrung.

Diese Sichtweise hat praktische Konsequenzen fuer unseren Engineering-Prozess:

Locale-spezifische Testmatrix. Unser CI fuehrt Critical-Path-Tests (Setup-Flow, Verbindungsaufbau, Genehmigungsflow) unter sechs nicht-englischen Locale-Konfigurationen durch. Eine Regression bei der IP-Eingabe im deutschen Locale wuerde vor dem Merge erkannt.

Lokalisierungsbugs erhalten Severity-1-Triage, wenn sie Kernfunktionalitaet blockieren. Ein falsch uebersetztes Label ist kosmetisch. Ein locale-abhaengiger Eingabefehler ist ein Produktionsvorfall.

String-Freeze vor dem Release. Wir frieren englische Strings 72 Stunden vor jedem Release ein, um Uebersetzern ein stabiles Ziel zu geben. Uebersetzungen werden von muttersprachlichen Entwicklern im Team validiert, nicht nur von Linguisten.

Internationale Akzeptanz

Seit dem Launch der Mehrsprachigkeitsunterstuetzung sehen wir messbare Veraenderungen in unserer Nutzerbasis:

• Nicht-englische Locale-Nutzer wuchsen in sechs Wochen von 18% auf 41% der woechentlich aktiven Nutzer.
• Chinesisch (vereinfacht)-Nutzer sind jetzt die zweitgroesste Sprachgruppe und repraesentieren 15% der woechentlich Aktiven.
• Japanische Nutzer haben die hoechste durchschnittliche Sitzungsdauer aller Sprachgruppen — 52 Minuten gegenueber 47 Minuten insgesamt.
• Die Setup-Abschlussrate liegt ueber alle Locales hinweg jetzt innerhalb von 2 Prozentpunkten der englischen Baseline. Vor der Lokalisierungsarbeit hatten einige Locales Abschlussraten die 15-20% unter dem Englischen lagen.

Die Konvergenz der Setup-Abschlussrate ist die Metrik, die uns am meisten interessiert. Sie validiert, dass Lokalisierung Zuverlaessigkeitsluecken schliesst und nicht nur uebersetzte Labels hinzufuegt.

Naechste Schritte

Wir erweitern die Sprachunterstuetzung basierend auf denselben Kriterien: Nutzernachfrage plus Zugang zu muttersprachlichen technischen Reviewern.

• Weitere Sprachen werden basierend auf Nutzernachfrage und Verfuegbarkeit muttersprachlicher technischer Reviewer evaluiert.
• Wir bauen einen Community-Beitrags-Workflow fuer Uebersetzungen auf, mit einem Review-Prozess der technische Genauigkeit vor dem Merge sicherstellt.

Details dazu, wie Spracherkennung und Fallback funktionieren, finden Sie unter Lokalisierungsarchitektur. Wenn Sie Uebersetzungen fuer eine nicht unterstuetzte Sprache beitragen moechten, wenden Sie sich ueber die Support-Seite an uns.