In WorldServer, what is Segment Preferred In-context Exact (SPICE) Match and how does it work?

What is Segment Preferred In-context Exact (SPICE) Match and how does it work?

The segment preferred in-context exact (SPICE) match is similar to the basic ICE mechanism. The SPICE match process supports another leverage level that is superior to the basic exact match supported by traditional TM systems. Instead of inferring context information from the surrounding segments and the containing document, the SPICE mechanism derives context explicitly from segment identifier (SID) tags embedded within the document. The SID defines the intended context, and thus the combination of the SID and the source segment text correlates to a specific translation within the TM regardless of the document within which it is embedded.

SPICE matches are global within the defined TM. There can be only one SPICE match candidate for any given segment/SID combination. This is different from the ICE mechanism, which allows for different documents to potentially have different translations for a common block of content. SPICE match usage is optional. System parameters can be configured to indicate whether SPICE matches are preferred over ICE matches.

TM configuration options are defined in tm.properties, using the following entry:
 

prefer_sid_over_ice_matches=true

When SPICE matching is enabled (default setting), SPICE is preferred over ICE by default. If set to true, WorldServer will look for SPICE match before looking for ICE match. If set to false, seek ICE match first.

SID vs. ICE Priority Settings

WorldServer allows the customer to control the order in which context-based matches are retrieved.

• disable/enable SID-based matching (#prefer_sid_over_ice_matches=false)
• prefer ICE over SID-based matching (prefer_sid_over_ice_matches=false)
• prefer SID over ICE-based matching (prefer_sid_over_ice_matches=true)

Preferring the standard ICE matches means that you prefer the more localized usage context of translations. In this strategy, you might have SID-based matches that provide a default SPICE translation in the absence of a localized ICE match. However, as soon as there is a localized ICE match, it will be preferred.

Preferring SPICE matches (which is the default setting) over the standard ICE means that you want to establish more consistent, universal translations for content. The SID defines the context entirely, negating the normal match ranking strategy. Since there can only be one SPICE match for a given SID + Source text combination, there is no need for ranking. ICE matches become secondary, and are used only when SPICE matches are not available.

The preference options for ICE and SPICE matches may not result in significant leverage results in environments that almost entirely use SID-based content or in environments that use mainly non-SID-based content. For asset segments without associated SID values, WorldServer stores a copy of the translation for each asset. Currently WorldServer does not store asset-based entries for segments containing SIDs when the translation has not been updated.

Relevant articles about this topic:

How to set up a SPICE (SID) Matching configuration in WorldServer based on AIS properties
WorldServer - is it possible to avoid the creation of "duplicated" TM entries by removing the 'Same AIS path" criteria
In WorldServer, what are Segment Identifiers (SIDs) and how are they used?
Support of SIDs for File Types in WorldServer
How are SIDs displayed in Trados Studio?