Translation Memory Systeme - digitales Übersetzungsmanagement

Translation Memory Systeme - digitales Übersetzungsmanagement

Posts 1-7 of 7
  • Hajo Hensel
    Hajo Hensel    Premium Member
    The company name is only visible to registered members.
    Austauschformate
    Gibt es eine für alle TMS eine gleiche fest definierte Schnittstelle zum Datentransfer (wie z.B. BMEcat bei Übertragung elektronischer Produktkataloge)?
    Welches Austauschformat ist aus der Praxis das sinnvollste (Excel, CSV, XML ...)?
    Bei Excel bekomme ich Bauchschmerzen bei längeren Texten >255 Zeichen.
    Bei CSV sind es die Zeilenumbrüche, Zeichenkodierung und Escape-Zeichen (; und ") die Probleme bereiten.
    Viele PIM-Systeme bieten aber Excel oder CSV als Standardaustauschformat an.
    This post was modified on 11 Jan 2008 at 05:29 pm.
    • 11 Jan 2008, 5:14 pm
  • Ulrich Schmidt
    Ulrich Schmidt    Premium Member
    The company name is only visible to registered members.
    Re: Austauschformate
    ... ja gibt es, tmx heißt es
    leider bemühen sich die Hersteller nicht, das tmx wirklich absolut exakt gleich auszugeben. Hier gibt es leider verschieden Versionsstände und jeder hersteller unterstützt einen anderen Versionstand (siehe http://www.lisa.org/standards/tmx/)
    Auch die Tagauszeichnung innerhalb des tmy ist nicht eindeutig.

    Das Resultat?: ein tmx-Austausch von einem TM-System zum Nächsten verursacht immer Verluste in der Effizienz. Neben dem Austausch ist es bei einem Datenportierung auf ein anderes TM-System nötig, das TM-System so zu konfigurieren, das es sich gleich verhält wie das System, in dem die Daten produziert wurden (Stichwort Segmentierung)

    Alles nicht so einfach und auch nicht schnell zu erlernen, hierfür bedarf es vertiefter Kenntnisse von dem Quell- und Zielsystem.

    Die höchste Effizienz erziehlt man bei einem tmx-Austausch, wenn die Quelldaten xml waren
    • 06 Feb 2008, 4:45 pm
  • Marco Kahler
    Marco Kahler    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Austauschformate
    Ich habe mal von einem XLIFF Format gelesen, doch leider bis heute in der Praxis keinerlei Erfahrungen gemacht. Nach meinen Informationen wollte Trados/SDL diesen Standard fördern.
    Ist jemanden dieses Format bekannt und hat jemand Erfahrung damit?
    Ist dies i.d.T. eine Trados/SDL Domäne?

    Ich würde mich über tiefere Informationen freuen.

    viele Grüße
    Marco Kahler
    • 06 Feb 2008, 10:32 pm
  • Ulrich Schmidt
    Ulrich Schmidt    Premium Member
    The company name is only visible to registered members.
    Re^3: Austauschformate
    Anbei ein Artikel zum Thema XLIFF von dem Forum FOLT, zusammengefasst: XLIFF ist ein Austauschformat, herstellerunabhängig, aber bisher in der Praxis kaum im Einsatz

    Artikel FOLT:
    In letzter Zeit taucht immer häufiger das Akronym „XLIFF“ auf. Es ist also an der Zeit, einmal zusammenzutragen, was „XLIFF“ eigentlich bedeutet und wofür die zugrunde liegende Technologie eingesetzt werden kann.

    Zunächst einmal der Name: Was bedeutet „XLIFF“?

    XLIFF steht für XML Localisation Interchange File Format. XLIFF ist aber mehr als ein „Dateiformat“, es ist ein bei der OASIS (Organization for the Advancement of Structured Information Standards, http://www.oasisopen. org) angemeldeter Standard zum Austausch von Dokumentendaten.

    Welches Problem wird mit diesem Standard angegangen? Nehmen wir als Beispiel das Zusammenspiel zwischen Dokumentenerstellern – z.B. eine Dokumentationsabteilung eines Maschinenherstellers – und Übersetzungsdienstleister. Immer wenn zwischen diesen beiden Parteien Dokumentendaten ausgetauscht werden, um den Inhalt zu übersetzen, werden heute ganze Dokumente hin- und hergeschickt, vollständig inklusive Layoutdaten, Bildern, PDF-Dateien als Referenz usw. Das können Word-Dateien sein, InDesign- oder FrameMaker-Dokumente, oder was auch immer zum Erstellen und Produzieren der Dokumentation verwendet wird. Der Übersetzungsdienstleister setzt ein Translation Memory System ein, um so seine Kunden schnell, effizient und preiswert zu bedienen. Diese Systeme verarbeiten aber vor allem und am besten den reinen Text (also: den Inhalt) der Dokumente; Bilder und Layoutdaten sind eigentlich nur störender Ballast, der die maximale Wiederverwendung schon vorhandener Übersetzungen behindert.

    Ein Übersetzungsdienstleister, der seine Kunden optimal bedienen möchte, muss also zunächst die Kundendokumente so konvertieren, dass sie vom verwendeten TMSystem verarbeitet werden können. Das bedeutet: Der Text muss vom restlichen Dokument getrennt werden, und zwar idealerweise so, dass nach der Übersetzung der übersetzte Text wieder möglichst automatisch und korrekt in das Dokument eingesetzt werden kann. Noch ist aber nichts übersetzt: Das TM-System verwaltet nur schon bestehende Übersetzungen, für neue oder geänderte Texte ist der Übersetzer gefragt, oder, bei größeren Projekten, ein Team von Übersetzern. Diesen Übersetzern müssen nun die Daten – Texte – zur Verfügung gestellt werden, die sie bearbeiten sollen. Dabei muss berücksichtigt werden, welches Werkzeug der jeweilige Übersetzer verwendet und ob dieses Werkzeug mit dem verwendeten TM-System kompatibel ist und Daten ohne Umwandlung ausgetauscht werden können. Meist ist aber auch hier eine Konvertierung notwendig, da es kein gemeinsames, von allen Übersetzungswerkzeugen verstandenes Datenformat gibt. Nach der Übersetzung wird wieder konvertiert; die fertigen Inhalte sollen ja in das ursprüngliche Dokument „eingebaut“ werden, also ins Layout eingefügt werden. Und da nun schon mehrfach konvertiert wurde, muss das Layout häufig von Hand repariert werden und – vor allem – aufwändige Qualitätssicherung betrieben werden, um sicher zu stellen, dass all die Konvertierungen und Layout-Korrekturen keine Fehler ergeben haben. Schlimmer noch ist aber ein anderer Effekt: Auch die Übersetzer verwenden TM-Systeme, diesmal aber als komfortables Werkzeug zur Erstellung der Übersetzung. Moderne TM-Systeme haben speziell für den Übersetzer hochspezialisierte Oberflächen, um ihn bei der Arbeit maximal zu unterstützen. Automatisierte Übersetzungsvorschläge, Terminologieunterstützung und mehrsprachige Rechtschreibkontrollen sind nur ein paar der Funktionen, auf die ein Übersetzer heute nicht mehr verzichten sollte. Das bedeutet aber, dass der Übersetzer seine zu übersetzenden Texte in einer Form erhalten muss, die sein TM-System verarbeiten kann. Wenn ein Übersetzer, den man einsetzen möchte, nicht das TMSystem des Übersetzungsdienstleisters verwendet, muss konvertiert werden, da die auf dem Markt befindlichen TM-Systeme natürlich nicht kompatibel zueinander sind. Diese Konvertierungen sind immer fehleranfällig und oft mit dramatischen Konvertierungsverlusten verbunden. Viel zu oft bedeutet dies, dass man einen Übersetzer, den man eigentlich wegen seiner fachlichen Befähigung einsetzen sollte, anhand der von ihm verwendeten Werkzeuge auswählt. Eine sicher mehr als unglückliche Situation.

    Für all dies soll XLIFF d i e Lösung sein. Wie das?

    XLIFF gibt es nun schon in der 3. Überarbeitung (Version 1.2 ist zurzeit im sog. „Public Review“ und steht damit kurz vor der Verabschiedung) und ist ein XML-basiertes Datenaustauschformat. Die Historie reicht zurück in das Jahr 2000, als sich Vertreter der Firmen IBM, Novell, Berlitz und Oracle zusammenfanden und eine Arbeitsgruppe gründeten mit dem Ziel, Austauschformate im Übersetzungsprozess zu vereinheitlichen. Daraus entstand XLIFF 1.0, das aber zunächst nicht veröffentlicht werden konnte, da sich die Beteiligten nicht über Urheberrechtsfragen einigen konnten. Statt dies wie sonst gerichtlich zu regeln, trat man im Jahre 2001 der OASIS bei und übergab den „Working Draft“ damit effektiv der Öffentlichkeit („Public Domain“). Der „Working Draft 2a“ wurde nun von der OASIS am 15.09.2002, der aktuelle Standard XLIFF 1.1 schließlich am 31. Oktober 2003 veröffentlicht. Ein wichtiges Ziel der Arbeitsgruppe war, den Datenfluss im gesamten Übersetzungsprozess zu unterstützen. Es sollte also möglich sein, dass Redaktionssysteme, Layout-Programme und klassische Textverarbeitungssoftware ihre Inhalte als XLIFF-Datenstrom bereitstellen, entweder direkt oder über spezielle Filter. Die XLIFF-Struktur sollte so beschaffen sein, dass diese XML-Daten dann unkonvertiert von TM-Systemen und Übersetzungs- Workflow-Systemen aufgenommen und weiterverarbeitet werden können. Insbesondere sollte auch die Schnittstelle zum (Einzel-)Übersetzer berücksichtigt werden, damit diese in ihrer Arbeit besonders unterstützt werden können.

    Dazu müssen in XLIFF u.a. folgende Inhalte abbildbar sein:

    Ursprünglicher Inhalt der Dokumente:
    Der gesamte Inhalt der Dokumente soll darstellbar sein. Das ist in erster Linie natürlich der vollständige Text, in einer sinnvollen Reihenfolge. Der Text wird dazu vorab in seine kleinsten unabhängig übersetzbaren Einheiten zerlegt, die so genannten Segmente. Ein Segment entspricht meistens genau einem Satz in der Quellsprache, es kann aber auch z.B. eine Kapitel- oder Spaltenüberschrift oder gar ein ganzer Absatz sein. Letztlich muss das Redaktionssystem bzw. der XLIFF-Filter anhand der Dokumentenstruktur entscheiden, was genau jeweils ein Segment darstellt.
    Kontextinformationen:
    Für das Verständnis und die Übersetzung ist es oft notwendig, Informationen wie das Fachgebiet, die verantwortliche Abteilung, Verweise auf externes Material (Bilder, Referenzdokumente etc.) zur Verfügung zu haben. Es können aber zu jedem Produktionsschritt Kontextinformationen generiert werden. So können z.B. Rückfragen eines Übersetzers direkt in den XLIFF-Daten transportiert werden, ohne dass ein gesonderter Kommunikationsweg nötig ist.

    Übersetzungsvorschläge aus dem Translation Memory
    (auch mehrere alternative Vorschläge) oder aus maschineller Übersetzung. XLIFF ist hier besonders reichhaltig ausgestattet. Es können nicht nur mehrere Vorschläge dem Übersetzer geliefert werden, diese Vorschläge werden zudem noch mit Meta-Informationen verknüpft, so dass zu jedem Vorschlag angezeigt werden kann, aus welchem TM, aus welcher Quelle und mit welcher Treffsicherheit diese Übersetzung ausgewählt wurde. Der Übersetzer kann auch erkennen, ob das Segment eventuell maschinell übersetzt wurde und so insgesamt besser beurteilen, ob und welcher Vorschlag verwendet werden kann.

    Informationen zu Qualität und Quelle der Übersetzungsvorschläge:
    Dem Übersetzer sollen bei mehreren Übersetzungsvorschlägen Entscheidungshilfen an die Hand gegeben werden. So wird er z.B. übersetzten Segmenten, die aus „ähnlichen“ Übersetzungsprojekten stammen, sicher den Vorzug gegenüber maschinell übersetzten Texten geben.

    Terminologie: Informationen aus Terminologiedatenbanken wie Bedeutung, Übersetzung und Verwendung eines Terms können direkt dem Segment mitgegeben werden, in denen ein Term aus der Datenbank verwendet wird.

    Die Übersetzung selbst.

    Verwaltungsinformationen wie Status, Termine, Zielsprachen etc. für die Workflow-Steuerung.

    Daten zur Unterstützung der Qualitätssicherung: abgelehnte oder verbesserte Übersetzungen, vorherige Übersetzungen und Bewertungen.
    Segmentabhängige Layoutinformationen wie Fettdruck einzelner Wörter oder Marken für die automatische Indexerstellung.

    Bei alledem ist XLIFF ein offener Standard. Durch die Ansiedlung bei der OASIS ist sichergestellt, dass die XLIFF Spezifikationen, die gesamte Dokumentation dazu und der Prozess der Weiterentwicklung auch in Zukunft für jedermann transparent und einsehbar sind. Mehr noch: die Verwendung von XLIFF ist – jetzt und in Zukunft – an keine Lizenzgebühren gebunden. Die Übergabe eines Standardisierungsprojektes an die OASIS bedingt ausdrücklich, dass alle Copyrights, Urheberrechte und Lizenzrechte unwiderruflich kostenfrei an die OASIS übergehen und die OASIS in die Lage versetzt wird, alles Material frei und öffentlich zur Verfügung zu stellen. Dazu gehört auch, dass XLIFF ausdrücklich produkt- und firmenunabhängig ist. Kein einzelner Software-Hersteller kann ein OASIS-Projekt kontrollieren oder dominieren, es wird auch kein projektabhängiges Sponsoring akzeptiert. Auch das soll dazu beitragen, dass OASIS-Standards unabhängig und offen bleiben. XLIFF basiert auf bestehenden standardisierten XML-Formaten wie UIML, OpenTAG oder TMX und fasst deren Anwendungsbereich zusammen. So sollte es relativ einfach sein, schon bestehende Schnittstellen zu TMX auf XLIFF zu erweitern. Da XLIFF aber wesentlich breiter angelegt ist als TMX, das nur dem Translation- Memory-Austausch dienen soll, wäre ein simpler TMX-zu- XLIFF-Konverter bestenfalls ein Startpunkt. Sinnvoller ist es, die jeweilige Applikation mit echten, vollständigen XLIFF-Schnittstellen auszurüsten. Am wichtigsten aber ist, dass XLIFF selbst ein XML-Format ist. XML als Basistechnologie wird heute in allen Bereichen der Dokumentenbearbeitung eingesetzt und es hat sich ein überaus reichhaltiges Sortiment an Werkzeugen und Bibliotheken zur Softwareentwicklung etabliert. Jedes XMLbasierte Redaktionssystem – und jedes System, das etwas auf sich halten will, sollte XML-basiert sein! – kann problemlos um eine XLIFF-Schnittstelle erweitert werden. Die meisten Layoutsysteme bieten schon XML-Schnittstellen, auf die aufgesetzt werden kann. Es zeigt sich eben auch hier wieder einmal, wie überaus wertvoll XML als offenes, weltweit standardisiertes Format zum Datenaustausch ist. XLIFF als eine spezialisierte Anwendung von XML verdient es, häufiger eingesetzt zu werden
    • 07 Feb 2008, 09:19 am
  • Bernd Schwennicke
    Bernd Schwennicke
    The company name is only visible to registered members.
    Re^3: Austauschformate
    XLIFF ist keine Trados/SDL-Domäne. Das ist ein vom OASIS standardisiertes, XML-basiertes Austauschformat für sämtliche Lokalisierungsdaten, also TMs, Terminologie-DBs, aber auch zu übersetzende Texte an sich. XLIFF könnte also TMX oder TBX überflüssig machen. Die Idee ist, zu übersetzende Texte direkt in XLIFF umzuwandeln, so dass sie von jeder Übersetzungsumgebung verarbeitet und mit anderen ohne Datenverlust ausgetauscht werden könnten.

    Richtig umgesetzt ist das meines Wissens nur in den Open Language Tools (Sun) und in Transolution (was aber offenbar nicht mehr gepflegt wird). Wir haben uns das mal angesehen, sind aber -- u. a. wegen mangelnder Unterstützung bestimmter Dateiformate, was wieder Mehraufwand zum Konvertieren benötigt hätte -- wieder bei einer kommerziellen Lösung gelandet.

    Ahoi,
    Bernd
    • 07 Feb 2008, 09:39 am
  • Post visible to registered members
  • Bernd Schwennicke
    Bernd Schwennicke
    The company name is only visible to registered members.
    Re^5: Austauschformate
    Stimmt, XLIFF wird TMX nicht ersetzen -- muss es auch nicht, hätte jedoch ;-)

    Aber das mehr oder weniger große Problem bleibt: Jeder Hersteller hat quasi "sein" TMX, und der Import aus einer Umgebung in die andere kann sich deshalb schon mal schwieriger als erwartet gestalten.

    Ich wünschte mir XLIFF jedoch als anerkanntes Dateiformat für zu übersetzende Dateien. Es gibt ja Konverter (z. B. Suns OLT), die schmerzfrei aus ODT, Java Properties u. a. XLIFF erzeugen; damit könnte jede ÜS-Umgebung (in unserem Fall: across) diese sonst nicht unterstützten Dateiformate verarbeiten.

    Ahoi,
    Bernd
    • 07 Feb 2008, 3:29 pm