Skip to main content
Softwarelokalisierungskurs 5

5. Problemquellen der Lokalisierung

Bei der Übersetzung von Software sehen sich Übersetzer neuen Arten von Texten gegenüber, die von den herkömmlichen abweichen. So unterscheidet sich beispielsweise der zu übersetzende Text von Benutzeroberflächen von dem von Online-Hilfe-Dateien oder von gedruckten Handbüchern. Diese unterschiedlichen Textarten stellen für die Übersetzer bei der Softwarelokalisierung eine Herausforderung dar, hauptsächlich weil in diesen Texttypen mehr mögliche Problemquellen für Übersetzer auftreten. Übersetzer können sich jedoch nur der möglichen Probleme, die auf sie zukommen können, bewusst sein. Es ist die Aufgabe der Softwareentwickler zu versuchen, diese Problemquellen zu vermeiden oder in den Griff zu bekommen. Eine Möglichkeit, diesen Problemquellen aus dem Weg zu gehen, besteht ? noch vor der Lokalisierung ? in der Internationalisierung der Softwareanwendung. Die Internationalisierung ist der erste Schritt um sicherzustellen, dass das Produkt lokalisierbar und auf den internationalen Märkten funktionsfähig und akzeptiert ist.

Es konnten bereits viele Problemquellen der Lokalisierung identifiziert werden, wenn die Software nicht internationalisiert ist. Zum Beispiel:

Terminologie: Die nicht einheitliche Verwendung von Terminologie seitens der Sotwareentwickler oder technischen Schreiber (z.B. Verwendung von Synonymen für den gleichen Prozess oder Begriff)

Mehrdeutigkeiten: Die Verwendung des selben Namens für unterschiedliche Prozesse oder Begriffe im gleichen Kontext (z.B. Verwendung des gleichen Namens für unterschiedliche Kommandos der Benutzeroberfläche)

Verwendung von lokalen Bezügen: Besonders beim Schreiben für ein internationales Publikum ? wie es meist der Fall ist beim Schreiben von Texten für eine Softwareanwendung ?, sollten die mitgelieferten Beispiele keine lokalen Bezüge enthalten. In diesem Sinne sollten auch lokalspezifische Bezüge vermieden werden.

Text in Grafiken: Die Tatsache, dass der Text übersetzt werden muss, bedeutet hier, dass die Grafiken bearbeitet werden müssen, was eine sehr zeitaufwendige Aufgabe darstellen kann.

Abkürzungen: Es ist üblich, aus Platzgründen auf Abkürzungen zurückzugreifen, aber dies wird zu einem Problem, wenn Entwickler oder Schreiber sie nicht einheitlich verwenden.

Platz: Besonders bei Benutzeroberflächen müssen Entwickler oder Schreiber beachten, dass die Länge eines übersetzten Textes in der Regel von dem original abweicht. Daher sollte es möglich sein, Elemente (z.B. Schaltflächen) anzupassen, Dialogfelder sollten längere Texte akzeptieren und/oder im Programm sollte Speicherplatz für längere Fehlermeldungen reserviert sein.

 

Nicht-Abgrenzung von Kodierung und Text: Sehr oft ist der zu übersetzende Text in den Programmcode eingebettet. Dies stellt ein Problem dar, da bei Aktualisierung der Anwendung alle Strings wieder bearbeitet werden müssen, und da das Risiko besteht, dass Übersetzer versehentlich Kodierungen ändern oder löschen. Es ist auch schwieriger für die Übersetzer, den zu übersetzenden Text zu identifizieren, wenn dieser mit dem Programmiercode vermischt ist. Um zu überprüfen, dass Code und Text getrennt vorliegen, können Entwickler und Schreiber Evaluierungstools (z.B. Entwicklertools, Internationalisierungstools, Lokalisierungstools, usw.) verwenden.

Variablen: Bei der Verwendung von Variablen in Nachrichten sollten Entwickler und Schreiber beachten, dass die Grammatik der Zielsprache eine Neuordnung der Parameter verlangen könnte. Beispielsweise könnte das "%" in der Nachricht "% Dateien zuletzt gespeichert am % von %" je nach korrekter Wortstellung in der Zielsprache an anderer Stelle gesetzt werden müssen. Ebenso kann die grammatikalische Form (Geschlecht, Anzahl, Fall) der Elemente, die die Variablen ersetzen, variieren, z.B..

Datum-, Zeit- und Zahlenformate: Entwickler und Schreiber sollten sich auch bewusst sein, dass je nach Zielsprache oder -kultur die Gepflogenheiten in Bezug auf Datum-, Zeit- und Zahlenformat variieren können. Daher sollte an deren Anpassung gedacht werden.

(Nach Esselink, 2000 und Ottmann, 2002)

 

Weiter