Sep 2, 2011

Bringing XLIFF content into SDL Trados Studio

When SDL released its new flagship product, SDL Trados Studio 2009 a few years ago, one encouraging feature was its use of a real standard... after a fashion. XLIFF has become widespread in recent years as a standard for exchanging translation project data, and SDL decided to "extend" this standard by adding their own unique tweaks to it. Nonetheless, a number of other tools are able to read and translate SDLXLIFF files, even if segment status marking is not performed for the deviant format. I have translated a number of these SDLXLIFF files generated by SDL Trados Studio 2009, and there have never been any problems.

When I was asked how data might be moved from an old memoQ project into the new Trados version, I naturally thought of using XLIFF as a simple option and an alternative to filtering and exporting TMX from the translation memory. Once it worked in fact, but too often error messages like the following were seen:


I was utterly baffled by this one, as were the project managers at the agency using the SDL tool. I could not understand why importing an XLIFF worked on some systems some of the time but not on others. Then once again, my favorite internal information source at SDL explained that there is a bug in the XLIFF import filter that yields this error if the default source and target languages are not in the same group as the languages set in the XLIFF file. In this case, the default settings were:


The source language in the XLIFF file I attempted to open was German.

There are two ways to deal with this problem if you need to import an XLIFF file from another source into Trados Studio:
  1. Set the source and target languages in Studio to something in the same language group as the source and target language of the XLIFF file. In the case of my XLIFF file, generic German and English were set, so when I changed the defaults in Studio to DE-DE and EN-US, the file opened, but I was warned that the language abbreviation in the XLIFF file was not "fully qualified" (a common German obsession). But still, it worked, and the content could be edited or fed to a TM.
  2. Another way to deal with this if you are aware that Studio will be involved is to use sublanguages in the environment that generates your XLIFF file. In my case, that would mean setting the memoQ project to DE-DE and EN-US rather than just DE and EN for the source and target languages. Then SDL Trados Studio will identify the languages in the XLIFF file correctly and open the file without warnings or errors.

5 comments:

  1. Nice tip. Any idea what exactly is so different about the SDLXLIFF format in comparison to the standard? I recently had troubles re-exporting files to Trados in this format (ended up finding a workaround by using a translation memory export).

    ReplyDelete
  2. The problem described here isn't the SDLXLIFF format, it's the bad programming of SDL Trados Studio that causes the languages not to be recognized if sublanguages are not specified and the languages differ from your defaults. However, I do not know if this problem has been addressed by SDL recently. It was a fairly low development priority, but I fully expect matters to be resolved before the polar ice caps melt.

    ReplyDelete
  3. You should also try working with https://poeditor.com for xliff files. It has a very nice user interface and helpful features. I recommend it.

    ReplyDelete
  4. Thanks for the tip, Alexander. However, I generally think it's good to avoid switching translation tools to accommodate particular file types where there is an alternative to work in one's usual environment. I've found that unfortunately many translators have a very poor understanding of ergonomics and efficiency, and most do not realize how much switching between various CAT tools can slow down one's output, particularly for small jobs. There are, of course, sometimes inherent differences in efficiency to be found between working environments - the current column grid paradigm used by Trados Studio, memoQ, WordFast Pro and others is probably some 20 to 30% more efficient than the over/under arrangement for translation in the confused bilingual view of WordFast Classic or Trados Workbench and probably OmegaT as well. But these differences are quickly obscured by the time and effort it takes to re-orient oneself when switching from one tool to another.

    I've explained this for over a decade now since I first collected data for switching between Déjà Vu and Trados Workbench, and I think subsequent SDL studies back up my conclusions. When SDL Trados Studio was first introduced, I remember some colleagues protesting loudly how much worse the new paradigm was, but after a short time of orientation, these same complainers praised the greater efficiency of the new working environment.

    When I hear some colleagues announce proudly how they "tool hop" between three or four or more CAT tools, changing almost with every little job, I shake my head and think how nice it must be to have so much free time to waste and so little need to seek better returns for an hour of work. I'm a lazy fellow, so I just want to maximize my hourly earnings and play with my dogs or read a book or go for a hike a lot more to kill any free time....

    ReplyDelete
  5. All depends. Trados Studio (and other xliff-based sofware) will never offer a so functional, quick, precise working environment as a Word environment offers: totally flexible search-replace tool, wide zoom range, avoiding awkward time comsuming tagging, and most of all, the possibility of creating macros (for quicli eding, self-pplying glossaries, and quick back-conversion to any tr software the client happen to prefer.

    ReplyDelete

Notice to spammers: your locations are being traced and fed to the recreational target list for my new line of chemical weapon drones :-)