1 Einleitung Begriffsdefinition Kosten- / Nutzen-Betrachtung Fallbeispiele Embedded Java Showcase...

Transkript

1 Einleitung 3 Inhalt 1 Einleitung Begriffsdefinition Kosten- / Nutzen-Betrachtung Fallbeispiele Embedded Java Showcase Mars Climate Orbiter verglüht Leitstand für Druckmaschinen bei der manroland AG Festlegung des Umfangs der Software-Internationalisierung Sprachen und Übersetzungen Schriften und Schriftsysteme Layout der Bildschirmmasken Textausrichtung Texteingabe Hervorhebungen Sortierung Grafiken und Icons Farben Formate und Einheiten Interkulturelles Dialogdesign Simultane Mehrsprachendarstellung Bedienoberflächen ohne Text Software-Internationalisierung Internationalisierung in der Software-Entwicklung Anforderungen an die Software-Architektur Locale-Wechsel Werkzeuge zur Internationalisierung Internationale Nutzerstudien Wartung / Pflege / Service / Hotline Zusammenfassung... 66

2 4 Einleitung Anhang I Beispielprojekt Anhang II Glossar Anhang III Quellennachweis Anhang IV Weitere Informationen Anhang V Literaturempfehlungen Autorenverzeichnis... 81

3 Einleitung 5 1 Einleitung Die US-Investmentbank Goldman Sachs bestätigte 2007: Deutschland ist eines der am besten auf die Herausforderungen der Globalisierung vorbereiteten Länder und einer der größten Profiteure (Hoffman, 2007). Die Exporterfolge, insbesondere in der Investitionsgüterindustrie, spielen dabei eine herausragende Rolle. Erzeugnisse deutscher Hersteller sind international begehrt und werden in die ganze Welt geliefert. Rund 400 mittelständische Unternehmen sind mit ihren speziellen Produkten sogar absolute Weltmarktführer (Industrienet, 2008). Hersteller mit einem Exportanteil von 90% und mehr sind keine Seltenheit. Abbildung 1: Entwicklung der Absatzzahlen der MAN Roland Druckmaschinen AG in China Doch die anspruchsvollen internationalen Kunden erwarten nicht nur technische Präzision Made in Germany. Selbstbewusst fordern sie die Anpassung der Produkte an ihre lokalen Bedürfnisse und meinen dabei nicht nur die Übersetzung der Bedienoberfläche bzw. der technischen Dokumentation in ihre Sprache. Sie erwarten Produkte, die die regional vorherrschenden gesetzlichen und physikalischen Gegebenheiten, sowie die kulturelle Mentalität der Benutzer optimal berücksichtigen. Regionale Anbieter haben hier einen Vorteil: Sie sind, trotz teilweise technologischer Defizite, näher am Benutzer und dessen Mentalität dran. Aber auch die anderen großen Exportnationen setzen den deutschen Unternehmen zu. Nur kontinuierliche Anstrengungen der deutschen Hersteller stellen sicher, dass diese im globalen Wettrennen am Ende die Nase vorn haben. Im Zeitalter der fortgeschrittenen Digitalisierung ist die Schnittstelle zwischen dem Benutzer und dem Produkt (HMI hier: Human Machine Interface) ein wichtiger Faktor in diesem weltweiten Wettstreit. Ein an die lokalen Anforderungen angepasstes HMI steigert den Absatzerfolg deutlich (siehe Abbildung 1). Doch es gibt noch weitere Gründe, die für diese Anpassung sprechen: Erschließung neuer Märkte außerhalb der bekannten Absatzgebiete Verlagerung der Absatzmärkte (beispielsweise die Verlagerung verschiedener Produktionszweige immer weiter nach Osten) Konkurrenzdruck durch lokale oder internationale Anbieter, die ihre Produkte besser an die lokalen Anforderungen angepasst haben Verschiedensprachige Benutzer innerhalb der bekannten Absatzgebiete

4 6 Einleitung Für einen deutschen Ingenieur oder Software-Entwickler ist dies keine einfache Aufgabe. Wie soll er alle äußeren und kulturellen Einflussfaktoren der Regionen kennen, in die das Produkt später einmal ausgeliefert werden soll? Diese Aufgabe überlässt er besser den spezialisierten Lokalisierungsdienstleitern. Aber er kann das Produkt und speziell die zugrundeliegende Software fit für den internationalen Einsatz machen. Diese erlaubt dann eine rasche und mit geringem Aufwand verbundene Anpassung des HMI an eine andere Sprache. Der VDMA Arbeitskreis Software-Internationalisierung des Fachverbands Software hat sich dieser Herausforderung angenommen. Die Erfahrungen der Praxisexperten sind im vorliegenden Leitfaden zusammengefasst und können so auch anderen Unternehmen als Hilfestellung dienen. Über den Leitfaden Neben der Einleitung und Begriffsdefinition (Kapitel 1) wird in diesem Leitfaden anhand einiger Fallbeispiele dargestellt, welchen Einfluss die Software-Internationalisierung hat (Kapitel 2). Die Festlegung von Art und Umfang der Software-Internationalisierung durch Ermittlung des Lokalisierungsbedarfs wird im Kapitel 3 erläutert. In Kapitel 4 werden dann einige Hinweise zur Software-Internationalisierung aufgeführt. Der Anhang bietet neben Informationen zur Selbsthilfe auch eine kleine Beispielimplementierung. Wer soll den Leitfaden lesen? Er richtet sich an alle Unternehmen der Investitionsgüterindustrie, deren Produkte international vertrieben werden. Der Leitfaden soll Entwicklungs- und Projektleitern helfen, ihre Entwicklungsprozesse und die Softwarearchitektur so anzupassen, dass die spätere Lokalisierung der Produkte einfach und ökonomisch möglich ist. Zur Reihe Methoden und Verfahren des Fachverbandes Software Dieser Leitfaden ist in der Reihe Methoden und Verfahren des Fachverbandes Software entstanden, die dem Thema Softwareengineering eine breite Plattform bietet. Alle Elemente des Softwareentwicklungsprozesses sind speziell für den Maschinen- und Anlagenbau aufbereitet und werden somit konzentriert der Branche zur Verfügung gestellt. Dabei bauen die Publikationen aufeinander auf und ergänzen sich gegenseitig. Die beiden Leitfäden zur Anforderungsanalyse ( Methodenbeschreibung und Prozessbeschreibung, VDMA, 2002) bilden den Anfang der Reihe. Sowohl der vorliegende Leitfaden, als auch der Leitfaden Software-Ergonomie (VDMA, 2004) liefern zusammen mit der Anforderungsanalyse den Input für die Systemspezifikation. Der Leitfaden Systemspezifikation (VDMA, 2000) ist dabei Anleitung und Vorlage für die zu erstellende Spezifikation eines Entwicklungsvorhabens. Der Leitfaden Nearshore/Offshore (VDMA, 2005) ergänzt die Reihe um die Frage der Fremdvergabe von Entwicklungsleistungen und erörtert das Für und Wider. Das Thema Softwarequalitätssicherung (VDMA, 2006) wird in dem gleichnamigen Leitfaden ausgiebig behandelt. Dabei werden die einzelnen Entwicklungsstufen sehr genau hinsichtlich ihrer Auswirkungen auf die Qualität der Software unter die Lupe genommen. Mit dem Leitfaden Projekthandbuch (VDMA, 2001) werden auf die Strukturierung und die Werkzeuge für eine reibungslose Projektabwicklung eingegangen. Der Leitfaden für das Übersetzungsmanagement beschreibt die Vorgehensweise beim Übersetzen der technischen Dokumentation (VDMA, 2007).

5 Einleitung Begriffsdefinition Unter Softwarelokalisierung (L10N = LocalizatioN) wird die Anpassung von Software an die in einem bestimmten geographisch oder ethnisch umschriebenen Absatz- oder Nutzungsgebiet (Land, Region oder ethnische Gruppe) vorherrschenden "lokalen" sprachlichen und kulturellen Gegebenheiten verstanden. Beispiele für Lokalisierungen sind die Anpassung von: Sprache, Schrift, Leserichtung und Satzzeichen Text- und Zeicheneingaben (z.b. Tastatur, Eingabeeditoren für asiatische Sprachen) Farben und Icons Darstellungsformaten (z.b. Datum, Zeit, Zahlen, Adressen, Papiergrößen) Dabei ist zu beachten, dass neben den oben genannten Punkten auch lokale Gesetze, Regeln und kulturelle Mentalitäten zu berücksichtigen sind. Diese können zu ganz landesspezifischen Lösungen für das Softwareprodukt führen. Gängige Irrtümer der Software-Internationalisierung Bei der Software-Internationalisierung wird die Bedienoberfläche externalisiert, so dass die Software übersetzt werden kann. Übersetzer suchen die beste Formulierung in der Zielsprache aus. Die Software ist in Java programmiert und deshalb bereits internationalisiert. Mein Produkt ist internationalisiert, weil es Unicode unterstützt. Mein Produkt basiert auf Open Source. Aus diesem Grund betrifft uns die Software- Internationalisierung nicht. Alle unsere Angestellten sprechen Englisch. Aus diesem Grund benötigen wir für unser internes Tool nur Englisch. Bedienoberflächen für Administratoren benötigen keine Internationalisierung. Wir werden dieses Produkt / Modul / Komponente niemals lokalisieren. Deshalb benötigen wir auch keine Software-Internationalisierung. Wir haben die Software-Internationalisierung in der letzten Version realisiert. Wir sind also fertig. Wenn etwas falsch ist, dann wird unser Kunde uns das mitteilen. Mein Produkt ist internationalisiert, weil es Japanisch unterstützt. Die Software-Internationalisierung wird implementiert, nachdem die Basis-Software durch eine andere Gruppe von Entwicklern fertig gestellt wurde. Software-Internationalisierung wird nur in einer Softwareentwicklungsabteilung benötigt. Es ist sinnvoll, dass bereits in der Konzeptionsphase die Voraussetzungen zur späteren Lokalisierung geschaffen werden. Doch erst mit einer vorhergehenden Internationalisierung der Software (I18N = InternationalizatioN) die bereits in der Konzeptionsphase bedacht werden muss, können die Voraussetzungen für eine spätere Lokalisierung geschaffen werden. Die spätere Anpassung des Produktes an die landesspezifischen Gegebenheiten sollte einfach zu ermöglichen sein, idealerweise per Knopfdruck.

6 Fallbeispiele 11 2 Fallbeispiele 2.1 Embedded Java Showcase In der Software-Internationalisierung tauchen Herausforderungen oft unerwartet auf. Der Showcase balance war von Anfang an für verschiedene Sprachversionen vorgesehen. Die ersten Sprachversionen waren Deutsch und Englisch. Dabei gab es keinerlei Umsetzungsprobleme, weder in der Übersetzung noch im Zeichensatz oder im Layout. Die dritte und vierte Sprachversion waren Chinesisch und Japanisch mit den erwarteten zusätzlichen Entwicklungsaufwänden. Eine konkrete Anpassungsschwierigkeit ergab sich aber dennoch: Der Zeichensatz war zu klein. Die komplexeren asiatischen Kanji- Zeichen waren unleserlich geworden während die etwas einfacheren Hiragana- und Katakana- Zeichen der japanischen Schrift durchaus noch akzeptabel zu erkennen waren. Die Größe musste daher von 11pt auf 15pt angehoben werden (siehe Abbildung 2). Abbildung 2: Die Schriftgröße muss bei komplexen Kanji-Zeichen erhöht werden (macio GmbH, 2007) Die von Personen des Testteams (Native Speaker, Chinesisch) gewünschte farbliche Anpassung für den asiatischen Raum wurde in diesem Fall nicht berücksichtigt, da sie dem Design-Gesamtkonzept deutlich widersprach. Solche Entscheidungen müssen allerdings gut abgewogen werden. Hier stand das einheitliche Look & Feel, der Wiedererkennungswert im Vordergrund. Im Einzelfall ist natürlich zu prüfen, ob durch eine farbliche Anpassung die Usability für den Nutzer eher verbessert wird, als durch den Vorteil einer einheitlichen Erscheinung für die Bedienung.

7 12 Fallbeispiele 2.2 Mars Climate Orbiter verglüht Der Mars Climate Orbiter wurde 1998 als erster Teil einer Tandem-Marsmission ins All geschickt. Er sollte als Relaisstation für den Funkkontakt des Mars Polar Lander und nachfolgender Mars- Bodensonden mit der Erde dienen. Des Weiteren sollte er auch der erste interplanetare Wettersatellit werden. Doch die Mission scheiterte beim Eintritt des Orbiter in die Marsumlaufbahn und war somit ein Totalverlust für die NASA. Insgesamt 125 Millionen US-Dollar wurden sprichwörtlich in Luft aufgelöst. Daraufhin wurde die Katastrophe vom eigens eingerichteten Mars Climate Orbiter Mission Failure Board untersucht. Als Schlüsselfehler stellte der Ausschuss eine Verwechslung zwischen metrischen und englischen Maßeinheiten fest. Die Herstellerfirma Lockheed Martin ging bei der Konstruktion von amerikanischen Maßeinheiten aus, sodass der Orbiter Eingaben in Pound Force erwartete. Das Navigationsteam übermittelte die Steuerbefehle jedoch in der für die Wissenschaft international üblichen Einheit Newton. Hieraus ergab sich in der Folge eine Diskrepanz um den Faktor 4,45 zwischen den angenommenen Steuerbefehlen und den tatsächlich erfolgten Manövern. Sicherlich wären die falschen Einheiten aufgefallen, wenn man in der Eingabemaske die Einheiten mit angegeben hätte oder diese zwingend hätte angeben müssen. Insofern offenbarte sich dabei auch ein software-ergonomischer Mangel des Systems. Die Navigationsfehler hielten sich die ganze Reise zum Mars über in Grenzen, sodass dieser Fehler bis zuletzt nicht bemerkt oder korrigiert wurde. Durch den im Vergleich zur Missionsplanung 170 km tieferen Eintritt in den Marsorbit verglühte der Orbiter in der Marsatmosphäre. Damit schlug schließlich auch die Mission des Landers fehl. 2.3 Leitstand für Druckmaschinen bei der manroland AG Ab 1988 entwickelte die heutige manroland AG einen Leitstand für ihre Druckmaschinen. Da das Unternehmen sehr exportlastig aufgestellt ist und dieser Leitstand unter MS-DOS (Programmiersprache Modula 2) entwickelt wurde, stand von vorn herein fest, die Oberflächen in den wichtigsten europäischen Landesprachen anzubieten. Dazu gehörten u.a. Englisch, Französisch und Spanisch. Insgesamt waren 1990 elf Sprachen im Lieferumfang der Druckmaschinen-Software enthalten. Diese Sprachen waren aufgrund der Tatsache, dass die ANSI Codepage 1252 ein Standard des Turbo-Pascal- Grafiktreibers war, leicht im Modula 2 System integrierbar. Mit wachsendem Druck des Wettbewerbes wurden weitere Sprachen nachimplementiert (siehe Tabelle 2). Der erste wichtigste Internationalisierungsschritt in dieser Software ereignete sich Nicht zuletzt durch das Angebot einer japanischen Oberfläche der Druckmaschinensoftware wurde der japanische Markt nun stärker erschlossen. Allerdings war dafür auch ein spezieller Font-Treiber notwendig, um die japanische Oberfläche zu ermöglichen. Vorausschauend wurde er so implementiert, dass der gesamte CJK 1 -Sprachraum abdeckbar wäre. Dabei war die Online-Sprachumschaltung ein wichtiges Feature. Sie erlaubte dem Service, bei laufender Maschine, die verschiedenen installierten Sprachen je nach Notwendigkeit zu aktivieren. Das erleichterte anstehende Servicearbeiten. 1 CJK -Chinesisch, Japanisch, Koreanisch

8 Fallbeispiele 13 Sprache(n) Zeit Gründe Bemerkung Wichtige europäische Sprachen (z.b. Englisch, Französisch) Bis 1990 Absatz in den entsprechenden Ländern Alle Menü- und Buttontexte wurden übersetzt Japanisch 1991 Potenzieller Markt in Japan Zusätzlich wurden auch die Hilfetexte in Japanisch angezeigt; Neuer Grafik-Mode (SVGA) Polnisch, Griechisch, Türkisch Chinesisch (ZHH)[=Chinese Hong Kong] Tschechisch, Slowakisch, Türkisch Thai, Russisch, Ungarisch, Indonesisch 1991 Erschließung neuer Märkte Ein Neuer 8-Bit Font-Treiber war nötig 1993 Verkaufsinitiative Complex Chinese 1994 Zum Teil durch EU-Richtlinien gefordert 1997 Neue Märkte erschließen Koreanisch 1998 Wettbewerb Kroatisch, Estnisch, Lettisch, Litauisch, Slowenisch Chinesisch (CHS) [=Chinese Simplified] 2003 Zum Teil durch EU-Richtlinien gefordert 2005 Wettbewerb Complex Chinese wird vollständig gegen Simplified Chinese ersetzt Tabelle 2: Die Evolution der Lokalisierung bei der manroland AG Abbildung 3: EGA-Bildschirm (640x350x16 Farben) zur Darstellung der elf europäischen 8-Bit-Sprachen (bis 1990)

9 16 Festlegung des Umfangs der Software-Internationalisierung 3 Festlegung des Umfangs der Software-Internationalisierung Zu Beginn des Internationalisierungsprozesses muss entschieden werden, welche Bestandteile lokalisiert werden sollen. Auf der Grundlage dieser Festlegung können dann entsprechende Maßnahmen zur Software-Internationalisierung getroffen werden. Nachfolgend wird der Lokalisierungsbedarf für folgende Elemente einer Bedienoberfläche erläutert: Sprachen und Übersetzungen Schriften und Schriftsysteme Layout der Bildschirmmasken Textausrichtung Texteingaben Hervorhebungen Sortierung Grafiken und Icons Farben Formate und Einheiten Ebenfalls muss entschieden werden, ob eine simultane Darstellung mehrerer Sprachen auf der Bedienoberfläche (siehe Kapitel 3.12) erforderlich ist. Eine Bedienoberfläche, die vollständig auf Text verzichtet, hat ebenso spezielle Anforderungen (siehe Kapitel 3.13). 3.1 Sprachen und Übersetzungen Es werden heute etwa verschiedene Sprachen gesprochen. Davon ist allerdings etwa die Hälfte vom Aussterben bedroht (Wikipedia, 2009). Andere Quellen sprechen von unterschiedlichen Sprachen Wahl der Quellsprache Um ein Softwareprodukt bereits von Anfang an für den internationalen Markt zugänglich zu machen, wird in Deutschland häufig in englischer Sprache entwickelt. Dieses Verfahren bringt jedoch zwei Nachteile mit sich, die die Qualität des Produktes negativ beeinflussen. Zum einen sind Softwareentwickler keine Autoren und man kann von ihnen nicht die konsistente Verwendung von Terminologie oder Kenntnisse über Standardformulierungen und Schreibstil erwarten. Zum anderen haben nichtmuttersprachliche Softwareentwickler oft nur technische Englischkenntnisse, die für die Kunden eines Produktes zuweilen zu eher belustigenden Resultaten führen. Die Qualität einer Übersetzung ist stark von der Güte der Texte der Quellsprache abhängig. Nicht selten wird aber erst zu Beginn der Lokalisierung von den Übersetzern festgestellt, wie schlecht die Qualität in der Quellsprache ist. Häufig behelfen sich die Unternehmen dann mit einer Vorabübersetzung von Entwicklerenglisch in korrektes Englisch, die dann auch die Basis für die Übersetzung in weitere Sprachen bildet. Wer die Qualität und Konsistenz der Quellsprache von Anfang an sicherstellen will, sollte in der Muttersprache entwickeln lassen und kann dem Entwicklungsteam zusätzlich einen technischen Autor (z.b. aus der Dokumentationsabteilung) beistellen. Dieser ist in der Lage bereits während der Entwicklung

10 Festlegung des Umfangs der Software-Internationalisierung 17 die Einhaltung konsistenter Terminologie zu überprüfen und einen standardisierten Schreibstil zu verwenden. Ein weiterer Vorteil ist, dass Dokumentationen wie Handbücher und Online- Hilfe zeitnah zur Produktentwicklung erstellt werden Verwendung von Terminologie Die konsistente Verwendung von Terminologie innerhalb des gesamten Produktes ist eine wichtige Voraussetzung für die Lokalisierung. Es soll erreicht werden, dass in der Programmoberfläche, in der Online-Hilfe, den Handbüchern und auf den Produkt-Webseiten die gleichen Benennungen für die gleichen Begriffe verwendet werden. Dazu sind die jeweiligen Fachwörter vorab festzulegen und auszuwählen. Die Einführung eines Terminologie-Managements in einem Unternehmen ist eine gute Investition. Bei Produkten, die von vielen Mitarbeitern erstellt werden, wird sich diese Investition sehr schnell in gesteigerter Effizienz bei der Auswahl der richtigen Fachwörter und in verringerten Kosten für die Übersetzung der Produkte niederschlagen. Damit erhöht sich auch die Qualität des Gesamtproduktes Spezifische Eigenschaften verschiedener Sprachen Die Grammatik in der Zielsprache kann eine Vertauschung von Platzhaltern innerhalb einer Meldung notwendig machen. Es sollten also Formatierungsfunktionen des API 2 verwendet werden, die eine Vertauschung der Platzhalter erlauben. Beim Einsatz von Platzhaltern in Meldungen, die durch Substantive ersetzt werden, benötigt der Ü- bersetzer auch Informationen über den Genus des Substantivs, um die Verben korrekt übersetzen zu können. Werden in einen Platzhalter verschiedene Substantive eingesetzt, kann dies dazu führen, dass eine Übersetzung immer falsch ist. In diesem Fall empfiehlt es sich, mehrere Meldungen zu generieren. Fragmentierte Texte, die erst zur Laufzeit zusammengesetzt werden, sind nur schwer zu übersetzen und sollten ganz vermieden werden. Denn der Übersetzer ist meistens nicht in der Lage zu erkennen, welche Textteile zusammengesetzt werden. Deutsch Polnisch 1 Datei 1 plik 2 Dateien (2 bis unendlich) 2 pliki (2 bis 4) Tabelle 3: Übersicht Pluralfälle im Polnischen 5 plików (5 bis unendlich) In manchen Sprachen treten sogar mehrere Pluralfälle auf (siehe Tabelle 3). Daher müssen Methoden entwickelt werden, die bei Meldungen mit Platzhaltern ebenfalls sinnvolle Übersetzungen ermöglichen. Checkliste für Sprachen und Übersetzungen 1. Steht die Quellsprache fest? 2. Wird eine Terminologie bei der Erstellung der Quellsprachentexte verwendet? 3. Werden Platzhalter verwendet und können diese bei der Übersetzung in der Reihenfolge vertauscht werden? 2 API Application Programming Interface (Programmierschnittstelle)

11 18 Festlegung des Umfangs der Software-Internationalisierung 3.2 Schriften und Schriftsysteme Eine Schrift ist ein abstraktes, vereinheitlichtes, zusammenhängendes Schreibsystem, bestehend aus Buchstaben, Zahlen, Interpunktionen, Symbolen, etc. Eine Schrift kann dabei eine oder mehrere Sprachen unterstützen (z.b. einsprachig: armenische Schrift; mehrsprachig: lateinische Schrift). Sprachen können auch durch verschiedene Schriften abgebildet werden (z.b. Türkisch kann in arabischer oder lateinischer Schrift dargestellt werden) (Brekle, 2005). Im Folgenden werden anhand pragmatischer Erfahrungswerte die geschriebenen Sprachen der Welt in Schriftsysteme eingeteilt. Für die Sprachen innerhalb eines Schriftsystems sind die gleichen technischen Komponenten für die Darstellung der Zeichen notwendig. Die Gestaltung der Oberfläche muss hingegen für jedes Land innerhalb der Schriftsysteme gesondert geprüft werden. Die Schriften unterscheiden sich durch: Verwendete Zeichen Zeichensatzumfang Schreibrichtung (links-nach-rechts, rechts-nach-links) Formate, Zahlen, Datum Komplexe Zeichenausgabe ( Layout-Engine notwendig) Zeicheneingabemethoden Übersicht Die Einteilung der Schriftsysteme erfolgt aus Sicht der deutschen / westeuropäischen Entwickler. Dabei können weltweit sechs verschiedene Schriftsysteme gebildet werden (siehe Abbildung 7). Abbildung 7: Verteilung der Schriftsysteme (DCC GmbH, 2009)

12 Software-Internationalisierung 53 4 Software-Internationalisierung Aufgrund des Einsatzes von Computern im internationalen Maschinenbau steigt zunehmend der Bedarf an Softwarelösungen, die nicht nur an die Sprache, sondern auch an die kulturbedingten Bedürfnisse der Benutzer angepasst sind. Die Übersetzung der im Produkt enthaltenen Texte reicht dafür in der Regel nicht aus. Erfolgreich auf dem internationalen Markt kann das Produkt nur sein, wenn es beim Kunden auch vertraute Assoziationen weckt und positiv konnotiert wird. Die Missachtung dieser Gesichtspunkte kann zu einer völligen Ablehnung des Produkts führen. Die Produktanpassung erfolgt über den gesamten Produktentwicklungszyklus und besteht aus Software-Internationalisierung und Software-Lokalisierung (siehe Abbildung 36). Abbildung 36: Globaler Produktentwicklungszyklus (ecolotrain, 2009) Für den globalen Markt werden Produkte so entwickelt, dass sie leicht an die lokalen Bedürfnisse angepasst werden können Dabei sind das komplette Softwarepaket sowie unter Umständen auch die Hardware einer Maschine betroffen (z.b. Speichererweiterung aufgrund neuer Fonts). Dazu gehören sowohl Aspekte, welche die HMI direkt betreffen, wie die Bedienoberfläche mit ihren Komponenten (z.b. Dialogboxen, Menüs oder Meldungen aller Art) als auch indirekte Faktoren wie die Dokumentation (z.b. technische Beschreibungen, Online-Hilfe, Benutzerhandbücher etc.). Um eine vollständige kulturspezifische Benutzerfreundlichkeit eines Softwareproduktes zu erreichen, ist zusätzlich auch die Anpassung der Programmbausteine notwendig, die den Ebenen der ungeschriebenen und unbewussten Regeln zugeordnet werden können. Dazu zählen z.b. das Navigationskonzept, die Strukturierung von Informationen oder die Formulierung von Systemmeldungen. Die Software-Internationalisierung erfolgt historisch gewachsen und beinahe deckungsgleich entsprechend des Aufwandes in mehreren Stufen (Sturm, 2002). Auf der technischen Ebene wird zunächst die Infrastruktur angepasst (z.b. Stromanschluss). Anschließend erfolgt die Sprachanpassung durch den Einsatz entsprechender Fonts und einer möglichen Umstellung der gesamten Softwarearchitektur auf Unicode. Auf der nächsten Ebene sind die kulturellen Anpassungen vorzunehmen

13 54 Software-Internationalisierung (z.b. Farb- und Layout-Konzept, Währungsformate etc.). Schließlich können auf der kognitiven Ebene auch auf den ersten Blick versteckte Aspekte im Navigations- und Interaktionsdesign wie z.b. das Reaktions- und Informationspräsentationsverhalten des Systems an den Denkstil des Benutzers angepasst werden (Heimgärtner, 2007). 4.1 Internationalisierung in der Softwareentwicklung Im Folgenden wird der Softwareentwicklungsprozess mit Hinblick auf mögliche Anforderungen an die lokalisierbare Software beschrieben. Eine detaillierte Darstellung der zugehörigen Aktivitäten und Dokumente befindet sich im Leitfaden Softwarequalitätssicherung (VDMA, 2006). Ein Softwareentwicklungsprozess beschreibt den systematischen Vorgang der Softwareentwicklung. Unterschiedliche Modelle wurden entwickelt, um einzelne Phasen des Entwicklungsprozesses voneinander abzugrenzen und zueinander in zeitliche und hierarchische Abhängigkeit zu bringen. Grundlage aller Modelle sind die Kernprozesse eines Entwicklungsprozesses: Planung und Analyse, Lösungsentwurf, Realisierung, Systemintegration, Abnahme und Validierung / Verifikation. Die Software-Internationalisierung ist ein Aspekt, der in jeder Phase eines gesunden Entwicklungsprozesses berücksichtigt werden sollte, unabhängig vom gewählten Entwicklungsmodell. Die Phasen des Softwareentwicklungsprozesses (siehe Abbildung 37) orientieren sich am Leitfaden Softwarequalitätssicherung (VDMA, 2006). Die Anzahl und Bezeichnung der Phasen ist an dieser Stelle nur beispielhaft veranschaulicht und kann den jeweiligen Unternehmensgegebenheiten angepasst werden. Abbildung 37: Internationalisierungsaspekte sind in jeder Phase des Softwareentwicklungsprozesses zu berücksichtigen ebenso wie spezifische lokale Ausprägungen

14 Software-Internationalisierung Initialphase Marketing und Vertrieb analysieren die Chancen, Kosten und Risiken für die Erschließung neuer Märkte, die sich durch die Internationalisierung eines Produkts ergeben. Neben den einmaligen Entwicklungskosten müssen auch die Folgekosten für Test und Pflege von zusätzlichen Sprachen berücksichtigt werden. Nach Abschluss der Analyse kann die grobe Projektplanung der Softwareentwicklung beginnen. Die Software-Internationalisierung benötigt ebenfalls Ressourcen. Im Projektplan sollte außerdem der erhöhte Testaufwand für die Internationalisierung berücksichtigt werden. Zusätzlich sind geeignete Teststrategien für die umgesetzten Locales zu entwickeln. In der Budgetplanung können die Kosten für Internationalisierungsmaßnahmen bereits eingeplant werden. Eine Risikobewertung ergänzt schließlich die angepasste Planung Anforderungsspezifikation und Lösungsspezifikation Bei der Planung einer Software wird idealerweise schon im Lastenheft beschrieben, welche Sprachen unterstützt werden sollen und in welchen Ländern die Software später zum Einsatz kommt. Insbesondere ist zu klären, ob eine Sprachumschaltung zur Laufzeit vorgesehen ist oder ob die Software in fertigen Länderversionen ausgeliefert wird. Weiterhin ist der Umfang der Lokalisierung festzulegen. Müssen alle zugehörigen Dokumente lokalisiert werden (auch Online-Hilfe, technische Dokumentation und Serviceunterlagen) oder genügt eine Lokalisierung der Bedienoberfläche der Software? Möglichst frühzeitig sollten auch die Qualitätsanforderungen an die Software ermittelt werden. Diese umfasst die Aspekte Funktionalität, Zuverlässigkeit, Benutzerfreundlichkeit, Effizienz, Wartbarkeit und Portierbarkeit. Für alle geforderten Aspekte müssen Prüfkriterien festgelegt werden, sonst ist später keine objektive Verifikation möglich. Zur Sammlung von Anforderungen bietet sich die VDMA-Vorlage Systemspezifikation an (VDMA, 2000). Im Rahmen der Qualitätssicherung können auch Szenarien und Use-Cases zur Abdeckung aller geplanten Einsatzgebiete entworfen werden oder Key-User für interne Reviews der Spezifikation definiert werden. Hintergrundinformation An dieser Stelle einige Beispiele aus Kapitel 3: Für die zu unterstützenden Sprachen ist zu klären, ob noch weitere Schriften und Schriftsysteme benötigt werden, um sicherzustellen, dass alle Zeichen durch das System unterstützt werden. Des Weiteren ist zu prüfen, ob Fehlermeldungen oder Installationsanweisungen eventuell in für den Maschinenführer unverständlichen Sprachen erscheinen. Die Eingabemedien sollten ebenso Gegenstand der Betrachtung sein. Für Hardware-Tastaturen sind eventuell spezielle Tastaturbelegungen notwendig, um die erforderlichen Zeichen eingeben zu können. Touchscreen-Tastaturen ( OSK) müssen gegebenenfalls sogar neu entwickelt werden. Bei asiatischen Sprachen sind Eingabeeditoren für die Auswahl der Zeichen unentbehrlich. Die arabischen Sprachen erfordern sowohl eine korrekte Zeichenanzeige von rechts nach links als auch eine korrekte Schreibweise der Zeichen. In diesem Fall ist eine so genannte Layout-Engine unerlässlich. Entweder ist sie im Betriebssystem bereits integriert oder sie muss ergänzt werden. Bei Verwendung externer Lokalisierungswerkzeuge ist es wichtig, deren Schnittstellen genau zu spezifizieren.