Von einer Globalisierung und Internationalisierung der Wirtschaft ist nahezu täglich die Rede. Dies gilt auch für die IT-Industrie und dort im speziellen für Software-Entwickler. Die in Genf ansässige Localisation Industry Standards Association (Lisa, http://www.lisa.unige.ch) schätzt, daß im vergangenen Jahr mit lokalisierter Software, also Produkten, die an die jeweiligen nationalen Gegebenheiten angepaßt sind, weltweit ein Umsatz von zirka 50 Milliarden Dollar erzielt wurde. In Anbetracht dieses Marktvolumens haben Hersteller, die sich von Anfang an den Herausforderungen der Internationalisierung gestellt haben, eine sehr gute Ausgangsposition.

Dabei müssen Entwicklungssysteme von Applikationen getrennt werden. Denn die Internationalisierung betrifft weniger die Entwicklungsumgebung als die damit erstellte Software. In 95 Prozent der Fälle nutzen Programmierer weltweit eine englische Version, eine Anpassung ist nur für bestimmte Staaten wie arabische Länder, Frankreich, Japan oder Thailand notwendig. Anders sieht die Sache bei Applikationen aus, die in einem hohen Maß an lokale Gegebenheiten angepaßt werden und multilingual sein müssen. Die entsprechenden Voraussetzungen dafür muß die Entwicklungsumgebung erfüllen.

Die zentralen Aspekte einer internationalen Software lassen sich in drei Kategorien untergliedern:

- internationale Zeichensätze und ihre Verarbeitung (Formatierung, Sortierung etc.),

- Währungen einschließlich der für Bankgeschäfte wichtigen Rundungsregeln sowie

- Darstellung von numerischen Werten, Zeitangaben (Uhrzeit, Datum), Maßeinheiten (Entfernung, Gewicht) und Unterstützung verschiedener Kalendersysteme.

Internationale Zeichensätze

Wer Applikationen rund um den Globus einsetzen will, benötigt Versionen in den entsprechenden Sprachen. Mehrsprachigkeit gehört bei Software zwar mittlerweile zum guten Ton, wenn es aber um andere Schriftarten oder gar Schriftsysteme geht, sind spezielle Anpassungen erforderlich. Als Faustregel läßt sich festhalten: Internationalisierung kommt vor der Lokalisierung. Außerdem gilt: Der Aufwand für eine Lokalisierung ist um so geringer, je mehr von Anfang an in die Internationalisierung investiert wurde.

Mit 8 Bit, also einem Byte, können 256 verschiedene Zeichen dargestellt werden; dies ist ausreichend, um nahezu alle Eigenheiten der auf dem lateinischen Alphabet beruhenden Schriftsprachen abzudecken, einschließlich der deutschen Umlaute und einer Fülle von Akzenten in anderen Sprachen. Alle Zeichen sind als Bit-Folge gespeichert und auf Basis der Character-Sets (auch Code-Page genannt) von der Software interpretiert.

256 mögliche Zeichen genügen jedoch noch nicht einmal, um alle Sonderformen der europäischen Buchstabenwelt wie Polnisch, Tschechisch, Slowakisch, Kroatisch oder Slowenisch abzudecken. Im Laufe der Zeit werden deshalb die verschiedenen Zeichensätze durch Unicode abgelöst. Software, die international über Sprachgrenzen hinweg eingesetzt wird, muß fähig sein, Unicode zu verarbeiten und alle Funktionen darauf direkt auszuführen. Sie soll ein Zeichen nicht nur richtig darstellen, sondern für String-Operationen auch wissen, um welche Art von Zeichen es sich handelt (siehe Kasten "Unicode").

So verfügen beispielsweise die meisten Datenbanken über eine Funktion "Upper" zur Umwandlung von Klein- in Großbuchstaben. Unterschiedlich ist auch die Sortierung: Wir sind gewohnt, daß eine Datenbank wie ein Wörterbuch sortiert ist, und erwarten den Umlaut Ä nach A, finden ihn aber manchmal nach Ae; in Schweden ist è gar der letzte Buchstabe des Alphabets. Kein triviales Problem etwa für eine Datenbank, die von schwedischen, deutschen und polnischen Anwendern gleichzeitig benutzt werden soll. Aus Gründen der Einheitlichkeit können international tätige Softwarehersteller diese Dinge nicht einem Betriebssystem überlassen, denn eine Datenbank soll mitunter auch plattformunabhängig laufen. Die Datenbank muß daher die verwendeten Code-Pages selbständig überwachen können.

Wesentlich in diesem Zusammenhang ist auch, daß Anwendungen möglichst einfach auf die Datenbank zugreifen können - unabhängig davon, ob die Daten in Unicode oder in anderen Zeichensätzen abgelegt sind. Ein einfacher Zugriff läßt sich mit Java direkt oder mit Hilfe der in Java enthaltenen Konvertierungsroutinen gewährleisten.

String-Verarbeitung

Zur Anpassung der Applikationen an verschiedene Sprachen werden spezielle Klassen verwendet, die für Strings Referenzen auf Resource-Files enthalten, in denen die jeweiligen Ausprägungen festgehalten sind. Eine Steuerung erfolgt zur Laufzeit über die entsprechenden Einstellungen von Parametern im Betriebssystem. Durch die gewählte Technik ist auch eine Anpassung der Sprache zur Laufzeit möglich, falls es die Anwendung vorsieht. Das gleiche Verfahren gilt ebenso für andere Aspekte der Internationalisierung.

Unterstützt werden damit Anforderungen wie Vergleiche von Strings, Sortierungen, automatische Groß-/Kleinkonvertierungen, Nutzung von Resource-Files und - durch die Laufzeitparametrisierung - multilinguale Anwendungen, die gerade in einer globalen Geschäftswelt immer wichtiger werden.

Währungen und Rundungsregeln

Wo es sich um Geld und Währungen dreht, kommt es in Applikationen auf höchste Genauigkeit an. Angenommen, in einer Electronic-Business-Anwendung gehen Bestellungen aus den unterschiedlichsten Ländern ein, die dann in eine gemeinsame Währung zu konvertieren sind. Zu berücksichtigen ist hier zunächst einmal die Darstellung von positiven und negativen Beträgen einschließlich der Währungssymbole. In Deutschland und Frankreich werden negative Beträge mit einem Minuszeichen vor dem Betrag und der Währungseinheit dargestellt (-123,45 DM; -123,45 F). In Hongkong, Ungarn und den USA steht das Währungssysmbol zwischen dem Negativzeichen und dem Betrag (-$123.45; -FT123,45 und -$123,45). Zu berücksichtigen sind auch lokale ($ und DM) und genormte Währungsbezeichnungen (USD und DEM).

Weiterhin sind Trennzeichen für Tausender- und Dezimalstellen zu beachten. Bei der Umrechnung von einer Währung in die andere gilt es, drei Varianten von Nachkommastellen zu berücksichtigen: Die meisten Länder verwenden zwei Nachkommastellen, einige drei, andere wiederum überhaupt keine. Um Beträge in einer Applikation umzurechnen, können in der Applikation entweder feste Kurse verwendet werden, oder das Programm holt sich selbst die aktuellen Werte aus dem Internet.

Zeit- und Maßeinheiten

Bei der Software-Entwicklung für internationale Märkte spielen schließlich auch Zeit- und Datumsangaben, lokale Kalender mit unterschiedlichen Feiertagen oder Maßangaben eine Rolle. Die Konvertierung von Maßeinheiten (Kilometer in Meilen, Liter in Gallonen etc.) läßt sich standardmäßig parametergesteuert über Funktionen abwickeln. Schwieriger wird es bei Kalenderfunktionen, die beispielsweise im Projekt-Management benötigt werden und Besonderheiten wie Arbeitstage, freie Tage und Feiertage berücksichtigen müssen.

Zweifelsohne gibt es noch eine Reihe von weiteren Aspekten, die bei der Internationalisierung von Applikationen eine Rolle spielen, so etwa kulturelle Besonderheiten wie die Verwendung von Symbolen und Metaphern. Dies gilt für die eigentliche Benutzeroberfläche einer Applikation. International tätige Softwarehersteller testen daher Applikationen gerade unter diesen Aspekten sehr ausführlich.

Unicode

Geht es um Schriften- und Code-Pages, lautet das Stichwort "Unicode" (standardisiert nach ISO 10646). Damit wird eine Code-Page für alle Sprachen auf Double-Byte-Basis zur Verfügung gestellt. Für die meisten Einsatzgebiete dürften die zirka 65000 Zeichen unter Unicode ausreichen - derzeit sind nur zwei Drittel belegt; es wird aber auch schon über noch weitergehende Standards auf Basis von 4 Byte diskutiert.

Windows NT beispielsweise ist im Kern bereits Unicode-fähig, und auch Java ist schon auf Unicode eingerichtet: Alle String-Operationen in Java können diesen Code verarbeiten. Auch die ersten Unicode-fähigen Browser gibt es bereits. Für die wichtigsten Unix-Derivate und die Mainframe-Welt existieren ebenfalls Unicode-Implementierungen oder zumindest entsprechende Konvertierroutinen.

Helmut Weber ist Fachbereichsleiter Bolero Entwicklung bei der Software AG in Darmstadt.