Internationale Webanwendungen erfolgreich umsetzen – Technische Herausforderungen und Lösungen (Teil 2)

14.12.2015

paketshop_sucheAm Beispiel der DHL Paketshop-Suche, bei der doubleSlash als Entwicklungspartner der Deutsche Post DHL Group tätig war, beschreibt dieser Artikel, was bei der Planung und Umsetzung einer internationalen Java Webanwendung zu beachten ist. Im ersten Teil habe ich bereits die Faktoren Zeitplan und die Wichtigkeit der Internationalisierung beschrieben. In diesem Beitrag werden nun technische Lösungsansätze für verschiedene Aufgabenstellungen vorgestellt.

Wie im ersten Teil der Serie bereits beschrieben, bedeutet Internationalisierung, die Lokalisierung einer Anwendung für neue Länder so einfach und wenig aufwändig wie möglich zu gestalten [1]. Ein Aspekt wichtiger der Lokalisierung ist die Möglichkeit, die Anwendung in unterschiedlichen Sprachen anzeigen zu lassen.

Anzeige der unterschiedlichen Sprachen bei internationalen Webanwendungen

Um eine korrekte Anzeige der verschiedenen Sprachen mit ihren unterschiedlichen Zeichensätzen zu erreichen (z.B. auch Russisch oder Chinesisch), muss man dafür sorgen, dass alle von der Anwendung erzeugten HTML-Seiten in UTF-8 kodiert sind. Auch der Applikationsserver und die verwendete Datenbank müssen auf UTF-8 eingestellt werden. Das ist bereits während der Entwicklung von Bedeutung als auch bei der Produktivnahme durch den Betrieb. In beiden Prozessschritten muss die korrekte Zeichenkodierung auf den Produktivsystemen sichergestellt sein. Daher müssen entsprechende Konfigurationsschritte der Systemkomponenten im Installations- bzw. Betriebshandbuch vorgesehen werden.

postfinder_internationalisierung

Wie im ersten Teil bereits beschrieben, sollte die Anwendung am besten so entwickelt werden, dass sie initial bereits mindestens zwei unterschiedliche Sprachen unterstützt. Damit wird von vorne herein eine konsequente Umsetzung der Mehrsprachigkeit erzielt. Neben den vorgeschlagenen Sprachen deutsch und englisch empfiehlt es sich, noch eine weitere Sprache hinzu zu nehmen, deren Zeichensatz nicht mit der in Westeuropa üblichen ISO 8859-1 bzw. 8859-15 Codierung abgebildet werden kann – beispielsweise Russisch. So erkennt man frühzeitig Probleme mit der Zeichenkodierung und erreicht eine konsequente Umsetzung von UTF-8 über alle Anwendungsschichten hinweg.

Anzeige unterschiedlicher Sprachen durch Template-Mechanismen und Formatter

Damit die Texte und Beschriftungen in der Anwendung in unterschiedlichen Sprachen angezeigt werden, muss die Anwendung bzw. das von ihr verwendete Framework einen Template-Mechanismus verwenden, der dafür sorgt, dass Platzhalter im HTML-Code durch die Texte der anzuzeigenden Sprache ersetzt werden. Zudem empfiehlt es sich, Formatter vorzusehen, welche die anzuzeigenden Zahlen (mit Tausender- und Dezimaltrennzeichen), Datumswerte oder Uhrzeiten zur Anzeige in das jeweils länderspezifische Format bringen.

Datenbank als zentraler Informationsspeicher für die Internationalisierung von internationalen Webanwendungen

Die übersetzten Texte legt man am besten in einer Datenbank ab. Zum einen, weil die Java-eigenen, für Lokalisierung vorgesehenen ResourceBundles auf dem Zeichensatz ISO-8859 basieren und von Haus aus kein UTF-8 unterstützen. Bedeutender ist aber, dass es dadurch möglich wird, Übersetzungen im laufenden Betrieb zu korrigieren oder neue hinzuzufügen, ohne dass ein Deployment mit neuen bzw. geänderten Ressource-Files nötig ist. Aus Performancegründen sollte man die Anwendungstexte allerdings im Arbeitsspeicher cachen, anstatt bei jeder Benutzeranfrage einen Datenbankzugriff auf die Übersetzungs-Tabelle zu machen.

Auch Informationen über die unterstützten Länder und Sprachen legt man am besten in der Datenbank ab. Dort kann z.B. gespeichert werden, welches Datums- und Uhrzeitformat oder welche Währung für jedes der unterstützten Länder angezeigt werden soll. Über ein „active“-Flag in den Tabellen mit den Länder- und Sprachinformationen kann man erreichen, dass die in der Anwendung auswählbaren Länder und Sprachen zur Laufzeit dynamisch hinzu oder weggeschaltet werden können.

Unterstützung von rechts-nach-links-Schriften

In einigen Ländern werden Schriften verwendet, die von rechts nach links geschrieben werden, wie beispielsweise hebräisch oder arabisch (eine umfangreiche Liste findet sich unter [2]).

dhl_postfinder_spiegelschrift

Die englische Bezeichnung für solche Schriften ist „right-to-left“, abgekürzt „RTL“. Soll die Anwendung RTL-Schriften unterstützen, muss man dies bei der Aufwandsschätzung und im Webdesign berücksichtigen. Da die Schreibrichtung auch die Blickführung des Lesers insgesamt beeinflusst, muss für RTL-Schriften ein gespiegeltes Layout erstellt werden. Auch hier gibt es wieder einige Besonderheiten zu berücksichtigen. Die Grundrichtung der Schrift wird mit dem „dir“-Attribut im HTML-Tag angegeben (<html dir=“rtl“>). In RTL-Sprachen kommt es allerdings oft vor, dass Text aus einer links-nach-rechts geschriebenen Schrift eingebettet wird – wie „MYDHL Express“ in der obigen Abbildung der hebräischen DHL-Webseite. Der so entstehende Bidirektionale Text (abgekürzt „Bidi“) muss im Markup der Anwendung korrekt behandelt werden, indem alle Abschnitte mit von der Grundrichtung abweichenden Schriftrichtungen mit entsprechendem Markup umschlossen werden (dir=“ltr“). Da die Textausrichtung ein wesentlicher Bestandteil der Dokumentstruktur ist, sollte die Schriftrichtung immer mittels Markup, und nicht durch CSS vorgegeben werden [3]. Auch in Formularen und Eingabefeldern stellt die rechts-nach-links-Schrift eine besondere Herausforderung dar. Insgesamt ist das Webdesign für RTL-Schriften ein Thema für sich, das an dieser Stelle nicht umfassend behandelt werden kann. Details dazu sind unter anderem in [2] und [3] nachzulesen.

Ermitteln des Anwender-Landes bei internationalen Webanwendungen

In der Auswahlliste der Standortsuche sollte das Land, in dem sich der Anwender befindet, bereits voreingestellt sein, damit dieser sein Land nicht jedes Mal selbst aus einer langen Liste von Ländern auswählen muss.

Die Spracheinstellungen im Web-Browser des Benutzers sind für die Ermittlung des Landes allerdings kein verlässliches Indiz. Denn im Accept-Language-Header, den der Browser zum Server schickt (z.B. „de-DE, en“) ist zwar die vom Anwender bevorzugte Sprache enthalten, allerdings nicht unbedingt auch sein Land. Darüber hinaus ist es auch möglich, dass der Benutzer ein anderes Land eingestellt hat als das, in dem er sich tatsächlich befindet.

Besser ist es also, das Land über einen anderen Weg zu ermitteln. Eine Möglichkeit wäre, der Anwendung beim Aufruf einen Ländercode mitzugeben. Das funktioniert dann, wenn unterschiedliche länderspezifische Webseiten jeweils auf die Anwendung verlinken. Doch man sollte auch bedenken, dass die Anwendung gegebenenfalls auch über eine Suchmaschine gefunden und aufgerufen wird. In diesem Fall bekommt die Anwendung keinen Ländercode mit, so dass sie sich anderweitig behelfen muss. Sie könnte dann ein vordefiniertes Standardland verwenden – zum Beispiel das Land in dem das Unternehmen die meisten Kunden hat. Es gibt allerdings noch eine elegantere Möglichkeit: Die Ermittlung des Landes anhand der IP-Adresse, von der aus die Seite aufgerufen wird. Zu diesem Zweck gibt es verschiedene IP-to-Country-Datenbanken, die sich in die Anwendung einbinden lassen.

Für die Integration dieser Datenbanken gibt es unterschiedliche Ansätze. Ein Ansatz ist, einen Webservice aufzurufen, dem man die IP-Adresse übergibt und der das entsprechende Land zurück liefert. Durch die Einbindung eines fremden Webservice handelt man sich allerdings auch ein Stück weit Kontrollverlust und neue potenzielle Problemquellen ein. Sie könnte beispielsweise eine Verschlechterung in der Performance der eigenen Anwendung bewirken. Außerdem benötigt man eine Ausnahmebehandlung für den Fall, dass der Webservice nicht verfügbar ist oder für eine unverhältnismäßig lange Zeitspanne nicht antwortet. Im Gegenzug kann man aber davon ausgehen, dass die Ergebnisse durch die Einbindung eines Webservice auf einer stets aktuellen Datenbasis basieren.

Der von uns für die DHL Paketshop-Suche gewählte Ansatz funktioniert mit einer Datenbankdatei, die lokal im Dateisystem der Webanwendung abgelegt und über eine Java-Bibliothek angesprochen wird. Dadurch wird die Abhängigkeit zu einem fremden Webservice eliminiert. Die Kehrseite ist, dass man einen Regelprozess für den Betrieb etablieren muss, durch den die Datenbankdatei regelmäßig aktualisiert wird. Die IP-to-Country-Datenbanken sind allerdings meist nicht kostenlos, vor allem wenn man qualitativ hochwertige Ergebnisse haben möchte. Dazu kommt ein erschwertes Testen, denn während der Testphase ist die Anwendung üblicherweise noch nicht über das offene Internet erreichbar. Die Aufrufe der Anwendung müssen somit vom Firmennetz aus oder über ein VPN erfolgen. Möglicherweise wird dann ein falsches Land ermittelt, wenn die IP-Adresse des Aufrufenden nicht dem Land zugeordnet ist, in dem er eigentlich sitzt.

Fazit: Die Entwicklung von multinationalen Webanwendungen ist komplex, da es viele Dinge zu beachten gilt. Wenn man die Fallstricke kennt und sie von Anfang vermeidet, steht einer erfolgreichen Umsetzung aber nichts mehr im Wege.


Quellen:

[1] http://www.w3.org/International/questions/qa-i18n

[2] http://www.w3.org/International/questions/qa-scripts.de.php

[3] http://www.w3.org/International/tutorials/bidi-xhtml/Overview.de.php

 

doubleSlash-Teaser-Blog_Digitale-Transformation

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*