Internationalisierte Java-Programme

Wer Open-Source-Programme schreibt, verwendet als Sprache für Ausgaben, GUI-Elemente und Kommentare meist erst mal Englisch - sowohl für das Programm als auch für Meldungen und Beschriftungen. Das hat verschiedenste Gründe. Entweder herrscht großer Zeitdruck oder das Programm ändert seinen Status fließend vom Prototyp zu einer Produktionsversion. Endanwender wollen aber Software in ihrer eigenen Sprache. Das fällt naturgemäß bei erfolgreichen Programmen besonders auf - die Nutzer in den nicht-englischsprachigen Ländern drängen dann den Entwickler, seine Software nachträglich zu internationalisieren.

Internationalization, kurz I18n wegen der 18 Buchstaben zwischen dem I und dem n, bezeichnet ein Design, bei dem die Anwendung an verschiedene Sprachen und lokale Gegebenheiten (etwa das Datumsformat) angepasst werden kann, ohne dass Programmänderungen notwendig sind. Mit Localization, analog mit L10n abgekürzt, bezeichnet man den konkreten Übersetzungsprozess für eine Sprache samt Anpassung an lokale Besonderheiten.

Einfache Mechanismen

Internationalisierte Programme sollen ohne großen Aufwand und vor allem ohne Neukompilierung zusätzliche Sprachen unterstützen und spezialisierte Daten, etwa Adressen, Datumsangaben und Geldbeträge, in den landesüblichen Formaten ausgeben. Textelemente, beispielsweise Beschriftungen von GUI-Elementen oder Meldungen, sind deshalb außerhalb des Programms gespeichert; das Programm lädt sie dynamisch. Java unterstützt I18n und L10n durch eine Reihe von Klassen und zwei grundlegende Mechanismen.

Zentrale Klassen des I18n-API

Zum Ersten werden Textelemente nicht hart kodiert, sondern über Schlüssel angesprochen. Die Suche nach dem richtigen - oder besser dem am besten geeigneten - Wert zum Schlüssel übernimmt eine Java-Klasse. Zum Zweiten hat Java spezielle Formatierungsklassen, die eingebautes Wissen über Datums- und Währungsformate besitzen.

Bei beiden Mechanismen ist es ausreichend, die aktuelle Sprache und das Land zu definieren. Viel Arbeit fällt hier nicht an, denn die Java-Runtime holt sich Defaultwerte vom Betriebssystem. Sollen dagegen auf einem deutschsprachigen Rechner die Meldungen in Englisch erscheinen, kann der Entwickler das explizit festlegen. Nützlich ist so ein Verhalten für Serverprozesse, die entweder immer in einer festen Sprache mit dem Client kommunizieren oder je nach Client anders lokalisierte Meldungen ausgeben.

Die Lokalisierung steuern Instanzen der Klasse »java.util.Locale«. Sie haben selbst keine eigene Funktionalität, sondern dienen als Marker für andere Klassen. Der Aufruf des Konstruktors erfolgt mit dem Sprachcode (ISO-Sprachcode gemäß[1]) und Länderkennung[2]. Typische Konstruktoraufrufe sehen also wie folgt aus:

Locale a = new Locale("en","US");
Locale b = new Locale("en","UK");
Locale c = new Locale("en");

Letzteres spezifiziert nur die Sprache, nicht die Region und ist immer dann ausreichend, wenn es keine Unterschiede in Texten gibt und das Programm keine Währungen, Daten und Zahlen darstellen muss. Ein dritter Parameter wäre eine applikationsspezifische Variable, die aber in vielen Fällen nicht unbedingt nötig ist.

Die Klasse »java.util.ResourceBundle« dient dazu, Texte über Schlüssel anzusprechen. Der Konstruktor erhält als Parameter den Namen - er verweist auf eine Klasse - sowie optional eine Instanz der Klasse »Locale«. Die »getString(key)«-Methode holt dann den zugehörigen Wert.

Für die Darstellung von Meldungen, Zahlen und Daten sind die unterschiedlichen Format-Klassen im Package »java.text« zuständig, vor allem die Klassen »DateFormat«, »MessageFormat« und »NumberFormat«. Die »Collator«-Klasse - ebenfalls in »java.text« zu finden - sortiert Strings gemäß den lokalen Gegebenheiten, was insbesondere in Sprachen mit Sonderzeichen wie im Deutschen wichtig ist.