WorldServer - is it possible to avoid the creation of "duplicated" TM entries by removing the 'Same AIS path" criteria?

If a translation unit is identical to an existing translation unit in the Translation memory (same source, same target), the existing translation unit in the Translation Memory will only be updated if the new translation unit shares the same Entry Origin, i.e. the same AIS path. For instance, while translating in Browser Workbench, Online Editor or after the import of a WorldServer Return package containing an updated translation that was previously a TM Match. Else, a new TM entry is created, even if the source and target text is identical to the existing one.

If my above statement is correct, is it possible to disable this mechanism so that the existing Translation Unit is updated, regardless of the Entry Origin?

It is not possible to disable the search for AIS Context Match in WorldServer (displayed as Entry Origin in the Translation Memory page), which determines whether a new TM entry is created or an existing one is updated.

There are two possible strategies to address the issue of so-called "duplicated TM entries" that are created because the AIS Context Match differs:

1- Perform a scheduled TM maintenance to remove "duplicates" from your Translation Memory following the step-by-step instructions provided in this article. If done regularly, your TM will not be "inflated" with multiple TM entries with identical translations.

2- You can also consider implementing SPICE Match in your WorldServer environment. The advantage is that any segment/Translation Unit associated with a SID (Segment Identifier) value can only generate a single TM Entry.

Spice matches allow you to:

• Treat the SID (provided corresponding options are set in tm.properties) as absolute context
• If a segment has a SID, there can only be one in the TM
• Source Segment + SID = Context
• Subsequent translations with the same source segment and same SID will trigger the TM segment to get overwritten. There cannot be any duplicate TUs.
• SID is to be configured via a custom AIS property.
• With SIDs you can control (on a file-based level) if there are supposed to be segment-variants (TU duplicates) or not
• If there is no SID value, the behavior of the TM regarding TUs will be as for normal ICE matches (Context, Path etc.)

This article provides more information about SPICE Match and references more articles and documentation. We recommend that you contact the RWS Professional Services Team if you are interested in implementing SPICE Match and SIDs in your process.

These articles are relevant:

Worldserver - How to delete TM Duplicates from a Translation Memories?