2. Überblick
Softwarelokalisierungstools sind relativ neu. Vor 1990 gab es noch keine solchen Tools, wie wir sie heute kennen. Normalerweise wurden hardkodierte Benutzeroberflächen direkt im Quellcode übersetzt und später angepasst. Je nach Komplexität der Programmtexte musste die Anpassung des übersetzten Textes von den Programmierern selbst, von Übersetzern mit Programmierkenntnissen oder in Zusammenarbeit von Programmierern und Übersetzern durchgeführt werden.
In den 90er Jahren änderte sich die Situation. Softwareentwicklungsunternehmen begannen, die Lokalisierung ihrer Software auszulagern. Dies führte zu einem dringenden Bedarf an speziellen Tools und Prozessen, die es Übersetzern ermöglichen, Benutzeroberflächentexte ohne spezielle Programmierkenntnisse oder die ständige Hilfe von Programmierern zu editieren (Reineke, 2005:73-74). Demzufolge setzte eine neue Herangehensweise an die Lokalisierung ein: Das Übersetzen von zahlreichen (oft hunderten) Ressourcendateien (RC) und das Anpassen von Dialogfeldern mit Hilfe von Tools wie Microsoft Developer Studio oder Text-Editoren.
Immer häufiger wurden neue, aktualisierte Versionen derselben Software herausgebracht, was die Arbeit der Übersetzer teilweise sehr repetitiv machte. Um Zeit und Aufwand zu sparen, begannen die Übersetzer Übersetzungsdatenbank-Tools (oder Translation-Memory-Tools) zu verwenden. Der Prozess der Anpassung von Elementen der graphischen Benutzeroberfläche war jedoch zeitaufwändig und fehleranfällig. Wieder wurde der Bedarf an Lokalisierungstools deutlich, die Elemente von Translation-Memory-Technologie mit visuellem Editieren kombinieren. Es war an der Zeit, Softwarelokalisierungstools zu entwickeln.
Der nächste Schritt der Lokalisierungsindustrie bestand darin, sich mit Hilfe von speziellen Softwareanwendungen, nämlich Softwarelokalisierungstools, von den zeitaufwändigen RC-basierten Prozessen weg zum Prozess der direkten Lokalisierung von kompilierten Binär-Dateien zu bewegen (Lingobit Technologies, 2003-2007).
In der Vergangenheit stellten Frankreich, Deutschland und Japan die größten Märkte für lokalisierte Produkte. Normalerweise lassen Softwareentwickler ihre - in der Regel in Englisch verfassten - Produkte zuerst in FIDS (engl. FIGS) (Französisch, Italienisch, Deutsch und Spanisch) und Japanisch lokalisieren. Andere gefragte Lokalisierungssprachen sind Schwedisch, Norwegisch, Dänisch, Niederländisch oder Brasilianisches Portugiesisch (Esselink, 2000:6).
Heutzutage verfügen Softwarelokalisierungstools über einen größeren Bereich unterstützter Dateiformate. Sie unterstützen Formate wie:
- Binärdateien von Windows-Standard-Resourcen (16 und 32 bit) (EXE, DLL, SYS) und RC-Dateien
- Microsoft Visual Basic 6-Binärdateien
- XML-Dateien, inkl. XLIFF
- HTML
- Microsoft Installer-Dateien (MSI)
- Monolinguale Textdateien
Einige Tools unterstützen andere Dateiformate mit Add-ins. Dies sind kleine Programme, die zur Erweiterung spezieller Features von Softwarelokalisierungstools geschrieben wurden.
Einige optionale Add-ins für andere Dateiformate sind:
- Microsoft.NET: binäre Quelldateien (EXE, zugehörige DLLs und Komponenten), Quelldateien (RESX und RESOURCE), Unterstützung vererbter Dialogfelder (WYSIWYG), Unterstützung von Custom Controls und Properties, Unterstützung aller .NET-Systeme
- Borland Delphi / C++ Builder: binäre Quelldateien (EXE, DLL, BPL)
- Java (alle Plattformen: J2EE, J2SE und J2ME), Property-Dateien (PROPERTIES), Quelldateien (JAVA), Binärdateien (CLASS), Java Projektdateien (JAR)
Zusätzliche unterstützte Dateiformate:
- ODBC-Datenbank-Parser
- MS Access, MS Excel
- MS SQL Server
- Oracle
- IBM DB2
- Palm OS-Parser
- .po-Parser