Trados Business Manager
Speech to Text
Managed Translation - Enterprise
Translation Management Connectors
Language Weaver Connectors
Language Weaver Edge
Tridion Docs Developers
RWS User Experience
Internal Trados Ideas Community
RWS Community Internal Group
RWS Access Customer Portal
RWS Professional Services
RWS Training & Certification
RWS Enterprise Technology Partners
Trados Academic Partners
Trados Approved Trainers
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic Tridion Docs User Group
Tridion Docs Europe & APAC User Group
Tridion UK Meetup
Tridion User Group Benelux
Tridion User Group New England
Tridion User Group Ohio Valley
Tridion West Coast User Group
WorldServer User Group
Trados GroupShare Ideas
Trados Studio Ideas
Language Weaver Ideas
Language Weaver Edge Ideas
RWS Language Cloud TMS Ideas
RWS Language Cloud Terminology Ideas
RWS Language Cloud Online Editor Ideas
Managed Translation - Enterprise Ideas
Tridion Docs Ideas
Tridion Sites Ideas
LiveContent S1000D Ideas
Events & Webinars
To RWS Documentation
To RWS Support
Detecting language please wait for.......
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 :)
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…
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…
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,
Any other idea or feedback? I was hoping someone might have encountered the same issue and could help?
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.
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 !!
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!
You're welcome! Always a pleasure to help!
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...
Annette (from Manfred's account)
Manfred Altmann Ingrid Fischer
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!