Yes, I want my consultation

While We Are Waiting for the Best SDLXLIFF Filter for OmegaT

SDL_Trados_Studio_OmegaTRight now, there is no easy way to process SDLXLIFF files in OmegaT. All current methods have their drawbacks. I already wrote extensively about translating SDLXLIFF files in the past, but after a few related discussions on the OmegaT forum, I decided to compile a short table listing all current SDLXLIFF translation methods. Until we have one best method, translators processing SDLXLIFF with OmegaT can use this table as guidance when choosing among the four methods. I will also explain why I believe the Okapi filter is the most promising.

IMPORTANT! With all methods except the native filter, a roundtrip (saving target SDLXLIFF files and opening them with SDL Trados Studio before starting the actual translation) is absolutely essential.

Native XLIFF filter in OmegaT

Pros Cons
The most reliable filter currently Requires segmentation of files with Studio
Enables processing SDLXLIFF files directly, without conversion into an intermediate format and accompanying problems Has problems with the header tag
Allows adjusting (optimizing) the source text displaying in OmegaT easily. Since OmegaT reads the target part of SDLXLIFFs, you can safely make optimization changes to that part directly in SDLXLIFFs without affecting the source part. Result: optimized text for translation in OmegaT, no visible changes in the source part of SDLXLIFFs. Does not support 100% matches in files. 100% matches need to be re-inserted in OmegaT from a TMX. If SDLXLIFF files have two or more different translations of one non-unique segment (due to context), the alternative translations are lost, since only one version makes it from a TMX into OmegaT

This is my favorite method to translate SDLXLIFF files at the moment, because it is less time-consuming in terms of file preparation and the most reliable compared to other methods.

Conversion with Rainbow

Pros Cons
Segmentation of files with Studio is not required Major disadvantage: Translated files often do not open in Studio
Rainbow produces a bilingual XLIFF file that can be translated with other CAT tools Does not support 100% matches in files
Resulting XLIFF files are pre-segmented, which might be more convenient than OmegaT’s segmentation on-the-fly Creates intermediate format, which often results in conversion problems and additional work

Conversion into TTX with SDLXLIFF to Legacy Converter

Pros Cons
In theory, segmentation of files with Studio is not required (but it is recommended) File preparation is time-consuming
Supports 100% matches in files (right now this filter is irreplaceable, when it comes to editing SDLXLIFF files translated by someone else) Creates intermediate format, which often results in conversion problems and additional work
Resulting TTX files are pre-segmented, which might be more convenient than OmegaT’s segmentation on-the-fly Often causes problems with tags, especially when tags were intentionally deleted in 100% matches

Okapi XLIFF filter

Pros Cons
Segmentation of files with Studio is not required Major disadvantage: Sequential tag numbering makes the filter very impractical, because each translated segment with tags is essentially unique and difficult to reuse both in the same project and future work
Okapi XLIFF filter supports 100% matches in files Major disadvantage: Translated files often do not open in Studio, with the “object reference” error
Enables processing SDLXLIFF files directly, without conversion into an intermediate format and accompanying problems

Why is the Okapi filter most promising?

Since segmentation is not required, there is no preparation for translation involved. You simply put the SDLXLIFF files that you received into the source subfolder of OmegaT project as they are.

Full support of 100% matches makes it possible to process files pre-populated with translations easily, whereas with other methods, it is either impossible or very challenging. Unlike the Okapi filter, the native filter also destroys the original 100% match statuses in the SDLXLIFF, as a result of copying the source text into target, which is sometimes inconvenient for clients who will work on these files in Studio after your delivery.


Yves Savourel, the mind behind Okapi and the Okapi filters plugin for OmegaT in particular, was kind enough to add the XLIFF filter to the mix of filters in the plugin last spring. Now, all of us translating SDLXLIFF files are looking forward to further improvements of the filter. Yves is aware of the disadvantages and will see what he can do, when he has time.

If you have questions about this post, feel free to ask in the comments below or by contacting me through LinkedIn.


  • dasmi says:


    for some tricky sdlxliff files I had to invent another, more verbose, procedure.

    1) With Studio, create a temporary TM
    2) Copy source text on target
    3) Confirm all the target in the temp TM
    4) Export tm in tmx format
    5) With Okapi Rainbow, convert tmx to xliff
    6) With OmegaT translate xlicc
    7) With Okapi Rainbow, back convert xliff to tmx
    8) With Studio, import the tmx file in a new TM
    9) With Studio, translate the original SDLXLIFF file

    As I said, it is a bit verbose, but it allows to give to your customer files translated with Studio (some agencies are strict on this point). And then it allows you to handle some tricky files (eg. word files containing soft break, converted in sdlxliff by the customer). Major disadvantage: you need Studio anyway..

    • Hello,
      Thank you for your comment. Yes, I read your message on the OmegaT forum describing this process. I am sure that it works well. What I do not understand, though, is why you want to go through the hassle of multiple conversions and working on the TMX instead of translating the SDLXLIFF file that you have after Step 2 directly in OmegaT. Is it because you have not tried this route yet or for another reason? And actually with this route, you CAN avoid using Studio, but I am not ready to tell you how to do it yet, as I need to do more testing.
      Best regards,

  • dasmi says:

    It’s just because on some tricky files everything else failed. The sdlxliff file translated with omegaT (or with other tools) would not open in Studio after translation. I suspect the problem was the soft return of some .doc files, but I am not sure because it is a project of several months ago and I don’t remember exacly. Maybe the newest releases of OmegaT and Okapi filters have solved this particular issue. I will try.

  • David Koot says:

    Hi Roman,
    I was testing with the combination of SDLXLIFF translation in OmegaT, when I found your blog here. Very clear and informative. Thank you!
    I’d like to use the Okapi filter as plugin for OmegaT just make SDLXLIFF files translatable for translators without Trados Studio. But I noticed the following.
    I had in my test-file two translation units that didn’t need translation, because they only consisted of xliff-element . This is the complete trans-unit:

    As soon as OmegaT creates a translated document of the file containing this kind of trans-units, they are removed from the translation (including the style information in the header, attached to this with id=”0″). Trados Studio opens the translated sdlxliff without problem, but it cannot convert it back to the original format (in my case a Word .docx file), because this removal (object reference error)
    Do you recognize this, and this is this one of the cons you write about in this blog?

    Kind regards, David

  • David Koot says:

    Thank you for your comments, Roman. You’ve put me on the right track, I think. I didn’t use the native filter for OmegaT: I was using an old version (2.5.x), and the filter that came with that version didn’t work well. But I tried with the latest Beta version (3.0), and the native filter now seems to do a very good job. Thanks for the tip. I will try to work with this workflow now!

    BTW: I’ll try again to post the trans-unit from my previous post. Let’s see if it works… :

  • David Koot says:

    Ouch. Maybe this:
    <trans-unit translate=”no” id=”fd2cc08d-ff85-407d-a0ad-cbc776fbb13a”><source><x id=”0″/></source></trans-unit>

Add comment

About the Author

Roman Mironov
Roman Mironov
CEO & Founder

As the founder of Velior, Roman has had the privilege of being able to turn his passion for languages into a business. He has over 15 years of experience in the translation industry. Roman has helped dozens of clients increase sales by making their products appealing for speakers of other languages.