Übersetzen Sie noch oder lokalisieren Sie schon?

Transkript

1 Aufgaben eines Softwarelokalisierers Übersetzen Sie noch oder lokalisieren Sie schon? Katja Müller Während in den 70er und 80er Jahren zunächst Software nur in einigen sehr speziellen Bereichen eingesetzt wurde, hält Software heute zunehmend in allen Lebensbereichen Einzug und hat sich längst auch im Übersetzerberuf etabliert. Der Softwarelokalisierer sollte offen gegenüber neuer Technik und ein Teamarbeiter sein. Wie groß der Bedarf an Spezialisten in der Softwarelokalisierung ist, zeigt sich, wenn man sich Gedanken darüber macht, was alles unter das Stichwort Software fällt. Unter Software fallen nicht nur das klassische Beispiel eines Textverarbeitungsprogramms, sondern auch spezielle Anwendungen für den Maschinenbau oder Produkte zur Planung des Fertigungsprozesses. Software wird zudem in Werkzeugmaschinen mit moderner Steuerungstechnik, sogenannten CNC-Maschinen, eingesetzt oder umfasst den Anzeigetext eines Mobiltelefons oder die Menüführung einer Kaffeemaschine. Die eigentliche Softwarekomponente, die lokalisiert werden muss, ist die Benutzeroberfläche (GUI, Graphical User Interface). Außerdem enthält komplexe Software meistens eine integrierte Online-Hilfe. Damit Endbenutzer die Software bzw. die damit laufenden Geräte bedienen können, werden Begleitdokumente bereitgestellt, deren Übersetzung ebenfalls Bestandteil der Softwarelokalisierung ist. Diese Dokumentation kann aus einem Benutzer- bzw. Bedienungshandbuch, einer Kurzanleitung oder Schnellstartanleitung bestehen. Falls die Originalsoftware auch Audioinhalte wie Kommentare oder Sprachunterstützung enthält, müssen die Audioskripts ebenfalls lokalisiert und synchronisiert werden. Zu guter Letzt kommen noch die Marketingmaterialien (Collaterals) hinzu, wie zum Beispiel die Einzelhandelsverpackung, das Begleitheft oder die Hülle der Installations-CD für die Software. Lokalisierungsprojekt gleich Projektarbeit Softwarelokalisierung ist also immer ein ganzes Paket und kann meistens aufgrund der hohen Anforderungen sowohl sprachlich als auch technisch nicht von einer einzigen Person, z. B. von einem einzigen Übersetzer, bewältigt werden. Lokalisierungsprojekte sind technisch komplex und anspruchsvoll und werden im Allgemeinen von einem Team aus Projektleiter, Techniker, Übersetzer/Lokalisierer sowie DTP-Spezialisten abgewickelt. Das Zusammenspiel aller Beteiligten beeinflusst die Qualität der lokalisierten Software entscheidend. Denn wenn der Lokalisierer zwar eine qualitativ hochwertige Übersetzung liefert, jedoch technische Fehler in der Software nicht behoben werden, ist dies trotz einer einwandfreien Übersetzung Grund für Unzufriedenheit beim Kunden und Endbenutzer. Übersetzer sind in der Lokalisierungsbranche, ob freiberuflich oder festangestellt, also alles andere als Einzelkämpfer. Die einzelnen Mitglieder im Team müssen eng zusammenarbeiten und ständig in Kontakt stehen, damit Probleme schnell erkannt und sinnvolle Lösungen rasch gefunden werden und der Erfolg des Projekts durch Missverständnisse nicht gefährdet wird (die Aufgaben der Projektmitglieder haben wir in Tab. 1 aufgelistet). Diese vielfältigen Aufgaben lassen erahnen, dass der als Softwarelokalisierer tätige Übersetzer mehr als nur Übersetzungskompetenz benötigt. Softwaretechnische Fachkenntnisse sowie ein grundlegendes Verständnis der DTP-Arbeit sind dabei genauso wichtig wie wirtschaftliches Denken bei der Unterstützung des Projektleiters oder Führungsqualitäten bei der Leitung eines Übersetzungsteams. Der Lokalisierer kann in alle Projektphasen involviert sein, und der Aufgabenbereich kann sich von Projekt zu Projekt unterschiedlich gestalten. Zu Beginn des Projekts stellt der Projektleiter sein Team aus Übersetzern, Technikern und DTP-Spezialisten zusammen und handelt mit dem Kunden einen Budget- sowie Zeitplan aus. Anschließend wird aus den binären Ausgangsformaten (z. B. DLL, EXE) der zu übersetzende Text extrahiert (Dateivorbereitung/-aufbereitung). 1 So können die Inhalte auch in einem übersetzungsfreundlichen Format bereitgestellt werden, und da der Programmcode fehlt, wird er weder versehentlich übersetzt noch geändert. Ein veränderter Programmcode kann dazu führen, dass die spätere Software Funktionsstörungen aufweist, im Fachjargon oft als build break bezeichnet. Für die Übersetzung der Software stehen dem Übersetzer Lokalisierungswerkzeuge zur Verfügung, u. a. Alchemy Ca- Aus Copyright-Gründen extrahieren viele Kunden selbst den zu lokalisierenden Inhalt, da der Programmcode durch das Urheberrecht geschützt ist und ungern aus der Hand gegeben wird. 44

2 talyst, SDL Passolo, Visual Localize oder RC-WinTrans. Zwar kämen auch gängige CAT-Tools wie SDL Trados oder Across in Frage, aber Softwarelokalisierungstools bieten den entscheidenden Vorteil, dass sie spezielle Vorschau- und QA-(Qualitätssicherungs-)Funktionen aufweisen, die dem Lokalisierer das Übersetzen von kontextlosen Texten enorm erleichtern. So werden in RC-WinTrans (Abb. 1) oder Catalyst beim Übersetzen der Textsegmente der Softwareoberfläche zusätzliche Informationen zu den einzelnen Segmenten angezeigt, z. B. der Segmenttyp Schaltfläche oder Dialogfeld. Darüber hinaus kann man jederzeit in den Vorschaumodus wechseln, um zu sehen, um welche Art von Segment es sich hier handelt (Kontrollkästchen, Optionsschaltfläche, Textfeld usw.). Die speziellen QA-Funktionen hingegen erlauben es, softwarespezifische sprachliche Besonderheiten, die während der Übersetzung einzuhalten sind, maschinell prüfen zu können. Eine solche Besonderheit ist z. B. die Längenbeschränkung. So kann in einem Projekt die Vorgabe lauten, die Anzahl der Zeichen im Quellsegment einzuhalten (d. h., die Übersetzung darf nicht länger sein als das Ausgangssegment) oder nur um einen bestimmten Prozentsatz (z. B. 10 % der Zeichen im Quellsegment) zu überschreiten (siehe Abb. 2). So kurz wie möglich und so lang wie nötig Häufig müssen Lokalisierer bei der Einhaltung der Längenbeschränkung in die Trickkiste greifen, um die Übersetzungen ohne Inhalts- und Verständnisverlust zu kürzen. Dabei dürfen nicht einfach wahllos Wörter abgekürzt werden, sondern die Übersetzung sollte vorsichtig und sinnvoll gekürzt werden. Es ist zu überlegen, ob nicht durch eine andere grammatische Struktur oder durch Wahl anderer Termini eine kürzere Übersetzung erzielt werden kann. Bei Letzterem muss der Übersetzer jedoch darauf achten, dass durch das Austauschen von Benennungen keine verbindliche Terminologie verletzt wird, die dem Lokalisierer vom Kunden in Form von Terminologiedatenbanken zur Verfügung gestellt und zwingend einge- Abb. 1: Ausschnitt aus der Benutzeroberfläche von RC-WinTrans, die zusätzliche nützliche Informationen zu den Übersetzungseinheiten wie Type oder Name/ID zur Verfügung stellt Abb. 2: Automatische Angabe der eingegebenen Zeichen im Zielsegment (rechts) in RC-WinTrans. In diesem Beispiel beträgt die französische Übersetzung 33 Zeichen, wohingegen das Quellsegment 29 Zeichen lang ist Die Tücken der Lokalisierung meistern Der Bedarf an Softwarelokalisierungsleistungen steigt kontinuierlich. Zusätzlich zu den Übersetzungsfertigkeiten sollte ein Lokalisierer die Arbeit mit Softwareprogrammen als willkommene Herausforderung sehen, gerne im Team arbeiten und belastbar sein. Er wird dann mit abwechslungsreichen Projekten belohnt. Allerdings muss er die Tücken der Softwarelokalisierung wie Längenbeschränkung, Beachtung der Interpunktion, Variablen, Steuerzeichen und Hotkeys meistern. Über den gesamten Lokalisierungsprozess einschließlich der Tests arbeitet er eng mit dem Projektleiter, den Technikern sowie DTP-Spezialisten zusammen. Overcoming the pitfalls of localization The demand for software localization is constantly increasing. A localizer should relish using his/her translation skills, welcome the challenge of dealing with software programs, enjoy working in a team, and be capable of performing well under pressure. A person with these abilities will be rewarded with a variety of interesting projects but will also have to overcome the pitfalls of localization. These include restrictions on text length, as well as the need for attention to punctuation, variables, control characters and hotkeys. Throughout the localization process, including the test phase, the localizer will work closely with the project manager, technicians and DTP specialists. Maîtriser les pièges de la localisation Le besoin en prestations concernant la localisation de logiciels augmente constamment. En plus de ses compétences au niveau de la traduction, un localisateur devrait considérer le travail avec des logiciels comme un défi nouveau, estimer le travail en équipe et être performant. Il sera alors récompensé par des projets variés. Toutefois, il doit maîtriser les pièges de la localisation de logiciels tels que limitations de longueur, respect de la ponctuation, de variables, de caractères de commande et de raccourcis clavier. Durant tout le processus de localisation, tests inclus, il travaille étroitement avec le chef de projet, les techniciens ainsi qu avec les spécialistes PAO. 45

3 Interpunktionszeichen Original (Englisch) Übersetzung (Deutsch) Anführungszeichen Klammern Doppelpunkt Punkt am Satzende Fehlender Punkt am Satzende Doppelte Punkte (Ellipsen) Leerzeichen (Leading/trailing spaces) To obtain your profile click Get Profile button. Size (W x H) Are you sure you want to copy {0}? Unable to open database at [{0}] Failed to save the file, with the message: Error. The file has been corrupted Export... Checking.. _export failed Loading failed._ Abb. 3: Beispiele für wichtige Interpunktionszeichen, auf die besonders geachtet werden muss Um Ihr Profil zu erhalten, klicken Sie auf die Schaltfläche Get Profile. Größe (B x H) Soll {0} wirklich kopiert werden? Öffnen der Datenbank auf [{0}] nicht möglich Datei konnte nicht gespeichert werden, mit der Nachricht: Fehler. Die Datei ist fehlerhaft Exportiert... Prüfung läuft.. _Export fehlgeschlagen Laden fehlgeschlagen._ halten werden müssen. Manchmal reicht es bereits, Pronomen und Fürwörter zu streichen, die für das Verständnis des Segments nicht so wichtig sind (Datei erstellt statt Die Datei wurde erstellt). Wenn das Segment dann immer noch zu lang ist, können einzelne Wörter sinnvoll abgekürzt werden, die Abkürzungen müssen aber für den Nutzer der Software später noch nachvollziehbar sein. Beispielsweise gelten im Deutschen u. a. die Regeln, dass Abkürzungen nicht mit einem Vokal enden sollen (erfolgr. statt erfolgre.), dass mehr als nur der letzte Buchstabe eines Worts weggelassen werden soll (Webvorl. statt Webvorlag.) oder bei einer Silbe mit Doppelkonsonanten die Doppelkonsonanten erwähnt werden müssen ( - Einstell. statt -Einstel.). Punkt, Komma, Strich vergiss mich nich! Bei der Interpunktion gibt es ebenfalls bestimmte Regeln, da diese großen Einfluss auf die später kompilierte Software hat. In Softwaretexten werden normalerweise nicht die runden deutschen Anführungszeichen ( ) wie in Dokumentationen üblich verwendet. Welche Anführungszeichen der Übersetzer verwenden darf, hängt vom Dateiformat und vom Programm ab. Gängig sind die einfachen, geraden Anführungszeichen ('). Bei Klammern muss sich der Übersetzer ebenfalls am Quellsegment orientieren, denn eine Verwendung von anderen Klammern als im Ausgangstext kann zur Folge haben, dass die Software später Funktionsstörungen aufweist. Den Satzzeichen am Satzende muss besondere Beachtung geschenkt werden, da es bei der Softwarelokalisierung normalerweise nicht erwünscht ist, dass der Übersetzer nach Belieben bzw. nach den gängigen Rechtschreibregeln der Zielsprache einen Punkt oder Doppelpunkt am Ende des Satzes verwendet. Die Interpunktion muss aus dem Quellsegment exakt übernommen werden, da nach einem Doppelpunkt oder Punkt später noch Text folgen kann. So müssen beispielsweise bei den beiden Segmenten Failed. und Try again. in der Übersetzung auch Punkte gesetzt werden, auch wenn dies nach einem unvollständigen Satz in der Zielsprache unüblich ist. Der Grund liegt darin, dass die Segmente beim Übersetzen zwar in unterschiedlichen Übersetzungsdateien vorkommen, aber später in der Software in einer Zeile als Fehlgeschlagen. Versuchen Sie es noch einmal. angezeigt werden können. Dies gilt auch für Leerzeichen, die im Ausgangssegment an den Anfang und/oder an das Ende gesetzt werden. In Softwarelokalisierungswerkzeugen werden diese Leerzeichen häufig als Unterstrich dargestellt, um zu verhindern, dass Leerzeichen übersehen werden. Auch zwei oder drei Punkte am Satzende (Ellipsen) sind keine Fehler im Ausgangssegment, sondern Absicht, und stellen eine Verlaufsanzeige bzw. einen Fortschrittsbalken (progress bar) dar. Abb. 3 gibt einen Überblick über diese Interpunktionszeichen. Variablen und Steuerzeichen Charakteristisch für Software sind die vielen Variablen und Steuerzeichen, mit denen Softwarelokalisierer vertraut sein müssen. Variablen (in Form von %s, %d, %1, {0}, {1} usw.) dürfen weder in der Übersetzung ausgelassen noch übersetzt oder verändert werden, da diese einen Ausdruck ersetzen. Allerdings muss der Übersetzer genau überlegen, wo er die Variable in der Übersetzung platziert, damit später beim Ersetzen der Variable durch den entsprechenden Begriff der Satz grammatikalisch noch sinnvoll ist. In den meisten Fällen ist leider nicht bekannt, wodurch die Variable später ersetzt wird. Bei File {0} cannot be saved ist es noch verhältnismäßig leicht zu erkennen, dass die Variable {0} durch den Dateinamen ersetzt wird, daher ist die deutsche Übersetzung mit Datei {0} kann nicht gespeichert werden angemessen. Kniffliger wird es schon bei folgendem Segment: Faulty %d to be deleted? Durch die Anpassung der Adjektive an die Substantive im Deutschen ist es unmöglich, das Segment mit Soll fehlerhaftes %d gelöscht werden? wiederzugeben, da %d für Datei (f.), Dokument (n.) oder Server (m.) stehen kann. Unter Umständen wird dieser String später mehrfach an unterschiedlichen Stellen in der Software mit jeweils einer anderen Ersetzung verwendet. Da Konstruktionen wie Fehlerhafte/ s/r unschön sind und vermieden werden sollen, ist die Formulierung %d fehlerhaft. Löschen? eine mögliche Lösung des 46

4 Abb. 4: Hotkeys werden in der kompilierten Software mit einem Unterstrich gekennzeichnet, z. B. der Buchstabe M der Option Makros anzeigen Problems, denn die Variable kann hier durch ein Subjekt jeden Geschlechts ersetzt werden. Vor solchen Herausforderungen stehen selbstverständlich nicht nur Übersetzer für die deutsche Sprache, ähnliche Probleme gibt es in jeder Sprachkombination. Steuerzeichen hingegen sind keine Variablen, sondern Zeichen, die der Software mitteilen, wie der Text dargestellt werden soll. Steuerzeichen sind zum Beispiel \n für den Zeilenumbruch oder \t für den Tabulatorsprung. Diese Zeichen müssen in der Übersetzung sinnvoll und an die richtige Stelle gesetzt werden. Wer die wichtigsten Steuerzeichen und deren Bedeutung kennt, wird in der Zeichenkette Soll\nein Dokument gespeichert werden? nicht das Wort nein, sondern das Steuerzeichen für den Zeilenumbruch und das Wort ein erkennen. Hotkeys eine heiße Angelegenheit Durch das Drücken bestimmter Tasten auf der Tastatur kann der Benutzer seiner Software den Befehl übermitteln, eine bestimmte Aktion durchzuführen. So wird in vielen ins Deutsche lokalisierten Programmen durch Drücken der Tasten STRG+S ein Speichervorgang durchgeführt. Tastenkombinationen (Tastaturbefehle oder auch Tastaturkürzel) sind weder allgemeingültig noch standardisiert und werden daher für jede Software neu festgelegt, auch für jede neu lokalisierte Software. Welcher Buchstabe für die Tastenkombination verwendet wird, kann während der Übersetzung festgelegt werden, aber die Hotkeys müssen während der Testphase nach der Kompilation der Software vom Techniker geprüft bzw. neu Abb. 5: Dialog feld in RC-WinTrans, in dem der Übersetzer für eine QA-Prüfung der Softwareübersetzung verschiedene Optionen auswählen kann. Die gefundenen Fehler werden in einem Fehlerbericht aufgelistet und können so schnell vom Übersetzer korrigiert werden festgelegt werden, da der Übersetzer die Software selten als Ganzes vorliegen hat und in einem Dialogfeld möglicherweise ein- und denselben Buchstaben für unterschiedliche Aktionen als Hotkey festlegt. Ein Beispiel für Hotkeys im Deutschen finden Sie in Abb. 4. In den Dateien, die der Lokalisierer zum Übersetzen bekommt, wird der Hotkey als &-Zeichen gekennzeichnet. In der Originalsoftware liegt der Hotkey bei der Option Clear Pr&oject auf dem Buchstaben O. Der Benutzer der Originalsoftware kann demnach über den Buchstaben O auf seiner Tastatur das Projekt löschen. Hier bietet es sich an, in der deutschen Übersetzung den Hotkey auf den Buchstaben l zu legen: Projekt &löschen. Beim Festlegen der Hotkeys haben Übersetzer und Techniker (fast) freie Hand. Prinzipiell kann jeder beliebige Buchstabe gewählt werden, aber es gibt auch für das Festlegen von Hotkeys einige Regeln zu beachten. Hotkeys sollten nie bei Sonderzeichen (z. B. ö, ñ, ğ, ř, ð, š, ë, æ) gesetzt werden. Zum einen sind diese Zeichen nicht auf jeder Tastatur verfügbar für fast jede Zielsprache gibt es eine passende Tastatur oder sie befinden sich auf der Tastatur der Zielsprache an einer anderen Stelle (z. B. befindet sich das Z auf der deutschen Tastatur dort, wo auf der englischen Tastatur das Y ist). Zum anderen kann dadurch auch die Lesbarkeit beeinträchtigt sein. Aus diesem Grund sollten Buchstaben vermieden werden, die mit Unterstrich schlecht lesbar wären (z. B. g, j, y, q, ÿ, þ, ß,ç,ą). Ein kleiner Tipp am Rande: Soll in der Übersetzung das &-Zeichen als richtiger Text verwendet werden, kann man eine versehentliche Umwandlung in einen Hotkey vermeiden, indem man && einfügt. So wird die Übersetzung Partner&&Sohn später in der Software als Partner&Sohn anstelle von PartnerSohn angezeigt. Sorgfalt ist gut, Kontrolle ist besser Die oben beschriebenen Tücken der Softwarelokalisierung Längenbeschränkung, Interpunktion, Variablen, Steuerzeichen und Hotkeys sind nur eine kleine, feine Auswahl der sprachlichen Besonderheiten, die bei der Softwarelokalisierung auftreten können. Sie können wie eingangs erwähnt in den Softwarelokalisierungswerkzeugen über integrierte QA- Funktionen geprüft werden, welche den Übersetzer auf formale Fehler aufmerksam machen, die beim Übersetzen schnell passieren und beim Lektorat leicht übersehen werden. In RC-WinTrans ist es möglich, die Übersetzung daraufhin zu prüfen, ob alle Hotkeys gesetzt wurden, die Interpunktion mit dem Original übereinstimmt und die Anzahl und Art der Variablen sowie alle Steuerzeichen in die Übersetzung korrekt übernommen wurden (siehe Abb. 5). Selbst die übersetzten 47

5 Segmente, die eine maximale Längenvorgabe überschreiten, können über ein spezielles Makro herausgefiltert und somit nachträglich korrigiert werden. Dreimal -ing: Testing, Bug-Fixing und Regression-Testing Sobald die Übersetzung und dazugehörige Aufgaben wie Lektorat oder Qualitätsprüfungen abgeschlossen sind, setzt der Techniker aus den Übersetzungsdateien die lokalisierte Software zusammen. Damit ist die Arbeit für den Lokalisierer noch nicht getan, denn jetzt schließt sich das Testen der fertig übersetzten Software an. Das Testen von Software durchläuft drei Phasen: das Testing ( Testen der Software) und Bug-Reporting (Dokumentieren von Fehlern), das Bug-Fixing (Fehlerbehebung) und das Regression- Testing (Überprüfung der behobenen Fehler). Das Suchen nach Fehlern obliegt häufig dem Softwarelokalisierer. Der Techniker korrigiert die gefunden Fehler direkt in der kompilierten Software (Beispiele für mögliche Fehler siehe Abb. 6). Das Testen der Software darf nicht mit einem sprachlichen Lektorat verglichen werden, das während des Übersetzungsprozesses bereits stattgefunden hat, sondern der Lokalisierer muss hier auf folgende Punkte achten: Wurde alles in die Zielsprache übersetzt? Sind noch unübersetzte Zeichenketten zu finden? Wurde konsistent übersetzt? (Zum Beispiel sollte eine Option in einem Menü mit der Überschrift des aufgerufenen Dialogfelds übereinstimmen.) Ist alles gut lesbar, d. h. wurde auch kein Text abgeschnitten bzw. passt der Text in die Schaltfläche, in das Optionsfeld usw.? Wurde kein Hotkey doppelt vergeben? Und zu guter Letzt ganz wichtig: Funktionieren alle Funktionen, Aktionen, Abläufe und Vorgänge? Da es aufgrund des Zeit- und Kostenaufwands selten der Fall ist, dass die komplette Software getestet werden kann, kommen überwiegend zwei verschiedene Ansätze zum Einsatz. Eine mögliche Variante für weniger komplexe und umfangreiche Software ist die, dass der Lokalisierer unter Angabe eines Zeitbudgets möglichst viele Funktionen der Software testet und anschließend im sogenannten Bug-Report einem Fehlerbericht im Excel-Format zum Beispiel oder über eine spezielle Software zum Erfassen von Fehlern, auch Issue-Tracker genannt, die Fehler dokumentiert. Als Voraussetzung dafür, dass der Techniker die Fehler finden und rekonstruieren kann, muss genau beschrieben werden, wie der Lokalisierer sich durch die Software bewegt hat. Dies ist recht zeitaufwändig, wenn man bedenkt, dass viele Softwarefunktionen aufeinander aufbauen. Bei einer sehr komplexen Software, für die Fachkenntnisse oder Schulungen erforderlich sind, empfiehlt es sich, dass der Kunde einen sogenannten Testplan erstellt und angibt, Abb. 6: Dialog feld mit mehreren Fehlern: Die Übersetzung Verbindung automatisch herstellen ist zu lang und kann daher nicht vollständig angezeigt werden. Sie muss gekürzt werden. Außerdem ist Password noch unübersetzt und der Hotkey für Domäne wurde auf ein Sonderzeichen gesetzt welche Funktionen getestet werden sollen. In einem solchen Testplan wird meistens auch sehr genau beschrieben, welche Schritte der Lokalisierer in der Software durchführen muss, um zur einen oder anderen Funktion zu gelangen. In vielen Fällen müssen zunächst Daten eingegeben, Profile erstellt, Schaltpläne gezeichnet oder Baupläne generiert werden, damit bestimmte Funktionen überhaupt verfügbar sind. Technische Fehler werden anschließend vom Techniker behoben, sprachliche Fehler werden sowohl vom Übersetzer in die Übersetzungsdateien, Translation-Memorys, Glossare usw. als auch vom Techniker entsprechend den Vorgaben des Lokalisierers in der Software korrigiert, da diese nicht noch einmal neu kompiliert wird. Im Idealfall wird als Erstes die Softwarekomponente des Gesamtpakets übersetzt, damit die lokalisierte Software anschließend für die Online-Hilfe und alle anderen Dokumentationen als Referenz dienen kann. Eine kurze Produkteinführungszeit (Time-to-Market) hat für Kunden oft höchste Priorität, und Ziel ist es, die lokalisierten Versionen zeitgleich mit der Originalsoftware auf den Markt zu bringen. Wenn also während des Testens der Software bereits die Übersetzung der Dokumentation begonnen hat und der Übersetzer noch Fehler sprachlicher Natur gefunden hat, wodurch die entsprechende Softwareoption noch einmal geändert oder gekürzt werden muss, müssen diese nachträglichen Änderungen genau dokumentiert und dem Übersetzungsteam mitgeteilt werden, um die Konsistenz zwischen Software und Dokumentation zu wahren. Lokalisierungsteams stehen daher stets vor der Herausforderung, ein komplexes Projekt in einem sehr engen Zeitrahmen bewältigen zu müssen, ohne dass dabei die Qualität beeinträchtigt wird. Es ist nicht unüblich, dass aufgrund eines engen Kosten- oder Zeitplans nur ein Teil der gefundenen und gemeldeten Fehler behoben werden kann. In einem solchen Fall muss der Lokalisierer auch in der Lage sein, einen wichtigen von einem unwichtigen Bug zu unterscheiden. Alle Fehler, die die Funktionalität und das Benutzererlebnis beeinträchtigen, sind weitaus schwerwiegender als beispielsweise Rechtschreib- oder Kommafehler. Nach 48

6 9909_3_08_LES_titel.indd :27:07 Uhr Te c h n i k i m B e r u f Anzeige Lebende Sprachen Zeitschrift für fremde Sprachen in Wissenschaft und Praxis Abb. 7: Beispiel für eine Inkonsistenz zwischen tatsächlicher Softwareoption und Dokumentation in der Outlook 2007-Hilfe. Die Bildschirmkopie der Software zeigt, dass die Option Keine Füllung lautet, in der Dokumentation wird jedoch mit Keine Farbe auf diese Option Bezug genommen dem Testing und Bug-Fixing kann sich noch ein Regression-Testing anschließen, bei dem geprüft wird, ob die Fehler tatsächlich behoben wurden. Auf die Software folgt die Dokumentation Wie bereits erwähnt, werden die Online-Hilfe und die Dokumentationen erst nach der Software übersetzt. Grund hierfür ist, dass die Software für beides als Referenz dient, da die in der Online-Hilfe und der Dokumentation erwähnten Softwareoptionen mit den entsprechenden Optionen in der eigentlichen Software übereinstimmen müssen. Oberste Regel ist deshalb, dass Optionen in Dokumentationen nie nach Lust und Laune übersetzt werden dürfen. Jede einzelne Option muss in der Software nachgeschlagen und die dort verwendete Übersetzung übernommen werden. Die Software steht dem Übersetzer dabei in Form eines Translation-Memorys zur Verfügung, aber auch ein Glossar oder eine Terminologiedatenbank wären denkbar. Unerfahrene Übersetzer machen häufig den Fehler, Softwareoptionen in der Dokumentation zu korrigieren (vgl. Inkonsistenz in Abb. 7). Die Übersetzung der Option muss exakt übernommen werden, auch wenn diese fehlerhaft ist, Rechtschreibfehler enthält oder falsch übersetzt wurde. 2 In der Dokumentation kommt es darauf an, dass der Endbenutzer mithilfe dieser Dokumentation die Software bedienen und die Optionen in der Software wiedererkennen kann. Fehlerhafte Optionen können natürlich vom Übersetzer dokumentiert werden. Eventuell können Fehler noch in der Software und somit auch in der Dokumentation korrigiert werden, dies hängt jedoch sehr stark vom Zeitplan ab und ist letztendlich auch eine Kostenfrage. Eine terminologische Änderung einer einzigen Option kann zur Folge haben, dass weitere Optionen durch diese eine Änderung ebenfalls geändert werden müssen. Der Arbeitsaufwand kann explodieren, wenn Hunderte oder Tausende von Dateien durchsucht, die ent- 2 Das Lektorat und/oder zusätzliche sprachliche Prüfungen werden im Anschluss an die Übersetzung der Software durchgeführt. Sobald die Software als final erklärt wird und mit der Übersetzung der Dokumentation begonnen wird, sind nachträgliche Korrekturen der Softwareübersetzung nur noch schwer möglich, da die Software weiterverarbeitet (kompiliert) wird. In Lebende Sprachen finden Sie Aufsätze zu vorwiegend anwendungsbezogenen Themen im Zusammenhang mit Sprachen sowie Glossare, Rezensionen und verschiedene informative Rubriken. Sie können Lebende Sprachen im Abo beziehen oder auch einzelne Hefte für je 17,50 zuzüglich Versandkosten über die unten angegebene Adresse oder jede Buchhandlung bestellen. BDÜ-Mitglieder erhalten einen Rabatt. Das Inhaltsverzeichnis der aktuellen Ausgabe sowie eine Vorschau auf das nächste Heft finden Sie unter Ausgabe 3/2008 ist Mitte September erschienen. Preise ISSN Jahresabonnement: 62,90 Ermäßigtes Abonnement für BDÜ- Mitglieder: 54,90 Einzelheft: 17,50 (Preise zuzüglich Versandkosten: Inland 4, Ausland 12) Bestellungen Langenscheidt KG Abt. Vertriebsservice Postfach München Tel.: (089) Fax: (089) kundenservice@langenscheidt.de (oder über jede Buchhandlung) A Lebende Sprachen ZEITSCHRIFT FÜR FREMDE SPRACHEN IN WISSENSCHAFT UND PRAXIS zugleich Fachblatt des Bundesverbandes der Dolmetscher und Übersetzer e.v. (BDÜ) Begründet von Alexander Lane Herausgegeben von Peter A. Schmitt und Reinhold Werner 53. Jahrgang Heft 3/2008 Aufsätze H. J. Vermeer: Gedanken zu Kristmannssons translation without an original beinahe eine Rezension 98 P. Baumgartner/R. Kraus: Die sprachliche Abbildung von Ursache-Wirkung-Beziehungen in englischen und deutschen technischen Texten 109 S. Pöllabauer: Forschung zum Dolmetschen im Asylverfahren: Interdisziplinarität und Netzwerke 121 Glossare T. Ischganeit: Bagger-Glossar (DE EN) (1. Teil) 130 Fachliteratur E. Lück: Neuerscheinungen auf dem Fachwörterbuchmarkt 139 Rezensionen 140 Umschau

7 Katja Müller 2003 Abschluss als Diplom-Fachübersetzerin (FH ) für Englisch und Französisch an der Hochschule Anhalt (FH ) in Köthen. Anschließend von 2003 bis 2006 festangestellte Übersetzerin bei SDL International am Hauptsitz in Maidenhead/Großbritannien sowie von 2006 bis Januar 2008 bei der Locatech GmbH, einem in Dortmund ansässigen Lokalisierungsunternehmen. Seit Februar 2008 freiberufliche Übersetzerin mit der Spezialisierung IT, Informatik und Softwarelokalisierung. sprechende Option sowie alle mit ihr verwandten Optionen korrigiert und diese Änderungen wenn die Software bereits kompiliert ist vom Techniker in der Software noch einmal nachgezogen und die entsprechenden Stellen erneut getestet werden müssen. Deshalb ist es nicht unüblich, dass nach eingehender Aufwandsabschätzung durch den Lokalisierer und nach Absprache mit dem Projektleiter und dem Kunden entschieden wird, dass bestimmte Fehler erst im nächsten Update der Software korrigiert werden und der Fehler in der aktuellen Version noch beibehalten wird. Gerade in einem solchen Fall ist es unabdingbar, dass die Übersetzer die fehlerhaften Optionen exakt übernehmen, damit diese zu einem späteren Zeitpunkt in allen Dokumenten problemlos und vollständig ausgetauscht werden können. In solchen Situationen kommt dem erfahrenen Lokalisierer eine Beratungsfunktion zu, da nur er den tatsächlichen Aufwand von sprachlichen Änderungen abschätzen kann. Dabei ist die Korrektur eines Tippfehlers viel weniger zeit- und kostenintensiv als eine terminologische Änderung eines Schlüsselbegriffs. Er kann daher dem Projektmanager von Änderungen abraten oder unkomplizierte Fehler zur Korrektur in der Software und Dokumentation freigeben. Online-Hilfe und Desktop-Publishing Nach der Lokalisierung der Online-Hilfe ist wieder die Kompetenz des Technikers gefragt, der die Hilfe aus den Übersetzungsdateien kompiliert, da diese Hilfe in die Software integriert ist. Das Testen der kompilierten Online-Hilfe verläuft ähnlich wie bei der Software. Der Schwerpunkt liegt hier wieder weniger auf dem sprachlichen Lektorat, sondern darauf, ob alle Links funktionieren, die Querverweise konsistent sind, ob Format und Layout in Ordnung sind und ob das Stichwortverzeichnis richtig erstellt wurde. Alle anderen Dokumentationen wie Benutzerhandbuch, Kurzanleitung, Marketingmaterialien usw. werden hingegen vom DTP-Spezialisten in der Zielsprache bis zur Publikationsreife bearbeitet. Er erstellt das Inhalts- und Stichwortverzeichnis, bearbeitet und korrigiert das Layout und führt gegebenenfalls eine automatische Silbentrennung durch. Die fertigen Dokumente werden dem Lokalisierer aufgrund seiner Sprachkompetenz ebenfalls zur Schlussprüfung vorgelegt, um letzte Fehler zu korrigieren. DTP- Spezialisten beherrschen nicht immer die Sprache des Zieldokuments und sind daher auf die Hilfe und Unterstützung des Sprachspezialisten angewiesen. Auch bei Muttersprachlern ist es ratsam, den Softwarelokalisierer zu Rate zu ziehen, da dieser für die finale Übersetzungsqualität verantwortlich ist. Wieder wird geprüft, ob alles übersetzt wurde und das Layout in Ordnung ist. Befinden sich alle Formatierungen an der richtigen Textstelle? Darüber hinaus wird bei Druckdokumenten besonders auf die korrekte Silbentrennung geachtet, auf die richtigen Seitenzahlen sowie auf die Konsistenz zwischen Inhaltsverzeichnis und Überschriften im Dokument sowie die korrekte Erstellung des Stichwortverzeichnisses. Bei Marketing-Materialien wie Verpackung, CD-Hülle oder Begleitheft ist es ganz wichtig, dass das Layout konsistent und die Sprache stimmig ist. Bei diesen Dokumenten fallen der Text und das Layout dem Käufer besonders ins Auge. Fehler im Layout und in der Sprache fallen sofort auf und halten den Käufer eventuell vom Kauf des Produkts ab, was beim Kunden zu Umsatzeinbußen führen kann. Die Faszination des Berufs Softwarelokalisierer machen neben der sprachlichen Übersetzungskompetenz und dem technischen Hintergrundwissen vor allem die vielseitigen Aufgabenbereiche aus. Der Lokalisierer agiert als Übersetzer sowie als Sprachexperte und Berater für die Anpassung eines Softwareprodukts an einen Zielmarkt und bis zu einem gewissen Grad auch als Techniker und DTP-Spezialist. Die Herausforderung liegt darin, dass jedes Lokalisierungsprojekt unter unterschiedlichen Bedingungen abgewickelt wird und man sich als Lokalisierer immer wieder neu auf ein Projekt einstellen muss. Die direkte Beteiligung an der wochen- und monatelangen Lokalisierung einer neuen Software mit allen dazugehörigen Komponenten ist äußerst spannend. Wer also als Übersetzer den Schritt zum Softwarelokalisierer wagt, arbeitet in einem Tätigkeitsfeld mit besten Zukunftsaussichten und wird mit interessanten und abwechslungsreichen Projekten belohnt. 50