Terminologie (1/10)
Bevor man verstehen kann, warum Terminologie im Lokalisierungsprozess so wichtig ist, muss man zunächst die Frage stellen, was Software-Terminologie für die Lokalisierung bedeutet.
Software-Terminologie hat mit der klassischen Fachterminologie nicht viel gemeinsam, außer dem allgemeinen Ziel einer "ungehinderten Verständigung". Ein wichtiger Unterschied ist die Tatsache, dass Software-Terminologie sich auf die Kommunikation zwischen Mensch und Maschine bezieht, während Fachterminologie die Kommunikation zwischen Menschen erleichtern soll. Obwohl Software-Anwender oft nicht unbedingt Fachwissen benötigen, so kann doch der Anteil an Fachterminologie in einem bestimmten Software-Paket je nach Grad der Spezialisierung der Software unterschiedlich hoch sein. (vgl. Kemmann, 2002:88).
Da die Anwender eines bestimmten Zielmarktes in ihrer Muttersprache angesprochen werden sollen (und wollen), wird die Suche nach Terminologie in der Zielsprache zu einem wichtigen Schritt im Softwarelokalisierungsprozess, der im allgemeinen interessante Herausforderungen mit sich bringt. Bei der Lokalisierung von Software kommt es häufig vor, dass Terminologie in der Zielsprache nicht existiert. Deshalb müssen Übersetzer/Lokalisierer die Terminologie der Ausgangssprache strukturieren und mögliche zielsprachliche Äquivalente noch vor Projektbeginn festlegen. Nur so kann eine konsistente Verwendung der Terminologie von Projektbeginn bis hin zur Abschlussphase sichergestellt werden - eine Grundvoraussetzung in der Softwarelokalisierung. Welche Verwirrung würde sonst entstehen, wenn die Terminologie nicht in allen Software-Komponenten - der Software selber (Benutzeroberfläche) und der Dokumentation (Online-Hilfe, Printdokumentation und produktbezogene Webseiten) - konsistent verwendet würde? Ein weiterer Grund für die Festlegung der zu verwendenden Terminologie schon in der Anfangssphase von Projekten hat damit zu tun, dass Softwarelokalisierungsprojekte oft sehr komplex sind und innerhalb sehr knapper Fristen bearbeitet werden müssen. Gleichzeitig sind mehrere Akteure am Projekt beteiligt (vgl. Schmitz, 2005a:9-10).
Erfahrungen im Bereich der Softwarelokalisierung haben gezeigt, dass allgemein verwendete Terminologiedatenkategorien (z.B. ISO 12620:1999) für die Terminolgiearbeit in der Softwarelokalsierung nicht ausreichen.
Aber warum? Der Grund dafür liegt vor allem darin, dass innerhalb der Software ein einziger Term sich je nach seinem unmittelbaren Kontext (z.B. in einem Menü, einem Dialogfenster oder einer Fehlermeldung) auf verschiedene Begriffe beziehen kann.
Außerdem gibt es Unterschiede zwischen der Terminologie, die in der Software-Dokumentation verwendet wird (Online-Hilfe und Webseiten) und derjenigen, die in der Benutzeroberfläche verwendet wird. Software-Dokumentation kann als "normaler" Fachtext bezeichnet werden, der Termini enthält, die als begriffsorientierte terminologische Einträge behandelt werden können. Wenn man jedoch z.B. bestimmte Terminologie, wie sie in Benutzeroberflächen verwendet wird, betrachtet - etwa "Speichern unter", "Tabelle einfügen", "Indexeintrag festlegen", usw. und andere Arten von Systemmeldungen - so ist es nicht einfach, den Begriffsinhalt (entsprechend den Regeln der Terminologielehre) solcher "Termini" festzulegen.
Dieses Problem kann teilweise dadurch gelöst werden, dass man solche Benutzeroberflächen-Terminologie (z.B. Systemmeldungen) mit Hilfe von Translation-Memory-Tools verwaltet statt mit Terminologieverwaltungssystemen. TM-Tools jedoch bieten nicht die Möglichkeit, Lokalisierungseinheiten anhand von Datenkategorien genau zu beschreiben.
Eine weitere Möglichkeit ist es, spezielle Datenkategorien für Lokalisierungseinheiten zu verwenden. Die folgende Tabelle zeigt Reinekes (2003) Vorschlag zur Einführung lokalisierungsspezifischer Datenkategorien. Sie sind auf allen Ebenen des terminologischen Eintrags angesiedelt und ermöglichen eine terminologische Beschreibung von Elementen in Benutzeroberflächen (vgl. Schmitz, 2005b:42-44).
Lokalisierungstyp | Art der Lokalisierungseinheit (main resource type) (Menü, Dialogfenster, Systemmeldung etc.) |
| Art des Menüelements (menu type) (Menüleiste, Menüoption etc.) |
| Art des Elements des Dialogfensters (control type) (Kontrollkästchen, Schaltfläche, statisches Element etc.) |
| Art der Systemmeldung (string type) (Meldung, Statusleiste etc.) |
Umgebungsteilbestand | Angabe zur Gültigkeit innerhalb einer bestimmten Umgebung (environment subset) (z.B. Windows) |
Produkt-Teilbestand | Angabe zur Gültigkeit für ein bestimmtes Programm (product subset) (z.B. Notepad) |
Lokalisierungsnummer | Eindeutige Nummer der Lokalisierungseinheit (resource ID) (eigentlich Eintragsebene, wichtig für den Datenaustausch) |
Lokalisierungsursprung | Gebietsschema der Originalsoftware (localization source) (z.B. en-US) |
Lokalisierungsziel | Gebietsschema der lokalisierten Software (localization target) (z.B. de-DE) |
Reinekes Datenkategorien für die Softwarelokalisierung: Anzugeben für jeden Term/jede Lokalisierungseinheit (aus Schmitz, 2005b:44)
An dieser Stelle folgen einige allgemeine Tipps für die Terminologiearbeit, die sich für Übersetzer, Lokalisierer und technische Redakteure bei der Softwarelokalisierung als nützlich erweisen können.
- Legen Sie ein Glossar oder (noch besser) eine Terminologiedatenbank mit produkt-, unternehmens- oder branchen-bezogenen Termini für das jeweilige Lokalisierungsprojekt an.
- Verwenden Sie einfache und prägnante Sätze. So sollten Sie von Anfang an festlegen, ob Sie z.B. "anklicken", "klicken", "wählen" oder "auswählen" bei der Beschreibung von Befehlen verwenden wollen.
- Verwenden Sie Terminologie konsistent in allen Software-Komponenten - Software (Benutzeroberfläche) und Dokumentation (Online-Hilfe, gedruckte Dokumentation und produktbezogene Webseiten).
(nach Esselink, 2000:28)
Kontextinformationen und die zur Verfügung stehenden Referenzmaterialien sind sehr wichtig für die Terminologiearbeit. Übersetzer sollten den Kontext von Textelementen kennen, die z.B. auf der Benutzeroberfläche auch als Einzelelemente auftreten können. Auch sollte ihnen der Software-Kontext bekannt sein, also das Umfeld, dem die Software angehört, denn dies kann die Verwendung einer speziellen, vorgegebenen Terminologie erfordern - z.B. Windows-Terminologie. Als Kontext bzw. Referenz können Übersetzer/Lokalisierer z.B. folgende Materialien verwenden:
- Glossare zu Betriebssystemen
- Hilfe-Dateien, Online-Hilfe
- Referenzhandbücher mit Beschreibungen einzelner Elemente
- Betriebssystem in der Zielsprache
- Aktuelle Version der Anwendung in der Zielsprache
- Frühere Version der Anwendung in der Zielsprache