Fachzeitschrift ’technische kommunikation’ | 32.Jahrgang | 2 / 2010 | Seite 21

Entwicklungen und Zukunftsszenarien von Translation-Memory-Systemen

Vom Segment zum Kontext

von Ziad Chama

In den letzten 15 Jahren haben Translation-Memory-Systeme, TMS, entscheidend dazu beigetragen, Übersetzungsabläufe deutlich zu straffen. Da das Potenzial eines klassischen TMS heute weitestgehend ausgereizt scheint, überarbeiten viele Hersteller ihre Lösungen auf der Suche nach weiteren Rationalisierungsmöglichkeiten.

Translation-Memory-Systeme besitzen Datenbanken, in denen ausgangssprachliche Sätze mit ihrer jeweiligen Übersetzung abspeichert werden können. Kommt derselbe oder ein ähnlicher Satz an anderer Stelle nochmals vor, lässt sich die gespeicherte Übersetzung auf Knopfdruck abrufen und wiederverwenden.

Im Grunde funktionieren diese Systeme seit etwa 15 Jahren nach demselben Prinzip: In einer Datenbank werden Ausgangs- und Zielsätze paarweise erfasst. Die Satzpaare, so genannte Übersetzungseinheiten, lassen sich mit Zusatzinformationen versehen, um einen gewissen Kontext herzustellen. Auf diese Weise kann beispielsweise nachvollzogen werden, ob eine Übersetzungseinheit aus einer Technischen Dokumentation oder aus einem Marketingtext stammt. Der Nachteil dabei: Die Pflege solcher Felder ist ziemlich aufwendig. Nicht zuletzt deswegen verläuft die Produktivitätskurve eines Translation-Memory-Systems in drei Phasen:

1. Die Produktivität steigt anfangs langsam, weil das noch leere System erst mit Daten gespeist werden muss.
2. Immer mehr Übersetzungslösungen sind zentral abrufbar, die Produktivitätskurve steigt steil an.
3. Die Kurve flacht ab, eventuell fällt sie sogar leicht, weil sehr große Datenbestände mit vielen Zusatzinformationen einen hohen Aufwand für die Datenpflege verursachen.

Schwachstelle von TMS

Um diesen Verwaltungsaufwand zu vermeiden oder zumindest zu reduzieren, müsste sich das System den Kontext „von selbst“ merken, ohne dass der Benutzer dem System dies über Zusatzfelder mitteilen muss. Beispiel:

• We have released the beta version. The application is ready to be reviewed.
• I have filled in the application form. The application is ready to be reviewed.

Wie der Satz „The application is ready to be reviewed“ ins Deutsche zu übersetzen ist, hängt vom Kontext ab, der sich in diesem Beispiel aus dem Vorgängersatz ergibt. Im ersten Fall müsste die Übersetzung zum Beispiel lauten „Die Anwendung kann jetzt getestet werden“, im zweiten Fall „Der Antrag ist zur Prüfung bereit“.

Nehmen wir an, beide Übersetzungen sind in einem Translation-Memory-System gespeichert. Die Datenbank kann nicht „wissen“, welche dieser beiden Lösungen jeweils die richtige ist, da sie immer nur den aktuellen Ausgangssatz mit dem Inhalt des TMS vergleicht. Sind beide Zielsätze im System gespeichert, dann werden diese beim Übersetzen vorgeschlagen. Der Übersetzer kann interaktiv entscheiden, welcher Vorschlag der richtige ist. Wie sieht es aber aus, wenn der Text mit dem TMS automatisch vorübersetzt wird, wie es bei großen Volumina oft der Fall ist? Hier besteht die Gefahr, dass unerkannt die falsche Übersetzung eingefügt wird.

Deshalb lassen viele Unternehmen immer den gesamten Zieltext nachlesen, auch wenn beispielsweise nur zehn Prozent des Inhalts wirklich neu zu übersetzen waren. Daraus leitet sich das Argument ab, dass auch 100-Prozent-Treffer aus einem TMS immer nachkontrolliert werden müssen.

Referenzdateien als Alternative

Einen anderen Ansatz verfolgt beispielsweise das System STAR Transit: Anstatt mit einer zentralen TM-Datenbank zu arbeiten, erfolgt der Abgleich hier anhand von Referenzdateien. Der Vorteil ist, dass ein neu zu übersetzender Text kontextsensitiv mit einem sehr viel übersichtlicheren Datenbestand, also einer Vorgängerdatei, abgeglichen werden kann. Der Nachteil von Referenzdateien: Die Anwender greifen nicht auf eine einzige Quelle zu, in der Lösungen verschiedenster Projekte oder auch Fachrichtungen zentral gespeichert sind. Außerdem verursacht eine große Zahl von Referenzdateien ebenfalls einen hohen Verwaltungsaufwand.

Referenzdateien bieten aber einen Vorteil bei der Kontextsensitivität, weil hier die Satzpaare nicht aus dem Zusammenhang gerissen sind. Deshalb ergänzte der Hersteller SDL Trados sein System schon vor einigen Jahren um die Technologie „PerfectMatch“, die neue Ausgangsdokumente mit zweisprachigen Vorgängerdateien abgleicht. Dadurch bietet SDL Trados derzeit als einzige Lösung beide Ansätze, also eine zentrale TM-Datenbanken und Referenzdateien. PerfectMatch ergänzt das System, es ist aber nicht Bestandteil der Datenbank. Das bedeutet, dass immer zwei separate Bestände zu pflegen sind.

Kontextsensitive TMS

Einfacher wäre es natürlich, wenn das Translation-Memory-System selbst den Kontext speichern würde, wie es bei den neueren Systemen bis zu einem gewissen Grad der Fall ist. Grundsätzlich wird die Kontextsensitivität damit erreicht, dass eine Übersetzungseinheit mehr als nur ein isoliertes Satzpaar enthält. Die Anwendung MemoQ des ungarischen Anbieters Kilgray beispielsweise „merkt“ sich neben dem Ausgangs- und Zielsatz auch, welcher Satz dem aktuellen Segment in einem früheren Dokument vorausging und welcher nachfolgte. Erst wenn der aktuelle, der davorstehende und der nachfolgende Satz wieder in derselben Reihenfolge vorkommen, vergibt MemoQ ein 101 Prozent Match. Diese Technik bezeichnet MemoQ als ContexTM. Mit dessen Hilfe kann das System auch in nicht eindeutigen Fällen mit mehreren Übersetzungen die richtige Lösung vorschlagen.

Ähnlich geht auch das System Atril Déjà-Vu vor, das ebenfalls die umgebenden Sätze berücksichtigt und bei Übereinstimmung ein so genanntes Guaranteed Match liefert.

Auch SDL Trados hat sich mit diesem Ansatz bereits beschäftigt: SDL Trados Studio 2009 berücksichtigt immer den davor stehenden Satz und dessen Übersetzung. Das heißt, wenn der vor dem aktuellen Segment stehende Satz sowie dessen Übersetzung zu einem früheren Dokument identisch sind, vergibt SDL Trados Studio 2009 ein so genanntes Context Match. Darüber hinaus erfasst die Anwendung auch weitere Kontextinformationen, zum Beispiel ob ein Segment in einer Überschrift, einer Tabelle oder in einer Fußnote vorgekommen ist.

Abb. 1: SDL Trados 2009 Studio speichert zum Beispiel ab, ob ein Segment in einer Überschrift steht.

Weg vom Segment?

Seit über zehn Jahren unterteilen Translation-Memory-Systeme Dokumente in Segmente, die in der Praxis meist einem Satz entsprechen. Die Entwicklung geht derzeit dahin, in einer Übersetzungseinheit  auch das unmittelbare Umfeld eines Segments zu speichern. Gelegentlich wird aber auch diskutiert, ob es nicht sinnvoller wäre, sich sogar komplett vom klassischen Segment zu lösen.
Inwiefern könnte ein Bruch mit der segmentbasierten Tradition die Produktivität steigern? Gehen wir einmal davon aus, dass sich Übersetzungsprojekte grob in drei Gruppen aufteilen lassen:

• Update-Übersetzungen mit sehr hohem Übereinstimmungsgrad zu Vorgängerdokumenten, zum Beispiel Software-Handbücher
• Dokumente mit sehr niedrigen Wiederholungsraten und wenigen Übereinstimmungen zu Vorgängertexten, zum Beispiel Broschüren
• sehr kurze Texte, zum Beispiel Memos, die oft von Gelegenheitsübersetzern, also nicht von Profis, übersetzt werden

Die Unterteilung in Segmente ist gerade bei der zuerst genannten Kategorie, also den Update-Übersetzungen, nicht immer der ideale Ansatz.
Nehmen wir an, die im letzten Jahr übersetzte Dokumentation zu einer Software (Version 1.0) umfasst 10.000 Segmente. Nun steht ein Update auf die Version 1.1 an. Gehen wir davon aus, dass sich die Dokumentation zur Version 1.1 sich nur um fünf Prozent vom Vorgängerhandbuch unterscheidet, also grob gesagt nur 500 Segmente neu übersetzt oder geändert werden müssen. Dennoch müssen natürlich alle anderen 9.500 identischen Segmente in den Zieltext eingefügt werden – entweder manuell bei gleichzeitiger Prüfung durch die Übersetzer oder automatisch und ohne manuelle Prüfung.

Die Wahrscheinlichkeit, dass sich in einem solchen Fall ganze Absätze oder gar Kapitel deckungsgleich zur Vorgängerversion sind, ist sehr hoch. Oft wird nur an einigen Stellen ein Absatz eingefügt, um eine neue Funktion zu beschreiben. Deshalb würde man bei einem solchen Projekt mehr davon profitieren, wenn die Übersetzungseinheiten zum Beispiel ganze Absätze oder Abschnitte anstelle isolierter Einzelsegmente umfassen. Der Abgleich größerer Sinneinheiten liefert deutlich mehr Kontextinformationen als Einzelsätze und ist damit erheblich sicherer. Ein Nachteil beim Abgleich mit größeren Sinneinheiten wäre, dass einzelne Sätze möglicherweise nicht mehr erkannt würden. Beispiel: Ein ganz neuer Abschnitt enthält den aus einem Vorläuferdokument bereits bekannten Einzelsatz „Beachten Sie Folgendes“.
Beim Abgleich ganzer Absätze würde ein solcher Satz eventuell nicht mehr erkannt werden, weil er innerhalb eines Textblocks, der zum Beispiel 500 Wörter umfasst, kaum ins Gewicht fällt. Daher müsste er wieder manuell übersetzt werden, was die höhere Sicherheit und den geringeren Prüfaufwand für das Gesamtprojekt allerdings mehr als wettmachen würde.

Natürlich wirkt sich die Speicherung kompletter Absätze in einer Übersetzungseinheit nicht bei jeder Art von Projekt positiv auf die Produktivität aus. Ideal wäre es daher, der Anwender könnte sein Translation-Memory-System so konfigurieren, dass es je nach Anforderung und Textart größere oder kleinere Sinneinheiten speichert, also Abschnitte, Absätze oder wie bisher Einzelsätze.

Erkennung von Teilsegmenten

Die Übersetzer von Broschüren oder auch Gelegenheitsübersetzer profitieren dagegen kaum von der Speicherung großer Sinneinheiten, weil bei ihnen die Chance sehr gering ist, dass sich Sätze oder Absätze wiederholen. Deshalb gehen einige Hersteller parallel zur Speicherung größerer Übersetzungseinheiten auch in die entgegengesetzte Richtung: Ihre Systeme erfassen zusätzlich kleinere Einheiten, so genannte Teilsegmente. Zahlreiche Texte enthalten nämlich nur wenige Satzwiederholungen. Klassische Beispiele hierfür sind Marketing-Broschüren und Pressemitteilungen. Einzelne Wörter, Ausdrücke oder Nebensätze dagegen kommen in jeder Textart gehäuft vor. Im Grunde bieten die Systeme aller Herstellers seit langem eine Teilsegmenterkennung, die Anwendern als Konkordanzsuche bekannt ist und die für viele sogar die wichtigste Funktion eines Translation-Memory-Systems darstellt.

Über die Konkordanzsuche lassen sich alle Sätzen aus dem Systemspeicher abrufen, die einen bestimmten Ausdruck enthalten. Einziger Nachteil: Die Suche muss aktiv durchgeführt werden, die Anwender werden also nicht automatisch auf mögliche Lösungen aufmerksam gemacht. Außerdem muss der passende zielsprachliche Ausdruck im Satz identifiziert, ausgewählt und von Hand in den Zieltext eingefügt werden.

SDL Trados Studio 2009 bietet mit AutoSuggest nun eine Funktion, mit der sich passende Teilsegmente schnell in den Zieltext übernehmen lassen. Die Funktion schlägt automatisch beim Tippen Ausdrücke vor, die auf den jeweiligen Kontext passen. Enthält der Ausgangssatz beispielsweise das Teilsegment „according to our agreement“, reicht es aus, den Buchstaben „l“ einzugeben. Das System ergänzt die Eingabe zu „laut unserer Vereinbarung“ – je nach Wunsch des Anwenders.

Abb. 2: Beim Schreiben werden entsprechende Teilsegmente vorgeschlagen.

Eine Teilsegmenterkennung kann die Übersetzungsgeschwindigkeit und den Benutzerkomfort deutlich steigern. Auch wenn ein Dokument nur wenige Satzwiederholungen aufweist, Teilsegmente wiederholen sich in nahezu jeder Textart. Der Wehmutstropfen bei AutoSuggest: Die Teilsegmente werden nicht im Übersetzungsspeicher selbst, sondern in einer separaten Datenbank gespeichert, die in einem gesonderten Schritt aus dem Translation Memory heraus erstellt wird.

Auch andere Anbieter haben ihre Lösungen mit einer Teilsegmenterkennung ausgestattet: Die Anwendung MemoQ beispielsweise wendet auf jedes Ausgangssegment automatisch eine Konkordanzsuche an. Passende Teilsegmente aus anderen Segmenten werden dann in einem eigenen Fenster angezeigt wie Abbildungen 3 und 4 zeigen.

Abb. 3: Eine erweiterte Konkordanzsuche hebt gefundene Teilsegmente hervor.

Abb. 4: Einstellmöglichkeiten für die Teilsegmenterkennung in MemoQ 3.6

Der Vorteil ist, dass die erweiterte Konkordanzsuche nicht in einer separaten Datenbank, sondern im Übersetzungssystem selbst erfolgt, das während des Übersetzens interaktiv mit weiteren Teilsegmenten angereichert wird. Der Nachteil: Das Einfügen passender Teilsegmente in den Zieltext gestaltet sich weniger komfortabel, da es nicht nahtlos in den Schreibfluss integriert ist.

Weniger Word, mehr Browser?

Neben neuen Systemfunktionen ist ein klarer Trend bei den Editierumgebungen auszumachen: Die direkte Integration von TM-Funktionen in Microsoft Word war vor einigen Jahren noch eine Art Branchenstandard. Die feste Anbindung von TM-Datenbanken an das Produkt eines Drittherstellers scheint aber bald der Vergangenheit anzugehören – spätestens mit den neuen Generationen von SDL Trados undWordFast, die beide keine direkte Microsoft Word-Schnittstelle mehr bieten, sondern ausschließlich auf eine eigene Editierumgebung setzen. Eine weitere Konsequenz daraus: An die Stelle zweisprachiger Word-Dateien treten nun XML-basierte Austauschformate.

Damit ist auch schon die Grundvoraussetzung für den nächsten Schritt geschaffen: das Übersetzen im Webbrowser. Vor allem Gelegenheitsübersetzern und Korrekturlesern bietet sich eine browserbasierte Editierumgebung an. Für Anwender, die zum Beispiel pro Monat nur drei Seiten übersetzen müssen, wird sich die Installation einer Desktopanwendung nicht lohnen. Dasselbe gilt für die Vielzahl möglicher Korrekturleser und Prüfer.

Browserbasierte TM- und Editierumgebungen für Übersetzer sind bisher allerdings nur vereinzelt erhältlich, zum Beispiel als Teil einer Workflow-Lösung wie Across Language Server oder SDL TeamWorks. Es wäre zu wünschen, dass der Anwender nahtlos zwischen einer Desktop-Anwendung für den Profiübersetzer und einer Browseralternative für sporadische Benutzer wechseln kann. Dies wäre auch ein entscheidender Schritt, um dem Translation-Memory-System zur Massentauglichkeit zu verhelfen.

Fazit

Die Möglichkeiten des klassischen Translation-Memory-Systems, das lediglich Satzpaare speichert, scheinen größtenteils ausgereizt zu sein. Während Anwender noch vor Jahren zufrieden waren, einigermaßen passende Treffer aus einem TMS zu erhalten, wird heute erwartet, dass das System absolut einwandfreie und zuverlässige Lösungen liefert.

Um die Zuverlässigkeit eines TM-Treffers zu erhöhen, reicht die reine Speicherung des Ausgangs- und Zielsegments in einer Übersetzungseinheit nicht aus. Das Hinzufügen und Verwalten von Zusatzinformationen in Form von Attributfeldern löst das Problem nur bedingt – zum Preis eines hohen Verwaltungsaufwands. TM-Systeme müssen also in einer Übersetzungseinheit automatisch erweiterte, kontextrelevante Informationen speichern. Dazu gehören Strukturinformationen, zum Beispiel ob ein Satz in einer Überschrift vorkommt, oder das Umfeld eines Segments, also vorhergehende und nachfolgende Sätze oder auch Absätze.

Auf der anderen Seite ist allen Textarten gemeinsam, dass sich die Produktivität durch eine ausgeklügelte Teilsegmenterkennung deutlich steigern lässt. Die Kombination aus kontextsensitiven Übersetzungseinheiten einerseits und der Speicherung von Teilsegmenten andererseits bietet ein weiteres, ähnlich hohes Rationalisierungspotenzial wie die ersten Translation-Memory-Systeme, die den Markt vor 15 Jahren revolutionierten.

Ziad Chama hat in München studiert und ist staatlich geprüfter Übersetzer und Dolmetscher. Von 1999 bis 2006 war er als Produktmanager an der Entwicklung von Produkten von SDL Trados beteiligt. Seit 2007 ist er als freiberuflicher Business Consultant und Trainer für TM-, Terminologie- und Workflow-Systeme tätig.

Ziad Chama
zchama@mac.com