Manfred Gahr ist Unternehmensberater in München.

Fast automatisch programmiert jeder Entwickler Softwarepakete in seiner Muttersprache. Stellt der Anbieter fest, daß sich die Vermarktung auch im Ausland lohnen würde, entsteht meist für jede Landessprache ein System-Duplikat. das eigens gewartet werden will - eine teure und unprofessionelle Methode. Manfred Gahr zeigt eine Alternative auf.

Europa steht vor der Tür: Für die einen bedeutet dies lästigen zusätzlichen Wettbewerb, für die anderen die Möglichkeit, neue Märkte zu erschließen. Software-Anbietern, die bereit sind, die Herausforderung anzunehmen, bieten sich interessante Absatzmärkte. Voraussetzung ist allerdings, daß die Programme in verschiedenen Sprachen mit dem Endbenutzer kommunizieren können.

In der Regel wird ein derartiges Feature völlig ungeplant auf ein bereits fertiggestelltes System aufgepflanzt. Eine internationale Benutzeroberfläche bereitet aber mehr Schwierigkeiten als auf Anhieb erkennbar; sie läßt sich nur dann erfolgreich realisieren, wenn sie von Anfang an gut überlegt in das Design eines Systems integriert wird.

Ein großes Programmsystem verfügt über eine ganze Menge Text, mit dessen Hilfe es mit dem Benutzer kommuniziert: Menüs, Funktionstasten-Beschriftungen, Feld- und Dateinamen, Hilfstexte, Fehlermeldungen etc. Ein Teil dieser Informationen befindet sich in der Regel direkt im Programmcode (zum Beispiel Instruktionen), ein anderer in externen Dateien (Masken-Layouts und Fehlermeldungen), ein weiterer in Dictionaries (Feldnamen) und der Rest im Betriebssystem (Systemmeldungen).

Sollen alle diese Textinformationen nachträglich in mehreren Sprachen verfügbar gemacht werden, so ist in der Regel ein enormer Änderungsaufwand notwendig. Der Aufwand kann so groß sein, daß entweder eine derartige Änderung überhaupt nicht lohnt oder aber ein komplettes Duplikat des Programmsystems sowie sämtlicher externer Dateien und Dictionaries angelegt werden muß. Die Nachteile sind bekannt: Abgesehen vom enormen Wartungsaufwand und den unvermeidbaren Inkonsistenzen erhalten die Vertriebspartner im Ausland die aktuelle Programmversion mit monatelanger Verspätung.

Der Doppelgänger macht sich leicht selbständig

Die wesentlichen Probleme der Mehrsprachigkeit sind:

* der unterschiedliche Platzbedarf verschiedener Sprachen,

* die verschiedenen Quellen sprachlicher Information (Programmcode, Dateien, Dictionaries und Betriebssystem),

* die Übersetzung bestimmter Schlüsselbegriffe bei international eingesetzten Datenbanken sowie

* Laufzeitprobleme im Multi-User-Environment.

Die physikalische Begrenzung des Raumes auf dem Bildschirm ist ein wesentliches Handicap, wenn ein Programm ohne Umarbeitung in einer anderen Sprache verfügbar gemacht werden soll. Braucht beispielsweise eine Interaktion, die in Englisch mit einer Maske durchführbar war, in Deutsch deren zwei, so führt dies zu lästigen Ergänzungen in der Programmlogik. Spätestens hier macht sich der Sprachdoppelgänger selbständig.

Sprachinformation gehört nicht in den Programmcode

Vermieden werden kann dieses Problem durch den Einsatz von Fenstertechniken. Dabei sind die Eingabemasken nicht mehr in einzelne Seiten unterteilt und an die Bildschirmgröße gebunden; vielmehr können sie sich zu beliebigen Größen ausdehnen.

Die Maske wird in einem Bildschirmfenster sowohl vertikal als auch horizontal gerollt, sobald der Cursor an eine der Begrenzungen gerät. Das erlaubt das automatische Generieren von Masken in verschiedenen Sprachen und verschiedenen Größen anhand einer einzigen View-Definition. Hilfstexte und Fehlermeldungen werden ebenfalls über Windows in dynamischer Größe dargestellt.

Diese Technik erfordert die konsequente Kontrolle aller I/O-Operationen zum Bildschirm über einen Device-Manager, der die Anpassung von Window-Größen an den tatsächlichen Platzbedarf sowie das Rollen der Fensterinhalte in vertikaler und horizontaler Richtung regelt.

Eine wesentliche Grundregel sprachunabhängiger Systeme ist, daß keine Sprachinformationen im Programmcode enthalten sein dürfen. Ein "Write-String"-Statement ist nicht erlaubt. Statt dessen wird ein Language-Manager aufgerufen, der entscheidet, woher die Sprachinformation geholt werden soll. Dieses Modul hat Zugriff auf verschiedene Dictionaries sowie einen Cache-Speicher, der häufig benutzte Literale enthält.

Die Dictionaries werden so strukturiert, daß für alle Namen (zum Beispiel Applikations-, Relations- und Feldnamen) mehrere Felder je Sprache zur Verfügung stehen. Literale hingegen werden in einem separaten Language-Dictionary abgelegt. Dazu gehören simple Instruktionen wie "Press Return to continue", Maskenüberschriften und

-erläuterungen, Beschriftungen der Funktionstasten, Hilfstexte und Fehlermeldungen.

Zum Auffinden eines Literals dienen vier Deskriptoren:

* "Domain" gibt die logische Zugehörigkeit eines Literals an (zum Beispiel: zum Query-System gehörend),

* "Key" ist ein uniquer Schlüssel innerhalb einer Domain,

* "Type" gibt die Literalart an, und

* "Language" dient als Sprachschlüssel.

Soll das Programmsystem in einer neuen Sprache verfügbar gemacht werden, so müssen die Literale nur übersetzt und dann von einer Schreibkraft in das Dictionary eingegeben werden. Recompilierung oder gar Eingriffe in den Programmcode sind dazu nicht erforderlich.

Bei international eingesetzten Datenbanken taucht das Problem der Übersetzung von Schlüsselbegriffen auf. Wird beispielsweise ein Kunde in Hamburg als "männlich" in "München" erfaßt und derselbe Kunde in London unter "male" und "Munich" gesucht, so muß das System diese Begriffe automatisch übersetzen und in einen internationalen Code überführen können.

Höhere Rechnerbelastung muß ausgeglichen werden

Das Problem läßt sich mit Hilfe eines Conversion-Dictionary lösen. Dieses Dictionary enthält die Übersetzungen von Schlüsselbegriffen in mehreren Sprachen. Bei der Datenerfassung wird jeweils eine Feldeingabe auf Gültigkeit geprüft und intern in codierter Form abgelegt. Bei der Datenausgabe werden diese Werte wiederum in verschiedene Sprachen rücktransformiert.

Die bisher beschriebenen Programmtechniken bieten den Vorteil großer Flexibilität und leichter Ausbaubarkeit des Systems für weitere Sprachen. Der Nachteil besteht sicherlich in einer Mehrbelastung des Rechners für ganz normale Benutzerinteraktionen. Durch eine Reihe von Maßnahmen kann dieser Nachteil jedoch ausgeglichen werden.

So müssen beispielsweise Online-Zugriffe auf die Dictionaries während Benutzerinteraktionen vermieden werden. Daher sollte man häufig verwendete Literale von einem Applikations-Compiler in bereits aufbereiteter Form (zum Beispiel Überschriften zentriert) in einer Datei ablegen. Diese Literale werden dann beim Start einer Applikation in einen Balanced-Tree eingehängt, der einen schnellen Zugriff ermöglicht.

Schon für zwei Sprachen lohnt sich der Aufwand

Literale, die immer zusammen auftreten (zum Beispiel Menü-Überschriften, Instruktionen und Funktionstasten) werden zusammen gruppiert und erfordern dann nur einen Zugriff auf den Literal-Tree. Darüber hinaus lassen sich häufig benutzte Übersetzungen aus dem Conversion-Dictionary in einem Cache-Memory zwischenspeichern .

Die hier beschriebenen Techniken haben sich bei der Entwicklung eines Datenbanksystems bewährt, das 32 Sprachen simultan unterstützt. Der erhebliche Mehraufwand macht sich jedoch bereits bezahlt, wenn das gleiche System in nur zwei Sprachen verfügbar sein soll.