Introduction
In XTM Workbench, you might sometimes come across the following message displayed in the metadata of particular TM entry for a particular segment: This TM entry has been changed and no longer meets the criteria to be qualified as a match.
IMPORTANT!
The message only applies to the TM matches which were populated during project analysis, and which no longer meet relevant criteria once an XTM Workbench session is triggered.
From a business perspective, there are some general rules:
Each TM match that was populated into the target segment during the project analysis (the target segment was filled with the translation from the TM match) should be kept on the list in the Matches tab of the docked panel even if its score, status, target or context has been changed.
If such a TM match has been modified and returning it in the same form to the Matches tab is not possible, the TM match should be maintained but marked with a warning (by hovering the cursor over the warning icon, as an explanation of why such a marking is used in the first place).
The message above appears if specific requirements are met in XTM Cloud.
When does the message occur?
There are multiple scenarios in which this message might occur:
A newer version of a TM match exists
Once a project has been created, the segment in question was populated by a TM match, which is currently marked with the message This TM entry has been changed and no longer qualifies as a match.
Then, after some time, a new project with the exact same segment was created under one of the XTM customers, which TM has been used in the initial project, and according to the global TM settings of your XTM instance, a new TM entry has been created (Configuration → Settings → Translation → TM → Matches - general:
Modify the existing TM record if the project segment has the same: Source, Inlines, Context, Tags;
Modify the existing TM record if the project segment with Segment ID has the same: Source, Inlines, Segment ID, Context, Tags).
Upon re-entering XTM Workbench for the initial project, you will actually see the message This TM entry has been changed and no longer qualifies as a match.
Remember to always access a particular segment in XTM Workbench in the edit mode, to make sure that the related TM matches are updated.
EXAMPLE:
Both the initial and further TM matches were created from the segment that contained Segment ID. As the tags and segment IDs for those 2 segments were different, instead of updating an existing TM match, a new TM entry has been created.
This TM entry has been applied to the reported project, replacing the previous match and being placed at the first place in the Matches tab of the docked panel. Once this happened, XTM Cloud indicated that the previous TM match cannot be returned anymore, since a newer TM match with the same source and target has been found for this segment. Two matches with matching source and target are viewed as duplicates, therefore only the newer match can appear.
Generally, XTM Cloud does not show duplicates (same source and target in both TM matches). Therefore, when suddenly there are two TM matches in a segment that have the same source + target + score, one of them has to be filtered out – the older one. If the older TM match was populated during project analysis and a TM match update subsequently occurs in XTM Workbench, then this older TM match gets the warning.
You do not use Not Approved Memory
Another scenario assumes the situation in which you do not use Not approved TM at all.
In this case, a TM match is returned as Approved during project analysis, but its status has changed to Not approved while the XTM Workbench session is active.
For this reason, the TM match has to be deleted because you do not want to see not approved translation memory in your projects. Therefore, the said TM match gets a warning accordingly.
A Leveraged match transforms into an ICE match
Imagine you have a Leveraged match populated during project analysis. Then, in an XTM Workbench session, a new TM entry appears – an ICE match.
It points to the same TM entry as the Leveraged match, because it originates from the same TM record. You must have confirmed the segment and added context to the very same TM entry, according to your global TM settings:
The TM entry has thus become an ICE match, and no longer a Leveraged match, so it no longer qualifies as a valid Leveraged match. Therefore, it must get a proper warning in its metadata in XTM Workbench, and the ICE match must appear instead.
A Leveraged match transforms into an ICE match due to update in another project with the same source file
Another scenario also revolves around Leveraged and ICE matches. This time you also receive a Leveraged match populated during project analysis. Then, you create a new project with exactly the same source file, and this project also gets the same Leveraged match. You accept the TM match in that second project, which causes a new TM entry to be created with the appropriate context, according to your global TM settings:
You also have the following option selected, in the Leveraged matches section (Configuration → Settings → Translation → TM → Leveraged matches → Search only if there are no ICE matches).
You come back to the first project and open XTM Workbench in the edit mode. A new ICE match appears. Since there is an ICE match, the said Leveraged match can no longer be returned, so, again, it gets a proper warning.
A TM match was modified or deleted
When a particular TM match has been modified in one way or another, a proper message will be displayed in its metadata, stating exactly that the TM was modified.
A populated TM match comes from an additional XTM Cloud customer
The message might also be displayed in a TM match that does not come from the project’s main XTM Cloud customer, but from one which was added additionally.
The root cause for such a message to appear in the first place is that you must have removed the said customer from the project at one point in time.
A populated TM match has a tag
The message might also be displayed in a TM match which had some tags right after the project creation. Once the project is created, you then add a TM penalty profile to the project, that is supposed to remove all TM matches with that tag. As a result, the TM match in question will get a proper warning.