.NET-Anwendungen erfolgreich lokalisieren, Teil 1

Veröffentlicht: 27. Okt 2006

Von Jens Konerow

Der internationale Erfolg einer Anwendung ist von mehreren Faktoren abhängig, die Qualität der Lokalisierung ist daran maßgebend beteiligt – vor allem wenn die "Muttersprache" der Anwendung ungleich der englischen Sprache ist. Diese zweiteilige Artikelserie widmet sich dem Lokalisierungsprozess einer Anwendung und stellt zwei verfügbare Werkzeuge zur Lokalisierung von Software näher vor.

Diesen Artikel können Sie dank freundlicher Unterstützung von dot.net magazin auf MSDN Online lesen. dot.net magazin ist ein Partner von MSDN Online.

Auf dieser Seite

 Einleitung
 Die CultureInfo-Klasse
 Datums- und Zeitangaben
 Kalendarformalitäten
 Ressourcen in .NET
 Catalyst von Alchemy Software
 Quick Start
 Die Umgebung
 Dinge, die das Leben erleichtern
 Ein Wort zur Arbeitsteilung
 Ausblick
 Über den Autor
  Links & Literatur

Einleitung

Mit der Lokalisierung einer Anwendung ist meist der Übersetzungsprozess gemeint, welcher die letzte von drei Stufen darstellt. Die eigentliche Arbeit fällt bereits in der Planung und in der Entwicklung einer Software an. Aus diesem Grund sollten alle Beteiligten, sprich Entwickler,

   
        kurz & bündig
     
Damit eine Software international erfolgreich
ist, muss sie lokalisiert werden. Dazu gehört
bei größeren Projekten mehr als nur eine
Übersetzung des Textes. Dieser Artikel zeigt
Ihnen, worauf Sie achten müssen, welche
Mittel Ihnen vom .NET Framework mitgegeben
werden und welche Werkzeuge Dritthersteller
anbieten
Zusammenfassung
Auch wenn .NET 2.0 mit der ComponentResourceManager-
Klasse eine Verbesserung
gegenüber dem RessourceManager von .NET
1.1 bietet, für größere Projekte sind Werkzeuge
von Drittherstellern unverzichtbar 

Lokalisierungsmanager und Übersetzer eng zusammenarbeiten. Die Internationalisierung (siehe Kasten) umfasst jene Tätigkeiten, die sicherstellen, dass der Programmcode bei der Anpassung an eine andere Region möglichst unberührt bleibt (Stufe 1). Hart kodierte Zeichenfolgen in Dialogen beispielsweise führen zu erneuten Änderungen am Programm und gehören genauso „bestraft“. Bereits von Anfang an sollten Zeichenfolgen, zumindest als Dummies, in Ressourcendateien ausgelagert werden. Schnell geraten kleine hart kodierten Zeichenfolgen in Vergessenheit, schummeln sich durch die Tests und tauchen dann erst wieder beim Kunden auf, der Ihr Produkt gerade wegen der angepriesenen lokalisierten Version als erste Wahl empfunden hat. Zur Lokalisierung gehört jedoch nicht nur die Übersetzung des Textes. Eine wichtige Rolle spielt die Berücksichtigung kultureller und gesetzlicher Rahmenbedingungen der jeweiligen „Lokale“. Der Kasten „I18N – Checkliste“ enthält eine Checkliste, die in die Planung einer Anwendung einbezogen werden sollte. In der zweiten Phase wird die Anwendung einem Test unterzogen, welcher sicherstellen soll, ob alle Punkte zu Genüge umgesetzt worden sind. In manchen Lokalisierungswerkzeugen gibt es sog. Pseudoübersetzer. Ihre AufgaInhalt be besteht darin, sämtliche Dialoge und

Internationalisierung
und Lokalisierung

Für die Begriffe Internationalisierung (engl.
Internationalization) und Lokalisierung (engl.
Localization) haben sich im Internet branchenspezifische
Abkürzungen entwickelt,
unter denen Sie nach weiteren Informationen
zum Thema suchen können: I18N bzw. L10N.
Die Abkürzungen setzen sich aus dem Anfangs-
und Endbuchstaben des jeweiligen
Wortes sowie aus der Anzahl der dazwischen
liegenden Buchstaben zusammen.
      

Zeichenfolge in dessen Größe zu variieren. Auch besondere Schriftzeichen können mittels dieser Übersetzerfunktionen eingefügt werden. Die daraus resultierende Programmversion wird anschließend auf Herz und Nieren getestet. Schwachstellen müssen in dieser Phase möglichst aufgedeckt und behoben werden. Spätestens an dieser Stelle werden Sie feststellen, wie gut in der Planungs- und Entwicklungsphase gearbeitet wurde. In der letzten, also der dritten Stufe wird die Arbeit an die Übersetzter delegiert. Als vorbereitende Maßname sollte der entsprechende Koordinator mit den Programmierern die Ressourcen durchsehen und ggf. nicht zu übersetzende Zeichenfolgen markieren. Diverse Lokalisierungstools bieten dazu die Möglichkeit, einen „Nur-Lese-Status“ einzurichten.

 

Die CultureInfo-Klasse

Bereits während der Entwicklung sollten alle Punkte einer Lokalisierung beachtet werden, um im Anschluss lediglich die Übersetzung durchführen zu müssen. Das .NET Framework bietet mit der Culture- Info-Klasse im Namespace System.Globalization eine Klasse, die den Dreh- und Angelpunkt darstellt, wenn es um sprachspezifische Details geht. Zu den Informationen, die sich über die Klasse abrufen lassen, gehören Sprache, Datums- und Zeitangaben oder Informationen, die zur Formatierung von Zahlen oder für einen Vergleich von Zeichenfolgen benötigt werden. Die jeweilige Kultur und Region

   Eine I18N-Checkliste
- Schreibsystem, Sortierung von Text, Sonderzeichen
- Variation der Länge von übersetzten Texten
- Grafiken mit Texten
- Zahlen, Währungs-, Datums- und Zeitformate
- Physikalische Einheiten
- Vertauschung von Variablen durch grammatikalische
  Unterschiede im Satzbau
- Darstellung von Postleitzahlen, Telefonnummern
- Rechtliche Bestimmungen für Grafik und
  Text (Beispielsweise ist die Verwendung
  einer bestimmten Symbolik in Computerspielen,
  dessen Szenarien in der Zeit des
  Zweiten Weltkrieges liegen, bei der Veröffentlichung
  für den deutschen Markt zu
  vermeiden.


      

wird anhand eines eindeutigen Kürzels identifiziert, welches dem Standard RFC 1766 folgt (siehe Kasten „RFC 1766“). Die CultureInfo-Klasse bietet über ihre statische Eigenschaft InvariantCulture auch eine kulturunabhängige Einstellung an. Diese Kultur basiert auf der englischen Sprache, lässt jedoch regionale Besonderheiten außen vor. Formatierungen mithilfe dieser CultureInfo-Instanz dürfen lediglich zur internen Datenhaltung und - Verwaltung angewandt werden – andernfalls entspricht das Format gegebenenfalls nicht der gewählten Region. Nicht zu verwechseln sind sprachunabhängige Kulturen mit neutralen Kulturen, welche zwar eine Sprache spezifizieren, sich aber auf keine Region beziehen. Ein CultureInfo-Objekt besitzt eine Eigenschaft namens UseUserOverride. Besitzt diese den Wert True und entspricht die angegebene Kultur der unter Windows aktuell eingestellten Kultur, werden die Einstellungen des Benutzers, welche in der Systemsteuerung vorgenommen wurden, in dieser CultureInfo-Instanz reflektiert. Jene Überschreibungen gelten ebenfalls für die NumberFormatInfo- bzw. der Date- TimeFormatInfo-Instanz, die den Eigenschaften NumberFormat und DateTime- Format entnommen werden können.

 

Datums- und Zeitangaben

Bei der Konvertierung einer DateTime- Struktur in eine Zeichenfolge wird implizit die DateTimeFormatInfo-Instanz der aktuellen Kultur des Threads verwendet, um die Daten entsprechend der Spracheinstellung als String-Repräsentation wiederzugeben. Die ToString-Methode der DateTime-Struktur besitzt diverse Überladungen, um beispielsweise ein Objekt zu übergeben, welches die IFormat- Provider-Schnittstelle implementiert. Dies ist sowohl bei der CultureInfo-Klasse, als auch bei der DateTimeFormatInfo- Klasse der Fall:

System.Threading.Thread.CurrentThread.CurrentCulture =
new CultureInfo(“en-US“);
      

Die spezialisierten Konvertierungsmethoden, wie beispielsweise ToLongDate- String, bieten keine Überladung und werden somit immer durch die Culture- Info-Instanz des Threads gespeist. Um eine Formatierung in einer anderen Sprache durchzuführen, muss entweder die Spracheinstellung des Threads folgendermaßen geändert werden:

System.Threading.Thread.CurrentThread.CurrentCulture =
new CultureInfo(“en-US“);
      

 

Kalendarformalitäten

Oder aber es wird auf die ToString-Methode ausgewichen, welcher neben dem Format Provider zusätzlich ein Format String übergeben werden kann. Bei Verwendung der Eigenschaften Day, Month und Year bzw. bei Verwendung der Methode AddDays der DateTime-Struktur sollte bedacht werden, dass diese Operationen immer auf gregorianischen Kalender basieren. Sind stattdessen kalenderspezifische Angaben gefragt, schaffen die Eigenschaften und Methoden der Calendar- Klasse Abhilfe. Der Default-Kalender zu der jeweiligen Kultur verbirgt sich hinter der Calendar-Eigenschaft einer Culture- Info-Instanz. Sonstige Kalendertypen die durch die jeweilige Kultur unterstützt werden, liegen als Calendar-Array unter der OptionalCalendars-Eigenschaft bereit.

 

Ressourcen in .NET

Microsoft hat mit dem .NET Framework und Visual Studio bereits sehr gute Grundlagen zur Lokalisierung einer Anwendung geschaffen – ein Zauberwort heißt Satelliten- Assembly. Assemblies dieser Art beinhalten keinen ausführbaren Code, sondern ausschließlich Sprachinformationen. Für jede Anwendung existiert eine standardmäßige bzw. eine sog. neutrale Sprache, die

        RFC 1766


Der Standard RFC 1766 definiert Tags, die
zur eindeutigen Identifikation einer Kultur
und einer Region verwendet werden (engl.
Tags for the Identification of Languages).
Der eindeutige Name setzt sich aus einem
„Primary Tag“ (Sprachcode) und aus einem
„Subtag“ (Regions-/ Landescode) zusammen.
Der Landescode besteht aus zwei
kleingeschriebenen Buchstaben, welche die
Kultur beschreiben (z.B. de). Der Code der
Subkultur gibt die spezifische Region bzw.
das Land zu dieser Kultur an und wird in zwei
großgeschriebenen Buchstaben ausgedrückt.
Beide Tags werden mit einem Bindestrich
verbunden (Beispiel: de-AT für Deutsch in
Österreich). Weitere Informationen zu diesem
Standard finden Sie unter: rfc.net/rfc1766.html.
Eine genaue Auflistung der Sprachkürzel entnehmen
Sie bitte der MSDN Library.
      

in der die Anwendungs-Assembly hinterlegt ist. Alle zusätzlichen Sprachen werden in gesonderten Satelliten-Assemblies gespeichert, die sich meist in einem Unterordner des Anwendungsordners befinden. Der Name des Unterordners hält sich ebenfalls an den RFC-1766-Standard. Zudem sind diese Sprachbibliotheken insofern optimiert, dass sie lediglich die Änderungen in Bezug auf die neutrale Sprache beinhalten. Die Vorgehensweise der Runtime, wie bzw. von wo eine Satelliten-Assembly geladen wird, ist im sog. Resource Fallback Process definiert – dieser beinhaltet die folgenden Schritte:

• Zunächst wird im GAC nach einer Übereinstimmung der angeforderten Kultur gesucht.

• Anschließend wird im Ordner der ausführenden Assembly nach Unterordnern bzw. nach Ressourcen in diesem Unterordner gesucht, die der Kultur entsprechen. Damit die CLR die Ressource finden kann, muss der Ordner gemäß dem RFC-1766-Standard benannt sein.

• Im dritten Schritt wird nochmals der GAC durchsucht, ob sich nun eine alternative Assembly finden lässt, die mit der angeforderten Kultur am meisten übereinstimmt. Als Beispiel deckt die Sprache Deutsch die Länder Deutschland, Österreich und Schweiz ab. Schlug die Suche nach de-DE fehl, greift die Runtime auf die Kultur de zurück. In der Literatur ist von der Parent-Assembly die Rede.

• Eine wiederholte Suche im Ordner der ausgeführten Assembly erfolgt nun nach der Parent-Assembly.

• Wurde die Ressource bis hierher noch nicht gefunden, werden potentielle Parent-Assemblies gesucht, da die eigentliche Parent-Assembly der angeforderten Ressourcen evtl. wiederum eine Parent-Assembly besitzt.

• Soweit keine spezielle Satelliten-Assembly verfügbar ist, werden die Ressourcen der Default-Assembly entnommen.

• Wurden die Ressourcen selbst in der Default-Assembly nicht gefunden, wird eine Ausnahme geworfen.

        LCID

Unter dem Kürzel LCID (Local Identifier) wird
ein 32-Bit-Integer-Wert verstanden, der die
Sprache sowie die Sortierung eines spezifischen
Gebiets beschreibt. Mittels dieser
Nummer können die Schemainformationen
dem Betriebssystem entnommen werden. In
den ersten 16 Bit wird die Sprache gespeichert,
in den darauf folgenden 4 Bit die Sortierung
und die letzten 12 Bit sind reserviert.

      

Verantwortlich für die Umsetzung dieses Fallback-Vorgangs ist die ResourceManager- Klasse. Jene fungiert als eine Art Schnittstelle zwischen Satelliten-Assembly und der Anwendung. Zwei Methoden dienen dem Ressourcenzugriff: GetObject und GetString. Beide besitzen zwei Überladungen. Die Standardüberladung erfordert lediglich die Übergabe des Schlüssels, mit dem die Zeichenfolge bzw. das Objekt hinterlegt wurde. Für welche Kultur die Daten abgefragt werden, ist abhängig von der Spracheinstellung des Threads:

System.Threading.Thread.CurrentThread.CurrentUICulture
      

In deren zweiter Variante kann die gewünschte Kultur durch eine CultureInfo- Instanz explizit angegeben werden. Damit die Verwendung von Satelliten-Assemblies für ein Formular aktiviert wird, muss lediglich die Localizable-Eigenschaft auf True gestellt werden. Daraufhin wurden im .NET Framework 1.1 alle lokalisierbaren Eigenschaften eines Objekts (jene sind mit einem Localizable- Attribut gekennzeichnet) in die Ressourcendatei aufgenommen – auch wenn für diese keine unterschiedlichen Einstellungen getroffen wurden. Bei .NET 2.0 wurde dieser etwas undurchsichtige Vorgang durch die ComponentResourceManager- Klasse abgelöst, welche von der ResourceManager- Klasse erbt, um für jedes Steuerelement explizit festzulegen, ob dieses zu lokalisieren ist oder nicht. Standardmäßig fügt der Designer den nötigen Aufruf der ApplyResources-Methode für alle Steuerelemente hinzu.

Wird im Eigenschaftenfenster die Eigenschaft Language umgestellt, erstellt Visual Studio eine neue Ressourcendatei, insofern die entsprechende Kultur noch nicht abgedeckt wurde. Anschließend können die Beschriftungen der Elemente abgeändert werden. Es ist darauf zu achten, dass Änderungen am Layout eines Formulars immer in der Standardsprache durchgeführt werden, insofern diese alle Kulturen betreffen. Andernfalls ist die Änderung nur für die spezifische Sprache verfügbar.

Trotz gewisser Verbesserungen bei .NET 2.0 ist die Lokalisierung einer Anwendung „zu Fuß“ eine genauso arbeitsintensive wie fehlerträchtige Angelegenheit. Ohne kommerzielle Werkzeuge, von denen im Folgenden einige vollkommen wertfrei vorgestellt werden, lässt sich diese Aufgabe vermutlich nicht erfolgreich bewältigen.

 

Catalyst von Alchemy Software

Von der irischen Firma Alchemy Software entwickelt, bietet Catalyst eine Umgebung, um den gesamten Workflow, der mit einer Lokalisierung in Verbindung steht, abzudecken. Als einziges von Microsoft zertifiziertes Lokalisierungswerkzeug für .NET unterstützt Catalyst Lokalisierer bei der Internationalisierung Ihrer Desktop-, Mobile- und Internet-Anwendungen. Visuelle Editoren gewährleisten die ständige Qualitätskontrolle frei nach dem WYSIWYG-Prinzip. Unterstützt werden alle gängigen Formate und Anwendungstypen: Zum Beispiel .NET-Assemblies oder die XML-basierten Ressourcendateien des .NET Framework (*.resx), Win32-Anwendungen und -Bibliotheken, Delphi, Java, SQL-Server-Datenbanken, Access, Oracle, IBM DB2 oder aber Markup- Sprachen wie beispielsweise XML, XHTML, HTML oder ASP.NET.Catalyst selbst liegt in englischer, japanischer und chinesischer Sprache vor – eine deutsche Variante ist bereits in Vorbereitung und soll in absehbarer Zeit ebenso verfügbar sein.

 

Quick Start

Gleich zu Beginn, noch bevor ein neues Projekt in Catalyst angelegt wird, muss entschieden werden, ob die Lokalisierung anhand von XML-Ressourcendateien oder einer .NET-Assembly durchgeführt werden soll.

        Catalyst selbst testen

Auf der Homepage der Firma Alchemy
Software (www.alchemysoftware.ie) ist eine
kostenlose Demo-Version im Download-Bereich
verfügbar. In dieser Version sind einige
Funktionalitäten deaktiviert oder in ihrem Umfang
beschränkt. Auf Anfrage sendet Ihnen
Alchemy Software eine 7-Tages-Lizenz für die
Localizer-Edition per E-Mail zu, damit sämtliche
Funktionalitäten, bis auf den QuickShip
Expert und den Layout Manager, auf Herz
und Nieren geprüft werden können. Eine
E-Mail an info@alchemysoftware.ie genügt.

      

In beiden Fälle müssen Formulare als lokalisierbar gekennzeichnet sein – die Localizable-Eigenschaft muss den Wert True enthalten – damit in der Endfassung auf Satelliten-Assemblies zurückgegriffen werden kann. Letztere Variante bietet jedoch den Vorteil, dass weniger Dateien verwaltet werden müssen. Sie haben quasi alle Informationen auf „einen Schlag“ zur Verfügung, die für die Übersetzung relevant sind. Anschließend wird in Catalyst ein neues Projekt angelegt, woraus eine Ttk-Datei resultiert. Dieser werden über den Menüeintrag File | Insert Files… die zu lokalisierenden XML-Ressourcen oder .NET-Assemblies hinzugefügt, welche anschließend im Navigator (Abbildung 1) zu sehen sind. Die Quell- und Zielsprache wird durch die oberste Symbolleiste definiert. Durch Selektion im Navigator aktualisiert sich der Dialog-Editor (mittig angesiedelt) – dort können die Zeichenfolgen ausgewählt und in der darunter liegenden Translator- Toolbar übersetzt werden.

Abschließend müssen die Übersetzungen extrahiert werden. Ein Klick auf den Eintrag Extract Files im File-Menü genügt, um den Prozess zu beginnen (beachten Sie, dass dazu das Projekt oder die Ressource im Navigator aktiviert sein muss). Wählen Sie im ersten Schritt einen Ordner aus, in dem die generierten Dateien gespeichert werden. Im zweiten Schritt erfolgt nochmals die Angabe der Zielsprache bzw. die Angabe des Unterordners für die Satelliten-Assembly. In Abhängigkeit von den importierten Dateien generiert Catalyst nun entweder die neuen Resx-Dateien oder die Satelliten-Assemblies gemäß dem RFC-1766-Standard. Die Exportfunktionalität zum Erzeugen der Ressourcendateien ist zu 100 Prozent Unicode-fähig. Somit wäre Ihre Anwendung lokalisiert – im idealen Fall mussten keine Änderungen am Quellcode oder am Design der Dialoge durchgeführt werden.

Abb. 1: Die Umgebung von Catalyst 6 (Bitte zur Grossansicht klicken!)

 

Die Umgebung

Alchemy Software bietet ihre visuell unterstützte Lösung als eigenständige Umgebung an – eine Integration für Visual Studio gibt es nicht. Abbildung 1 zeigt Catalyst, nachdem ein Projekt erstellt und eine .NET-Assembly importiert wurde.

Der auf der linken Seite befindliche Navigator reflektiert die Inhalte des Projekts. Über ihn lassen sich Ressourcendateien verwalten und strukturieren. Die oberste Symbolleiste bietet zudem diverse Standardbefehle zur Verwaltung eines Projekts. Wie bereits erwähnt, kann mithilfe dieser Symbolleiste die Quell- und Zielsprache des Lokalisierungsprojekts definiert werden. Selektionen im Navigator spiegeln sich direkt im Dialog-Editor wieder. Jener verfügt über zwei Modi – den Visual und den String Mode. Letztere Variante entspricht einer Tabelle, in welcher beispielsweise der Schlüssel einer Zeichenfolge, die Übersetzung oder der Status zu sehen ist. Die Tabelle kann über dessen Kontextmenü den Bedürfnissen des Benutzers angepasst werden. Der Visual Mode zeigt die Form, wie Sie auch im Visual Studio Designer zu sehen wäre. Insofern in einem Projekt Referenzen auf andere Assemblies bestehen, versucht Catalyst diese ebenfalls zu laden, um genau dasselbe Abbild zu erzielen. Somit werden sowohl Visual Inheritance als auch Steuerelemente von Drittherstellern unterstützt. Der Dialog- Editor signalisiert geerbte Objekte, die als Private markiert worden sind, durch ein Symbol mit einem roten Pfeil (entspricht dem Symbol des Windows Forms Designer). Zu Zwecken der Konsistenz dürfen jene Objekte nicht bearbeitet werden – stattdessen muss die entsprechende Änderung direkt am Basisformular vorgenommen werden. Die Modifizierer Public und Protected werden gleichermaßen behandelt und bewirken die Darstellung desselben Symbols in blauer Farbe. Geerbte Objekten denen einer dieser zwei Modifizierer zugewiesen wurde, können pro Instanz bearbeitet werden.

Abb. 2: Die Translator- Toolbar

Eine Kombination aus String Mode und Visual hat in einer Vielzahl von Fällen den meisten Sinn, denn der Dialog-Editor vermittelt dem Übersetzer den Kontext zwischen dem Textelement und dessen Verwendung in der Anwendung durch die Umrandung des betroffenen Steuerelements. Im Menü View | Workspace bietet Catalyst dazu zwei Varianten: Split Horizontal und Split Vertical. Die Translator- Toolbar darunter ist eine Art Steuerzentrale zur Bearbeitung eines selektierten Textelements. Sie bietet neben der Übersetzungsfunktionalität eine Rechtschreibprüfung, ein Glossar, eine Übersicht der Objekteigenschaften und gewährt dem Übersetzer zugleich die Statusverwaltung für das jeweilige Element. In Verbindung mit dem Visual-Dialog-Editor ist ein direktes Feedback auf die vorgenommenen Änderungen gewährleistet und Fehler können frühzeitig behoben werden. Alternativ zu direkten Anpassungen im Dialog-Editor, lässt das Eigenschaftsfenster in der Translator-Toolbar Koordinaten- und Größenänderungen zu. Auf der rechten Seite, in der Project Result Bar, gibt die Anwendung Infos über die gerade ausgeführten Aktionen an Sie weiter. Im Fall einer fehlenden Assembly, beim Laden eines Projekts beispielsweise, würde die Result Bar einen Eintrag mit dem Namen der vermissten Bibliothek beinhalten. Dessen Aufgabenfeld ist aber noch vielseitiger. Sie dient zugleich als To-Do-Liste oder gibt die Fundorte einer Find&Replace-Operation aus. Mit einem Doppelklick auf eines dieser Suchergebnisse dirigiert Catalyst Sie direkt zum entsprechenden Dialog und aktiviert das Control bzw. das Textelement.

 

Dinge, die das Leben erleichtern

Visuelle Editoren und eine spezialisierte Projektverwaltung für Lokalisierungsprozesse sind zwar unterstützend, der wirkliche Mehrwert wird jedoch erst dann erreicht, wenn dem Lokalisierer Arbeit abgenommen wird. Den ersten Schritt in diese Richtung ermöglichen Glossare, Translation Memories in Verbindung mit der Power-Translate-Funktionalität und der sog. Leverage Expert. Glossare bieten in Catalyst die Möglichkeit die Translator- Toolbar mit bekannten, bereits übersetzten Wörtern oder Wortgruppen zu bestücken, um dann beim aktiven Übersetzungsprozess auf diese Wörter zurückgreifen zu können. Insofern mehrere Wörter im Glossar enthalten sind, die für das aktuelle Textelement zutreffend sein könnten, bietet Ihnen die Translator-Toolbar eine Liste an, wobei ein Doppelklick genügt um die Übersetzung abzuschließen (Abbildung 2).

Wiederum ein Stück komfortabler sind die sog. Translation Memories in Verbindung mit der Power-Translate-Funktionalität. Neben dem Verwalten der Glossare wird im Optionsdialog und dort im Abschnitt Power Translate ein primärer sowie ein sekundärer Übersetzungsspeicher hinzugefügt. In der Praxis entspräche die verwendete Translation Memory (TM) beispielsweise der Projektdatei ei- ner zuvor lokalisierten Version Ihrer Anwendung. Zusätzlich obliegt Ihnen die Entscheidung, wie hoch die Übereinstimmung einer Wortgruppe ausfallen muss, damit Catalyst diese mit einer vorhandenen Übersetzung in der Translation Memory identifiziert.

Die Power-Translate-Toolbar – entspricht der mittig gelegenen Symbolleiste in Abbildung 1 – stellt die Verbindung zwischen dem Übersetzungsspeicher und dem selektierten Textelement her. Diese hält beispielsweise folgende Befehle bereit:

        TRADOS
TRADOS ist ein Tool zum Erzeugen von
Translation Memories, um die Wiederverwendung
von bereits übersetzten Zeichenfolgen
zu gewährleisten. Catalyst besitzt beispielsweise
eine Komponente zum direkten Zugriff
auf die Translation Memories von TRADOS.
Ob die Daten auf dem lokalen Computer oder
auf einem Server liegen, spielt dabei keine
Rolle. Zur optimalen Handhabung beider
Tools sind die wichtigsten Schnittstellen und
Hot Keys beider Anwendung aufeinander
abgestimmt.



      

Abb. 3: Der Leverage Expert ermöglicht die Wiederverwendung von bereits lokalisierten Projekten

• Open: Sucht in der Translation Memory nach potentiell zutreffenden Übersetzungen und bietet die Liste in der Translator- Toolbar an

• Open/ Get Translation: Durchsucht den Speicher und ersetzt das Textelement nach erfolgreicher Suche

• Open Next/ Get Translation: Aktiviert die nächste Zeichenfolge und ersetzt diese im Fall einer erfolgreiche Suche mit der Übersetzung aus dem Speicher

Wem der manuelle Weg zuviel Zeit in Anspruch nimmt, kann eine automatische Übersetzung veranlassen, wobei dann der komplette Dialog lokalisiert wird. Die letzte Steigerung in der Wiederverwendung einer Lokalisierung bietet der Leverage Expert (Abbildung 3). Aufgrund von variierenden Textlängen sind teils Größenanpassungen notwendig. Damit diese Anpassungen bei gleichen Dialogen nicht erneut durchgeführt werden müssen, überträgt der Leverage Expert jene Änderungen auf das aktuelle Projekt – selbst Bitmaps lassen sich somit automatisiert lokalisieren.

 

Ein Wort zur Arbeitsteilung

Große Software-Projekte, die in mehr als zwei, drei Sprachen übersetzt werden sollen, erfordern die Delegation der Lokalisierung an externe Übersetzer. Voraussetzung für eine erfolgreiche Zusammenarbeit ist ein einheitlicher Datenbestand und das Verständnis des Kontexts eines Textelements zu dessen Einsatzgebiet. Dennoch ist die Verteilung des gesamten Projekts und der Third-Party-Controls dem Projektmanager ein Dorn im Auge. Catalyst bietet als Lösung eine Exportfunktionalität, um Sektionen (eine Sektion kann z.B. ein oder mehrere Dialoge umfassen) in gesonderten Projektdateien zu speichern. Der besondere Clou dabei: Die daraus resultierende Ttk-Datei fungiert zugleich als Cache. Denn der Übersetzer ist in gleichen Maße in der Lage den Visual Mode des Dialog- Editors zu verwenden, obwohl das Software- Projekt und die Steuerelemente von Drittherstellern nicht installiert sind, da die Projektdatei alle nötigen Daten speichert. Benötigt jeder Übersetzer eine eigene Lizenz für Catalyst? Nein – Alchemy Software bietet eine kostenlose Version mit dem Namen Translator Lite Edition. Mittels dieser abgespeckten Version können die exportierten Sektionen beispielsweise getrennt bearbeitet und anschließend wieder importiert werden. Bis zu dem Zeitpunkt, an dem die exportierten Sektionen wieder in das Projekt integriert werden, sind die betroffenen Elemente zu Zwecken der Datenkonsistenz gesperrt. Damit der Übersetzer nicht diverse Konfigurationen vornehmen muss, weil neben der Projektdatei auch noch Glossare, Translation Memories oder Benutzerprofile, die aus dem Optionsdialog heraus exportiert werden können, zugesandt wurden, existiert in Catalyst ab der Developer- Version ein QuickShip Expert, welcher eine selbstausführbare Datei erzeugt, in der alle nötigen Dateien hinterlegt sind. Wird das QuickShip Bundle ausgeführt, werden die Dateien dekomprimiert und das Projekt in der Catalyst Translator Lite Edition geöffnet.

 

Ausblick

In dieser Folge wurden die Grundlagen der Globalisierung/Lokalisierung sowie die Mittel vorgestellt, die das .NET Framework von Haus aus mitbringt. Wurden bei der Planung und Entwicklung auch nicht alle Aspekte beachtet, greifen Tools wie Catalyst Ihnen unter die Arme, um diesen Misstand zu beheben und den letzten Schritt – den Übersetzungsprozess – zügig zu vollenden. Nachbesserungen am Layout sind dank des visuellen Editors sehr komfortabel machbar. Catalyst ist nicht nur auf die unterstützende Wirkung bei Übersetzungen beschränkt, sondern bietet auch eine Menge Funktionalität zur Qualitätssicherung und zur automatisierten Korrektur von Designschwächen in Dialogen, die im zweiten Teil vorgestellt werden sollen. Als Alternative zu Catalyst wird in der nächsten Folge das Lokalisierungstool der amerikanischen Firma Lingobit vorgestellt.

 

Über den Autor

Jens Konerow studiert internationale Informatik und sorgt nebenbei als Software-Entwickler bei der Firma KEEP IT SIMPLE GmbH Hamburg dafür, dass alles einfach bleibt. Für Fragen steht er Ihnen gern unter der Adresse Jens.Konerow@keepitsimple .de zur Verfügung.

 

Links & Literatur

[1] www.alchemysoftware.ie

[2] Lingobit Localizer:www.lingobit.com

[3] Passolo: www.passolo.com

[4] TRADOS: www.trados.com