Jeder Schweizer Hersteller, der seine Software exportiert, begegnet rechtlichen und organisatorischen Hürden. Zudem bestehen auch sprachliche und kulturelle Herausforderungen bei der Anpassung der Software an neue Märkte. Die korrekte Lokalisierung, d.h. Übersetzung und kulturelle Anpassung der Software, übernehmen meist Übersetzungsagenturen. Was unterschätzt wird, ist der Managementaufwand, der mit neuen Sprachversionen und besonders mit zunehmender Textmenge steigt. Diesen kann die Übersetzungsagentur nicht übernehmen, er bleibt beim Softwarehersteller hängen. Da wäre die technische Aufbereitung der Strings beim Export und Import, der Mehraufwand für nachträgliche Änderungen im Text, die nicht standardisierten und nicht automatisierten Arbeitsschritte und die Organisation fürs Testing der fremdsprachigen Versionen.
Der SLP: im Detail komplexer, als er aussieht (Quelle: z.V.g)
Klare Text-Richtlinien sind wichtig für den internationalen Markt. (Quelle: Ernesto Pletsch)
Ein strukturierter Softwarelokalisierungsprozess (SLP) kann diesen Aufwand reduzieren und bessere Resultate punkto Kosten und Qualität erzielen.
Die schwerwiegendsten Probleme, die ohne strukturierten Softwarelokalisierungsprozess entstehen können: verspätete Auslieferung der fremdsprachigen Versionen, hohe Übersetzungskosten, ungeplante Korrektur- und Supportkosten sowie Qualitätsprobleme, die nicht den Übersetzern zugeschrieben werden können. Softwarenutzer mögen bei schlecht übersetzten Texten zwar oft ein Auge zudrücken, trotzdem kann die Sprache in einer Software zu einem Usability- und somit zu einem Verkaufskiller werden.
Der Softwarelokalisierungsprozess
Die Grafik gibt eine einfache Sicht auf den sprachlichen Teil der SLP. Ein relativ einfacher Prozess – so scheint es auf den ersten Blick. Doch wenn man den einzelnen Prozessschritten die zuständige Person und Abteilung zuordnet und sich fragt, wer eigentlich den Überblick über den ganzen SLP hat, dann merkt man, dass dieser Prozess etwas komplexer ist. Es kommt hinzu, dass es für jede Textsorte (UI-Texte, Helptexte, Handbücher …) einen eigenen Lokalisierungsprozess braucht, da selten alle Textsorten parallel erstellt und übersetzt werden. Zudem ist der SLP vom Softwareentwicklungsprozess abhängig, der gewisse Meilensteine und insbesondere der Zeitplan für den SLP vorgibt. Auf detaillierter Ebene ist jeder Softwarelokalisierungsprozess deshalb so einzigartig wie der dazugehörige Entwicklungsprozess.
Tipps für die Definition eines schlanken SLPs
Das Schwierige am Softwarelokalisierungsprozess ist, dass viele Leute aus verschiedenen Fachteams beteiligt sind und es kaum eine Person gibt, die sich einen Überblick über den gesamten Prozess verschaffen kann. Dieser Überblick ist jedoch enorm wichtig, gerade weil die Prozessbeteiligten aus verschiedenen Teams kommen. Wie in jedem Prozess braucht es auch im SLP einen konkreten Plan für Termine, Ressourcen, einzelne Tasks, Budget und Kommunikation, damit er reibungslos ablaufen kann. Alles was nicht klar definiert und dokumentiert ist, birgt Risiken wie Ineffizienz, Leer- oder Mehrfachläufen und Qualitätsverlusten. Hier einige Tipps für die Definition eines schlanken SLPs.
Nehmen Sie eine saubere Internationalisierung Ihrer Software vor: Auf der Architekturebene muss sichergestellt werden, dass eine saubere Internationalisierung vorgenommen wurde. Stichworte: flexible Textlängen zulassen, Unicodeunterstützung, keine dynamisch zusammengestellten Sätze, etc.
Bestimmen Sie einen Prozessverantwortlichen: Er sollte Kenntnisse aller Prozessschritte haben. Notwendig ist das Verständnis über den Ablauf des Softwareentwicklungs- und des Übersetzungsprozesses, ebenso Projektmanagementerfahrung und technische Kenntnisse der eingesetzten Tools und Abläufe. Vernetztes Denken und linguistischer Ausbildungshintergrund oder langjährige Erfahrung mit Übersetzungsproblematiken sind ein Muss, Fremdsprachen ein grosses Plus.
Integrieren Sie den SLP in den Entwicklungsprozess: Der SLP sollte unbedingt als Teil des Softwareentwicklungsprozesses angesehen werden, denn eine Verzögerung im SLP hat auch eine Verzögerung des Releases zur Folge. Eine gute Kommunikation und Planung zwischen Entwicklung und Lokalisierungsteam ist entscheidend, gerade bei agilen Entwicklungsmethoden. Am besten wird der SLP-Prozessverantwortliche zu relevanten Architektur- und Entwicklermeetings eingeladen, angefangen bei der Spezifikation der Requirements.
Setzen Sie die Lokalisierung zum richtigen Zeitpunkt an: Wichtig ist es, die Übersetzungen im Entwicklungsprozess so früh wie möglich anzusetzen. Allerdings auch nicht zu früh, damit nicht ständig Änderungen zur Nachübersetzung in Auftrag gegeben werden müssen. Unabhängig vom Übersetzungszeitpunkt zahlt sich aber z.B. eine frühzeitige Terminologiearbeit (Bestimmen eindeutiger Fachwörter) immer aus.
Erstellen Sie klare Richtlinien für Autoren und Übersetzer: Ob Autoren von GUI-Strings, Helptexten oder anderen Dokumentationen, alle brauchen klare Anleitungen für die Texterstellung, denn die wenigsten sind ausgebildete und erfahrene Technische Redaktoren. Saubere, standardisierte, konsistente und evtl. kontrollierte quellsprachige Texte führen dazu, dass die Texte schneller fertig sind und somit früher übersetzt werden kann. Der angenehme Nebeneffekt: weniger Nachübersetzungen und Korrekturen müssen in Auftrag gegeben werden und die Terminologiearbeit profitiert ebenfalls davon. Richtlinien für Übersetzer können ebenfalls sinnvoll sein wenn man mit wechselnden Übersetzern arbeitet.
Automatisieren Sie soviel Sie können: Für die Automatisierung von Prozessschritten können Tools erworben und evtl. auch selbst entwickelte Workflowautomatisierungen eingesetzt werden. Welche Tools sich lohnen, sollte sorgfältig evaluiert werden. Visual Localization Tools beispielsweise sind toll, um den Übersetzern eine geschützte Sicht auf das Userinterface zu ermöglichen und so Mehrdeutigkeiten auszuschliessen. Die Marktführer der Visual Localization Tools haben zudem eine Menge an Managementfunktionen im Tool integriert, die die Arbeit der Übersetzungsverwaltung erleichtern können.
Die Hüter des Quellcodes wird es freuen, dass man mit solchen Tools z.B. Sonderzeichen in Strings sperren kann, damit sie von den Übersetzern nicht überschrieben werden können. Nicht zu vergessen: ein tolles Tool bedingt immer auch gut geschulte User, damit man die Funktionen auch voll ausschöpfen kann.
Sorgen Sie für eine gute Kommunikationskultur: Die Vielfalt der beteiligten Fachpersonen ist im SLP eine grosse Schwierigkeit. Übersetzer, Entwickler, Projektmanager, Tester sprechen eine andere «Sprache» und können Verständigungsschwierigkeiten haben. Wichtig ist es, eine offene Kommunikationskultur zu pflegen. Die Prozessbeteiligten sollen einander erklären, worin ihre Aufgabe besteht, was für sie wichtig ist und offen sein für Fragen und Anregungen. Im agilen Entwicklungsumfeld ist eine gute und frühzeitige Kommunikation unabdingbar.
Schliessen Sie Wissenslücken: Überprüfen Sie, welches Wissen den einzelnen Prozessbeteiligten fehlt. Schliessen Sie diese Wissenslücken durch firmeninterne Knowhow-Weitergabe oder durch externe Schulungen.
Erstellen Sie eine gute Prozessdokumentation: Zeichnen Sie Ihren SLP auf und halten Sie die Tasks und die Verantwortlichkeiten fest. Schriftlich dokumentierte Anleitungen zu jedem Task sind sinnvoll, weil die Knowhow-Weitergabe so im Falle einer Vertretung oder Nachfolge gesichert ist.
Wenn Sie den Prozess, der hinter der Mehrsprachigkeit Ihres Produkts und Ihrer Dokumentationen steckt, erkennen und nach den oben genannten Punkten durchleuchten, können Sie einiges an Zeit und Kosten in Ihrem Softwarelokalisierungsprozess einsparen.
Einzelne Massnahmen können relativ schnell umgesetzt werden, andere wiederum können sehr aufwändig sein … wie bei allen Prozessoptimierungen.
Software-Export und Mehrsprachigkeit
Eine neue Studie des Dachverbands ICTswitzerland zeigt, dass das Exportvolumen der Schweizer ICT-Branche 2011 rund 9 Mrd. CHF betrug. Die Schweizer ICT-Produkte und -Dienstleistungen gehören somit zu den zehn wichtigsten Exportgruppen. Die Schweiz exportiert sechsmal mehr ICT als Käse und Schokolade zusammen.
Eine Studie des EU-Projekts CELAN («Business Sector Reports on Companies‘ Language Needs – ICT Sector», 2011,
http://www.celan-platform.eu/assets/files/D1.2SectorReportICT_EMF_v1.0.pdf) unter 84 Firmen aus 24 Ländern ergab, dass nur 19% eine formelle «Mehrsprachigkeitsstrategie» haben, obwohl dies 92% für einen Wettbewerbsvorteil halten.
Nataly Hüeblin
Studium der Computerlinguistik und Japanologie an der Universität Zürich (M.A.) und Berufserfahrung in der Software- und Übersetzungsbranche. Heute selbständige Beraterin für Fragen rund um Software und Mehrsprachigkeit mit einem speziellen Fokus auf den Softwarelokalisierungsprozess.
www.hueblin.ch/blog
