GET A FREE CONSULTATION OR SAMPLE TO GET YOUR PROJECT GOING.

Yes, I want my consultaion

SDLXLIFF Support in OmegaT Got Better

Okapi helps translate SDLXLIFF with OmegaT

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.

Conclusion

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!

14 comments

  • Thanks for the info and good news!

    You wrote:
    But if you do own Trados, why would you want to translate the SDLXLIFF files with OmegaT in the first place? Quite a paradox.

    IMHO not a paradox: Trados Studio is awfully slow and conceptually insane. Moreover you can’t use it under Linux.

    Cheers,

    Alexandre

    • Hello Alexandre,
      Thank you for your comment.
      Good points. Especailly because I need more reassurance because at times, I feel that we’d better off translating the SDLXLIFF files directly in Trados. By the way, I noticed that Studio performance increases with CPU and RAM speed.
      With kind regards,
      Roman

  • Hi Roman,

    Bad news. Though I had been able to open some sdlxliff with okapi 0.16 plugin, version 0.21 made OmegaT unable to open or create any project !

    Alexandre

  • Hi Roman,

    Thanks a lot for this synthetic information and the links. I must now be productive so I must deal with my old enemy Trados Studio once more 😉

    I will check this sdlxliff issue as soon as I have more time and keep you informed.

    Cheers,

    Alexandre

  • You wrote:
    By the way, I noticed that Studio performance increases with CPU and RAM speed.

    CPU and RAM will never be a substitute for correct programming techniques.

    Alexandre

  • Hi Roman, hi all,

    The problem I experienced with Okapi 0.21 plugin for OmegaT got fixed thanks to advice from OmegaT@yahoogroups.com, so I have been able to try the last SDLXLIFF Okapi filter. I currently have a whole bunch of SDLXLIFF files to translate. Most of them loaded in OmegaT or Swordfish but took ages to do so. I then found at http://tech.groups.yahoo.com/group/okapitools/messages/3463?threaded=1&m=e&var=1&tidx=1 that I could trim some fat from the SDLXLIFF files. After that, the SDLXLIFF files loaded amazingly fast in OmegaT. BTW I have seen at http://tech.groups.yahoo.com/group/memoQ/message/27990 that memoQ just puts a tag in place of those sections.

    Finally, I had about 10% of the files giving an error in OmegaT, either trimmed or not. Swordfish could not convert those files either, with e.g. “non XML character” errors. So for those I had to use the original DOC file converted into ODT.

    I find this very encouraging. Working with those make-believe money machines just make me sick. It is so much faster and convenient to work in OmegaT!

    Have a nice week-end,

    Alexandre

    • Hello Alexandre,
      Thank you for keeping us informed about your progress.
      I am still not sure which filter you are using, because the problem with the header tag normally happens with the native filter, not the Okapi one. Anyway, I am glad things are working out for the better. As long as you are happy with the challenges of converting the files for translation with OmegaT, you should be fine I guess.
      And yes, “non XML character” errors happen sometimes. I fix them on a case-by-case basis by searching and replacing in the SDLXLIFF opened in a text editor.
      Best regards,
      Roman

  • Hi Roman,

    Thanks for your informative answer.

    I can’t say which XLIFF filter I use because I don’t know if there is a priority mechanism and there seem to be only two outcomes with SDLXLIFF files :

    In Options > File Filters:
    1.
    XLIFF Files: checked
    XLIFF files (Okapi): unchecked
    -> sdlxliff errors on ~10% of files
    2.
    XLIFF Files: unchecked
    XLIFF files (Okapi): checked
    -> sdlxliff silently ignored
    3.
    XLIFF Files: checked
    XLIFF files (Okapi): checked
    -> sdlxliff errors on ~10% of files

    I used OmegaT for the project with 28 SDLXLIFF files (which Trados Studio 2011 was unable to merge). As I said before I use an ODT conversion, which is no problem due to the batch conversion feature of OOO. There were surprisingly few lost matches when I went back to Trados Studio 2011 in order to finalize from OmegaT’s TMX (about 3% to correct manually).

    There is really on comparison between the two programs as to the usability. For instance if you want to make project wide modifications in Trados Studio it is a nightmare : you have to open the TM, make changes page by page through the incredibly fastidious TM interface, probably edit orphan TUs or TUs which are not in your share of the project and that you should not touch (no author appears in TUs…). And of course wait ages to reload the files and then back to correct….

    In OmegaT you just run a search, get directly to the concerned segments by clicking on them et voilà!

    But that’s business as usual: people just pay solid bucks for crap, and if it were not enough lose their time struggling with it 😉

    Cheers,

    Alexandre

  • Артём Вечеров says:

    I have tried to open an existing bilingual SDLXLIFF (already translated) in OmegaT, however, I can’t see the Source segments at all. All I can see is my Target translation segments offered as Source segments, and the same as Target segments.

  • Артём Вечеров says:

    Oh, got it now. The Opaki filter for SDLXLIFF is unchecked by default.

    • Right, already translated SDLXLIFF files should be opened for viewing with Okapi XLIFF filter. However, I do not recommend using this filter for actual editing, because target SDLXLIFF files might fail to open in SDL Trados Studio.

  • Helgi says:

    Thank you so much for your informative write up. I was recently asked to translate a sdlxliff file, and was unable to open it. However, I was ignorant of the okapi filter. But would have had trouble, as it was getting to close to the deadline (Customers usually ask for things at the last minute), and I refuse to buy expensive CAT tools like TRADOS, that then get changed within a year, and forcing you to buy a new version, just because they changed it for the heck of it.

    I prefer LINUX and FOSS.

    Thanks again.

Reply to Helgi Cancel


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.