Internationalisierung der mobilen Apps: Wege und Methoden zur Steigerung der Einnahmen um 26%

Erläuterung der Begriffe auf “-ierung”

Für die Unternehmen, die bereits global agieren oder neue globale Märkte erst erschließen wollen, ist die Anwendungsentwicklung eng mit den drei “ierungs-Prozessen” verbunden:

• Globalisierung ist der ganze Zyklus der Planung und der Identifizierung von globalen Märkten für die kommende App ohne zwingende Anpassung. Laut der Assoziation für Lokalisierungsindustriestandards (Localization Industry Standards Association, LISA) umfasst die Globalisierung Internationalisierungs- und Lokalisierungsprozesse, die in der unten folgenden LISA-Tabelle dargestellt sind.

• Internationalisierung (alias i18n) bezieht sich in der Regel auf die Entwicklung und Gestaltung einer Produktanwendung, die an eine Vielzahl von Sprachen, Regionen und Kulturen angepasst werden kann. Nachdem die Anwendung internationalisiert worden ist, kann sie für die jeweilige Region oder Kultur lokalisiert werden. Die Internationalisierung bereitet eine Anwendung beim Design auf die nächste Phase, die Lokalisierung, vor.
• Lokalisierung (aka l10n) (alias l10n) ist der Prozess der Anpassung einer Anwendung an bestimmte sprachliche und kulturelle Besonderheiten. Die Lokalisierung beinhaltet die Übersetzung von Textelementen und Dokumenten der Benutzerschnittstelle sowie die Anpassung von nichttextlichen App-Komponenten, wie z. B. Datums- und Uhrzeitformaten, Adressen und Zeitangaben, Währungen, Symbolen, Grafiken usw.

Somit ist Globalisierung ein Prozess, der beide Phasen einbezieht. Durch Internationalisierung und Lokalisierung wird eine App an verschiedenen Orten wie ein Original aussehen.

Reasons to Globalize Applications

Obwohl die Implementierung von Internationalisierung und Lokalisierung ressourcenintensiv ist, zeigen die nachfolgenden Zahlen die konkreten Gründe für die Entwicklung einer weltweit einsetzbaren Anwendung. So belegt Distimo z. B. um 128% steigende Downloadzahlen und einen um 26% gewachsenen Umsatz nach der muttersprachlichen Anpassung von 200 iOS-Apps in 12 Ländern. Eine weitere Studie von AdColony von 2016 hat nachgewiesen, dass der lokalisierte kreative Inhalt höhere Installationsquoten auf verschiedenen Märkten bewirken kann.

Die Mehrheit der Benutzer von mobilen Anwendungen kommt nicht aus den englischsprachigen Ländern, wie die aktuelle Studie von StatCounter zeigt. Das Webanalyseunternehmen berichtet, dass die Mehrzahl der mobilen Nutzerin Indien, Indonesien, Südafrika, der Türkei und China wohnen. Der Verlass auf Englisch als die am meisten gesprochene Sprache kann also zum Hauptgrund für niedrige Zahlen bei bestimmten Zielgruppen werden.

Gleichzeitig zeigt, ine aktuelle Studie von Statista dass die APAC-Region (mit $38 Mrd.) vor Amerika (mit $14 Mrd.) und EMEA (mit $9 Mrd.) bei den tatsächlichen und prognostizierten Ausgaben für mobile Apps in den App-Stores führt. Diese Zahlen bestätigen, dass eine globalisierte Anwendung mehr Regionen mit potenziell kaufbereiten Kunden wird abdecken können, die sich eher den in ihren Muttersprachen verfügbaren Marken zuwenden werden.

Ein weiterer Grund für die Implementierung von i18n- und L10n-Prozessen ist der Erwerb der Präferenzen der Konsumenten und möglicherweise die emotionale Bindung an eine App, die ihre Muttersprache spricht. Laut einer Umfrage von Common Sense Advisory von 2014sind 75% der Verbraucher bereit, in ihrer Muttersprache zu bestellen. In einer groß angelegten Studie wird auch berichtet, dass fast 60% der 3.000 befragten Verbraucher aus 10 nichtenglischsprachigen Ländern kaum oder nie etwas von englischsprachigen Webseiten kaufen, während 70% der japanischen Käufer ihre Produkte ausschließlich auf ihren muttersprachlichen Webseten erwerben.

Unter Berücksichtigung aller Gründe und Zahlen scheint die Globalisierung der mobilen Apps eine vernünftige Investition zu sein, die zukünftig eine wachsende Anzahl der verkauften Anwendungen verspricht.

Internationalisierung und Lokalisierung in Aktion

Eine Anwendung kann bereits über eine integrierte Funktion der mehrsprachigen Unterstützung verfügen. Andernfalls müssen Sie diese im aktuellen Design hinzufügen. Um das Leben eines Lokalisierungsteams zu erleichtern, müssen Entwickler die folgenden wesentlichen Schritte durchlaufen:

• Bestimmung der Elemente, die übersetzt werden müssen (Textpassagen, Piktogramme, Dokumente);
• Übersetzungskontrolle der für die Benutzer sichtbaren Inhalte durch ein Lokalisierungsteam;
• Implementierung eines Lesemechanismus für die lokalisierten Elemente;
• Lazy Loading von schweren Elementen (spezifisch für mobile Anwendungen);
• Anpassung der Benutzeroberfläche einschließlich Unterstützung der linksläufigen Sprachen (Rechts-nach-links-Sprachen, RTL).

Einige der anderen spezifischen Funktionen wären die Bestimmung des aktuellen Landes des Geräts oder der mögliche Wechsel zu einer bestimmten Lokalisierung ohne einen Neustart der Anwendung.

Ermittlung der zu übersetzenden Elemente

Die Übersetzung von Titeln und Textpassagen reicht für die Lokalisierung nicht aus, da Piktogramme auch Textelemente enthalten können. Bevor ein separates Übersetzerteam mit der Übersetzung beginnen kann, müssen die Entwickler die grafischen Elemente von den textlichen im Rahmen des Internationalisierungsprozesses trennen. Solch eine Aufgabe kann sich als kompliziert erweisen, wenn der Text ein Teil der Bilder ist und die Bilder z. B. überdeckt. Die Lösung wäre, separate Bildersets in der jeweiligen Sprache bereitzustellen.

Im Idealfall sollten alle Dokumente übersetzt werden. Zu Beginn können Sie sich jedoch auf die Schlüsselelemente wie Kontaktinformationen, Hilfe, Nutzungsbedingungen und Datenschutzerklärung konzentrieren.

Die vom Server generierten Daten können in einer mobilen App ebenfalls angezeigt werden. Im Gegensatz zu kurzen Sätzen, die Sie sofort übersetzen können, müssen die vom Backend erzeugten langen Textnachrichten nur auf der Serverseite verarbeitet werden. In diesem Fall sollten Sie den Sprach-/Kulturcode auch an den Server übermitteln.

Vorbereitung auf die Übersetzung

Natürlich erwartet jeder Entwickler, dass er alle übersetzten Elemente in einem Paket erhält. Um eine effiziente Zusammenarbeit mit professionellen Übersetzern zu beginnen, sollte man allerdings ein strukturiertes Dokument zur Verfügung stellen, das alle notwendigen Textpassagen beinhaltet, die übersetzt werden müssen. Normalerweise sind es Tabellen mit den Hauptspalten “Schlüssel” – “Original” – “Übersetzung”.

Anhand des folgenden Beispiels können Sie aber auch eine Tabelle erstellen:

Quelle

Die Erstellung eines solchen Dokuments ist eine notwendige Maßnahme, da Übersetzer nur begrenzte technische Kompetenzen besitzen und höchstwahrscheinlich kein Skript für die Datenbank schreiben oder eine Quelldatei bearbeiten können.

Sie können auch Übersetzerprogramme testen, müssen dafür aber ein Skript schreiben und immer noch einen Fachmann zu Rate ziehen, der den Textteil verfeinern könnte. Für den Komfort des Übersetzers sollten die Entwickler auch alle Schlüssel mit den originalsprachlichen Textpassagen in eine Excel-Datei oder alternative Datenformate exportieren. Die Übersetzung wird dann aus derselben Datei zurück importiert.

Verarbeitungsmechanismus bei den lokalisierten Elementen

Die Verwendung von Quelldateien ist eine allgemein akzeptierte Möglichkeit, lokalisierte Passagen darzustellen. Nach diesem Prinzip bezieht sich eine Datei auf eine Kultur. Gleichzeitig wird jede Tabelle mit den Daten nach dem Muster “Schlüssel” – “Übersetzung” (einschließlich Ausgangssprache) folgendermaßen transformiert:

• Die Ressource, die mit einer Anwendung verknüpft ist (und während des Starts nicht in den Speicher geladen wurde), wird nach dem Muster “ID” – “Wert” verknüpft. Das Feld “Wert” enthält die übersetzten Elemente.
• Eine nach dem Muster “ID” – “Wert” automatisch generierte Klasse ist im folgenden Beispiel dargestellt:

Linked to public const int NotesLabel = 2130837620;

Dieses Beispiel zeigt, dass eine Ganzzahlkonstante einem Text des Help_Overlays_Menu entspricht, der als ein Ressourcen-Kennzeichen fungiert.

Die Adressierung der Ressource im Code wird die folgende Form haben:

myLabel.Text = AppResources.NotesLabel

Hier bezieht sich “AppResources” auf den Namen einer Ressourcendatei.

Die Lesbarkeit eines Textes ist für seine bequeme Verwendung und Umsetzung in einem Softwarecode essentiell. Parallel wird die Ressourcen-ID durch die Konstante bestimmt, was zusätzliche Berechnungen überflüssig macht.

Herausforderungen und Lösungen bei der Verwendung von Ressourcendateien

Die Verwendung von Ressourcendateien weist eine Reihe von unklaren Einschränkungen und Herausforderungen auf. Zunächst einmal können solche Dateien nicht zu einer Anwendung hinzugefügt werden, nachdem sie an Endbenutzer ausgeliefert worden ist. Es wird auch unmöglich sein, neue Sprachpakete darauf zu spielen oder Ressourcen zu modifizieren, ohne eine Anwendung aktualisieren zu müssen.

Außerdem sind konstante Texte unbequem zu ändern. D. h.auch, dass es kompliziert sein wird, auf die Ressource mit einem Berechnungsschlüssel zuzugreifen.

Eine weitere Einschränkung entsteht in der Syntax der Texte, da Leerzeichen und andere nichtalphanumerische Symbole fehlen werden.

Wenn die Ressourcendateien nicht in der traditionellen Art verwendet werden können, ist es möglich, auf deren Basis andere Lösungen zu entwickeln. Z. B. wenn in einer Ressourcendatei nur wenige Textzeilen vorhanden sind (weniger als 100 KB), können sie, von einem Schriftleseprogramm begleitet, im Programmspeicher gespeichert werden (Implementierungsbeispiele sind online verfügbar). Wenn die Speicheroptimierung aber bei einer großen Anwendung die oberste Priorität darstellt, sollten Sie die Datei in der lokalen Datenbank abspeichern. Diese Lösung bietet den Vorteil der Flexibilität und Skalierbarkeit und verringert die Ladezeit der Anwendung.

Bei diesem Ansatz hat die Adressierung der lokalisierten Ressourcen im Code die folgende Form:

myLabel.Text = ResourceManager.Get(“NotesLabel”)

“ResourceManager” ist hier die Klasse, die implementiert werden muss.

Lazy Loading

Im Vergleich zu Desktop- und Webanwendungen haben mobile Anwendungen ein spezifisches Datenmanagement. Allerdings gibt es ein paar erprobte und getestete Möglichkeiten, die Funktionsweise einer lokalisierten Anwendung zu verbessern.

Ein modernes mobiles Gerät verfügt über genügend Speicherplatz und einen leistungsfähigen Prozessor, um als vollwertiger Computer funktionieren zu können. Dennoch sollte ein Entwickler einige Besonderheiten im Lokalisierungsprozess berücksichtigen.

Eine davon ist die Größe eines Anwendungsinstallationspakets, die entscheidend ist, wenn ein Gerät in den entsprechend langsamen 3G- oder WLAN-Netzwerken betrieben wird. Die Größe einer Standard-App kann zwischen 1 MB und 20 MB liegen. Anwendungen mit einer Größe von über 100 MB werden als riesig eingestuft und können von einigen App-Stores abgelehnt werden. Außerdem kann die fehlende Netzwerkverbindung das Funktionieren einer übergroßen Anwendung sogar verhindern.

In diesem Fall ist die beste Lösung das verzögerte Laden (Lazy Loading) der erforderlichen Dokumente, Bilder und anderer Ressourcen nach der Installation. Zum Beispiel kann die Lokalisierung eines Programms für 10 Sprachen durchgeführt werden, indem ein Multiplikatoreneffekt genutzt wird. Dabei wird die Bildüberlagerung mit speziellen Beschriftungen zum Lokalisieren der Elemente einer Anwendung zusammengeführt. Die Gesamtgröße der Bilder erhöht sich nach der Zusammenführung von 5 MB auf 50 MB. Dies ist ein Hinweis darauf, dass die Anwendungsarchitektur durch Lazy Loading verbessert werden sollte.

Eine Anwendung sollte jedoch immer mindestens eine Basislokalisierung (normalerweise Eng-US) unterstützen, um eine Homepage vollständig anzuzeigen, falls das Lazy Loading aus bestimmten Gründen nicht möglich ist.

Auf dem unten stehenden Diagramm können Sie sich ein Prozessmodell der Implementierung von Lazy Loading anschauen.

Ursprünglich enthält eine Anwendung nicht alle lokalisierten Ressourcen, sondern lädt sie bei Bedarf unmittelbar nach einer App-Installation oder deren Updates vom externen Server (Anwendungsserver) in das lokale Repository eines mobilen Geräts (lokale Datenbank) herunter. Anschließend werden die lokalisierten Pakete in die für die App praktikable Ansicht umgewandelt. Danach muss eine Anwendung keine Verbindung zum externen Server mehr herstellen, weil die lokalisierten Daten aus dem lokalen Repository extrahiert werden.

UI Adaptation

Im Laufe der Geschichte der menschlichen Zivilisation erfand die Menschheit eine Vielzahl an unübertroffenen Schreibsystemen. Die Komplexität der Knotenschrift der südamerikanischen Ureinwohner (Quipu) und der japanischen Schriftzeichen (Kanji) beschäftigt uns immer noch.

Heute unterscheiden wir zwischen zwei Schreibsystemen, dem linksbündigen (LTR) und dem linksbündigen (RTL). Überraschenderweise hat die Art, wie Menschen schreiben, einzigartige kulturelle Unterschiede verursacht. Dieses scheinbar kleine Detail bestimmt außergewöhnliche Unterscheidungsmerkmale der Muttersprachler, die sogar ihre Denkweise beeinflussen.

Daher sollte ein Entwickler die entscheidenden Unterschiede zwischen den LTR- und RTL-Kulturen berücksichtigen, um die App-Internationalisierung umzusetzen. Zum Beispiel sollten solche Seitenverwaltungselemente wie Symbol, Eingabefeld und Schaltfläche bei den RTL-Sprachen in der umgekehrten Reihenfolge, also “Schaltfläche – Eingabefeld – Symbol”, angeordnet werden. Gleichzeitig sollte die Bildlaufleiste links und das Hamburger-Menü rechts liegen. Die folgenden Bilder zeigen, wie die Benutzeroberfläche für die kontrastierenden LTR- und RTL-Kulturen angepasst werden kann:

Quelle

Es gibt Tools und Technologien, die automatische Unterstützung der RTL-Sprachen anbieten. Das komplette Frontend der Seite sollte man jedoch neu festsetzen, um eine automatische Transformation beim Wechsel zu einer RTL-Kultur zu gewährleisten.
Beim Fehlschlagen einer automatischen Funktion wird empfohlen, einen UI-Lader zu schreiben, mit dessen Hilfe man die Ausrichtung ändern kann, sodass das Bild gedreht wird und der Pfeil von links nach rechts geht.

Außer der Anpassung der Benutzeroberfläche an die RTL-Kultur hängt die Ausrichtung einer Webseite auch von der Länge der übersetzten Sätze ab. Da jede Sprache ihr eigenes einzigartiges System für die Bildung sinnvoller Sätze hat und u.a. aus Wörtern besteht, die nicht direkt übersetzt werden können, wird die adaptive Ausrichtungsfunktion zu einem notwendigen Werkzeug, um die gewünschten Änderungen anzeigen zu lassen.

Fazit

Internationalisierung und Lokalisierung sind komplexe Prozesse, die viel Arbeit, Zeit, Aufwand und Investitionen erfordern. Ein professionelles Projektteam kann jedoch eine mobile Anwendung erfolgreich lokalisieren und die hohe Qualität lokalisierter Lösungen sicherstellen, wenn es eine durchdachte Globalisierungsstrategie verfolgt.