Internationalisierung: So setzen Sie Anforderungen an das Front-End um!
Im kompetitiven Umfeld der Endkundensoftware reicht eine Anwendung mit guten Features alleine nicht aus, auch die nichtfunktionalen Eigenschaften müssen überzeugen. Eine davon ist die Fähigkeit der Internationalisierung. Früher wurde damit lediglich die Lokalisierung einer Software gemeint, also das Austauschen von Bildschirmtexten. Die Anforderungen steigen jedoch.
Haben wir nicht schon alles erreicht?
Darauf hinzuweisen, wie viel leistungsfähiger Computer in den letzten Jahrzehnten geworden sind, ist schon ein Klischee geworden. Ein Punkt der seltener betrachtet wird, ist die Art, wie sich die Interaktion von Endkunden zu Software gewandelt hat. In den Zeiten der "grauen Blechkisten" war es noch völlig normal, dass sich der Benutzer ganz auf das System einstellen musste – Usability war noch kein Thema. Die neuen Möglichkeiten der elektronischen Datenverarbeitung (die Features) waren so verlockend, dass man bereit war, große Arbeit in die eigene Anpassung zu investieren. Inzwischen könnte man argumentieren, dass sich das Feld komplett gedreht hat. Das Angebot an Software ist groß, die Feature-Sets vergleichbar. Spätestens im Umfeld von "Apps" ist die Frage: "Kann ich die Software intuitiv bedienen?" zu einem entscheidenden Auswahlkriterium geworden.
Internationalisierung ist Teil der Usability und daher ein wichtiger Faktor der wahrgenommenen Softwarequalität. Es lohnt sich daher, den aktuellen Stand der Technik zu erfassen und diesen als Maßstab für die eigenen Entwicklungsarbeiten zu nehmen. Ich setze dabei folgendes Ziel: Eine internationalisierte Software muss aus technischer Sicht dynamisch und frei sein. Aus inhaltlicher Sicht muss sie regionale Sprachfärbungen und regionale Formatierungen beachten. Diese Begriffe werden im Artikel definiert. Damit sie nicht theoretisch bleiben, werden konkrete Umsetzungshinweise für .NET geliefert.
Begriffsdefinitionen
Dynamisch
Im Internetzeitalter sind mehrsprachige Oberflächen allgegenwärtig. Auch bei Desktop-Software tut sich vieles. Während Windows 95 "nur" 30 Sprachen unterstützte, waren es bei Windows 8 schon über 100. Wenn man dann noch bedenkt, dass eine der neuen Lokalisierungen von Windows 8 die der Cherokee-Indianer ist, könnte man zu dem Schluss kommen, dass Internationalisierung inzwischen ein gelöstes Problem ist.
Doch schauen wir genauer hin: In Windows 9x und NT war die Lokalisierung noch fest verzahnt mit dem Binärcode des Betriebssystems. Um die Sprache zu ändern, war es in der Regel notwendig, das System komplett neu aufzusetzen. Erst mit Windows 2000 war es möglich, Sprachen einzeln als Pakete zu installieren. Diese waren jedoch bis Windows XP nur für Volumenlizenznehmer verfügbar. In Vista und 7 erweiterte sich dieser Kreis auf die Besitzer der "Ultimate"-Versionen. Effektiv bedeutete das, dass Endkunden und Mittelständler auf diese Features in der Regel keinen Zugriff hatten.
Erst mit Windows 8 ist die technische Basis aller Sprachversionen gleich. Alle Sprachen werden als Sprachpaket gehandhabt und sind auch kostenlos für alle Benutzer zugänglich. Erst diese Version erreicht das Ideal einer dynamischen Lokalisierung: Der Benutzer kann jederzeit, ohne Aufpreise und ohne detaillierte technische Kenntnisse, die Sprache der Benutzeroberfläche ändern. Zur Erinnerung: Diese Software ist erst wenige Jahre alt! Ich erspare es mir hier, eine Vergleichsliste von Office-Programmen, Browsern, Entwicklungsumgebungen etc. zu erstellen. Die Quintessenz ist: bei vielen Anwendungen im täglichen Einsatz ist die Lage weniger gut, oder sie hat sich erst vor kurzer Zeit verbessert.
Frei
Eine mit der Dynamik eng verknüpfte Forderung ist die, dass die Lokalisierung frei von Nebeneffekten sein muss. Ein gängiger Fehler ist es, die gewählte Sprache auch dazu zu nutzen, die Software an verschiedene regionale Gesetzmäßigkeiten anzupassen. Das kann zu "witzigen" Effekten führen: Vor der Jahrtausendwende war es bei manchen Videospielen möglich, die deutschen Zensuren zu umgehen, indem man auf die englische Sprachfassung wechselte. Bei Produktivitätsanwendungen dürften solche Effekte dem Benutzer weniger witzig vorkommen. In Ländern wie der Schweiz gelten evtl. andere Rahmenbedingungen für den Einsatz spezifischer Software als in Deutschland, Frankreich oder Italien. Trotzdem wird dort auch deutsch, französisch und italienisch gesprochen. Das Beispiel sollte genügen, um zu zeigen, dass die Verknüpfung von Lokalisierung und Geschäftslogik sehr gefährlich ist.
Es ließen sich sicher noch andere Beispiele finden, aber das zentrale Dogma sollte klar sein: Der Benutzer hat nur dann etwas von den Lokalisierungsoptionen seiner Software, wenn er sie frei und ohne Nebenwirkungen ändern kann.
Regionale Sprachfärbungen
Sicher kennen die meisten aus ihrem Englischunterricht noch die Tatsache, dass es "das" Englische eigentlich nicht gibt. Es gibt amerikanisches, britisches und australisches Englisch – um nur die bekanntesten Dialekte zu nennen. Der Amerikaner fährt einen "Truck" und geht auf dem "Pavement", der Brite fährt eine "Lorry" und geht auf dem "Sidewalk". Wenn man nun keine der beiden sprachlichen Nutzergruppen düpieren möchte, hat man zwei Möglichkeiten: Entweder man findet einen "neutralen" Begriff oder behandelt britisch und amerikanisch als zwei verschiedenen Sprachen. Die Frage ist: Was wäre ein guter Kompromiss? Leo.org schlägt "Sideway" für den Bürgersteig vor – das klingt akzeptabel. Als Kompromiss für den Laster bleibt aber wohl nur das "Commercial Road Vehicle". Dieses klingt aber so umständlich, dass es für keine der beiden Seiten ein natürlicher Begriff sein dürfte. Aus GUI-Sicht stellt sich außerdem die Frage: Wie kriege ich diesen langen Begriff auf einem (Radio-)Button unter? Es kann durchaus passieren, dass das Widget aus Platzgründen die Abkürzung "C.R.T." verpasst bekommt. Das kann dann garantiert niemand mehr verstehen. Zugegeben, wenn es um die Auswahl eines Verkehrsmittels geht, wären auch Piktogramme eine gute, da verständliche und platzsparende, Lösung. Dies ist aber nicht der Regelfall.
Regionale Formatierungen
Das Problem der unterschiedlichen regionalen Formatierungen lässt sich am besten an einem Beispiel zeigen. Die folgenden Zeilen könnten eine deutsche Wetteranzeige sein:
Wetter am 10.5.2016
| 8:00 | 12:00 | 16:00 | 20:00 |
|---|---|---|---|
| 14,5° | 18,7° | 20,3° | 18,9° |
Sie könnten aber auch so aussehen:
Wetter am 5/10/2016:
| 8:00 am | 12:00 am | 4:00 pm | 8:00 pm |
|---|---|---|---|
| 14.5° | 18.7° | 20.3° | 18.9° |
Die Daten sind identisch, im Prinzip können wir alles verstehen. Es fühlt sich aber nicht "richtig" an. Der Grund ist, dass einmal deutsche und einmal amerikanische Konventionen zur Darstellung der Daten verwendet werden. Technisch gesprochen: Die Daten liegen binär immer gleich im Speicher vor, zur Darstellung müssen sie aber in einen Text umgewandelt werden. Wie dieser Text auszusehen hat, ist je nach Kultur unterschiedlich. Das ist mehr als ein kosmetisches Problem: Im Fall des Datums könnte man zu der falschen Annahme kommen, dass die Temperaturen zum fünften Oktober gehörten.
Ähnlich sieht es mit Eingaben aus. Immer dann, wenn numerische Daten vom Benutzer eingegeben werden, wird er dies mit den ihm bekannten Formatierungskonventionen tun. Wenn die Anwendung und der Benutzer dem Komma innerhalb einer Zahl jedoch unterschiedliche Bedeutungen zuweisen (einmal den Dezimaltrenner und einmal den Tausenderpunkt), kann es zu eklatanten Fehleingaben kommen.
Hinweise zur technischen Umsetzung
Zunächst ist zu sagen, dass die vier genannten Themen aus technischer Sicht sehr unterschiedlich zu betrachten sind. Zwei von ihnen sind schnell abgehandelt.
- Eine freie Anpassung der Internationalisierung ist dann gewährleistet, wenn regulatorische Fragen, die sich auf den Einsatz der Software in einer bestimmten Region beziehen, völlig getrennt werden von Fragen der Lokalisierung und Formatierung. Die regulatorischen Fragen sind vom jeweiligen Geschäftsfeld der Anwendung abhängig und daher kein Thema für diesen Artikel. Wenn Sie aber die Notwendigkeit der Trennung immer im Hinterkopf behalten, sind Sie auf einem guten Weg.
- Regionale Sprachfärbungen sind technisch fast überhaupt kein Thema. Der einzige entscheidende Punkt ist das Verhältnis von Sprachen untereinander. Ein Sprachpaket ohne regionale Sprachfärbung ("en") wird in .NET automatisch als Ersatz für ein fehlendes Sprachpaket mit regionaler Sprachfärbung ("en-AU") herangezogen.
Es bleibt also die Realisierung einer dynamischen Lokalisierung und regionaler Formatierungen. Bei genauerer Betrachtung lässt sich erkennen, dass es sich hierbei um zwei eng verwandte Vorgänge handelt. Bei beiden Punkten geht es darum, je nach gewählter Sprache die Anzeige der Anwendung zu modifizieren.
- Bei der Lokalisierung wird an die Stelle eines Platzhalters ein statischer Text gesetzt, der durch einen symbolischen Namen identifiziert wird.
- Bei der Formatierung wird an die Stelle eines Platzhalters die Textrepräsentation eines programmatischen Werts gesetzt. Weiterhin werden auch Eingaben, die in Textform vorliegen, in den dazugehörigen Wert umgewandelt.
Die Lokalisierung arbeitet also nur in eine Richtung, die Formatierung in zwei.
Lokalisierung
Auf den grundlegenden Ablauf einer Lokalisierung möchte ich hier nur kurz eingehen, denn es ist ein bereits vielfach behandeltes Thema. Wichtiger ist es, auf die Fallstricke genauer einzugehen.
Zunächst müssen alle Benutzertexte aus dem Quellcode entfernt und in Ressourcen ausgelagert werden. In der UI steht also kein Text mehr, sondern lediglich ein Verweis auf einen symbolischen Schlüssel. Die Ressourcen werden wiederum in "Satelliten-Assemblies" ausgelagert, also solche, die nur kulturell markierte Ressourcen enthalten und keinen Binärcode. Für jede zu unterstützende Sprache wird eine solche Assembly (quasi ein "Sprachpaket") erzeugt. Sie enthält für alle von der Anwendung verwendeten symbolischen Namen einen Text, übersetzt in die Sprache, mit der auch die Assembly in den Metadaten markiert ist. Diese Vorgänge sind im Wesentlichen Fleißarbeit, für die es auch diverse kommerzielle Tools gibt.
Wenn diese Schritte getan sind, wird für eine Ressource, die im UI adressiert wird, immer automatisch die aktuell passende Sprachvariante verwendet. Als einziger Arbeitsschritt verbleibt es zu klären, wie diese "aktuell passende" Sprache zu verstehen ist. Hierbei gibt es einiges zu beachten.
Zunächst muss geklärt werden, ob es akzeptabel ist, dass die Software nur unter Windows 8 und neueren Versionen funktioniert. In diesem Fall könnte sich die Anwendung ganz auf das Betriebssystem verlassen: Die Spracheinstellungen sind seit Windows 8 ein neu entworfener, eigener Punkt in der Systemsteuerung, der leicht zu bedienen ist. Wenn der Anwender hier seine gewünschte Sprache auswählt, setzt das Betriebssystem diese auch als aktive Sprache für die eigene Anwendung und das Thema ist erledigt.
Da es aber wahrscheinlich nicht akzeptabel ist, diese Voraussetzung zu machen, muss die Verwaltung der Sprache von der Anwendung selbst vorgenommen werden. Der Benutzer muss also seine gewünschte Sprache innerhalb der Software selbst auswählen können. Auf Basis dieser Auswahl muss dann die aktive Sprache gesetzt werden. Dies geschieht unter .Net durch Setzen des Properties:
Thread.CurrentThread.CurrentUICulture
Konzeptionell gesehen muss hier der Sprachcode der gewünschten Lokalisierung eingetragen werden. Technisch wird aber ein Objekt vom Typ CultureInfo erwartet. Der komplette Aufruf sieht dann z. B. so aus:
Thread.CurrentThread.CurrentUICulture
= CultureInfo.CreateSpecificCulture("en-US");Ein Punkt sollte ins Auge stechen: Die Einstellung ist Thread-spezifisch. Damit die Änderung wirkt, muss die Einstellung im UI-Thread vorgenommen werden. Dieses Design ist recht naheliegend, schließlich wird das Auflösen von Ressourcen auch spezifisch in der UI vorgenommen. Dafür gibt es in den diversen Technologien von .NET auch komfortable Möglichkeiten, z. B. deklarative Bindungen auf statische Ressourcen in XAML. Es gibt also eigentlich keine Notwendigkeit, Ressourcen "per Hand" aufzulösen. Falls man dennoch einmal auf Sprachressourcen in einem Worker-Thread zugreifen möchte, muss sichergestellt werden, dass auch in diesem die Kultur korrekt gesetzt ist. Spätestens beim Arbeiten mit dynamischen Threads wird dies schwierig. Aus diesem Grund gibt es ab .NET 4.5 die Möglichkeit, einen Default-Wert zu setzen, der für alle neuen Threads genutzt wird. Dieser wird direkt im CultureInfo-Objekt gesetzt. Der komplette Code um die Sprache in der UI zu setzen sieht daher wie folgt aus:
Thread.CurrentThread.CurrentUICulture
= CultureInfo.DefaultThreadCurrentUICulture
= CultureInfo.CreateSpecificCulture("en-US");Natürlich ist im Beispielcode die Sprache nur eine Konstante. In der realen Anwendung muss die Sprachauswahl persistiert werden. Hier ist zu beachten, dass diese Persistierung benutzerbezogen sein muss. Es wäre ärgerlich, wenn eine Software zwar prinzipiell alles richtig macht, dann aber die Lokalisierung als globale Option eines Servers versteht oder auf einem Smart-Client diese Einstellung systemweit und nicht im lokalen Benutzerkonto speichert. Dies würde die Freiheit des Benutzers bei der Sprachwahl unnötig einschränken.
Wichtig: Das Setzen der neuen Kultur hat natürlich nur Auswirkungen auf zukünftige Abfragen von Ressourcen. Die bereits aufgelösten Ressourcen sind und bleiben Teil der Bildschirmmasken. Es ist also notwendig, alle Bedienelemente neu aufzubauen. Da die Trennung von Anwendungslogik und Bedienoberfläche aber nur selten zu 100% durchgehalten ist und selbst kleine Überreste einer "alten" Übersetzung sehr störend wirken, ist es eine pragmatische Alternative, einfach die Anwendung komplett neu zu starten.
Formatierung
.NET bietet für die typischen Datentypen diverse Objektmethoden an, um einen formatierten String zu bekommen. Beispiel Datum: Das DateTime-struct hat die Methode ToShortDateString. Um das Wetterbeispiel wieder aufzugreifen:
new DateTime(2016, 5, 10).ToShortDateString()
Dieses Fragment erzeugt ein Datum in der Form "10.5.2016" oder "5/10/2016", nur um einige Beispiele zu nennen. Die konkrete Ausgabe ist abhängig von der aktuellen Formatierung.
Nicht vergessen werden sollte auch die entgegengesetzte Richtung – die Benutzereingaben. In diesem Fall kann ganz abstrakt die Eingabe in Form eines Strings genommen werden und an DateTime.Parse() übergeben werden. Es werden dann die aktuellen Formatierungen angewandt, um aus der Texteingabe wieder ein binäres Datum zu parsen.
Die vorhandenen Werkzeuge sind also sehr mächtig, wenn die richtige Formatierung eingestellt ist. Was muss nun also getan werden um diese korrekt einzustellen? Die erstaunliche Antwort lautet: Nichts – In der Regel wird einfach zu viel getan und dadurch entstehen erst Probleme. Diese Aussage ist erklärungsbedürftig. Fangen wir also nochmal am Anfang an.
Im Abschnitt über Lokalisierung haben wir folgendes festgestellt: Es ist notwendig, dass die gewünschte Sprache für die Benutzeroberfläche von der Anwendung selbst verwaltet wird, da die verbreiteten Windows-Versionen noch keine vom Endbenutzer verwaltbaren Spracheinstellungen bieten. Bei regionalen Formatierungen ist dies aber nicht der Fall. Schon Windows 95 verfügte in der Systemsteuerung über den Punkt "Ländereinstellungen" ("Regional Settings"). Schon dort konnte die Region ausgewählt werden, die darüber bestimmte, welche Formatierungen zu nutzen sind. Seitdem ist dieses System auf nahezu jede erdenkliche Region der Welt ausgeweitet worden. Die Formatierungseinstellungen können sogar vom Benutzer noch angepasst werden. Diese Einstellungen mitsamt Benutzeränderungen fließen automatisch in alle .NET-Prozesse ein. Man sieht also, dass es keinen Sinn macht, eine eigene Verwaltung von regionalen Formatierungen zu implementieren oder auch nur die aktuell eingestellten Formatierungen programmatisch zu ändern.
Vielleicht werden Sie sich jetzt fragen: "Wenn ich die Sprache für meine Oberfläche in der Anwendung verwalte, die Sprache für meine Formatierungen aber im Betriebssystem, laufen diese dann nicht evtl. auseinander?" Die Antwort lautet: Ja, und das ist auch gewünscht. Einen Teil der Erklärung für diese im ersten Moment verwirrende Aussage bekommt man, wenn man den von mir bewusst in die Frage eingebauten Fehler korrigiert. Formatierungen sind nicht bezogen auf Sprachen, sondern auf Regionen. Englisch ist das perfekte Beispiel: Sowohl in den USA, Großbritannien als auch in Indien wird englisch gesprochen, die Formatierungen sind aber immer unterschiedlich.
Das Aufrechterhalten der Systemformatierung bewahrt ein "Stück Heimat".
Eine andere Perspektive auf das Thema ist die folgende: Die Anzahl der von Windows unterstützten Formatierungen ist sehr groß. Die Wahrscheinlichkeit, dass die Regionseinstellungen den Wünschen des Benutzers entsprechen, ist dadurch ebenfalls sehr groß. Die Anzahl der Sprachen, die von der eigenen Lokalisierung abgedeckt werden, dürfte zumindest im Vergleich zu den Betriebssystemregionen eher klein sein. Wenn der Benutzer nun eine Sprache auswählt, könnte es sein, dass diese für ihn nur ein Kompromiss ist. Sicher ist er dann froh, wenn wenigstens die Formatierungen noch in der von ihm gewohnten Form durchgeführt werden. Beispiel: Ich bin Finne und bin es gewohnt, dass meine Muttersprache für die Lokalisierung nicht unterstützt wird. Ich wähle deshalb "englisch". Habe ich damit gesagt, dass ich gerne eine amerikanische Datenformatierung will? Sicher nicht.
Selbst wenn ich meine Muttersprache auswählen kann, sollte keine Änderung vorgenommen werden. Beispiel: Ich bin Brite und wähle deshalb ebenfalls "englisch", auch in diesem Fall möchte ich keine amerikanischen Formatierungen.
Man könnte sagen, dass das Aufrechterhalten der Systemformatierung ein "Stück Heimat" für den Anwender bewahrt. Das geht so weit, dass es sogar Sinn machen könnte, den Vorschlag für die Erstauswahl der Lokalisierung nicht auf Basis der Betriebssystemsprache zu machen, sondern auf Basis der im Betriebssystem eingestellten Region, da diese mit noch höherer Wahrscheinlichkeit den Wünschen des Benutzers entspricht.
Jetzt, wo Sie sicher auch der Meinung sind, dass die Regionseinstellung unangetastet bleiben sollte, noch eine Warnung: Setzen Sie sie auch nicht "aus Versehen". Dies geschieht nämlich sehr leicht. Sicher erinnern Sie sich noch an das Property CurrentUICulture, welches die Sprache für die Lokalisierung bestimmt. Das entsprechende Property für die Auswahl der Region (und damit für die Formatierung) ist CurrentCulture. Wenn man nicht genau hinsieht, könnte man den einzigen Unterschied glatt übersehen – einmal mit und einmal ohne "UI". Wegen der Namensähnlichkeit und der Tatsache, dass beide ein CultureInfo-Objekt akzeptieren, sowie der geringen Bekanntheit der oben beschriebenen, regionsbezogenen Use-Cases, sieht man oft den folgenden Code:
Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture = GetSelectedUserLanguage();
Wie gesagt, dieser Code ist weit verbreitet. Nichtsdestotrotz ist er falsch, sofern Sie meinen Argumenten zustimmen. Seien Sie mit Ihrer Software vorsichtiger, indem Sie das Setzen der CurrentCulture einfach unterlassen und damit die Usability Ihrer Software für Benutzer, deren Muttersprache selten übersetzt wird, verbessern.
Zusammenfassung
Eine Benutzeroberfläche mit einem modernen Anspruch an Internationalisierung muss eine dynamische und freie Lokalisierung anbieten, die idealerweise regionale Sprachfärbungen beachtet. Die technischen Grundlagen dafür sind in .NET vorhanden.
Weiterhin ist es wichtig, zwischen Lokalisierung und Formatierung zu unterscheiden. Regionale Formatierungen müssen unbedingt beachtet werden, um Verständlichkeit bei Ausgaben und Fehlerfreiheit bei Eingaben zu gewährleisten. Das wichtigste ist dabei die Sensibilisierung für das Thema, denn die technische Umsetzung ist mit vergleichsweise wenig Aufwand zu gewährleisten.
Am wichtigsten für eine korrekte Umsetzung von Internationalisierungszielen in .NET ist das Verständnis der Kultur-Properties. Zur Zusammenfassung noch einmal die wichtigsten Informationen dazu gegenübergestellt:
Informationen zu Kultur-Properties
| Property | CurrentUICulture | CurrentCulture |
|---|---|---|
| Thema | Lokalisierung | Region |
| Erklärung | Sprache der Bedienoberfläche | Datenformate bei Aus- und Eingabe |
| Besserer Name | CurrentResourceCulture | CurrentFormatingCulture |
| Von der Anwendung verwaltet? | Vor Windows 8: Ja,Exklusiv Windows 8+: Nein | Nein |
