I have been experiencing this problem for a while. Many times (not always) - either after I have started a project as "Translate single document" or after having been sent a package from a client - when I go to make a change/correction to a TU I have already translated and confirmed earlier, a duplicate TU is created rather than the old one being overwritten. The problem is that I end up erasing the duplicates manually, which is time-consuming and defeats the purpose of using a "fast" tool. How can this be corrected? As mentioned, it does not happen every time, so I am assuming it may not be related to a problem in the global settings. Please refer to attached a document containing the relevant screenshots.
Your question about particular scenarios got me thinking, so I started playing around. I am pretty sure that the problem seems to appear when I add TMs to a project using the Any TM option. This is something I do often, as half of my clients want their translations in UK English and the other half in US English. The Any TM option was very helpful, as it solved the problem of having to export and import TMs all the time. But there may be a glitch there. Please refer to attached document for detailed scenarios.
In answer to your other questions, my TMs are located in a file named Studio Memories in my local C drive (not in the default Studio 2015 file). All my TMs are also synced to a cloud through SygarSync. I may use anywhere between 1 and 4 TMs for a single project (in various language combinations & even reverse TMs). As for the "Add as a new translation" shortcut, not entirely sure what you mean.
I am currently using Studio 2015 SR2 - 12.2.5195.7. I have purchased Studio 2017 and even attended the Athens Roadshow, but have not upgraded to it yet (too busy). However, would be happy to do so immediately if there are no duplicate glitches with that one.
Awaiting your update.
Apologies for not getting back to you. Based on your response it sounds to me as though the combination of TMs you are using and working with AnyTM may be the root of the problem. Not because there is a bug, but because you are somehow adding TUs to multiple TMs. Can you check the individual TMs to see whether or not the TU that shows up in your results is actually in multiple TMs, or if it is duplicated into one TM?
On the "Add as new Translation Unit", I mean just double check that you are not inadvertently using this command via a keyboard shortcut perhaps?
Vicky Ghionis said:Actually, I was playing around just now and I repeated the process 6 times (correct a segment, save it, correct it again, save it again, etc.) and ended up with 6 TUs in a single TM for a single segment!
Can you provide me with your project files, and your TM and steps to reproduce. If I can reproduce the issue with your data then I may be in a better position to either explain it, or get this logged with development to fix.
Identical duplicates and/or source duplicates created instead of being overwritten seem to happen for certain people with certain setups. I have had this issue for years. One way to eradicate 'duplicates' periodically is to export the TM to tmx and reimport it, which overwrites each bunch of identical duplicates back to one. There is also an app that does this but I tested it out against my tmx method and found that it was via tmx that the last dated unit took priority. This may have changed since then because that was back in Studio 2009 or 2011...
I spent quite some time convincing Tech Support that it was actually happening as they couldn't reproduce it but Fasil Aziz was able to witness it happening on my computer remotely and to ascertain that it wasn't my setup's fault, but generated by Studio itself. The explanation given to Faz by development when they looked into it was that new background properties (hexadecimal) were being attributed for some reason to the corrected/changed or even identical unit created so although the source appeared identical, the two or more identical (Source or Source AND Target) units had different background properties.
The workaround suggested by development was to delete the original unit from the TM, then use the 'new' unit in the TM to translate the segment again then confirm the segment as translated, then that unit would 'stick'. It happens a lot, that's too time consuming. However, it is a useful method for correcting other odd TM behaviour too sometimes.
I have never seen proof that this issue was fully resolved as it has continued to happen 'off and on', I just accepted it as one of those inevitable glitches that happen with complex software. C'est la vie !
Maybe this new input will help get to the root of the problem - if, of course, the symptoms are due to the same cause...
All the best,