Softwarelokalisierung ist der Kernbereich der Lokalisierungsprozesse bei Logrus. Im Folgenden werden die wichtigsten Phasen dieses Prozesses vorgestellt:
1. In der Vorbereitungsphase spricht Logrus Umfang, Eckdaten und Sprachen mit dem Kunden ab, verhandelt mit den Übersetzungsanbietern, legt Größe und Struktur des Lokalisierungsteams fest und bestimmt einen Projektmanager (PM).
2. Sobald die Quellmaterialien zur Lokalisierung bereit sind, werden sie vom Kunden an Logrus geschickt. Üblicherweise handelt es sich dabei um Komponenten wie diese:
- Das Produkt selbst, zusammen mit seinen lokalisierbaren Ressourcen und/oder Hilfedateien
- Eine Kopie der Buildumgebung (oder eines Teils davon), erstellt von Entwicklern am Kundenstandort
- Eine Liste übersetzbarer Ressourcendateien mit Formatbeschreibungen und Übersetzungsanweisungen – produktspezifische Anweisungen, Hinweise und Empfehlungen aller Art (ausdrücklich erwünscht)
- Produkttests und Funktionsbeschreibungen, die im Teststadium benötigt werden
- Alle proprietären und benutzerdefinierten Tools, Methoden und Daten, die spezifisch für das zu lokalisierende Produkt sind sowie Listen mit nicht zu lokalisierenden Strings
3. Darauf folgt die Übersetzungsvorbereitung. Dabei werden die zu übersetzenden Teile ausgewählt und die Dateien in ein für den Übersetzungsanbieter geeignetes Format konvertiert. Dieses Stadium ist aus unterschiedlichen Gründen sehr wichtig:
- Zwar verfügen viele Übersetzungsdienstleister über ausreichend viel Erfahrung, um mit komplexeren Dateiformaten zu arbeiten. Aus Produktivitätsgründen ist es jedoch günstiger, Quellmaterial in so verbreiteten Formaten wie MS Word, .doc, .rtf, oder .htm zu übermitteln.
- Wenn Übersetzer mit benutzerdefinierten Quellmaterialien arbeiten, die nicht nur zu übersetzenden Text, sondern auch Code enthalten, besteht die Gefahr, dass die Codeinformationen beschädigt werden.
- Wenn eine neue Produktversion auf den Markt kommt, wird diese von Entwicklern in den seltensten Fällen vollständig neu geschrieben. Viele Strings und Sätze werden von Vorgängerversionen der Software oder Hilfe übernommen, und zahlreiche ähnliche Satzteile, Sätze und Strings (Repetitions genannt) sind in mehreren Teilen des Code oder der Dokumentation zu finden. Vorhandenes Material und Repetitions müssen nur einmal übersetzt werden. Dank der Verwendung einer Translation Memory-Software (TM), mit der quell- und zielsprachliche Paare in einer Datenbank gespeichert und bei Bedarf abgerufen werden können, können Repetitions unbegrenzt häufig wiederverwendet werden. Wir arbeiten so häufig wie möglich mit TMs und liefern die entsprechende Datenbank auch mit an den Kunden aus.
4. Die Lokalisierungsphase beginnt mit dem Aufbau eines Terminologieglossars.
Wenn noch kein Glossar vorhanden ist, wird dringend empfohlen, die Glossarerstellung einem professionellen Sprachdienstleister zu überlassen.
5. Das erstellte Glossar wird dann zur Überprüfung an einen unabhängigen Experten geschickt, z. B. an einen der Geschäftspartner des Kunden, der das Produkt gut kennt.
6. Während die Übersetzer an Software, Hilfe und Dokumentation arbeiten (siehe unten, Schritte 7 und 8), machen sich die Softwareingenieure von Logrus mit den vom Kunden gelieferten Materialien vertraut. Sie richten Umgebungen zum Erstellen von Produktbuilds ein und vervielfältigen die Verfahren zum Kompilieren, Erstellen von Builds und zum Wiedereinlesen der Strings. Meist benötigen wir in dieser Phase die Hilfe der Produktentwickler auf Kundenseite; gleichwohl bemühen wir uns, die Anzahl an Rückfragen so gering wie möglich zu halten.
7. Die Software, die Hilfe und die Dokumentation werden mithilfe des überprüften Glossars übersetzt.
8. Die übersetzten Dateien werden dann zum Zweck einer auszugsweisen unabhängigen Überprüfung verschickt, bevor sie wieder den Logrus-Ingenieuren übergeben werden.
9. Bei Logrus wird meist an mehreren Sprachen gleichzeitig gearbeitet, wobei die Arbeit an der Pilotsprache den anderen Sprachen um etwa eine Woche voraus ist.
Bevor die lokalisierten Builds erstellt werden, importieren die Logrus-Ingenieure die übersetzten Einheiten (Strings, Sätze und Teilsätze) in die Quelldateien und nehmen die notwendigen Konvertierungen vor. Dies geschieht oft in mehreren Phasen. Die lokalisierten Dateien werden dann mithilfe von Dienstprogrammen von Logrus oder von Drittanbietern auf Datenintegrität und Format überprüft.
10. Ein lokalisiertes Produkt wird niemals nach nur einem Build herausgegeben. In dieser frühen Phase können noch eine Vielzahl von Fehlern auftreten: Funktionsfehler (beim Übersetzen der Benutzeroberfläche gehen normalerweise Teile der Funktionalität verloren), abgeschnittene Zeichenketten, doppelt belegte Tastenkombinationen, sprachspezifische Probleme usw. Funktionale Fehler entstehen üblicherweise aufgrund von "Over-Translations", (d. h. ein String, der eigentlich nicht hätte berührt werden dürfen, wurde versehentlich übersetzt) oder aufgrund von Übersetzungen, die zwar technisch korrekt, aber für den String zu lang sind. Diese sind häufig schwer zu finden und zu beheben, aber die Softwareingenieure von Logrus verfügen über eine so weitreichende Erfahrung mit verschiedensten Produkten, dass immer eine Lösung angeboten werden kann. Falls der Code geändert werden muss, wenden sich entweder der Projektmanager oder die Softwareingenieure an den Kunden, beschreiben das Problem genau und schlagen Lösungen vor.
11. Jeder Build durchläuft die Stadien Qualitätssicherung (QA) und Fehlerbehebung. Alle gefundenen Fehler werden in eine spezielle Datenbank zur Verfolgung von Fehlern eingegeben, in der Angaben wie Produktname, Version, Buildnummer, Sprache, Schweregrad des Fehlers sowie eine genaue Beschreibung enthalten sind. Falls nötig, werden Bitmaps angefügt. Es kommt sogar recht häufig vor, dass bei der Lokalisierung Fehler im Ausgangsprodukt gefunden werden.
Zusätzlich zu den Standardtests und Funktionsüberprüfungen führen die Logrus-Tester auch sprachspezifische Tests zur Zeichendarstellung, Verwendung von Schriftarten, Import und Export, Dateinamen, Sortierung, Berichten und Vorlagen sowie zu Datums-, Uhrzeit- und Zahlenformaten durch.
Meist werden drei oder vier Builds erstellt, bevor das lokalisierte Endprodukt an den Kunden ausgeliefert werden kann. Die meiste Zeit für Qualitätssicherung und Fehlerbehebung wird naturgemäß nach dem ersten Build benötigt. Nach zwei bis vier Builds verringert sich die Zahl der Fehler jeweils entsprechend.
12. Beim Testen werden normalerweise Probleme wie fehlende Übersetzungen und zu kürzende Strings entdeckt. Solche kleineren Änderungsanfragen werden nochmals an die Übersetzungsanbieter geschickt, und die Korrekturen werden dann in spätere Builds integriert.
13. Vor der Veröffentlichung werden dem Kunden das endgültige Produkt und die endgültige Dokumentation (manchmal auch die älteren Builds) zur Abnahme vorgelegt.
14. Nach Fertigstellung und Lieferung des Produkts ist der Projektmanager von Logrus auch immer noch für das Produkt zuständig und steht dem Kunden witerhin für den Support zur Verfügung. Dies gilt auch im Hinblick auf die Lokalisierung kleinerer Patches und Updates.