Zweifellos bin ich nicht die erste Person, die das sagt, aber die Softwarelokalisierung unterscheidet sich auf viele Arten von der traditionellen Dokumentübersetzung.

Viele Unternehmen und professionelle Übersetzer haben eine Definition des Begriffes „Softwarelokalisierung“ formuliert, die in etwa so lauten könnte: Die Softwarelokalisierung sollte als Anpassung eines Softwareproduktes an die linguistischen, kulturellen und technischen Notwendigkeiten eines bestimmten Zielpublikums verstanden werden. Mit anderen Worten: Es geht dabei nicht nur um die Übersetzung des Textes, sondern auch um die Anpassung der Funktionalität einer Softwareanwendung.

Technischen Rahmenbedingungen

Die Softwarelokalisierung ist weit mehr durch die technischen Rahmenbedingungen geprägt, als etwa die traditionelle Dokumentübersetzung. Längenbeschränkungen sind vielleicht die bekannteste dieser Rahmendingungen, die beachtet werden müssen, wenn Softwarestrings übersetzt werden. Die Übersetzungen von Bezeichnungen für Schaltflächen, Bildschirme, Dialogfelder usw. sollten in die entsprechenden Felder passen. Das klingt selbstverständlich, kann aber sehr problematisch werden. Außerdem wissen wir alle, dass die französische Sprache mit sehr viel „Crème fraîche“ garniert ist. Oder dass Spanisch sprechende Personen ihre Sätze mit redundanten Wörtern vollstopfen, ohne irgendetwas von Bedeutung zu sagen.

Ein weiteres Beispiel für eine Regel der Softwarelokalisierung ist die richtige Anpassung der Abkürzungstasten. Jede Abkürzungstaste muss im Dialogfeld oder Menü der Zielsprache eindeutig sein und eine deutliche Verbindung mit der auszuführenden Aufgabe aufweisen.

Die oben erwähnten Beispiele sind sehr grundlegend und relativ einfach zu implementieren, aber im Laufe eines Softwarelokalisierungsprojektes können unerwartete Hindernisse (oder sogar unangenehme Überraschungen) auftauchen. Was ist zum Beispiel das beste Verfahren im Umgang mit Arabisch (oder anderen Sprachen, die von rechts nach links gelesen werden)? Wie sollten hartcodierte Datenformate verarbeitet werden, wenn die Lokalisierungsumgebung diese scheinbar nicht unterstützt?

Wenn mehrere dieser Faktoren, sowohl linguistische als auch technische, im Laufe eines Softwarelokalisierungsprojektes zusammenkommen, kann es sich in eine komplexe und aufwendige Aufgabe verwandeln, die einen genauen Fokus und das ausgeruhte Herangehen alle involvierten Personen erfordert. Das gilt nicht nur für die Übersetzer, sondern auch (und insbesondere) für die Programmierer, Projektmanager und QA-Spezialisten.

Softwarelokalisierungs-Tools

Bei Yamagata Europe haben wir regelmäßig mit Softwarelokalisierungsprojekten zu tun. Zu diesen Projekten gehören nicht nur die eigentlichen Übersetzungsaufträge, sondern auch Schulungen und die Problembehebung. Die praktischen Erfahrungen, die ich gesammelt habe, seitdem ich im Januar 2013 hier angefangen habe, haben mich gelehrt, dass der angemessene Einsatz eines Softwarelokalisierungs-Tools sehr wichtig ist, damit alles effizient abläuft. Die wichtigsten Tools, die bei Yamagata Europe zum Einsatz kommen, sind SDL Passolo und Alchemy Catalyst. Diese Lokalisierungsplattformen bieten eine große Bandbreite an Anwendungen, die zu einer reibungsloseren Lokalisierung auf der Ebene der Programmierung, Projektvorbereitung, Übersetzung und Nachbearbeitung beitragen. Beachten Sie, dass dieser Blogbeitrag Ihnen keine detaillierte Produktübersicht dieser Lokalisierungsumgebungen bieten soll (in diesem Fall wäre es auch angebrachter, ein ganzes Buch zu schreiben), sondern vielmehr ein paar Beispiele für interessante Funktionen.

Integration der Translation-Memory-Systeme

Ein gutes Beispiel einer solchen Funktion ist die Integration der Translation-Memory-Systeme, die zum Einsatz im Stadium der (Vor-)Übersetzung konzipiert sind. Passolo ist kompatibel mit TMs aus SDL Trados Workbench und Studio, Catalyst unterstützt zum Beispiel TM-Dateien im Format TTK, TMX und TXT. Die Abstufungsstatistiken der TMs können analysiert werden, wenn ein Projekt anläuft und neue TMs können durch das Alignment von bereits übersetztem Material erstellt werden.

Terminologieverwaltung

Es versteht sich von selbst, dass die Terminologieverwaltung bei der Softwarelokalisierung extrem wichtig ist. Sie möchten doch schließlich nicht, dass eine bestimmte Schaltfläche in jedem Dialogfeld eine andere Übersetzung hat, oder? Aus diesem Grund können sowohl in Passolo als auch in Catalyst Terminologieglossare erstellt oder hochgeladen werden. Passolo verfügt über ein internes Glossardateiformat, nämlich *.glo. Catalyst unterstützt zahlreiche Glossarformate, wie TXT, TBX, TMX und SDL MultiTerm-Datenbanken.

WYSIWYG

Das größte Plus ist wahrscheinlich die WYSIWYG-Umgebung (What You See Is What You Get). Durch diese Funktion kann der Benutzer die Übersetzungen in der Softwareanwendung visualisieren, während er sie erstellt und/oder bearbeitet. Auf diese Art können alle möglichen technischen Probleme leichter vermieden werden, die bei der Nachbearbeitung auftreten könnten. Trotzdem garantiert das aber nicht, dass alle erdenklichen Fehler während der Übersetzung erkannt und korrigiert werden. Daher bieten Passolo und Catalyst verschiedene QA-Funktionalitäten. Probleme, die während der Übersetzung nicht aufgefallen sind, können durch die Durchführung einer QA-Prüfung problemlos nach der Übersetzung behoben werden. QA-Optionen, sowohl allgemeine als auch softwarespezifische, können in Einklang mit den Anforderungen des QA-Spezialisten (de)aktiviert werden.

Zusammenfassend kann man sagen, dass die Softwarelokalisierung Besonderheiten mit sich bringt, die sie ganz klar von anderen Disziplinen in der Lokalisierungsbranche abheben. Alle Stadien des Lokalisierungsprozesses, von der Programmierung bis zur QA-Prüfung, sind durch technische Anforderungen charakterisiert, die ein gewisses Wissen und praktische Erfahrungen erfordern, damit alles richtig läuft. Daher ist die Softwarelokalisierung eine komplexe und sehr anspruchsvolle Angelegenheit.