Wechsel des Translation-Memory-Systems: Was hat das für Folgen?

Seit etwa sieben Jahren ist die Welt der Übersetzungstechnologien im Umbruch. Neue Produkte wie across oder MemoQ kamen 2004 bzw. 2005 auf den Markt, während etablierte Technologien neue Versionen präsentierten. Das vorerst letzte Kapitel dieser Entwicklung kündigte im Jahr 2009 SDL mit der lang ersehnten neuen Version Trados Studio an. Aufgrund ihrer neuen Architektur und Bearbeitungsformate kommt sie einem neuen Produkt gleich. Vor diesem Hintergrund sehen sich viele Firmen und Dienstleister mit einem möglichen und nicht immer freiwilligen Wechsel des Translation-Memory-Systems (TMS) konfrontiert. Bevor sie die endgültige Entscheidung für ein Programm treffen, sollten sie sich mit der Datenmigration beschäftigen, denn es ist keine triviale Aufgabe.

Was ist dabei zu bedenken? Zuerst geht es um die Übernahme vorhandener Translation Memories in ein neues Programm. Translation Memories stellen ein Vermögen dar. Es sind die über Jahre angesammelten übersetzten Segmente und Sätze. Diese Segmente enthalten oft Formatierungsinformationen, die der Importfilter eines TMS generiert. Es kann sich beispielsweise um einen Tag für eine gewisse Schriftart in InDesign handeln. Zusätzlich enthalten Segmente Attribute, die in jedem System unterschiedlich definiert sind. So kann ein Segment Attribute wie ein Wiederverwendungszähler, ein Änderungsdatum oder eine Projektnummer erhalten. Manche Attribute sind systemspezifisch, andere lassen sich individuell definieren. Bei einigen Übersetzungssystemen spielt außerdem das Translation – Memory – Konzept für die Migration eine Rolle. Zum einen haben wir segmentbasierte Translation Memories (Segmente bzw. Sätze werden in zwei Sprachen paarweise in einer Datenbank gespeichert) und zum anderen haben wir referenztextbasierte Translation Memories. Das Konzept der segmentbasierten TMs wurde außerdem in den letzten 2-3 Jahren erweitert, sodass manche neuere Systeme auch eine Art Mini-Kontext speichern.

Die neue Version von Trados, Trados Studio, erfasst z. B. zusätzlich zum eigentlichen Segment auch das vorhergehende Segment im Dokument als Mini-Kontext. Die Frage ist also, ob man all die Informationen innerhalb des Segments und über das Segment ohne Reibungsverluste von einem System in das nächste übernehmen kann. Die Migration gewährleistet leider keine 100%ige Kompatibilität und zieht je nach Migrationsrichtung auch mehr oder weniger große Informationsverluste bei den Metadaten nach sich. So werden die Informationen über InDesign-Formate zwischen zwei TradosVersionen (z. B. von Trados 2007 auf Trados Studio 2009) gut übertragen, während sie zwischen zwei konkurrierenden Systemen wie Trados und across verloren gehen, weil die Importfilter unterschiedlich arbeiten. Konkret bedeutet dieser Informationsverlust, dass das neue System vorhandene Übersetzungen nicht mehr zu 100% wiederverwenden kann. Wenn z. B. bei einem Translation Memory von ca. 40.000 Segmenten 5% der vorhandenen Übersetzungen in 20 Sprachen nicht mehr ganz, sondern nur als Fuzzy Match wiederverwendet werden, entspricht dies einem Wertverlust in der Größenordnung von 10.000 – 15.000 Euro. Weitere Migrationsprobleme können bei der Zeichencodierung oder bei unterschiedlichen Segmentdefinitionen auftreten.

Die Abspeicherung von TMs im Standardformat TMX garantiert ein Mindestmaß an Kompatibilität. Darüber hinaus können Transformationen einen Teil des Datenverlusts ausgleichen. So lassen sich nachträglich Attribute setzen (z. B. ein Bearbeitungsstatus, eine Zuverlässigkeitsquote), wobei dies mit Hilfe von Skripten, Makros, XSL oder Editoren wie Olifant erfolgen kann.

Auch übersetzte Projekte möchte man u. U. migrieren. Hierfür gibt es das Standardformat XLIFF, wobei ähnliche Restriktionen wie beim Austausch von Translation Memories gelten. Zusätzlich zu den Memories und Projekten sind bei manchen Applikationen weitere Dateien zu migrieren, die für die Konfiguration des Systems wichtig sind. Das ist beispielsweise für die INI-Dateien von Trados der Fall.

Neben Projekten sind eventuell auch Terminologien zu migrieren. Auch hier sind die Datenmodelle zwischen den einzelnen Anbietern teilweise stark unterschiedlich. Manche Systeme bieten nur eine begrenzte Zahl von Terminologiefeldern, während andere eine relativ große Flexibilität in Bezug auf das Datenmodell haben. Auch wenn Terminologie über Formate wie CSV oder TBX zur Verfügung steht, muss man trotzdem die Lücken im Datenmodell überbrücken. Zu guter Letzt gehören Einarbeitung und Schulungen zu den oft übersehenen Migrationskosten.

Neben Fragen der Datenkonvertierung bringt eine Migration weitere Herausforderungen mit sich wie den Austausch von Daten und Projekten mit externen Benutzern, die künftige Pflege und die Interaktion mit anderen Programmen und Datenbanken. Die Unterstützung von offenen Standards bringt in diesem Zusammenhang Vorteile.

Es empfiehlt sich also, vor der Entscheidung über ein neues System anhand von Testdateien den Aufwand und den Informationsverlust bei den in Frage kommenden TMS zu testen.

[Text: D.O.G. Dokumentation ohne Grenzen GmbH. Quelle: D.O.G. news 2/2011. Wiedergabe mit freundlicher Genehmigung von Dr. François Massion.]