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

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

Ingrid Fischer

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. Fasil Aziz 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

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

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

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!

Ingrid Fischer

Hi Ingrid,

You're welcome! Always a pleasure to help!

All the best,

Ali

Hi Ingrid Fischer and Alison Field,

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...

Best 

Annette (from Manfred's account)

Manfred Altmann Ingrid Fischer

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