Wie man DITA-Dateien ohne XLIFF-Konvertierung übersetzt

Suchen Sie nach einer Möglichkeit, Ihre DITA-Dateien zu übersetzen, ohne sich ständig mit manuellen XLIFF-Konvertierungen herumschlagen zu müssen? Wenn das der Fall ist, sind Sie hier genau richtig. DITA (Darwin Information Typing Architecture) ist bereits der Goldstandard für Effizienz und Inhaltswiederverwendung, dennoch stecken viele technische Content-Teams in einem frustrierenden Kreislauf fest: der XLIFF-Konvertierungsschleife.

Wenn Ihr aktueller Übersetzungsworkflow das Exportieren von DITA-Dateien in das XLIFF-Format, das Senden dieser Dateien an eine Agentur und das anschließende manuelle Reimportieren in Ihr System beinhaltet, verlieren Sie wahrscheinlich mehr als nur Zeit. Sie riskieren möglicherweise die Integrität der Dokumentation, an deren Erstellung Sie so hart gearbeitet haben.

In diesem Artikel werden wir über die technischen Fallstricke der manuellen Konvertierung, die versteckten Kosten der Delta-Verwaltung und darüber sprechen, warum die native DITA-Unterstützung ein Wendepunkt für moderne Dokumentationsteams ist. Wenn Sie diesen Artikel gelesen haben, sind Sie bereit, Ihre DITA-Übersetzungsworkflows zu optimieren und zu einem schnelleren, zuverlässigeren und deutlich kostengünstigeren Prozess überzugehen. Lass uns gleich loslegen!

Die XLIFF-Steuer auf technische Dokumentation

XLIFF (XML Localization Interchange File Format) ist ein hervorragender Standard für viele Dinge, aber für DITA-Benutzer fungiert er oft als Vermittler, der mehr verkompliziert als vereinfacht. Wir bezeichnen dies oft als die XLIFF-Steuer: den versteckten Preis an Zeit, Geld und manueller Arbeit, der erforderlich ist, damit das Format funktioniert. Hier erfahren Sie, warum dieser manuelle Konvertierungsprozess Ihr Team möglicherweise mehr kostet, als Sie denken.

1. Die Aufschlüsselung der Inhaltswiederverwendung: Conrefs und Keyrefs

Die wahre Genialität von DITA liegt in seiner Fähigkeit, Inhalte über mehrere Themenbereiche hinweg zu referenzieren. Bei der Konvertierung einer DITA-Datei in das XLIFF-Format werden diese komplexen Beziehungen oft aufgehoben oder vollständig zerstört. In einer Standard-XLIFF-Datei kann eine Inhaltsreferenz (conref) einfach als statische Textzeichenfolge erscheinen.

Dies führt zu einem erheblichen finanziellen Problem: Es kann passieren, dass Sie die gleiche Warnmeldung oder Sicherheitsvorschrift mehrfach übersetzen lassen müssen, weil das Konvertierungstool sie nicht als eine einzige wiederverwendbare Einheit erkannt hat. Noch schlimmer ist, dass Sie beim erneuten Importieren dieses Textes möglicherweise feststellen, dass Ihre globalen Inhaltsverweise durch fest codierten Text überschrieben wurden, was Ihre modulare Architektur effektiv zerstört und zukünftige Aktualisierungen zu einem Albtraum macht.

2. Beschädigte Tags und Validierungsfehler

DITA-Dateien unterliegen strengen DTDs (Document Type Definitions) oder XML-Schemas. Jedes Mal, wenn Ihre Inhalte vom .dita-Format ins .xliff-Format und wieder zurück konvertiert werden, besteht die Gefahr, dass ein sogenanntes Tag-Chaos entsteht.

Es genügt schon ein Übersetzer, der mit der DITA-Struktur nicht vertraut ist, um versehentlich ein erforderliches Attribut zu löschen oder ein schließendes Tag falsch zu platzieren. Eine einzige fehlende Klammer oder ein falsch platziertes Attribut während dieses Roundtrips kann Ihren gesamten DITA-OT-Build zum Scheitern bringen. Das kennen wir alle: Es ist Freitagnachmittag, und man versucht, eine neue Version zu veröffentlichen, aber stattdessen müssen die Support-Ingenieure Tausende von Codezeilen durchforsten, um einen einzigen Validierungsfehler zu finden.

3. Der Delta-Management-Albtraum

Manuelle XLIFF-Workflows zwingen Autoren oft dazu, ihre Kreativität aufzugeben und stattdessen Dateiverwalter zu werden. Um Übersetzungskosten zu sparen, versuchen Autoren oft, die Änderungen manuell zu ermitteln (nur die Dateien, die sich seit dem letzten Update geändert haben). Dieser Prozess ist aus drei Gründen bekanntermaßen schwierig:

• Es ist fehleranfällig: Wenn nur ein aktualisiertes Thema fehlt, kann dies zu einer nicht mehr synchronen Dokumentation führen, die Ihre Kunden verwirrt.
• Es ist technisch aufwendig: Ihr Team verbringt am Ende Stunden damit, Versionen zu vergleichen, anstatt neue, hilfreiche Inhalte zu schreiben.
• Es fehlt der Kontext: Wenn eine kleine Änderung in einem Thema die Bedeutung eines verwandten Themas beeinflusst, wird eine manuelle Delta-Auswahl dies wahrscheinlich nicht erkennen.

Jenseits des Etiketts: Die Bedeutung des Attributschutzes

Einer der am meisten übersehenen Aspekte des Konflikts zwischen DITA und XLIFF ist die Verwaltung von XML-Attributen. DITA stützt sich stark auf Attribute für Profiling und Filterung, wie z. B. Produkt, Plattform und Zielgruppe. Dies sind die Werkzeuge, mit denen Sie verschiedene Versionen eines Handbuchs aus derselben Quelle veröffentlichen können.

Bei Verwendung eines nativen DITA-Workflows sind diese Attribute standardmäßig geschützt. Bei MotaWord erkennt unser System, dass ein Produktattribut ein Metadatenelement ist, das niemals übersetzt werden sollte. Bei einer standardmäßigen XLIFF-Konvertierung werden diese Attribute oft entweder entfernt (was Ihre bedingte Veröffentlichung beeinträchtigt) oder dem Übersetzer zugänglich gemacht. Wenn ein Übersetzer pro_version sieht und es ins Spanische als version_profesional übersetzt, funktioniert Ihre bedingte Verarbeitungslogik nicht mehr.

Warum Translate=No ein Lebensretter ist

Das Attribut translate="no" ist ein wichtiges Werkzeug für technische Redakteure, die Code-Snippets, Befehlszeilenanweisungen oder bestimmte Markennamen in allen Sprachen einheitlich halten müssen. Ein nativer DITA-Parser berücksichtigt dieses Attribut auf Engine-Ebene. Bei manuellen XLIFF-Konvertierungen werden diese Anweisungen häufig von den Filtern ignoriert, die zur Erstellung der XLIFF-Datei verwendet werden, was zu kostspieligen und ärgerlichen Nachbearbeitungszyklen führt, um überübersetzte Inhalte zu korrigieren.

Die Kontextlücke: Warum Übersetzer mit XLIFF zu kämpfen haben

Übersetzung ist mehr als nur der Austausch von Wörtern: Es geht darum, den Kontext zu verstehen. Wenn ein DITA-Thema in eine flache XLIFF-Datei konvertiert wird, sieht der Übersetzer oft eine Liste isolierter Zeichenketten. Sie verlieren die Kartenansicht, die dem Projekt seine Struktur verleiht. Sie können nicht erkennen, dass ein bestimmter Titel zu einem spezifischen Abschnitt innerhalb einer größeren Aufgabe gehört.

Durch die Verwendung der nativen DITA-Übersetzung arbeitet der Übersetzer in einem System, das die DITA-Hierarchie tatsächlich versteht. Dies bietet mehrere Vorteile für die Qualität Ihrer Dokumentation:

• Es sorgt für mehr Klarheit: Der Übersetzer weiß, ob ein Wort ein Schritt, ein Ergebnis oder eine Voraussetzung ist.
• Es gewährleistet eine einheitliche Terminologie: Das System stellt sicher, dass ein in einer Kurzbeschreibung verwendeter Begriff mit demselben Begriff im Hauptteil des Themas übereinstimmt.
• Es wahrt die visuelle Integrität: Der logische Informationsfluss bleibt erhalten, was besonders wichtig ist, wenn Sie komplexe technische Handbücher für Hardware oder Software erstellen.

Ein besserer Weg: Native DITA-Übersetzung mit MotaWord

Wir sind der Ansicht, dass sich technische Redakteure auf den Inhalt konzentrieren sollten und nicht mit Dateiformaten kämpfen müssen. Deshalb haben wir daran gearbeitet, den XLIFF-Zwischenhändler durch einen nativen Ansatz zu eliminieren.

Workflow-Vergleich

Der manuelle XLIFF-Workflow

• Erfordert stundenlanges Exportieren und Filtern von Dateien.
• Birgt ein hohes Risiko der Verflachung von Inhaltsreferenzen.
• Führt häufig zu fehlerhaften oder versehentlich übersetzten Metadaten.
• Erfordert eine umfangreiche manuelle Qualitätssicherung nach dem Import der Dateien.
• Durch manuelle Arbeit und doppelte Saiten entstanden versteckte Kosten.

Der native DITA-Workflow mit MotaWord

• Durch das direkte Hochladen Ihrer Dateien dauert es nur wenige Minuten.
• Schützt die Integrität Ihrer Conref-Daten zu 100 Prozent.
• Metadaten werden automatisch gesperrt oder ignoriert, um ihre Sicherheit zu gewährleisten.
• Liefert Dateien, die sofort nach dem Herunterladen kompilierbar sind.
• Nutzt Translation Memory, um sicherzustellen, dass Sie nur für neue Inhalte bezahlen.

Laden Sie Ihre unkomprimierten .dita- und .ditamap-Dateien hoch.

Statt komplexer Exportvorgänge können Sie einfach Ihre DITA-Rohdateien oder Ihr gesamtes Ditamap-Projekt hochladen. Unsere Plattform ist so konzipiert, dass sie die DITA-Struktur nativ parsen kann. Es erkennt den Unterschied zwischen Titel, Textkörper und Kurzbeschreibung und stellt so sicher, dass Ihre Metadaten unberührt bleiben und Ihre Struktur intakt bleibt.

Automatisierung statt manueller Differenzierung

Da MotaWord ein integriertes Übersetzungsspeicher verwendet, müssen Sie nicht mehr Zeit damit verbringen, herauszufinden, welche Dateien geändert wurden. Sie können das gesamte Projekt hochladen und das System die Hauptarbeit erledigen lassen:

• Unser System vergleicht Ihre gesamte Ditamap mit Ihren vorherigen Übersetzungen.
• Es erkennt neue oder geänderte Zeichenketten in Sekundenschnelle.
• Sie zahlen nur für die neuen Wörter und profitieren so von den Kostenvorteilen der Deltas ohne den damit verbundenen manuellen Aufwand.

Die Ökonomie der baufertigen Dokumentation

Die wahren versteckten Kosten der XLIFF-Konvertierung zeigen sich im abschließenden Veröffentlichungszyklus. Bei einem manuellen Arbeitsablauf ist der Empfang der übersetzten Dateien erst die Hälfte des Prozesses. Sie müssen trotzdem alles erneut in Ihr CCMS (Component Content Management System) importieren, einen Test-Build mit dem DITA Open Toolkit durchführen und die unvermeidlichen XML-Fehler beheben.

Diese Lokalisierungs-Qualitätssicherungsphase kann Tage oder sogar Wochen der Arbeitszeit eines Autors in Anspruch nehmen. Die native DITA-Unterstützung stellt sicher, dass die heruntergeladenen Dateien sofort einsatzbereit sind. Da die Konstruktion nie demontiert wurde, um in einen XLIFF-Container zu passen, muss sie nicht wieder aufgebaut werden. Mit nur wenigen Klicks gelangen Sie von der fertigen Übersetzung zur veröffentlichten PDF- oder HTML-Website.

Häufig gestellte Fragen

1. Wie lassen sich DITA-Dateien übersetzen, ohne die Conrefs zu beschädigen?

Native DITA-Übersetzungsplattformen wie MotaWord verarbeiten die Dateien in ihrer ursprünglichen XML-Struktur. Durch den Verzicht auf die Konvertierung in XLIFF bleiben die Verweise auf Ihre Inhaltsreferenzen (conrefs) und Schlüsselreferenzen (keyrefs) erhalten. Dadurch wird sichergestellt, dass wiederverwendbare Objekte korrekt behandelt werden, ohne dass sie fest in den übersetzten Text einprogrammiert werden.

2. Welcher DITA-Übersetzungsworkflow eignet sich am besten für kleine Teams?

Der effizienteste Workflow für kleine Teams ist ein Direct-to-DITA-Ansatz. Anstatt in teure Middleware zu investieren oder stundenlang manuelle XLIFF-Exporte durchzuführen, sollten kleine Teams eine Plattform nutzen, die .dita- und .ditamap-Dateien direkt akzeptiert. Dadurch wird der technische Aufwand reduziert und die Notwendigkeit eines dedizierten Lokalisierungsingenieurs entfällt.

3. Unterstützt MotaWord spezielle DITA-DTDs?

Ja. Da DITA die Spezialisierung (die Erstellung benutzerdefinierter Elementtypen) ermöglicht, ist unser nativer Parser so konzipiert, dass er das zugrunde liegende XML-Schema berücksichtigt. Ihre benutzerdefinierten Tags und Attribute sind geschützt und werden bei der Wortzählung nicht berücksichtigt, es sei denn, sie enthalten übersetzbare Inhalte.

4. DITA vs. XLIFF für die Übersetzung: Welches ist besser?

Während XLIFF ein hervorragendes Austauschformat für allgemeine Softwarezeichenfolgen ist, ist DITA für strukturierte Dokumentation überlegen, da es mehr Kontext zur Wiederverwendung von Inhalten enthält. Die native Übersetzung von DITA ist fast immer besser, da sie die Roundtrip-Fehler vermeidet, die bei der Konvertierung zwischen zwei verschiedenen Dateiformaten häufig auftreten.

5. Kann ich die native DITA-Übersetzung mit meinem bestehenden CCMS verwenden?

Absolut. Die meisten Component Content Management Systeme, wie IXIASOFT, Heretto oder Oxygen Content Fusion, ermöglichen den Export von rohen DITA-Paketen. Sie können diese Pakete direkt in MotaWord hochladen und die übersetzten Ergebnisse anschließend ohne Zwischenschritte der Konvertierung wieder in Ihr CCMS hochladen.

6. Wie lassen sich die DITA-Übersetzungskosten mithilfe von Translation Memory reduzieren?

Durch das Hochladen Ihres gesamten Ditamap auf eine native Plattform nutzt das System Translation Memory (TM), um exakte Übereinstimmungen aus Ihren vorherigen Projekten zu identifizieren. Sie zahlen nur für neue oder geänderte Texte, was die Kosten bei langfristigen technischen Dokumentationsprojekten erheblich reduziert.

7. Wie handhabt man die DITA-Bildlokalisierung und hrefs?

Wenn Sie Ihr DITA-Projekt nativ hochladen, erkennt das System die Bild- und Link-Tags. Sie können festlegen, ob die Pfade zu diesen Bildern in lokalisierte Ordner aktualisiert werden sollen (z. B. der Pfad von /images/en/ in /images/es/ geändert werden soll) oder ob sie genau so bleiben sollen, wie sie sind. Dadurch wird sichergestellt, dass Ihre Links in der übersetzten Version nie funktionieren.

Hören Sie auf zu konvertieren und beginnen Sie mit der Synchronisierung mit MotaWord.

Wenn sich Ihr aktueller Übersetzungsworkflow wie eine manuelle Hürde anfühlt, die Ihren Arbeitsfluss hemmt, ist es wahrscheinlich an der Zeit, von der XLIFF-Konvertierung abzurücken und sich einem nativen DITA-Workflow zuzuwenden. Durch den Wegfall dieser manuellen Schritte verringern Sie das Risiko von Dokumentationsfehlern und beschleunigen Ihre globalen Releasezyklen erheblich.

Ihre Expertise sollte in die Erstellung großartiger Inhalte fließen, nicht in die Verwaltung von Dateiexporten. Möchten Sie sehen, wie viel Zeit und Aufwand Sie bei Ihrem nächsten Projekt sparen können? Bei MotaWord erhalten Sie sofort ein Angebot, indem Sie noch heute Ihre .dita-Dateien hochladen.

OYTUN TEZ - Chief Technology Officer (CTO) bei MotaWord

Übersetzungswissenschaftler mit einer Dissertation über maschinelle Übersetzung – insgesamt Technologieexperte und besessen von intelligenten, nahtlosen Übersetzungsprozessen.