Um der kombinatorischen Explosion an der Schnittstelle Redaktionssystem und Translation Memory System entgegenzuwirken haben namhafte Anbieter von Redaktionssystemen aus dem deutschsprachigen Raum unter dem Dach der DERCOM (Verband Deutscher Redaktions- und Content Management System Hersteller e.v.) in 2015 eine anbieterneutrale Schnittstelle für die bi-direktionale Übermittlung von Übersetzungspaketen zwischen CMS/RS und TMS spezifiziert. 

Mit einiger Verzögerung gelangen nun Implementierungen auf den Markt, als optionale Module bzw. Ergänzungen der Standardkonfiguration der Redaktionssysteme. 

In diesem Beitrag beleuchten wir Stärken und Schwächen der vorliegenden COTI-Spezifikation V1.0.1 und schlagen ein paar nützliche Erweiterungen vor.

Getestet wurde die Implementierung von COTI Level 2 in SCHEMA ST4 2016 Standard. An dieser Stelle bedanken wir uns für die prompte Teststellung des ST4 COTI-Servers durch die SCHEMA GmbH.

COTI Level 1 bis 3 

COTI Level 1 beschreibt Struktur und Inhalt von Übersetzungspaketen. Ein solches Paket besteht aus einer Manifest-Datei, in der die Parameter des Übersetzungsauftrags sowie die Position der zu übersetzenden Dateien und der Referenzdateien angegeben werden. Die Manifest-Datei „coti.xml“ wird mit den Übersetzungs- und Referenzdokumenten in ein ZIP-Archiv verpackt. Dieses trägt die Dateiendung „.coti“.

Level 2 beschreibt, wie Level 1 Pakete mittels eines überwachten Ordners zwischen zwei Systemen ausgetauscht werden können. Level 3 beschreibt den Austausch der Übersetzungsaufträge mittels Webservice. Für Level 2 und 3 ist die Kommunikation zwischen den Systemen inklusive detaillierter Fehlerbehandlung definiert.

Analyse einer COTI-Manifest-Datei

Das Wurzelelement <coti> beschreibt die Version der umgesetzten Spezifikation, gibt den COTI-Level (1 bis 3) an, fordert einen Kommunikationslevel von der Gegenseite (0=keine Logeinträge bis 5=sämtliche Logeinträge) und legt fest, ob die prozessierten Pakete archiviert oder gelöscht werden sollen.

Es sind mehrere <project> Elemente erlaubt, die im nur einmal erlaubten Kind-Element <translation> das Prozessieren eines Sets von Dokumenten in einer Sprachrichtung beschreiben.

Anmerkung: Hier wäre die Bezeichnung „order“ (Auftrag) wohl passender gewesen als „project“. Auch die Referenzdateien (d.h. alle nicht zu übersetzenden Dateien, die aus technischen oder inhaltlichen Gründen mitgeliefert werden) werden hier beschrieben. Es handelt sich dabei z.B. um Konfigurationsdateien für das TMS oder um Referenz-PDFs in der Ausgangssprache als Orientierungshilfe für die ÜbersetzerIn.

Metadaten für die Auftragssteuerung

Der COTI-Standard v1.0.1 liefert wesentliche Parameter für die automatisierte Weiterverarbeitung der COTI-Pakete auf der TMS-Seite. Neben den oben genannten Metadaten zur Steuerung des Verhaltens der Schnittstelle sind dies:

• Projektname und ID
• Nur zu Analysezwecken exportiert (Ja/Nein)?
• Erstellungsdatum
• Fälligkeitsdatum
• Sachgebiet (für Across wäre das die Relation, insgesamt könnte hier die Textart kodiert werden, um z.B. Filtereinstellungen im TM vorzunehmen)
• Ausgangssprache
• Zielsprache
• Dateiformat
• Unterscheidung von Referenzdokumenten und zu übersetzenden Dokumenten

Dieses Set von Parametern reicht aus, um TMS-Exporte (RS) in Übersetzungsaufträge (TMS) umzusetzen und auch (Level 2 und 3) den Rückweg zu moderieren.

Aus unserer Sicht lässt der COTI-Standard aktuell drei wesentliche Punkte offen, welche die TMS-seitige Automatisierung betreffen bzw. mit heutigem Stand die mögliche Automatisierungsstrecke empfindlich verkürzen:

• Workflow

Aufträge bestehen nicht immer nur aus Projektmanagement, Übersetzungs- und Lektoratsschritt. Es gibt noch zahlreiche wählbare Workflowkomponenten wie z.B. Terminologiepflege, Layout, Produktion, Niederlassungskorrektur. Wird der Workflow nicht bereits RS-seitig im COTI-Paket verbindlich festgelegt, dann ist TMS-Seitig ein (vermeidbarer) manueller Prozessschritt notwendig.

• Mandantenfähigkeit

Wer beauftragt werden? – Zumeist gibt es ja mehrere Dienstleister oder Übersetzer. Diese Entscheidung kann mit der derzeitigen Version des Standards nur auf die TMS-Seite verlagert werden (als manueller Prozessschrittt) oder erfordert eine zusätzliche Middleware, die diesen Teil der Logik implementiert, d.h. aus den Auftragsdaten auf den anzufragenden Auftragnehmer schliesst.

• Ersteller/Besteller

TMS und Auftragssteuerungssysteme beim internen oder externen Übersetzungsdienstleister ordnen Aufträge ihren Bestellern zu. Wie sonst könnte dieser kontaktiert bzw. über Lieferungen informiert werden?

Weichmacher im Datenmodell

Die Entwickler des Standards werden argumentieren, dass die soeben erwähnten, fehlenden Parameter durchaus mit dem Datenmodell des COTI-Standards erfasst werden können. Hierfür sind unterhalb des <project>-Elements beliebig viele generische <meta>-Elemente erlaubt:

Ersteller/Besteller
<coti:meta name="CMS-user" value="linnemann"/>

Workflow
<coti:meta name="workflow" value="terminology maintenance"/>

Mandantenfähigkeit
<coti:meta name="lsp" value="neo communication ag"/>

Der Haken an der Geschichte ist, dass solche optionalen Elemente wie <meta> bei Implementierungen der Anbieter typischerweise unter den Tisch fallen. Ausserdem wird TMS-seitige Konfiguration erzwungen, weil jede RS-Installation eine andere Semantik für die im <meta>-Element kodierten Parameter aufweisen wird.

Sinnvoller wäre es, z.B. die Angabe des Workflows mit einem eigenen Element vorzusehen, das von allen TMS, die den COTI-Standard implementieren, in identischer Weise ausgewertet wird:

<coti:workflow type="component" value="Proofreading"/>

Wie die Workflows benannt werden kann immer noch offen gelassen werden, da Bezeichnung und zugeordnete Bedeutung sich TMS-seitig und kundenspezifisch unterscheiden können.

Fazit

Der COTI-Standard ermöglicht die bi-direktionale, automatisierte Übermittlung von Übersetzungspaketen. Er ist der einzige uns bekannte Versuch, RS und TMS mit einem offenen Standard auf Prozessniveau zu koppeln. Andere branchenspezifische Standards wie XLIFF, TMS, TBX etc. dienen lediglich dem Austausch zwischen Systemen auf Dateiebene und kodieren wenig bis gar keine Parameter zur Prozessintegration. Systeme, die den COTI-Standard implementieren, können auch verteilt installiert sein (bei Auftraggeber und –nehmer). Nicht jede Redaktionsabteilung mit RS kann und will ein TMS bzw. Auftragssteuerungssystem in der eigenen Umgebung betreiben.

Die detaillierten Vorgaben des Standards zur Schnittstellenkommunikation ermöglichen sehr robuste Umsetzungen. Um viele CMS/RS und TMS-Anbieter anzusprechen beschreibt die Spezifikation den kleinsten gemeinsamen Nenner dieser Systeme in Bezug auf die obligatorischen Auftragsparameter. Das ist für die hoffentlich bald flächendeckende Verbreitung des Standards wichtig, ist andererseits aber auch der Grund für die von uns in diesem Beitrag kritisierten, inhaltlichen Lücken des Standards.

DERCOM überarbeitet aktuell die COTI-Spezifikation. Wir sind schon sehr gespannt, wie sich der Standard weiter entwickelt und ob einige unserer bereits kommunizierten Wünsche dann berücksichtigt werden konnten.

neo implementiert zurzeit eine COTI Schnittstelle für die eigenentwickelte, auf Microsoft SharePoint basierende Auftragssteuerung.

victor.linnemann[at]neo-comm.ch