Handling duplicate entries in the TM by XTM Cloud
Imagine the situation where you translate one project and then create a second project using the same file. In the second project you have the same source sentence in the same context, but you translate it differently. By default, a new TM entry is created and the data from the second project, such as tags, is included.
If, however, you do not touch the target and you just accept the segment, this forces a TM update - this situation can occur if there are no green ICE matches because they were set to orange for not approved memory. In this case XTM Cloud updates the date of the existing TM and also consolidates tags by adding all new tags to the existing memory.
Consolidating tags can also happen if you import memory with different tags. Let's say the first TM file has the tag “tag1” and the second “tag2”. After importing both files all similar segments will have both tags.
In the Configuration section it is possible to determine what should happen if the translation from the second project is different from the existing TM. We can control if a duplicate TM entry is created or the old record is overwritten, thus having only one translation in the TM and no duplicate for a given source and probably context.
The following examples demonstrate how XTM Cloud handles duplicate TM entries:
Our source file is:
First | sentence. |
Second | {1}sentence{1}. (sentence is bold) |
Third | sentence. |
The second sentence is translated into "Drugie {1}zdanie{1}" - the other translations are not important.
The settings for TM duplicates are:
Modify existing TM if source, context and inline tags are the same. If we translate the second sentence differently in our second project it will overwrite our existing translation.
If we now modify the settings so that they are less strict.
Modify existing TM if source, inline tags are the same.
Assume our source file is now:
Second | {1}sentence{1}. |
Third | sentence. |
We removed the first sentence and created a third project using this file.
When making amendments in our newest project, we will overwrite our one and only translation changing the context of the TM. This can have serious repercussions because if we create another project using the first file, we will not get an ICE matches. This is why this option should be used with care.
Even with greater care should be taken when the inline restriction is lifted.
If we make a fourth project where the second sentence is no longer bold
Second | sentence. (without bold style) |
When we edit the ICE match, we will make changes to our one and only database translation.
Note
Be aware that the first file (with inline tags) would have a lower match since the inline tags are missing.
Tags setting for duplicates
In the situation when an old project contains all the same tags as the new project (or does not have a tag group at all) the translation will be treated as duplicate.
First project has the tags TM_Status: | Working. |
Second project has the tags TM_Status: | Working. |
Those are obviously duplicates.
First project has the tags TM_Status: | Working, Golden. |
Second project has the tags TM_Status: | Working. |
Those are duplicates as well.
First project has the tags TM_Status: | Working. |
Second project has the tags TM_Status: | Working, Golden |
Those are NOT duplicates. New segments will be created when making changes in the second project.
First project has the tags TM_Status: | Working. |
Second project has the tags TM_Status: | Working; Year: 2014 |
If the tag group is not defined in the first project, then it is ignored in the second project. Thus, in this case only TM Status: tags are used.
Exact tags option
There is a further option with tags that simplifies the above cases. It is called Identical tags only:
 |
If the Identical tags only option of the Modify the existing TM record if the project segment has the same parameter is selected (see Matches – general section), the TM will only be updated if all tag groups and tags are exactly the same in the first and second project.
When a segment is locked with a method using the Mark segments as locked when parameter (see Matches – general section), it is grayed out and a key icon 
is displayed in the status column. In this state, clicking on the target text, does not make the cell active. Clicking on the key, allows the user to unlock the segment.