Software-Lokalisierung, Teil 1

Anpassungen bei der Internationalisierung einplanen

| Autor / Redakteur: Christian Rentrop / Stephan Augsten

Im Projektmanagement sollte man sich frühzeitig darüber klar sein, ob eine Software später auch lokalisiert werden soll.
Im Projektmanagement sollte man sich frühzeitig darüber klar sein, ob eine Software später auch lokalisiert werden soll. (Bild: geralt – Pixabay.com / CC0)

Bei der Software-Entwicklung ist eine Internationalisierung und Lokalisierung nicht selten aufwändig und kostenintensiv: Zahlreiche Kultur- und Sprachräume wollen bedient werden. Daher ist es sinnvoll, die Anpassung an andere Märkte möglichst einfach zu gestalten.

Bei der Planung eines Softwareprojekts kommen Projektmanager und Entwickler schnell an den Punkt, dass sich die Frage nach einer Internationalisierung und Lokalisierung stellt. Sei es, weil das Produkt oder die Plattform von vornherein in bestimmten Märkten eingesetzt werden soll. Sei es, weil eine spätere Verwendung andernorts, in anderen Kulturräumen und Sprachen, nicht von vornherein ausgeschlossen werden soll.

Aller Globalisierung zum Trotz gibt es nämlich zum Teil massive Unterschiede zwischen verschiedenen Märkten im Hinblick auf Design und Sprache. Gerade Web- und App-Entwickler müssen hier vom ersten Moment an flexibel bleiben – schließlich ist es nicht auszuschließen, dass das Produkt zu einem späteren Zeitpunkt auch global eingesetzt wird.

Internationalisierung vs. Lokalisierung

Grundsätzlich wird zwischen Internationalisierung und Lokalisierung unterschieden. Die Internationalisierung ist dabei der Begriff, der für Entwickler besonders relevant ist: Sie müssen bei der Entwicklung von Anfang an dafür sorgen, dass sich die Software später mit möglichst geringem Aufwand und ohne Quellcode-Anpassungen auf diverse Märkte bzw. Nutzungsgebiete und Benutzergruppen ausrichten, also lokalisieren lässt. Statt fest in den Quellcode.

Hierzu zählt zum Beispiel die Trennung von Quellcode und Beschreibungs- sowie Hilfetexten, die später variabel in Abhängigkeit der gewählten Sprache eingebunden werden. Diese Trennung stellt von vornherein gewisse Ansprüche an GUI-Elemente und die Benutzeroberfläche. Die Lokalisierung ohne vorhergehende Internationalisierung ist dementsprechend aufwändig.

Internationalisierung immer empfehlenswert

Vor der eigentlichen Entwicklung sollte also zunächst genau geprüft werden, ob eine spätere Lokalisierung des Produkts überhaupt vonnöten ist und ob dementsprechend für eine Internationalisierung gesorgt werden muss. Denn die Entwicklung internationalisierten Codes ist gegebenenfalls aufwändiger als die Beschränkung auf eine Sprache.

Allerdings empfiehlt es sich selbst bei der Entwicklung von Nischen- oder Steuersoftware für einen bestimmten Markt oder Auftraggeber immer, eine Internationalisierung einzuplanen. Schließlich könnte es mittelfristig doch sein, dass das Produkt – oder ein verwandtes, das auf den gleichen Code aufbaut – doch einer Lokalisierung bedarf. Schließlich könnte schon eine Empfehlung des letzten Auftraggebers Kunden mit anderen Anforderungen an die Lokalisierung bringen. Dementsprechend ist die Internationalisierung zwar mit höherem Aufwand verbunden. Der allerdings macht sich bezahlt, sobald eine Lokalisierung vonnöten ist.

Am Anfang steht die Marktanalyse

Da sich die Lokalisierung später auf zahlreiche Faktoren auswirkt, darunter vor allem die GUI-Gestaltung und die Wahl von unterstützenden Elementen wie Farben, Formen, Bildern und Sounds, ist es vor dem Schreiben der ersten Zeile Code daher auch sinnvoll, zunächst eine kleine Marktanalyse durchzuführen.

Ist eine Lokalisierung absehbar – und wenn ja für welche Märkte? Denn das grundsätzliche Design einer GUI kann sich schon dann schnell ändern, wenn zum Beispiel verschiedene Schriften (etwa Lateinisch, Kyrillisch, Chinesisch, Arabisch...) und damit Schreib- und damit auch Leserichtungen berücksichtigt werden müssen. Zudem besitzen Formulierungen in verschiedenen Sprachen oft verschiedene Längen, was zum Beispiel eine gewisse Flexibilität beim Design der Schaltflächen voraussetzt.

Weitere Faktoren sind Datumsangaben, Maßeinheiten, Sortierungsoptionen, Umlaute und Zeichensätze, die von Sprache zu Sprache sehr unterschiedliche sein können. Und dann sind da noch kulturelle und juristische Faktoren, die bei der Wahl von Farben, Formen und Bildern eine Rolle spielen.

Beschränkung auf Englisch kann sinnvoll sein

Ein Beispiel: Im Französischen und Deutschen sind Formulierungen oft länger als im Englischen, was trotz gleicher Schriftart und Schriftrichtung das Menüdesign beeinflussen kann. Wird die Sprachwahl weiter gefasst, muss gegebenenfalls auch die Bidirektionalität der Schriften berücksichtigt werden. So wird im Arabischen oder Hebräischen von rechts nach links gelesen, nicht von links nach rechts. Für die Internationalisierung bedeutet das, dass Elemente, die Text enthalten, entsprechend geplant werden müssen.

Es gibt allerdings auch Gegenbeispiele: So kann es in vielen Fällen reichen, sich auf die „Weltsprache“ Englisch zu beschränken. Etwa dann, wenn die voraussichtliche Zielgruppe diese Lingua Franca der Ingenieurswissenschaften beherrscht. Das ist zum Beispiel bei Steuersystemen für Anlagen oder Industriemaschinen der Fall, wo nun einmal Ingenieure mit der Bedienung befasst sind, die Englisch als „Berufsmuttersprache“ lesen und verstehen müssen.

Verschiedene Facetten der Lokalisierung

Ein anderes Beispiel sind Anwendungen für den Consumer-Bereich, die keine hohen Anforderungen an die Sprachkenntnisse des Anwenders stellen. So sind manche Videospiele und viele einfache Apps nur sehr eingeschränkt lokalisiert. Allerdings müssen hier oft rechtliche und kulturelle Faktoren beachtet werden, etwa die Gesetzgebung im Hinblick auf Gewaltdarstellung oder Nacktheit.

Zwar setzen die Entwickler auf Englisch als Bediensprache, sprachliche Lokalisierungen werden, wenn überhaupt, erst zu einem späteren Zeitpunkt nachgeschoben. Dennoch ist eine Internationalisierung vonnöten, um das Videospiel schnell an zusätzliche Märkte anpassen zu können. Statt des Textes wird hier dann jedoch die Grafik lokalisiert.

Ein wesentlich extremeres Beispiel für Lokalisierung ist Produktivitäts-Software: Schon bei einer Textverarbeitung wird vorausgesetzt, dass diese in der jeweiligen Muttersprache verwendet werden kann. Sind noch dazu rechtliche Aspekte involviert – etwa bei Software für Steuerfachleute – sollte die Internationalisierung vom ersten Moment an im Auge behalten werden.

Schnittstellen schaffen und Lokalisierungen ermöglichen

Unter dem Strich gibt es nur wenige Szenarien, in denen es nicht sinnvoll ist, auf eine Internationalisierung mit Hinblick auf eine Lokalisierung zu setzen. Mit der Größe der Zielgruppe und der Zahl der Märkte sowie den Anwendungsszenarien wächst der Bedarf, lokalisierte Fassungen der Software zu verwenden.

Entwickler sollten dementsprechend vom ersten Moment an dafür sorgen, dass durch Internationalisierung Schnittstellen zur Lokalisierung geschaffen werden, die eine Anpassung an neue Märkte ohne großen Aufwand ermöglichen. Der Verzicht auf Internationalisierung bedeutet im Zweifel auch den Verzicht auf Chancen – selbst wenn eine spätere Lokalisierung gar nicht nötig sein sollte.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44863389 / Projektmanagement)