Einleitung
In der heutigen Zeit ist Software praktisch aus keinem Lebens- und Arbeitsbereich mehr wegzudenken. Denn Software ist nicht mehr wie früher vor allem auf herkömmlichen PCs vorhanden, z. B. in Form eines grundlegenden Betriebssystems und darauf installierter Anwendungssoftware (von Büroanwendungen über Multimedia-Anwendungen bis hin zu Videospielen). In Form von mobilen Apps findet sich Software heute natürlich auch auf den allgegenwärtigen Smartphones und Tablets oder auch im Internet in Form von Webanwendungen. Darüber hinaus ist Software auch in vielen sonstigen Geräten und Maschinen vorhanden: Haushaltsgeräten, Autos, Produktionsanlagen in der Industrie etc.
In sehr vielen Fällen soll die Software nicht nur in der Sprache, in der sie entwickelt wurde, verfügbar sein, sondern auch in anderen Sprachen –um dadurch die Benutzerfreundlichkeit und die sogenannte User Experience zu verbessern. Hier kommt die Softwarelokalisierung ins Spiel, der eine immer größere Bedeutung zukommt.
Übersetzung = Lokalisierung = Übersetzung?
Im Zusammenhang mit der Übersetzung von Software (wie im Übrigen auch von Webseiten) spricht man häufig nicht von Übersetzung, sondern von Lokalisierung. Unter Lokalisierung versteht man im Allgemeinen die technische, sprachliche und kulturelle Anpassung eines Produkts – in unserem Fall einer Software – an einen regionalen Markt. Die Lokalisierung umfasst also mehr als die reine Übersetzung.
Für Lokalisierung wird übrigens häufig die Kurzform L10N verwendet – bestehend aus dem Anfangs- und Endbuchstabe von „localization“ und den 10 dazwischenliegenden Buchstaben.
Inhalte der Softwarelokalisierung
Die Lokalisierung von Software beinhaltet einerseits natürlich die Übersetzung der Programmdateien, aus denen sich die Software zusammensetzt. Andererseits umfasst sie in einem weiteren Sinne auch die Lokalisierung sonstiger softwarebezogener Bestandteile, wie die Lokalisierung der Online-Hilfe, der Produktdokumentation, der dazugehörigen Webseiten etc.
In der vorliegenden Beschreibung wird es ausschließlich um die Lokalisierung der Software an sich gehen.
Die zu lokalisierenden Inhalte einer Software bestehen in erster Linie aus Texten, die in der Benutzeroberfläche angezeigt werden, allen voran die Texte der Menüs und Dialogfenster (inkl. den darin enthaltenen Dialogelementen wie z. B. Kontrollkästchen, Dropdown-Listen und Schaltflächen). Nicht zu vergessen sind außerdem die so genannten Strings, d. h. Texte, die in bestimmten Fällen von der Software angezeigt werden, wie Fehler- und Statusmeldungen.
Darüber hinaus können auch Tastenkombinationen, mit denen bestimmte Funktionen ausgeführt werden können, sowie Versionsinformationen Gegenstand der Softwarelokalisierung sein. Die Versionsinformationen enthalten dabei grundlegende Informationen zur Software, wie z. B. Copyright-Informationen, den Produktnamen und natürlich die Version der Datei bzw. des Produkts. Sie werden angezeigt, wenn man die Eigenschaften der entsprechenden Datei öffnet.
Rechnergestützte Softwarelokalisierung
Die Lokalisierung von Software erfolgt heutzutage zumeist rechner- bzw. softwaregestützt, sei es mithilfe spezieller Softwarelokalisierungstools, sei es mit Hilfe von herkömmlichen Translation-Management-Systemen. Beide Arten von Software arbeiten dabei auf die gleiche Weise: Die Software extrahiert die zu lokalisierenden Inhalte aus dem Programmcode. Der Programmcode besteht vereinfacht ausgedrückt aus den Befehlen, die in der Programmiersprache der Software geschrieben sind.
Der WYSIWYG-Modus – WYSI what?
Neben Text können die zu lokalisierenden Inhalte auch Informationen zur grafischen Darstellung der Software enthalten – insbesondere von Dialogfenstern und deren Bestandteile. Um zu gewährleisten, dass das Ergebnis der Lokalisierung gerade auch in Bezug auf die grafische Gestaltung der Software korrekt ist, gibt es den so genannten WYSIWYG-Modus. Das Akronym WYSIWYG steht dabei für „What You See Is What You Get“, was auf Deutsch in etwa „Was man sieht, bekommt man auch“ bedeutet. Die Aussprache des Akronyms lautet übrigens [wiziwig]. Auf Deutsch wird teilweise auch der Ausdruck Echtzeitvorschau verwendet. Denn bereits während der Lokalisierung der Elemente von Dialogfenstern lässt sich sehen, wie ihre grafische Darstellung später aussehen wird.
Aber der WSIWYG-Modus liefert nicht nur eine Vorschau und somit einen visuellen Kontext der zu lokalisierenden Elemente: Falls nötig können die grafischen Elemente der Dialogfenster auch unmittelbar vom Lokalisierer in ihrer Größe und in ihrer Position angepasst werden. Ist eine Schaltfläche zu klein für die zielsprachliche Bezeichnung, kann die Schaltfläche einfach vergrößert werden, und zwar unmittelbar und ohne dass ein Softwareentwickler später nochmals eingreifen müsste.
Gängige Dateiformate
Eine Software setzt sich in der Regel aus einer kleinen oder auch großen Zahl von Programmdateien zusammen. Um eine Software vollständig zu lokalisieren, müssen daher auch all diese Dateien lokalisiert werden. Die Dateien liegen dabei meist in unterschiedlichen Formaten vor.
Welche Dateiformate vorliegen, hängt zunächst von der jeweiligen Entwicklungsplattform bzw. Programmiersprache ab. Weite Verbreitung haben das Standard-Windows-Ressourcenformat und .NET-Ressourcen.
Was die konkreten Dateiformate angeht, sind sicherlich EXE (von ausführbaren Dateien) und DLL (von Programmbibliotheken) relativ bekannt. Andere Formate sind OCX und CPL. Bei den genannten Formaten handelt es sich um Dateien, die im Binärformat vorliegen, d. h. die Dateien sind fertig kompiliert.
Neben den kompilierten Formaten gibt es auch unkompilierte Formate. Bei diesen wurden die zu lokalisierenden Inhalte vom Softwareentwickler aus den jeweiligen Programmdateien in textbasierte Dateien extrahiert. Hierbei handelt es sich um so genannte Resource-Script-Dateien. Gängige unkompilierte Formate sind RC, RC2 und DLG.
Die Lokalisierung von kompilierten Dateien hat den Vorteil, dass die Dateien nach ihrer Lokalisierung lauffähig sind, d. h. sie können direkt weiterverwendet werden, ohne dass der Softwareentwickler noch Arbeitsschritte durchführen muss. Der Vorteil der unkompilierten Dateien besteht hingegen darin, dass die Dateien mit einem beliebigen Texteditor geöffnet und ggf. bearbeitet werden können. Sie müssen nach der Lokalisierung aber wieder in den Programmcode integriert und anschließend kompiliert werden.
Darüber hinaus können Lokalisierungsinhalte auch in Form von Austauschformaten vorliegen. Ein Austauschformat für Übersetzungsressourcen im Allgemeinen ist XLIFF. Spezifische Austauschformate aus dem Bereich der Software-Entwicklung sind z. B. PO (für Portable Object) und JSON (für JavaScript Object Notation).
Vor dem Projektstart
Vor der Anlage eines Softwarelokalisierungsprojekts sind – aus technischer Sicht – zunächst einige Dinge zu prüfen und abzuklären. Hierzu zählen u. a.:
Lokalisierungsdateien und -anweisungen („Lokalisierungskit“)
Vor der Projektanlage ist zu prüfen, ob alle Dateien vorliegen und ob diese aus Sicht der eingesetzten Lokalisierungssoftware auch bearbeitbar sind. Alle Dateien müssen in Formaten vorliegen, die softwareseitig auch unterstützt werden. Zu prüfen ist ferner, ob es spezifische Inhalte gibt, zu berücksichtigen sind (z. B. Abbildungen innerhalb der Software, die mit Text versehen sind). Für den Erfolg des Lokalisierungsprojektes sind natürlich auch Anweisungen und Vorgaben von Seiten des Auftraggebers ausschlaggebend. Häufig werden all diese relevanten Informationen vom Softwarehersteller in Form eines so genannten Lokalisierungskits zur Verfügung gestellt.
Testing
Im Vorfeld der Projektanlage sollte mit dem Auftraggeber geklärt werden, ob ein Testing der fertig lokalisierten Software durchgeführt werden soll. Hierfür müssen vom Auftraggeber nach Abschluss des Projekts ggf. entsprechende Ressourcen (Installationsdateien etc.) zur Verfügung gestellt werden.
Anpassung von Tastenkombinationen
Für Tastenkombinationen, die in der Software für entsprechende Funktionen hinterlegt sind, ist im Vorfeld mit dem Auftraggeber zu klären, ob diese an die jeweilige Zielsprache angepasst werden sollen. In der Praxis werden Tastenkombinationen allerdings meist nicht lokalisiert.
Tipp: Die Standardeinstellungen der Across Translator Edition sehen vor, dass Tastenkombinationen im Rahmen der Lokalisierung angepasst werden können. Um dies zu ändern, muss die entsprechende Option in den erweiterten Einstellungen der Einstellungsvorlage der Windows-Ressourcen unter Tools → Systemeinstellungen → Dokumenteneinstellungsvorlagen → Windows-Ressourcen angepasst werden. Hierzu in der entsprechenden Einstellungsvorlage auf die Schaltfläche Erweitert klicken und die gewünschte Option wählen (z. B. Ausgeblendet).
Lokalisierung von Software mit der Across Translator Edition
Im Zuge der Projektanlage extrahiert die Across Translator Edition alle zu lokalisierenden Inhalte aus dem Programmcode. Der eigentliche Programmcode bleibt also außen vor. Dadurch kann sich der Übersetzer einerseits auf das Wesentliche konzentrieren – und andererseits kann er auch nichts Grundlegendes an der korrekten Funktionsweise der Software kaputtmachen. Die Lokalisierung einer Software ist dadurch im Grunde kein „Hexenwerk“. Dennoch gilt es ein paar Dinge zu beachten, die spezifisch für Softwarelokalisierungen sind.
Wichtig: Bei der Lokalisierung von Softwaredateien ist die Erstellung einer Vorschau in der Regel nicht möglich. Die Vorschaufunktion ist in der Oberfläche der Across Translator Edition entsprechend ausgegraut. Dies liegt daran, dass sich eine Software meist aus mehreren oder auch vielen Programmdateien zusammensetzt und eine einzelne Programmdatei somit nicht alleine lauffähig ist. Der WYSIWYG-Modus bei der Lokalisierung von Dialogen liefert aber eine Echtzeitvorschau. Bei sehr einfachen Anwendungen, die nur aus einer einzigen ausführbaren Datei bestehen, gibt es hingegen die Möglichkeit, eine WYSIWYG-Vorschau zu erstellen – siehe hierzu unten den Bereich „Tipps & Tricks“.
Zu den Dingen, die spezifisch für Softwarelokalisierungen sind, zählen:
Grafische Anpassung von Dialogelementen (WYSIWYG-Modus) #1
Für die Lokalisierung von Dialogfenstern und ihrer Bestandteile empfiehlt sich der so genannte WYSIWYG-Modus (siehe oben). Der WYSIWYG-Modus steht für die Quellsprache, aber vor allen Dingen auch für die Zielsprache zur Verfügung. Der Modus muss zunächst über das Icon in der entsprechenden Symbolleiste aktiviert werden. Die Übersetzung der Textbestandteile erfolgt jeweils im entsprechenden Eingabefeld.
Die Anpassung der Größe eines Dialogelements (z. B. eines Textfeldes, einer Dropdown-Liste, eines Kontrollkästchens oder auch einer Schaltfläche) erfolgt hingegen in der WYSIWYG-Ansicht selbst, und zwar mithilfe der quadratischen schwarzen Ziehpunkte an den Ecken und Seiten des jeweiligen Elements (wie man es beispielsweise von der Bearbeitung eines Bildes gewohnt ist). Die Position eines Dialogelements kann verändert werden, indem der Mauszeiger auf dem Dialogelement positioniert wird und man es bei gedrückter linker Maustaste an die gewünschte Position verschiebt.
Tipp: Die Qualitätsmanagement-Kriterien „Überschneidung bei Steuerelementen“ und „Textgrenzen“ helfen, Fehler bei der grafischen Darstellung von Dialogelementen zu vermeiden – siehe hierzu unten den Bereich „Tipps & Tricks“.
Grafische Anpassung von Dialogelementen (WYSIWYG-Modus) #2
Nach der Anpassung eines Dialogelements ist dessen Größe und/oder Position häufig nicht mehr einheitlich mit anderen Elementen des Dialogfensters. Um diese einheitlich anzupassen, werden die entsprechenden Elemente zunächst per Mehrfachauswahl ausgewählt (per gedrückter Strg-Taste). Anschließend können die ausgewählten Elemente über den entsprechenden Befehl aus dem Kontextmenü, das sich mit einem Klick auf die rechte Maustaste anzeigen lässt, einheitlich ausgerichtet oder auch einheitlich in der Größe angepasst werden.
Platzhalter
Platzhalter (wie z. B. %d oder %s bei Windows-Ressourcen bzw. {1} oder {2} bei .NET-Ressourcen) stehen im Bereich der Softwarelokalisierung für bestimmte Inhalte, wie Zahlen und Zahlenformate (z. B. das Änderungsdatum einer Datei) oder auch Namen (z. B. der Name einer bestimmten Datei). In Softwaretexten können Platzhalter in Status- und Fehlermeldungen vorkommen. Während der Laufzeit der Software werden die Platzhalter dynamisch durch die aktuellen Werte oder Bezeichnungen ersetzt: In der Fehlermeldung „Das Dokument %s kann nicht geöffnet werden.“ steht der Platzhalter %s z. B. für den Namen der Datei, die nicht geöffnet werden kann. Bei Verwendung des Programms wird der Platzhalter durch den jeweiligen Namen der Datei, die nicht geöffnet werden kann, ersetzt.
Wichtig: Bei der Lokalisierung der Softwaretexte ist darauf zu achten, dass die Platzhalter einerseits in die Übersetzung eingefügt werden und dass sie andererseits auch an der richtigen Position eingefügt werden. Das Einfügen der Platzhalter erfolgt dabei im Normalfall übrigens durch manuelles Tippen des jeweiligen Platzhalters.
Tipp: Das Qualitätsmanagement-Kriterium „Platzhalter“ hilft, Fehler bei den Platzhaltern zu vermeiden – siehe hierzu unten den Bereich „Tipps & Tricks“.
Hotkeys
Hotkeys, auch Zugriffstasten genannt, sind im Bereich der Softwareentwicklung und -lokalisierung Tastenkombinationen, mit denen Menübefehle oder auch Elemente in Dialogfenstern angesteuert oder ausgewählt werden können (typischerweise Alt+D zum Öffnen des Menüs Datei).
Hotkeys spielen insbesondere für die Barrierefreiheit von Software eine wichtige Rolle. In der Benutzeroberfläche von Software werden Hotkeys in Form eines Unterstriches dargestellt (z. B. Datei), softwareseitig hingegen durch ein &-Zeichen (Et-Zeichen oder auch Kaufmanns-Und, z. B. &Datei). Bei der Lokalisierung der Softwaretexte ist darauf zu achten, dass die Hotkeys bzw. die &-Zeichen in der Übersetzung an der richtigen Position eingefügt werden.
Wichtig: Die Hotkeys dürfen innerhalb eines Menüs bzw. innerhalb eines Dialogfensters nicht doppelt vergeben werden.
Tipp: Das Qualitätsmanagement-Kriterium „Hotkeys“ unterstützt dabei, Fehler bei den Hotkeys zu vermeiden – siehe hierzu unten den Bereich „Tipps & Tricks“.
Die Steuerzeichen \n und \t
Das Steuerzeichen \n steht bei Softwarelokalisierungen im Allgemeinen für einen Zeilenumbruch und ist z. B. in String-Tabellen enthalten. (Darüber hinaus kann es aber z. B. auch als Abgrenzer zwischen einem Statusleisten-Text und dem entsprechenden Tooltip fungieren.) Das Steuerzeichen \t steht hingegen für einen Tabulator und kommt für gewöhnlich in Menübefehlen vor, um den Menübefehl räumlich von der entsprechenden Tastenkombination abzugrenzen. Bei diesen Steuerzeichen ist darauf zu achten, diese auch in die Übersetzung einzufügen. Das Einfügen der Steuerzeichen erfolgt dabei im Normalfall übrigens durch manuelles Tippen des jeweiligen Steuerzeichens.
Tipp: Über das Icon \n kann das Steuerzeichen \n wahlweise als Zeilenumbruch oder als Zeichenkette in der WYSIWYG-Ansicht dargestellt werden.
Tastenkombinationen
Im Rahmen von Softwarelokalisierungen können auch Tastenkombinationen, die in der Software für bestimmte Funktionen hinterlegt sind, an die Zielsprache angepasst werden. Die entsprechenden Funktionen sind dabei in Form von IDs mit den entsprechenden Tastenkombinationen verknüpft. In der Praxis erfolgt eine Anpassung der Tastenkombinationen aber nur sehr selten. Falls diese aber durchgeführt werden soll, müssen vom Hersteller der Software die nötigen Informationen, insbesondere zur Bedeutung der IDs geliefert werden. Die Anpassung der Tastenkombinationen innerhalb der Across Translator Edition erfolgt dann im gleichnamigen Bereich der crossView.
Tipps & Tricks
QM-Prüfung
Für die Lokalisierung von Softwaredateien stehen in der Across Translator Edition spezielle Qualitätsmanagement-Kriterien (jeweils für Windows- und .NET-Ressourcen) zur Verfügung. Hierzu gehören:
- Platzhalter: Das QM-Kriterium überprüft die korrekte Verwendung von Platzhaltern.
- Hotkeys: Das QM-Kriterium überprüft, dass Hotkeys in Dialogfenstern und Menüs vergeben und, dass diese nicht doppelt verwendet wurden.
- Textgrenzen: Dieses QM-Kriterium kontrolliert, dass der Text innerhalb eines Steuerelements (z. B. eine Schaltfläche) nicht breiter als das Steuerelement selbst ist.
- Überschneidung bei Steuerelementen: Das QM-Kriterium überprüft, ob sich Steuerelemente überschneiden oder ob sich diese mit einem Gruppenfeld (d. h. ein Bereich eines Dialogfensters, der mehrere Steuerelemente enthält) überschneiden.
Anzeige von String-IDs in der crossView
Die Lokalisierung der Inhalte von String-Tabellen kann sich als problematisch erweisen, da die enthaltenen Strings ohne ihren jeweiligen Kontext übersetzt werden müssen. Eine Hilfe hierbei können die IDs der Strings liefern, anhand derer eine eindeutige Identifizierung der Strings im Zusammenspiel mit den Softwareentwicklern möglich ist. Um die String-IDs in der crossView (anstelle der String-Texte) anzuzeigen, kann über das -Icon in der Symbolleiste der Source View/Context View der Anzeige-Modus String-ID anzeigen ausgewählt werden.
Vorschauen bei einfachen Anwendungen
Bei der Lokalisierung von Software ist es im Allgemeinen nicht möglich, eine Vorschau zu generieren (siehe oben). Eine Ausnahme stellen sehr einfache Anwendungen dar, die lediglich aus einer einzigen ausführbaren Datei bestehen. Um in diesem Fall eine Vorschau erstellen zu können, ist eine Anpassung der Vorschau-Einstellungen nötig. Hierzu unter ToolsBenutzereinstellungen → Allgemein → Vorschau in der Liste der Dokumentenformate Ausführbare Datei auswählen und auf Bearbeiten klicken. Anschließend Ausführbare Datei auswählen und die Zeichenfolge „%s“ eingeben. Mit OK die Anpassung bestätigen. Nun kann über das Vorschau-Icon in der crossDesk Symbolleiste eine Vorschau der Anwendung erzeugt werden.
Magnetische Hilfslinien bei .NET-Ressourcen
Bei der Lokalisierung von .NET-Ressourcen erleichtern magnetische Ausrichtungslinien die millimetergenaue Positionierung von Dialogelementen. Zudem werden die Position und die Größe des aktuellen Dialogelements unterhalb des Target Editors angezeigt.
Schon gewusst?
Melden Sie sich für unseren Newsletter an, um Neuigkeiten von Across zu erhalten.