LOKALISIERUNG MODERNER SOFTWAREANWENDUNGEN: DER SCHLÜSSEL ZUM GLOBALEN MARKT

Transkript

1 mehr zum thema: von achim herrmann LOKALISIERUNG MODERNER SOFTWAREANWENDUNGEN: DER SCHLÜSSEL ZUM GLOBALEN MARKT der autor Die Einführung von Produkten auf ausländischen Märkten ist gerade in unserer exportorientierten Wirtschaft eine der wichtigsten Herausforderungen einer immer stärker globalisierten Welt. Entscheidend für den Erfolg auf dem globalen Markt ist es, den Kunden in seiner jeweiligen regionalen Sprache anzusprechen. Damit werden Übersetzung und Lokalisierung zu kritischen Faktoren für den internationalen Erfolg eines Unternehmens. Die Lokalisierung von Softwareanwendungen ist eine Aufgabe, die von einem meist räumlich getrennten Spezialistenteam aus Entwicklern, Lokalisierungsmanagern, technischen Autoren, Übersetzern und Testern durchgeführt wird. Der Artikel beschreibt einige Aspekte der Internationalisierung von Software und liefert allgemeine Hinweise, wie der Lokalisierungsprozess effektiv organisiert und effizient durchgeführt werden kann. Achim Herrmann ( ist Geschäftsführer der PASS Engineering GmbH. Er hat langjährige Erfahrung in der Softwareentwicklung und beschäftigt sich seit vor allem mit der Lokalisierung von Software. Internationalisierung Die Internationalisierung (I18N) 1 ) umfasst alle Aktivitäten während der Entwicklung, die sicherstellen, dass ein Produkt einfach an verschiedene landesspezifische Gegebenheiten (auch Locales genannt) angepasst werden kann. Lokalisierung (L10N) 2 ) umfasst alle Aktivitäten, mit denen ein Produkt an ein spezifisches Locale angepasst wird. Dazu gehören Übersetzung, Berücksichtigung des kulturellen Kontextes und der Marktanforderungen. Wer sich erst nach der Fertigstellung seines Produkts um Internationalisierung und Lokalisierung kümmert, der wird Budgets und Termine nicht einhalten können. Häufig wird ein Produkt aber erst nach einem Erfolg im Heimatmarkt in ausländischen Märkten eingeführt. Wenn das Management es versäumt hat, diese Anforderung zu Beginn der Entwicklung anzusprechen, kann es vorkommen, dass die Internationalisierung der Software nachträglich gemacht werden muss. Das ist teuer und sehr zeitaufwändig. Auch bei renommierten Unternehmen sind Lokalisierungsprojekte gescheitert, weil z. B. alle Texte der Software im Quellcode hart kodiert waren. Nach der Erstellung von Budgets und Zeitplänen für eine nachträgliche Internationalisierung und Lokalisierung der Software durch die Entwicklung ist so manches Projekt durch das Management gestoppt worden. 1 branchenübliche Abkürzung für den englischen Begriff Internationalization der häufig auch im Internet verwendet wird. Sie besteht aus den Anfangs- und Endbuchstaben sowie der Anzahl dazwischen liegender Buchstaben. 2 ) dito für Localization Internationalisierung und Lokalisierung sind grundlegende Produktanforderungen und entsprechend müssen sie innerhalb des Entwicklungszyklus eines Produkts behandelt werden. Eine enge Zusammenarbeit zwischen Entwickler, Lokalisierungsmanagern und Übersetzern verringert die Kosten der Lokalisierung und beschleunigt die Fertigstellung der übersetzten Softwareversionen. Daraus lassen sich die folgenden Anforderungen an das Produktmanagement und die Entwicklung ableiten: Das Management muss vor Beginn der Entwicklung die Zielsprachen festlegen und zusätzliche Ressourcen für Berater, Qualitätssicherung während der Entwicklung, erhöhten Implementierungsaufwand, Lokalisierungsaufwand und zusätzlichen Testaufwand einplanen. Die Entwickler müssen die Internationalisierung als ernst zu nehmende Aufgabe betrachten. Leider wird das Thema Internationalisierung von Software in der Ausbildung von Informatikern und Anwendungsentwicklern zur Zeit noch sehr stiefmütterlich behandelt. Internationalisierungsmethoden und Lokalisierungskonzepte sind zu prüfen, festzulegen und die entsprechenden Arbeitsprozesse sind vor Beginn der Entwicklung zu testen. Dazu gehört auch die richtige Auswahl von Entwicklungswerkzeugen und Bibliotheken. Es sind Spezifikationen und ein Design für die Internationalisierung zu erstellen, die nach der Implementierung zu testen sind. Kerstin Dittert beschreibt am Beispiel der Programmiersprache Java grundlegende Regeln der Internationalisierung von Software (vgl. [Dit01]). Um ein international vermarkt- bares Produkt zu erhalten, muss die Softwareentwicklung ein Design erstellen und implementieren, das für alle Zielmärkte geeignet ist. Die folgende Liste zeigt Eigenschaften, die in verschiedenen Ländern unterschiedlich gehandhabt werden und bei der Internationalisierung der Software zu beachten sind: Schreibsystem und Sortierung von Texten Währung, Kalender und Zeitzonen Gewichte und geografische Positionen Darstellung von Postleitzahlensystem und Telefonnummern Steuersätze Geschäftspraktiken rechtliche Bestimmungen (z. B. für Warnhinweise) Je nach Anwendung lässt sich diese Liste noch erweitern. Die fehlende Kompetenz der Entwickler in sprachlichen Belangen führt meist dazu, dass einige Punkte unbeachtet bleiben, die dann zu einen erhöhten Lokalisierungsaufwand führen: Textlängen können sich durch die Übersetzung vergrößern und das Layout statischer Dialoge sollten längere Texte in einem gewissen Maß tolerieren. Textspeicher, in denen zur Laufzeit Meldungen zusammengesetzt werden, sollten groß genug gewählt werden. Text in Bildern sollte wenn möglich vermieden werden. Landesspezifische Symbole sollten ebenfalls vermieden werden. Die Grammatik in der Zielsprache kann eine Vertauschung von variablen Parametern einer Meldung notwendig

2 machen. Es sollten die Formatierungsfunktionen der Windows-API verwendet werden, die eine Vertauschung erlauben. Fragmentierte Texte, die erst zur Laufzeit zusammengesetzt werden, sind nur schwer zu übersetzen. Manche Sprachen haben mehrere Pluralfälle (z. B. Polnisch). Es müssen Methoden entwickelt werden, die bei Meldungen mit variabler Anzahl sinnvolle Übersetzungen ermöglichen. Die von der jeweiligen Programmiersprache vorgegebenen Ressourcestrukturen sollten nach Möglichkeit verwendet werden. Benutzerspezifische Dateiformate mit zu übersetzenden Texten sind zu vermeiden. Solche und weitere Vorgaben sollten schriftlich erstellt und als Richtlinien für die Programmierer verfügbar sein. Regelmäßige Code-Reviews während der Entwicklung können die Einhaltung überprüfen. Die Internationalisierung endet nicht in der eigenen Entwicklungsabteilung. Wer Prozesse und Richtlinien für die Internationalisierung erstellt hat, muss diese auch bei externen Partnern, z. B. bei der Offshore-Entwicklung in Billiglohnländern, anwenden. Weniger beachtet wird meist die Thematik der Verwendung von Programmbibliotheken von Drittanbietern, die innerhalb der eigenen Entwicklung Produktivitätsvorteile versprechen. Bei der Evaluierung der in Frage kommenden Produkte ist darauf zu achten, dass diese auch für diejenigen Sprachen geeignet sind, in die das Produkt übersetzt werden soll. 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 zwei Nachteile mit sich, die die Qualität des Produkts 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 nicht muttersprachige Softwareentwickler eher technische Englischkenntnisse, die für die Kunden eines Produkts 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 ist. Wer die Qualität und Konsistenz der Quellsprache von Anfang an sicher stellen will, sollte in der Muttersprache entwickeln lassen und kann dem Entwicklungsteam zusätzlich einen technischen Autor (z. B. aus der Dokumentationsabteilung) beistellen. Dieser kann bereits während der Entwicklung die Einhaltung einer konsistenten Terminologie überprüfen und einen standardisierten Schreibstil verwenden. Ein weiterer Vorteil ist, dass Dokumentationen wie Handbücher und Online-Hilfe zeitnah zur Produktentwicklung erstellt werden. Einheitliche Terminologie Die konsistente Verwendung einer einheitlichen Terminologie innerhalb des gesamten Produkts 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-Web- Seiten 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 Terminologiemanagements in einem Unternehmen ist eine hohe 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 Gesamtprodukts. Zeichensätze und Fonts Die Frage, ob eine lokalisierte Software alle gewünschten Zeichen in der jeweiligen Zielsprache korrekt darstellen und verarbeiten kann, hängt von der Wahl der Programmiersprache und der Art der Kodierung ab. Mit dem Windows-Betriebssystem wurden so genannte Codepages für unterschiedliche Zeichensätze eingeführt. Eine Codepage enthält normalerweise den ASCII-Zeichensatz und weitere 128 Zeichen. Zusätzlich wird noch zwischen Single Byte Character Set (SBCS) und Multi Byte Character Set (MBCS) unterschieden. Beim MBCS enthält die erste Codepage auch den ASCII-Zeichensatz, in den oberen 128 Bytes sind jedoch zusätzlich so genannte Lead Bytes definiert, die dann auf eine weitere Codepage mit 256 (z.b. japanischen) Zeichen verweisen. Grundsätzlich ist die Anzahl der Zeichen innerhalb einer Codepage jedoch begrenzt und enthält nicht immer alle benötigten Zeichen. Wer Software mit dem Microsoft Visual Studio unter C++ entwickelt und diese auch für Kunden mit den nicht Unicodebasierten Windows-9x-Betriebssystemen bereitstellen will, muss gewisse Einschränkungen beachten. Denn obwohl die von Microsoft definierten Standardressourcen in der Binärdatei seit Windows NT 3.1 bzw. Windows 95 im Unicode- Format kodiert sind, kann eine auf ANSI- Codepages basierende Software nur die Zeichen der jeweiligen Codepage des aktuellen Systems darstellen. So kann z. B. ein in Deutschland für die ANSI-Codepage 1252 entwickeltes Programm das Quadratzeichen in m 2 korrekt anzeigen. Wenn diese Software in eine Sprache der mitteleuropäischen Codepage 1250 (z. B. Polnisch) übersetzt werden soll, steht das Quadratzeichen nicht mehr zur Verfügung. Der Übersetzer kann das Zeichen zwar bei der Lokalisierung verwenden und es wird als Unicode- Zeichen korrekt in den Ressourcen der übersetzten Zieldatei gespeichert, auf einem polnischen Betriebssystem wird die Software dieses Zeichen aber nicht laden können, weil es in der Codepage gar nicht vorhanden ist. Je nach Betriebssystem wird entweder eine Fragezeichen oder ein vom Betriebsystem als ähnlich erkanntes Zeichen angezeigt. Der Unicode-Zeichensatz hat eine Kapazität von bis zu einer Millionen Zeichen und kann somit die meisten Sprachen dieser Welt abdecken. Wurde die Software mit der Unicode-Laufzeitbibliothek kompiliert, ist sie aber nur auf einem Unicode- Betriebssystem (Windows NT, Windows 2000 und Windows XP) lauffähig. Es können aber alle Zeichen des Unicode- Zeichensatzes angezeigt werden, vorausgesetzt eine entsprechende Schriftart ist auf dem System installiert. Ist dies nicht der Fall, werden meist Kästchen angezeigt. Für bestimmte Sprachen, wie z.b. Japanisch oder Chinesisch, kann es notwendig sein, während der Lokalisierung die Schriftart zu ändern. Die Softwareent- 5/2005

3 wickler können diesen Prozess vereinfachen, indem sie generische Schriftarten verwenden, bei denen automatisch für die jeweilige Sprache die richtige Schriftart ausgewählt wird. Bei Java und den Programmiersprachen des Microsoft.NET Frameworks sind die jeweiligen Anwendungsframeworks bereits in Unicode kodiert. Mit den zur Verfügung gestellten Datenstrukturen für Texte und den Funktionen der Laufzeitbibliotheken kann eine auf Unicode basierende Software auch für Windows-9x-Systeme entwickelt werden. Zu beachten sind dann lediglich die Methoden für den Datenaustausch mit anderen, nicht auf Unicode basierenden Programmen und Repositorys. Bei den dann notwendigen Codepage-Konvertierungen können Zeichen nicht korrekt umgewandelt werden. Lokalisierungswerkzeuge Zur Lokalisierung von Software können verschiedene Werkzeuge verwendet werden. Neben Editoren und Entwicklungssystemen kommen Terminologie-Verwaltungsprogramme und Translation-Memory-Systeme (Übersetzungsspeicher) zum Einsatz. Mit der steigenden Anzahl an Ressourceformaten für Software haben sich in den letzten Jahren auch spezielle Lokalisierungswerkzeuge für Software etabliert, die wesentliche Funktionen aller einzelnen Werkzeuge beinhalten bzw. diese integrieren können. Diese Programme verfügen über die folgenden Funktionen: Lesen und Schreiben diverser Softwaredateiformate; neben den Ressourcedateien der Entwicklungsumgebungen können auch die ausführbaren Programme, Text- und XML-Dateien oder sogar Datenbanken lokalisiert werden. Integriertes Repository für Quelltexte, Übersetzungen und sämtliche für die Lokalisierung benötigten Dialogeigenschaften. Alignieren (Lesen von Übersetzungen und Dialogeigenschaften) aus bereits übersetzter Software in das Projekt. Update von Projekten, sodass bei einer neuen Softwareversion nur die Änderungen übersetzt werden müssen. WYSIWYG-Editoren für Dialoge und Menüs der gebräuchlichsten Entwicklungsumgebungen. Pseudoübersetzungsfunktion zum Test der Internationalisierung der Software. Internes Translation-Memory und Schnittstellen zu externen Translation- Memory-Systemen. Funktionen zur automatischen Vorübersetzung aus dem Übersetzungsspeicher und zur automatisches Übersetzung von sich wiederholenden Texten. Fuzzy-Matching-Technologie zur vereinfachten Übersetzung von Quelltexten, die sich ähnlich sind und schon übersetzt wurden. Prüffunktionen für die häufigsten Lokalisierungsfehler. Projektverwaltungsfunktionen für die Integration von externen Übersetzern. Exportfunktionen für die Wiederverendung bereits übersetzter Texte in der Dokumentation oder Online-Hilfe. Lokalisierungsmanager Die Lokalisierung von Softwareanwendungen ist ein komplexer Prozess, der nur mit einem Team von Spezialisten effizient durchgeführt werden kann. Die Softwareentwickler schaffen die Voraussetzungen und eine gute Internationalisierung des Programms kann den Lokalisierungsaufwand positiv beeinflussen. Neben dem Lokalisierungsmanager, dessen Aufgaben hier erläutert werden, sind Übersetzer, Lokalisierer, Testingenieure, Terminologen, technische Autoren und EDV-Fachleute manchmal sogar Mitarbeiter aus Tocherfirmen oder Software-Distributoren aus dem Zielland beteiligt. Der Lokalisierungsmanager verwaltet die Lokalisierungsprojekte und übernimmt vielfältige Aufgaben. Größere Unternehmen haben ganze Gruppen von Lokalisierungsmanagern, die die Übersetzung verschiedener Produkte des Unternehmens bearbeiten. In mittleren und kleineren Firmen wird diese Aufgabe teilweise von Entwicklern oder technischen Autoren aus der Dokumentationsabteilung übernommen. Nur wer seine Software komplett einem Lokalisierungsunternehmen übergibt, kann auf einen internen Lokalisierungsmanager verzichten. Ein Lokalisierungsmanager sollte eine technische Ausbildung haben. In vielen Studiengängen für Übersetzer gibt es mittlerweile aber auch Vorlesungen oder eine Spezialisierung für Softwarelokalisierung. Der Lokalisierungsmanager unterstützt die jeweiligen Spezialisten bzw. übernimmt folgende Aufgaben: Zusammenstellung des Lokalisierungspakets, Konvertierung bzw. Anpassung benutzerdefinierter Text- oder XML- Dateiformate, Test der Internationalisierung der Software, Erstellen und Vorbereiten des Lokalisierungsprojekts, Kommunikation mit den Entwicklern, Erstellung der Pakete für Übersetzungsbüros und externe Übersetzer, Überwachung des Arbeitsablaufs während der Lokalisierung, Kommunikation mit den Übersetzern und erste Anlaufstelle für deren Fragen, Qualitätskontrolle der übersetzten Pakete in technischer Hinsicht, Generierung der Zieldateien, Test des lokalisierten Produkts, Produktion der lokalisierten Produkts. Binär- oder Ressourcedateien Lange Zeit galt die Lokalisierung von Binärdateien als eine Aufgabe für Hacker. Der Prozess der Binärlokalisierung hat sich aber mittlerweile als Standardprozess für die Softwarelokalisierung etabliert, weil er wie in [Sye01] beschrieben viele Vorteile bietet. Die Angst der Entwickler, dass dabei der Code korrumpiert werden kann, ist unbegründet. Das Auslesen der Ressourcen aus den Binärdateien geschieht mit Hilfe von API-Funktionen des Betriebssystems oder der jeweiligen Frameworks der Entwicklungsumgebungen. Mit denselben API-Funktionen werden die übersetzten Texte in die lokalisierte Datei zurück geschrieben. Die Anzahl der zu lokalisierenden Dateien ist wesentlich geringer und der Prozess ist einfacher. Die Entwickler müssen nicht mehr in die Korrekturzyklen involviert werden und die übersetzten Ressourcedateien brauchen nicht in einen erneuten Build-Prozess integriert zu werden. Häufig werden aus den Originalprogrammen auch Laufzeitbibliotheken (DLLs) erzeugt, in denen nur die übersetzten Ressourcen enthalten sind. Die übersetzten Programme und DLLs können direkt in der Produktion verwendet werden, die sich an den Test der lokalisierten Software anschließt. Zusammenstellung des Lokalisierungspakets Zu Beginn eines Lokalisierungsprojekts muss das Lokalisierungspaket zusammengestellt werden. Da nicht alle Dateien eines Softwareprodukts zu übersetzenden Texte enthalten, muss der Lokalisierungsmanager mit Unterstützung der Entwickler diejeni

4 gen Dateien und Formate identifizieren, die zu bearbeiten sind. Für zu übersetzende Text- oder XML-Dateien mit benutzerdefinierten Strukturen sind Parser-Regeln zu schreiben, damit überhaupt Texte extrahiert werden können. Je nach Entwicklungsumgebung und Zielsprache gehören auch Bibliotheken von Drittanbietern und speziellen Schriftarten in das Lokalisierungspaket, weil sie beim Parsen der Quelldateien und zur Visualisierung der Kontrollen benötigt werden. Vorbereitung der Lokalisierung Nachdem alle Dateien des Lokalisierungspakets in ein Projekt eingelesen wurden, beginnt die Vorbereitung der Lokalisierung. Nicht alle eingelesenen Texte müssen übersetzt werden. Zum Teil speichern die Entwickler SQL-Abfragen, feste Dateinamen, Service- und Debug-Dialoge oder andere Texte in den Ressourcen, die zur Laufzeit wichtige Programmfunktionen steuern. Mit Hilfe der Entwickler kann der Lokalisierungsmanager diese Einträge im Projekt als nur lesbar markieren oder verstecken, damit sie von den Übersetzern nicht geändert werden. Immer wieder finden sich auch sehr kryptische oder zusammenhanglose Texte in den Ressourcen. Ein schönes Beispiel hierfür ist der Text ffppttddccrrll, der in der StringTable-Ressource des englischen Microsoft-Notepad-Editors vorkommt. Ohne einen entsprechenden Kommentar zu diesem Eintrag, wird kein Übersetzer wissen, was dieser bedeutet und wie er zu übersetzen ist. Es sind die Abkürzungen der Variablen für Dateiname, Seitennummer, Uhrzeit, Datum, Zentriert, Linksbündig und Rechtsbündig innerhalb der Kopf- und Fußzeile des Ausdrucks, die im Deutschen mit nnssuuddzzrrll zu übersetzen sind. Um ständige Anfragen der Übersetzer zu vermeiden, sollte der Lokalisierungsmanager solche Einträge mit Hilfe der Entwickler kommentieren. Viele Entwicklungsumgebungen bieten zwar die Möglichkeit, Kommentare einzugeben; von der Konzeption her sind diese Kommentare aber den Entwicklern vorbehalten und nicht für die Weitergabe an die Übersetzer gedacht. Innerhalb der Ressourcendateien gibt es meist kein von den Herstellern definiertes System, wie ein Kommentar einem bestimmten Eintrag zugeordnet werden kann, und in den Binärdateien ist der Kommentar gar nicht mehr enthalten. Neben der Kommentierung von Einträgen gibt es noch weitere Vorbereitungen, die sich positiv auf den Lokalisierungsaufwand auswirken. Bei Software für eingebettete Systeme ist die Länge der Übersetzung für die meisten Einträge begrenzt. Wenn die maximale Länge innerhalb des Projekts eingegeben wird, kann der Übersetzer die Textlängen automatisch überprüfen lassen. Test der Internationalisierung Mit Hilfe von Pseudoübersetzungsfunktionen der Lokalisierungswerkzeuge kann bereits vor der Übersetzung mit dem Test der Internationalisierung begonnen werden. Dabei werden statische Dialoge vergrößert und alle Texte um ein einstellbares Maß verlängert, wobei dafür auch spezielle Zeichen aus der Zielsprache verwendet werden können. Mit dem daraus entstandenen lauffähigen Zielprogramm kann beispielsweise getestet werden, ob alle zu übersetzenden Texte in Ressourcen gespeichert sind, ob interne Textbuffer groß genug oder alle für den Programmablauf wichtigen Ressourcetexte auf nur lesbar gesetzt wurden. Vorübersetzung Bereits vorhandene Übersetzungen können bei der automatischen Vorübersetzung eines neuen Projekts aus bereits abgeschlossenen Projekten und aus externen Translation- Memories übernommen und wieder verwendet werden. Dabei wird meist automatisch für den jeweiligen Kontext eine eindeutige Zugriffstaste vergeben. Einträge, für die es mehr als eine Übersetzung gibt, werden markiert, sodass der Übersetzer später die für den Kontext jeweils richtige Übersetzung auswählen kann. Die statistische Auswertung des Projekts nach der Vorübersetzung kann als Basis für Angebote und Abrechnungen mit Übersetzungsfirmen herangezogen werden. Für Textwiederholungen wird dabei nur ein reduzierter Satz berechnet. Kommunikation mit Übersetzern und Übersetzungsbüros Wer im Unternehmen keine internen Übersetzer hat, wird spätestens nach der Vorübersetzung das Projekt extern weiterbearbeiten lassen. Abhängig von Firmengröße, Umfang und geplantem Freigabetermin werden viele verschiedene Modelle praktiziert. Ein Projekt kann komplett einer Übersetzungsfirma übergeben Abb. 1: Multilinguales Übersetzungsprojekt für Griechisch, Japanisch und Arabisch 5/2005

5 werden, einzelne Sprachen oder Teile des Projekts können von Zweigniederlassungen oder Partnerfirmen im Zielmarkt bearbeitet werden oder es kann mit freiberuflichen Übersetzern im In- und Ausland zusammengearbeitet werden. Findet eine Lokalisierung in Sprachen mit einer anderen Codepage statt, sollte der Datenaustausch mit Übersetzungsfirmen und externen Übersetzern immer im Unicode-Format efolgen. Dies garantiert, dass beim Übergang zwischen den verschiedenen Betriebssystemen keine Zeichen durch Codepage-basierte Konvertierungen geändert werden (siehe Abb. 1). Bei der Definition des Lokalisierungsprozesses werden auch die Werkzeuge festgelegt, mit denen die am Prozess beteiligten Übersetzer arbeiten. Während diese Werkzeuge bei den Übersetzungsfirmen meist vorhanden sind, haben freiberufliche Übersetzer oder Partner in Drittländern häufig nicht die Mittel, sich diese zu beschaffen. Die Hersteller der Lokalisierungswerkzeuge bieten aber Funktionen und Lizenzmodelle an, bei denen der Übersetzer mit einer kostenlosen Editorversion arbeitet kann und trotzdem in der Lage ist, die Texte im Kontext der statischen Dialoge zu sehen und die Dialoge auch entsprechend anzupassen. Neben den zu übersetzenden Texten sind auch weitere Daten an den Übersetzer zu übergeben: Translation-Memories, die zur Vorübersetzung verwendet wurden; so wird gewährleistet, dass bei der Übersetzung der restlichen Texte die Übersetzungsvorschläge aus dem firmeninternen Translation-Memory stammen und eine konsistente Übersetzung entsteht. Kontrollen von Drittanbietern und verwendete Schriftarten; besonders bei der Lokalisierung von.net-software ist es wichtig diese Komponenten mit zu übergeben, weil sie zur korrekten Visualisierung der Kontrollen im Dialogeditor benötigt werden. Lokalisierungsvorgang Zunächst werden noch nicht übersetzte Texte bearbeitet. Aus den internen bzw. externen Translation-Memories können automatisch Übersetzungsvorschläge angezeigt werden. Der Übersetzer wählt einen Eintrag aus und passt die Übersetzung an. Ist kein Übersetzungsvorschlag vorhanden, wird die Übersetzung neu eingegeben. Sich wiederholende Texteinträge können automatisch übersetzt werden. Wird mit einer Terminologie-Datenbank gearbeitet, werden bekannte Begriffe im Ausgangstext markiert und der Übersetzer kann die Übersetzung dieser Begriffe übernehmen. Zusätzlich kann bei der Eingabe der Übersetzung automatisch die Rechtschreibung geprüft werden (siehe Abb. 2). Neben der Übersetzung der Texte müssen statische Dialoge angepasst werden, für den Kontext eindeutige Zugriffstasten vergeben und geänderte Tastenkombinationen angepasst werden. Moderne Lokalisierungswerkzeuge stellen für die jeweiligen Entwicklungsumgebungen spezifische WYSIWYG-Dialog- und Menü-Editoren zur Verfügung. Im Wesentlichen enthalten diese Editoren alle Funktionen zur effizienten Anpassung der Dialogkontrollen einer Software. Kontrollen können verschoben und an die Größe des Texts angepasst werden und für die Lokalisierung relevante Eigenschaften können geändert werden. Der Übersetzer hat nicht die Möglichkeit, Kontrollen zu löschen, hinzuzufügen oder die Struktur einer Ressource so zu ändern, dass die Software hinterher nicht mehr funktioniert. Ist der Übersetzer mit diesen Techniken vertraut, sollte man diese Aufgaben auf jeden Fall an ihn übertragen. Wer dem Übersetzer nur kontextlose Texte übergibt, muss Abstriche bei der Qualität der Übersetzung machen und die Anpassung der Dialoge in einer fremden Sprache sowie die Vergabe von eindeutigen Zugriffstasten selbst übernehmen. Prüfungen Ist ein entsprechendes Lokalisierungswerkzeug vorhanden, kann schon der Übersetzer die Prüfungen für die häufigsten Lokalisierungsfehler vornehmen und beseitigen. Dies entlastet die Lokalisierungsmanager und Entwickler. Folgende Prüfungen sind sinnvoll (siehe auch Abb. 3): Abb. 2: Integrierte Editierumgebung des Lokalisierungswerkzeuges PASSOLO Fehlt eine Übersetzung? Ist trotz leeren Quelltextes eine Übersetzung vorhanden? Gibt es eine unterschiedliche Anzahl von Leerzeichen vor und hinter dem Text? Fehlen Zugriffstasten, die im Quelltext vorhanden sind? Passt der übersetzte Text in die zugehörige Kontrolle des Dialogs? Ist der übersetzte Text zu lang?

6 Gibt es fehlende oder unterschiedliche Steuerzeichen (\t, \n, \r)? Gibt es fehlende oder inkonsistente Parameter (%d, %s usw.)? Passt der übersetzte Text passt in die zugehörige Kontrolle des Dialogs? Überlappen sich Kontrollen? Ragen Kontrollen aus dem Dialog heraus? Sind Rechtschreibfehler vorhanden? Sind doppelte oder unzulässige Zugriffstasten vorhanden? Test der lokalisierten Software Wenn alle Prüfungen abgeschlossen sind, können die Zieldateien generiert und getestet werden. Während das Generieren der übersetzten Dateien meist nur ein Mausklick ist, bedarf es für den Test der lokalisierten Anwendung einer weiteren Planung. Besonderes Augenmerk ist auch auf die Testumgebung zu legen. Je nach Entwicklungsumgebung und Art der Software kann der Test nur auf dem System durchgeführt werden, das in der jeweiligen Zielsprache läuft, nicht aber auf dem Lokalisierungssystem. Trotz unveränderten Codes ist eine lokalisierte Software nicht mit dem Original zu vergleichen und für jede Zielsprache sind spezifische Internationalisierungs- und Lokalisierungstests durchzuführen. Der Korrekturzyklus für hier aufgetretene Fehler kann bis zurück in die Entwicklung gehen. Nacharbeiten Ist die Lokalisierung einer Software abgeschlossen, muss ein Teil der Übersetzungen zur weiteren Verwendung exportiert werden. Sinnvollerweise sollte die Lokalisierung der Software zu Beginn einer Produktübersetzung durchgeführt werden. Die dabei neu entstandenen Begriffe und Übersetzungen sind der zentralen Terminologie-Datenbank und dem Translation- Memory hinzuzufügen, damit sie bei der Übersetzung von Handbüchern, Online- Hilfen und Web-Seiten wieder verwendet werden können. Nur so kann eine konsistente Benutzung von Begriffen und Phrasen innerhalb des gesamten Produkts gewährleistet werden. Update Durch das integrierte Repository sind Lokalisierungswerkzeuge in der Lage, Software-Updates sehr effizient zu bearbeiten. Dabei hilft die Struktur der Ressourcen mit ihren eindeutigen Ids, die von den Softwareentwicklern vergeben wurden. Bei Abb. 3: Ausgabe von Lokalisierungsfehlern bei der Prüfung einer Übersetzungsliste der Aktualisierung des Lokalisierungsprojekts kann so festgestellt werden, welche Texte sich in der neuen Softwareversion geändert haben oder hinzugekommen sind. Nur noch diese Texte sind dann zu übersetzen, der Rest bleibt unverändert. Dasselbe Verfahren wird auch für die Eigenschaften der Kontrollen in den statischen Dialogen angewendet. Durch diese Technik können nicht nur Software-Updates bearbeitet werden. Unternehmen sind damit auch in der Lage, die Lokalisierung einer Software bereits in einem sehr frühen Stadium der Entwicklung zu starten. Zum Freigabetermin der Originalsoftware kann dann ein so genanntes Sim-Ship (Auslieferung in allen Sprachversionen) gemacht werden. Fazit Der Einsatz von speziellen Werkzeugen innerhalb des Lokalisierungsprozesses amortisiert sich sehr schnell. Die Lokalisierung der Software ist aber nur ein Teilaspekt der Lokalisierung und Übersetzung eines Produkts. Deshalb ist es ebenso wichtig, dass die Unternehmen mit der Einführung von Lokalisierungswerkzeugen auch andere, damit zusammenhängende Arbeitsprozesse in der Softwareentwicklung oder der technischen Dokumentation erstellen bzw. optimieren. Die Fähigkeit eines Unternehmens, Softwareprodukte auch in anderen Ländern schnell und effizient auf den Markt zu bringen, verschafft die entscheidenden Vorteile in unserer immer stärker zusammenwachsenden Welt. Literatur & Links [Dit02] K. Dittert, Turmbau zu Babel: Architektur internationaler Anwendungen, in: OBJEKTspektrum: 3/02 [Sye01] S. Syed, Issues and Benefits of Binary Localization, in: MultiLingual Computing & Technology, 2001 Volume 14 Issue 11, siehe: ducts-ref-center/products-ref-center-whitepapers/products-ref-center-white-papers-localization/products-ref-center-white-papers-localization-binary.htm 5/2005