Working with TMX from Studio

One of the more common questions I see on the forums today is “I’ve finished my translation and now my client is asking for a TMX.  How do I get this from Studio?”.
In its simplest form the process could not be easier.  You simply open your Studio Translation Memory in the Translation Memories view so that it appears in the list, right-click it and select export… like this:

This creates a TMX file and you’re all done.  However, and there’s always a however, what happens under the following scenarios:

  1. The TM is your main TM and it contains the translation for this project you have just completed, and 357,652 more translation units for all the work you have ever done.
  2. You translated your file using field values that were appended to each translation unit for the client you were working for and they want the TMX complete with these values to use in SDL Trados 2007.

In these cases you probably want to be a little more precise than simply exporting your entire TM to TMX.  So let’s tackle the first issue first.

Using a Project TM

If you happened to create a Project TM when you started the Project then you would simply locate this TM and do the same thing as I described at the start – open in the TM view, right-click and export.  You’ll know if you used a Project TM because this only happens if you create a project and specifically ask for this to happen.  So at this stage of the project creation you select the “Prepare” option:

“Prepare” as opposed to “Prepare without project TM” will create a Project Translation memory and it is not the default selection.  When you select it you will see this in the list of tasks to be completed which creates the Project TM in the Project Settings like this:

During Translation it is the Project TM that will be updated and not the Main TM that you based the Project on.  So if you are using this method of working then you can easily find the Project TM by going to the Projects view, right-clicking and selecting “Open Project Folder”:

When this opens you will see something like this:

The Tm folder will contain the Project TM, probably within the specific target language folder, so in this case it was in a folder called en-US.  If you had a multilingual project with lots of target languages then there would be one folder for each target language inside the Tm folder.
So now you just open this Project TM in the Translation Memories view as before, right-click and select export.

Creating a filter on your TM

If you didn’t use a Project TM and your translation is now mixed in with all the work you have been doing for years, in one large Translation Memory, then you may still be able to rescue it with a filter.  To do this simply double click the TM in the Translation Memory view so it opens up for maintenance and then do the following:

  1. Click on “Add filter”
  2. Give it a name (not essential… but if you want to save it for use later it may be handy)
  3. Click on “Add” and add a condition

In this case I selected greater than yesterday as this should ensure the work translated yesterday and today will be included.  Then click on “Perform Search” to make sure it looks as though the filter is selecting the things you need.  Then if you want to save the filter click here to save it:

If the results shown in the TM View look ok then right-click on your TM as before, select export but this time add the same filter settings you just tested:

This time you get a TMX with only the Translation Units that were added since the 4th September 2012 at 10:06:20 (in my example).  Note that if you’re confident about the results you could simply go straight to this step and don’t bother opening up the TM as I showed here.

Importing the SDLXLIFF

Another way to handle this is to create a new TM in Studio and import the Studio bilingual file you just translated (SDLXLIFF) into it.  This is similarly easy… you create the new TM in the TM View here:

Then simply right click on it in the TM View and select “Import”:

Select the SDLXLIFF, making sure you take the one in the target language folder if you created a Project, and import.  Then you export this new Translation Memory to TMX as the example above.

Using the SDL OpenExchange (now RWS AppStore)

There are a couple of neat applications on the SDL OpenExchange (now RWS AppStore) that will allow you to convert your translated files, so the SDLXLIFF files, directly to a TMX.  So if you don’t want to mess around with Studio Translation Memories first then this might be the ideal mechanism for you.  The applications are the SDLXLIFF to Legacy Converter and SDLXliff2Tmx.  Both work in a similar way where you just drag and drop your SDLXLIFF files, or select them, and click a button that will convert these bilingual files into TMX files that can be used to update a Translation Memory.
The SDLXLIFF to Legacy Converter interface looks like this:

And the SDLXliff2Tmx interface looks like this:

Both applications offer some neat filtering options for only creating the TMX with the contents you need and are fast and simple to use.  I’d recommend you take a look anyway… neat tools to have in your Studio armoury.

Maintaining Trados 2007 TMX Format

If your client wants the TMX for use in Trados 2007, and you have been using fields that are added to your translation as you work so that the TM is updated like this for example then a different approach to creating the TMX is advisable:

The problem here is well documented by Tanja in her blog “Tanja’s thoughts on the translation industry” so I won’t go into lots detail here.  Suffice it to say that the TMX created by Studio is perfect for exchanging TMX files with other Studio users as the size is far less than that of an SDLTM, but if you wish to retain things like these fields so they are usable in Trados 2007 as well then you either have to follow the workaround suggested by Tanja, or use another OpenExchange application called the SDL Translation Management Utility.
This tool allows you to export a Studio SDLTM as a TMX suitable for Trados 2007 users.  The interface looks like this:

You just select your Studio Translation Memories, or drag and drop them, and then switch to this tab where you specify the folder to place the TMX files and then process the export:

An export from Studio looks like this where you can see the property elements containing the fields I created and used during the translation::

However, when I import this TMX into Trados 2007 Translators Workbench I see this where the two fields are not visible:

If I look at the TMX created from the OpenExchange application it looks like this, so similar but with different property attributes for the fields:

Importing this one into Trados 2007 looks like this where the field values I used in Studio are clearly seen:

So in summary I think there are many ways to get your TMX, but it’s important to know why you are creating it and make sure you either set yourself from the start so the process is simple no matter what you have to do, or use one of several methods as shown here… all of which are not too hard it’s just a case of knowing how.

0 thoughts on “Working with TMX from Studio

  1. A strange thing happened: I exported an sdltm into tmx using Studio, then imported it into Workbench in order to run through the translated ttx files for some boundary box checking. Almost no 100% hits, but the concordance function found them all! Obviously not a good thing.
    Then I tried the SDL Translation Management Utility and did the same thing. Guess what: translate to fuzzy worked like a charm!
    Can you explain that?

    1. Hi Mats,
      Very strange indeed. I discussed this with various developers and product management today because I was very interested myself to see why this might happen. The answer is we don’t know and would have to see your files and see if we could reproduce and then perhaps explain.
      The Translation Management utility only changes the field markup as I explained in the article, but there is no change to the segment contents at all. So any expected leverage would be down to filter differences between Studio and Workbench, or lack of Context Match in Workbench for example.
      So if you can share your files I’d really be very interested in finding the explanation for this one too..!

  2. Hi,
    Thanks for the info about skipping a project TM.
    > You’ll know if you used a Project TM because this only happens if you create a project and specifically ask for this to —happen.
    No you don’t, because you just stick with the default “Prepare”. Couldn’t they specify “Prepare with project TM” as well ?
    I never had the slightest use of a project TM. IMHO a project TM is a completely inadequate and redundant concept. You can always build a TM from bilingual files can’t you ?

    1. Hi Alexandre, I get the feeling you’re using an older version of Studio? The default, and I think this may have even changed in a later version of 2009 (can’t recall) is “Prepare without project TM”. So you have to consciously change this and select “Prepare” if you want Project Translation Memories. When you prepare a project at this stage all the individual tasks that are run are presented in front of you anyway so you do have plenty of opportunity to change your selection before allowing the project to be created.
      I don’t agree with you about this being a redundant feature… but perhaps you are only thinking about this from the perspective of creating a TM for your client, and here of course you could build one afterwards if you wanted to. Project TMs have uses for things you do before finishing the translation like:
      – creating a smaller TM when you prepare your project to share with others. So if you set this up correctly it will include all the information found by the fuzzy you specify and then you don’t have to send a TM with over a million TUs for example to another translator… you just send what’s useful
      – using it as a “scratch pad” so you don’t risk polluting your main TM before everything in the translation is reviewed and still being able to share this smaller TM with others
      I believe the default was changed because it caused all users to work with project TMs and this caused confusion for many users. So the way it works now means you have to make a conscious decision to use a project TM.

  3. Hi again,
    To experiment, I just changed the translation of a segment which appears in many previous projects sharing the same TM, each with a different field value for the same field. Can someone explain me why the modified segment is now shown in the lookup window or concordance with several previous field values in addition to the current one ?
    Terrible piece of code indeed.

    1. Hi Alexandre, perhaps you set this field up with the ability to use multiple field values? This is an option when you create your fields in the first place.

      1. Hi Paul,
        Thanks for your reply.
        There is a collection of different manuals which have many common segments. The field is just a reference to the specific manual(s) where the TU appears with the translation given in that TU. So I DO want multiple values fields, because a segment may have been translated identically in several manuals. When the TU is left unchanged for the new manual (having a field value of say manual_10), I want to keep the old field values (say manual_4 manual_5 manual_9) and just add manual_10 to the list. This works in Trados Studio 2009. Now if I change the translation specifically for manual_10, what is needed is a new TU with the new translation and only manual_10 as the field value. The old TU should remain unchanged with the old manual references. This worked perfectly in Trados 6.5 Freelance. Trados Studio on the other hand seems to consider that if I change a translation while translating manual_10, I also want to change the translations in manual_4 manual_5 manual_9, which is nonsense.
        Hope this was clear,

        1. Hi Alexandre, I’ll have a go at explaining this one. Let’s say the first three manuals all have the same common segments… in fact let’s say they look like this:
          This is my sentence
          Change this one.
          This my last sentence

          So each one of them now has three field values, one for each manual. Also note that in each case you will be getting a Context Match rather than a 100% match.
          Now you get the fourth manual, where the first and third segments are the same but you wish to change the second one. The second segment, even though you now want a different translation, has the same context around it so as far as Studio is concerned it’s exactly the same segment. So if you change it then you will change it for all the manuals and will now have that changed segment with four field values.
          If the fourth manual had three segments that looked like this:
          This is first my sentence
          Change this one.
          This my last sentence

          So the second segment is the same, but the context is different so you’ll get a 100% match rather than a Context Match. Now when when you save it this time a new TU will be created that contains only the field value for that one.
          The conclusion being that if you get a Context Match from your translation memory and you want a different translation then you need to be careful, especially if you are using field values the way you are, and you should add the translation as a new TU instead of simply confirming it.
          Does that make sense?

  4. Hi Paul,
    Thanks for your crystal clear explanation, which indeed makes sense. What does not however is the fact that Trados Studio should work that way. If it was really deemed necessary to implement this context match feature, the least of things would have been to do it without impairing other features which are by far more important. IMHO it is just another ill-implemented and essentially useless marketing gadget.
    P.S. It would be nice if you could tweak wordpress in order to avoid the nagging and undiscardable “Follow” pop-up.

  5. Hi again,
    After due verification in Trados Studio 2009 SP3, the aberrant behavior I pointed out concerning multiple values fields is not limited to CM. With 100% matches as well, the translation is updated and the old field values kept together with the new one. No new TU is created. So the program behaves logically only when you don’t modify the translation.
    Explicitly requesting a new TU in all those situations is clearly much too much overhead and not a thing I would consider doing on a regular basis.
    Again, this worked fine in Trados Freelance 6.5. Now it turns out not to be CM related, so why on Earth did they have to ruin it?

    1. Why not share some of these files with me? I don’t believe Studio 2011 works this way so perhaps the effect you have is the result of using an old version of the software? If you want to investigate this further you can mail me at so you don’t have to keep reading the nagging screen…

Leave a Reply