Für die Produktion der iOS App menu war es uns wichtig, bereits zum Launch neben der englischen Sprachversion auch Deutsch & Französisch zu integrieren. Die Möglichkeiten mit Xcode mehrere Sprachen zu verwalten sind, aus heutigen Usability Gesichtspunkten, so ziemlich gleich Null.
Von: Stephan Schoenen
Einfach, schnell, skalierbar — vor allem kostenlos
Der Kommentar im asana Issue unseres Lead Developers auf meine Frage wie wir am besten vorgehen sollen sah ungefähr so aus:
You know how it works. The ideal process that Xcode and Apple offer at the moment is localization files. So, I need a file for each language the app should be localized. The file structure should look like this:
“Start” = “Start”;
“Nearby” = “In der Nähe”;
Bei über 250 Strings, drei Sprachen zum Launch und den geplanten weiteren Varianten, mehreren Übersetzern (nicht jeder spricht 6 Sprachen) sollte sich jedem Product Owner sofort die Frage stellen: Wie schaffe ich mir das schnellstens vom Hals? Oder: An wen delegiere ich das? Bzw.: Wie kann man den Prozess kollaborativ gestalten und weitestgehend automatisieren?
TL;DR?
Link zum Tool am Ende des Artikels.
Maybe there’s an app for that?
Natürlich führt der erste Weg zu einigen potentiellen Lösungen, wie man sich diese Fleißarbeit möglichst ohne viel Zutun und vor allem die nötige Kontrolle des Codes ersparen kann. Das unserer Meinung nach beste Tool, welches wir gefunden haben, war poeditor.com. Eine vernünftig gestaltete SaaS Lösung mit vielen Features. Zu den wichtigsten gehörten für uns:
- Kollaboration (für mehrere Übersetzer)
- viele Exportmöglichkeiten (.strings, xml, .xls, etc.)
- Anzeigen möglicher Längenüberschreitung von Strings
Letzteres ist wirklich ein sinnvolles Feature. Es zeigt die Überschreitung einer String-Übersetzung im Vergleich zur Ursprungssprache an. Man sieht also recht schnell, ob eine Übersetzung weit über der Zeichenlänge der Ursprungssprache liegt, was in einigen Situationen zu Darstellungsproblemen führen kann. So etwas schmeichelt dem UI-Designer, denn für alle möglichen Übersetzungen Platz einzuplanen ist trotz Bemühungen oft einfach nicht möglich und sieht meist auch nicht gut aus.
Also: Lösung gefunden. Account erstellt. Alle Strings importiert. Mit Übersetzung begonnen. Kleingedrucktes wieder nicht ordentlich gelesen. Denn: 1000 Strings sind in der kostenlosen Version von POEditor verfügbar — insgesamt. Das bedeutet, dass jeder String jeder Sprachvariante zählt. Geärgert.
Das muss doch auch anders gehen
Manchmal muss man sich im Leben zwingen auch mal mit vorhandenen Tools eine Lösung herbeizuführen. Auch wenn es gut klingt, aber es gibt nicht für alles eine App. Und das ist auch gut so.
Die Excel-Jünger unter uns hätten schon längst interveniert — und ja, sie haben in diesem Fall wahrscheinlich auch Recht. Viele Aufgaben des Datenmanagements lassen sich mit Excel abbilden. Nun versuche ich persönlich Excel und alles andere von Microsoft — bisher erfolgreich — zu vermeiden. Bei JUNGMUT benutzen wir seit seiner Veröffentlichung Google Apps. Warum also nicht damit versuchen, eine gleichwertige Lösung mit gleichem Feature-Set zu bauen. An den Punkt Kollaboration können wir bei Google Apps schon mal einen Haken machen. Aber was ist mit den Exportmöglichkeiten und der Anzeige der Längenüberschreitung?
Versuchsaufbau
- Neues Google Spreadsheet anlegen
- Erste Spalte für Master-Sprache einrichten und alle Strings einfügen
- Weitere Spalte pro Sprache einfügen
Schritt 1: String-Länge messen und in Relation setzen
Die Länge eines Strings bzw. eines Zelleninhalts in Google Spreadsheets zu messen ist wirklich einfach. Dazu haben wir für die Master-Sprache eine zusätzliche Spalte rechts neben die eigentlichen Strings gesetzt.
Die Zelle C3 im Screenshot enthält die Formel:
=len(B3)
Das war einfach. Den Ergebniswert brauchen wir jetzt zur Berechnung der prozentualen Überschreitung der Zeichenlänge.
Zelle E4 ff. enthält folgende Formel, die den vorherigen Ergebniswert verwendet.
=if($C3=”0”;””;if(D3=””;””;(len(D3)/$C3)-1))
(Pro Tip: Man kann =len(B3) natürlich noch in diese Formel integrieren, wenn man möchte.) So hat man jedoch die originale Zeichenlänge in Spalte C direkt präsent. Noch ein paar Klicks unter Format/Bedingte Formatierung, die den Wert rot färben sobald er den Wert 0,5 überschreitet und schon haben wir das gleiche sinnvolle Feature wie bei POeditor. Ein weiterer Vorteil: Die Formel und Einfärbungen sind je nach Projekt und Vorgaben individuell anpassbar.
Schritt 2: Übergabe an Development automatisieren
Wir haben insgesamt zwei Tabellenblätter angelegt. Das erste für die Übersetzungen und das zweite für die Generierung des Codes.
Für ein iOS Localization File funktioniert es wie folgt: Das zweite Tabellenblatt ist identisch zum ersten aufgebaut: Jede Sprache eine Spalte.
Die Zellen dieses Tabellenblatts ziehen sich die Werte der Übersetzungen über die Funktion arrayformula(). Zelle B1 enthält beispielsweise folgende Formel:
=arrayformula(CHAR(34)&Translations!$B3&CHAR(34)&” = “&CHAR(34)&Translations!D3&CHAR(34)&”;”)
CHAR(34) bringt die Anführungszeichen in die Zelle, die Xcode fordert. Dieser besteht aus Verweisen auf die jeweilige Übersetzung.
Für unsere iOS Entwickler reicht das Ergebnis völlig aus. Mit einem simplen Copy/Paste-Schritt über eine komplette Spalte, ist das Einfügen einer neuen Sprachvariante in menu vollständig erledigt.
Unser Spreadsheet
Das Google Spreadsheet inkl. aller Formeln und Formatierungen haben wir hier öffentlich zugänglich gemacht:
Einfach duplizieren und für eigene Projekte nutzen. Kostenlos ;-) Wir gehen davon aus, dass sich das Prinzip auch auf andere Entwicklungsumgebungen und Workflows anwenden lässt.