TM keeps track of every change

Hi there Slight smile

I am working on a translation and facing what I feel is an issue (but it might be very useful to the client, so... ?).

Every time I decide to change a segment I already confirmed, the 2 translations show in the TM (the first and the corrected one). If I change it yet another time, I end up with another translation in the TM... and so on.

How can I change that and have the TM replace the older translation with the newer one?

I'd love to find some answer here :)

Top Replies

  • When you confirm a segment that is already in the TM, the last confirmed translation be in the TM. It will overwrite previous translations. The only exception to this is when you tell Studio to add an additional transation, which can be very useful, but you have to tell it explicitly each time:

    I don't think you can change this default behaviour. There is a function called LookAhead which is meant to speed up work with large TMs, and LookAhead can sometimes lead to puzzling issues. Check whether it is activated in Files -> Options and de-activate it if it is.


  • Hi Daniel and thank you very much for answering me Slight smile

    "Look ahead" was indeed activated. I have just disabbled it, but the TM still keeps tracks of every change I make :/

    Your first idea seemed to nail it, but as you said: normally, I should have to tell it each time to add the segment as a new translation. I don't do that of course, but it still works as if I did... Could it be some kind of setting from my client? If so, I tried to dabble with the parameters of the TM itself, but couldn't find anything even close to this "add as a new translation" :/

  • Any other idea or feedback? I was hoping someone might have encountered the same issue and could help?

  • Hi Ingrid,

    This is a bug that, since the first version of Studio came out, recurs for me and the wonderful agency I do most of my freelancing for. It has proved impossible to prevent. It is not consistently present. It will disappear for a while then return with a new update or version. It does not happen unilaterally for all Studio users and therefore cannot be identified and resolved. It only happens for a few of us.

    Years ago when I was employed by that agency and therefore worked on site, part of my job was to ensure the smooth running and troubleshoot Trados for the rest of the team. I found this was happening on everyone's machine and reported it.  looked at my setup remotely to identify that it really was happening, which he found it was. He also found that there was no identifiable cause that was specific to our setup rather than to the program itself, and that there was no way to prevent it happening. He therefore referred it to Development, who came back after looking into it and said that it was due to conflicting hexadecimal values, i.e. a background property of the segment that should have been the same as that of the translation unit was different, which means that the identical source translation unit wasn't 'identical'.

    I also experienced 'identical duplicates', where the source AND the target were identical to those of the existing TM translation unit, yet a new TU was created on confirming.

    The advice given at that time was to delete the old TU then use Ctrl+T to translate the new TU back to the segment, then confirm the segment again. This did then not create a duplicate. This is time-consuming and slows down the workflow, though I have become very fast at doing it. I work mostly as a proofreader now so correct more segments than the average translator would. 

    As most of our translators understandably did not want to slow themselves down by performing the above 'solution', I found that if I exported a TM to .tmx then imported it into a new TM (based on the old TM to retain the many customised settings), all the older duplicates would be overwritten. This we did periodically to prevent our TMs becoming too huge. Not perfect because where a newer TU is wrong it will overwrite the older, correct, TU. Also when one has actually created a new TU on purpose via 'Add as new translation', it will be overwritten so that only one version of that TU remains.

    If anyone could have solved this issue it would have been me because I worked very hard trying to find a solution and there is none. This doesn't stop me trying again if I have time. I have found no common denominator when comparing my setup to that of others. I have ideas on what is triggering it but if I'm right, there is definitely no solution. Long story.

    Anyway, what I do when this happens, if I need to do anything, is just right-click the old TU in the Translation Results window and hit Ctrl+Delete. As the TMs belong to the client and I don't return the TM with the job, this doesn't affect them so is unnecessary from their perspective. The reimporting of the SDLXLIFF into their version of the TM will (if I remember correctly) overwrite any uncorrected TUs, fortunately.

    So, worry not, you're not alone or imagining it. It is some sort of bug/glitch/feature but there's no way to prevent it happening to those rare individuals who experience it.

    All the best,

    Ali Slight smile

  • Hi Alison,

    Thank you for this very detailed answer!

    Obviously, you have indeed been working hard on this topic for quite some time... I also have to delete every double (or more) translation in the TM and was hoping for some quicker way.

    Now I know: not anytime soon Stuck out tongue

    Thank you !!

  • Hi Ingrid,

    If I ever find a solution to this, I will post it for all to see!

    At least I was able to tell you that you're not alone!

    All the best,

    Ali Slight smile

  • That would really be great :)

    Indeed, now I know I do not have some kind of hallucination....

    Thank you for taking the time to answer me!

  • Hi Ingrid,

    You're welcome! Always a pleasure to help!

    All the best,

    Ali Slight smile

  • Hi and ,

    I recently experienced the same thing, the segments got duplicated so that I had quite a list of them because I changed some of them several times.

    I cannot offer an explanation either, but can confirm this strange behavior.

    In my case, the reason was probably that I had attached several TMs to my project and for some reason, the segments also landed in a second one although I had only enabled one to be updated. I had added the TM in question via AnyTM . I find that these Any-TMs often behave strangely (not using the correct field values, etc.), and maybe this was the reason here, too.

    I then created a separate TM for this project and filled it with the segments from my files. Afterwards I deleted the corresponding segments from the previous TM so that they existed only once. 

    The error never appeared again...


    Annette (from Manfred's account)


    Hi Annette,

    Thanks for confirming that it has happened to you too. All I know is that there are background properties generated on confirming a segment that differ from those of the TM from which the translation came, causing a second TU to be created. I have never been able to pin down what triggers that but I presume it is a combination of complex custom settings that trigger an unintentional hexadecimal value. This also happened sometimes even when one hadn't made a change to the translation before confirming, creating a second TU that had identical source and target to the original TU. Exporting the TM to TMX, via the Translation Memories window, then reimporting either to the original TM or a new one eradicates this as well as multiple translated TUs. As I recall I use the default export & import settings for that.

    Have a good week!

    Ali Slight smile