Translation of the c-rex.net blog with MT
The scenario
Our c-rex.net blog posts are created in oXygen XML Editor in a DITA/XML environment.
The DITA source files are translated. And directly, without the use of a translation memory system.
The reason for choosing this constellation?
We are convinced that in the future Machine TranslationHuman Translation will play a central role. Therefore, we have built a corresponding translation scenario and present it to you here.
This scenario is certainly not suitable for every type of text. There are still use cases where Translation-Memory driven translation by human translation is the appropriate choice.
We are sure There are significantly more cases than many believe where a process automated in such a way or similar to the one we have implemented is the right one!
Let's take a look at the process in detail!
Three clicks and the translation is ready
We have built a tool landscape in which technical writers perform the entire process from authoring to translation to publication in one environment.
Everything from a single source with a very high level of automation!
After a blog post is ready in German, we launch pre-configured transformation scenarios that execute the entire translation process within seconds.
We then move the translated files to the folder of the target language.
This is followed by the HTML publication - also based on a transformation scenario that we have set up.
What is behind this 'magic', which automatic processes are hidden behind it, you can read in the next sections.
Our editorial environment
How does our MT translation process work? What tools are in use?
the XML editor Oxygen XML Editor
c-rex.net DITA-OT to extend the DITA-OT Frameworks
our cloud service Data Transformation Service DTS
the Machine Translation Engine DeepL
We work with the following tools:
Data collection and organization via DITA-OT-Plug-ins
We use self-developed plug-ins that extend the DITA-OT-Framework to collect, organize and compile data in such a way that it can be subsequently processed with c-rex.net DTS.
These plug-ins seamlessly integrate the functionality and access to the cloud service DTS into the standard DITA processes.
They are available to our customers as standard extensions for DTS for adoption in existing DITA-OT after completion of a test phase.
Collecting the files to be translated. In our case, the references are ignored (xref, conref, graphics). This behavior can be adjusted by configuring the interface if necessary.
Zipping the files
Sending the zip packages to the c-rex.net Data Transformation Service DTS
DTS translates the files in our case via DeepL and returns the translated zip package.
Of course, alternative Machine Translation Engines such as Google, Bing or others can also be included.
The zip package contains
A report
XLIFF files in the source language
bilingual XLIFF files with the source language and the DeepL translations
translated DITA-XML(in our case without graphics and linked topics)
Unpacking the translation result
Copy dependent resources to the output directory so that the DITA-Map is complete again
The process of data collection and data organization goes like this:
Translation process on the DTS server
Generation of an XLIFF for each file to be translated
Marking out the translation according to the ITS Rules
Custom Rules can be specified in the DITA-OT-Plug-in.
Segmentation of translation units based on SRX Rules
Custom Rules can be specified in the DITA-OT-Plug-in.
Resolution of variables in plain text
For DeepL we resolve variables (keyrefs) and put them into the translation together with the text to be translated. This has proven useful for DeepL to increase the quality of the translation, especially as far as grammar is concerned.
If you do not specify it and have defined a gender term in the plural, DeepL returns the translation for singular, for example.
Other Machine Translation Engines behave differently here; therefore, the behavior at these and other points is configurable.
Automatic marking of specific content
For the important topic of corporate terminology, we have created a terminology database in our editing environment, where we store terms, quotes and other texts together with the translation we require.
This could also be done with variables. However, we decided to use a terminology database in tbx format.
The correct translation of these terms is essential. We even think that it is more important than that the text around it is translated correctly.
And we look for these terms in this process step and automatically mark them up so that they can be handled appropriately in the translation process.
This way, no one has to worry about it during creation.
Preparation of data for DeepL
Support for structured data is rudimentary in DeepL, although DeepL has a configuration switch for XML. However, no XML per se is processed, but minimally other check routines are used in the plain text.
Therefore, we resolve deeply nested XML structures in DITA and in the resulting XLIFFs to the extent that a string is generated as close as possible to the optimal plain text and given to DeepL for translation.
This reduces possible sources of error when handling tags to a minimum.
To DeepL we also pass content that is not to be translated, such as variables, so that DeepL has the full context for the translation and thus provides a good translation.
Machine translated content is written to the 'target' element in the XLIFF.
Export XLIFF back to DITA
In the way back, content that is not to be translated is replaced again by the text in the source document. This also applies to variables and the auto-tagged content.
In doing so, we remove the texts in the 'keyrefs' and replace the term translated by DeepL with the text from the tbx termbase again for the autotagged content.
This occasionally leads to the problem that a word or quotation marks are removed because DeepL writes them into the tags and we overwrite them during the replacement process.
Finally, the DITA document is rebuilt from the contents of the target element using the Skeleton.
The c-rex.net Data Transformation Service performs the following operations:
Representation of the translation in the c-rex.net blog
Our blog has an integrated option to select translation variants.
automatic translation by DeepL,
the variant created by automated post-processing by c-rex.net
and a comparative presentation of both variants.
You can choose between
Summary and outlook
Let's summarize. What did the look behind the scenes show us?
The use of DITA-OT and the resulting integration of DTS Cloud Services into the standard DITA process leads to a high degree of automation and very fast translation results.
Working with a terminology database to provide corporate terminology, important terms, quotes with a fixed translation is essential.
The translation quality is good. There are some unattractiveness and also errors, but we can live well with them. We hope our readers do too!
How is Machine Translation suitable for our blog?
The scenario described here is also very suitable for the area of technical documentation.
This is because there is content that must meet a 100% quality standard, as well as content that does not.
Metadata, especially when using CCMS or DITA, can be used to control the process and separate the translation of critical content (safety instructions, legal texts) from the translation of the rest of the text.
Critical content in such a scenario would never go through the MT process and always through the Translation-Memory with human translation.
In other cases, you can combine this, first via MT because of the turnaround time (users waiting for info) and then via the human translation process for the high quality requirement.
And what about Machine Translation in the field of technical documentation?