Just a few months ago, I shared a few basiс tips about translating the SDLXLIFF files with OmegaT. A couple of weeks passed, and I had to blog about a converter that made a TTX file out of an SDLXLIFF file, adding another option to the mix. And now with the XLIFF filter added to the Okapi OmegaT plugin, we have yet another option. Aren’t things changing too fast?
Just kidding :). More options is always better even if the speed of change is slightly overwhelming. Let’s review this new option to see how it fits into the mix.
The Okapi filter (called XLIFF files (Okapi)) actually eliminates a few critical issues about the native filter:
Support for 100% matches
First and foremost, the Okapi filter supports the existing translations (100% matches) in the SDLXLIFF files. This is a huge step forward since the native filter lacks this capability. With the native filter, OmegaT displays for translation only what’s in the right column of an SDLXLIFF file—whether it’s the source text or the translation. If you have a translated segment in an SDLXLIFF file, the translation will appear in OmegaT as if it were the source text. To avoid this, you need to prepare an SDLXLIFF file for translation by copying all the source segments into the target ones, including the 100% matches (also known as segmenting). After you open this file in OmegaT, you have to insert the 100% matches from scratch, which may be a challenge because the tags between OmegaT and Trados don’t match.
Unlike the native filter, the Okapi filter reads the source text and any existing translations, correctly displaying both in OmegaT.
Segmenting is unnecessary
The Okapi filter eliminates the segmenting step. Even if you don’t have any 100% matches to worry about, the native filter still requires that you copy the source segments into the target ones. You need Trados for this. But if you do own Trados, why would you want to translate the SDLXLIFF files with OmegaT in the first place? Quite a paradox.
Another option is asking your client to segment the files, which isn’t practical unless your client is, for some strange reason, happy about doing your job for you.
With the Okapi filter reading the source segments from where they belong—the left column of an SDLXLIFF file—there’s no need to segment the source files.
Forget about the header problem
The new filter doesn’t require that you remove the header tag from the SDLXLIFF files. An SDLXLIFF file often contains a big block of binary information within the header tag. Although this block is irrelevant to translation, OmegaT processes it, which may cause problems, including slow loading of a project. To avoid this, you need to remove the header tag before feeding the files to OmegaT. After translation, you either copy the header tag back into the translated file manually or put the source file with the header tag intact into the source subfolder and, hopefully, create a translated file from that intact file.
Since the Okapi filter doesn’t process this tag, you can, at least theoretically, translate the SDLXLIFF files with big blocks of binary information without any preparation.
The new filter looks very good so far. Is there any catch? Perhaps. In the next article, I’ll look at the potential shortcomings of the new filter and some of the possible uses.
You might be also interested in the post about translating the TTX files in OmegaT. Thank you for reading this material. Your comments or additions are welcome!