Compatibility between SDL desktop translation tools (Part 1)

The new Studio product and the old Trados products are compatible aren’t they?  Would it be true to say that Studio can handle the old Trados formats, but Trados can’t handle the new Studio formats out of the box?  I think it’s true… but it still requires a little knowledge about how best to handle the compatibility issues that might arise.
But before we look at this it’s worth considering the general compatibility question itself.
So for example, the Studio bilingual file is called an SDLXLIFF.  This is a compliant XLIFF file, and it uses many allowable custom extensions in order to be able to share productivity enhancing features between Studio users.  But the old Trados tools are not sophisticated enough to make use of these, so in order to pass an SDLXLIFF to Trados you would need to create a custom ini file.  This may work, it won’t be pretty, it won’t be able to handle any of the custom extensions because Trados has no idea what to do with them… and I wouldn’t recommend it… but it is possible.  It is far better to use a tool like the SDLXLIFF to Legacy Converter which can convert the SDLXLIFF to TTX or Bilingual Doc formats.
The Studio Translation Memory is called an SDLTM.  The old Trados has no idea what this is so you have to convert it to a TMX first in Studio or by using one of a number of different OpenExchange applications that do a quick and simple job of this.  But here you may also get data loss for many reasons… Studio doesn’t store placeables like numbers and dates in the TM for example (at least those formats Studio recognises as a number and a date).  It stores one and then the rest are generated by Studio because it knows what to do with them.  So if you have a document that is very heavy on number only segments for example, then when you send the TMX over and pretranslate the same document in Trados you will not get all the numbers translated for you because they aren’t there.  You can work around this of course by converting the SDLXLIFF to TMX directly using a tool like the SDLXLIFF to Legacy Converter, or the SDLXliff2Tmx applications of the OpenExchange.
Considering terminology… the new Studio Platform uses SDLTB for it’s termbase format.  Recreating this as an MDB so that it works with the older versions of MultiTerm is possible, but here you can use the latest version of MultiTerm with the older Trados product so there is less of a requirement to do this.
So whilst you can work around these things it’s probably stretching things a little to say the two tools are fully compatible in this direction.  Fortunately the old Trados products are unlikely to be around for a long time and many users have already moved on.  So what about the other way… how compatible is Studio with the old Trados products?  A good place to start so I can answer this question is to look at what can come out of the old Trados products (so I mean SDL Trados 2007 Suite as this comprises the most variables I think, and is hopefully the most commonly used variant of Trados).

Looking at Bilingual files.  The old Trados products, and I include SDLX in this because it’s an important component of the things Studio has to contend with, can kick out four different kinds of bilingual files:

  1. Bilingual Doc
  2. Bilingual RTF
  3. TradosTag XML(TTX)
  4. Intermediate Translation Document (ITD)

There are also different flavours of these depending on the version of Trados you are using.

When I look at Translation Memories the situation is similar in that we have four flavours here too:

  1. Translation Memory Workbench (TMW)
  2. Translation Memory eXchange (TMX)
  3. Trados Workbench Export files (TXT)… why wasn’t this called TWE?
  4. MicroSoft DataBase (MDB)

These are further complicated by the requirement to handle server based memories as well, and we’ll consider these later on.

Both SDLX and Trados have their own Alignment technology that was capable of producing Translation Memories in a few formats, so we need to cater for this too… although this is really very much represented by the effort to handle Translation Memories.

Last but not least is Terminology where we have different versions of MultiTerm to contend with and also SDL TermBase which is part of the SDLX Suite of products and still available as part of the SDL Trados 2007 Suite.
This post would be incredibly long if I tried to cover all of this, so this introduction to set the scene is Part 1.  I’m thinking along the lines of having three more parts to this;

  1. Bilingual Files
  2. Translation Memories and Alignment
  3. Terminology

It would be easy to expect SDL Trados Studio to be able to handle all of these things exactly as the old Trados products did… but this is not a reasonable expectation.  So in these parts I hope to cover some of the compatibility issues to be aware of and provide some guidance on best practice when working with these old formats.

0 thoughts on “Compatibility between SDL desktop translation tools (Part 1)

  1. Hi Paul,
    There seems to be no answer to my question at proz.com, so I took the liberty of posting it here:
    It is about Splitting segments in SDLXLIFF files created from docx with Workbench segments.
    My question is this: is it safe to split such segments? Will it cause problems when “Saving targets as’?
    Piotr
    Link to my original post: http://www.proz.com/forum/sdl_trados_support/244406-splitting_segments_in_sdlxliff_files_created_from_docx_with_workbench_segments.html

    1. Hi Piotr, I can only say I’m not aware of any problems here. So if you found some I’d be interested to investigate them as I do see people raising this from time to time and stating “categorically” that this was the reason for the problem. It may well be the reason, but I haven’t been able to verify this yet so I wouldn’t say so.

      1. I haven’t yet tried splitting any such segments, I was just curious if it is safe, but with a tight deadline I rather prefer to be on the safe side. I’ll experiment when I have more time.

Leave a Reply to paulfilkinCancel reply