Documentation Center

Defining Context for ICE Matching

SPICE matches and 100% matches are automatically applied to the segments. SPICE and ICE matches generally are not reviewed, while 100% matches are generally are reviewed. Fuzzy match segments must be translated entirely. The question that you must ask yourself is what makes a SPICE match or an ICE match worthy of not having to be reviewed. The implied answer is that the quality of ICE and SPICE matches are high enough that they do not require further reviewing. However, what is sufficient quality for one is not sufficient quality for another. If the collection of matches that fall into the ICE category includes matches that do in fact need to be reviewed, then all ICE matches would need to be reviewed in order to ensure the required quality of all translations. If it were possible to separate the matches that need to be reviewed from those that do not, then you would be able to save money by not having to review all of the matches.

In WorldServer 9, we have added a number of ICE leverage options. These options are designed to allow greater level controls over ICE matching criteria. The significance of this is that it enables the user to customize the requirements for ICE matches. The user can now enforce stricter requirement for ICE matches, enforcing higher level of quality to be associated with the ICE status. In WorldServer 9 the following options are available for further restricting ICE matches:
  • Asset match requirement – ICE matches can be restricted to TM entries that are from a previous version of the asset currently being translated.
  • Metadata match requirement – ICE matches can be restricted to TM entries that share a complete set of mapped attributes with the asset being translated.
  • Reviewed match requirement – ICE matches can be restricted to TM entries that have been reviewed.
  • Full usage context requirement – ICE matches can be restricted to TM entries that share a full usage context. This means that the previous and next segments associated with the TM entry must match those of the segment being translated.
  • Null (boundary) usage context allowance – ICE matches can result for boundary segments based on leveraging an exact match that is on the same boundary. This null context or boundary condition is defined by the lack of a previous and/or next segment. The condition would allow a boundary segment to score an ICE based purely on the fact that the exact match being leveraged is on the same boundary as the segment (thus void of the same previous or next segment.) In short, this means that void or null is an acceptable usage context value.
Prior to WorldServer 9, ICE matching was based solely on the TM entry having been translated in the context of either the segment before or after the current segment being translated. The above option only influenced the ranking of ICE matches, but had no ability to promote an ICE match. These additional pieces of contextual data now have the ability to help define the context for an ICE match.
Asset Match Requirement (require_asset_match_for_ice )
This option allows you to impose the restriction that the ICE match process only considers TM entries that are associated with the asset (or an earlier version of the asset) being translated. Provided that an exclusive SID-based environment is not being used, WorldServer will store translations for each asset being translated. When re-leveraging or leveraging a newer version of the asset, the TM will prefer matches from the asset versus another asset based on the match ranking rules.
If the asset is new or has new segments, then those segments can still be ICE matched. The ICE matches in this case must originate from the translation of another asset. When dealing with a large volume of highly related information, this is extremely beneficial. It means that you can derive optimal benefit when leveraging newly introduced assets against an existing collection of TM data.
If your translation jobs center around the translation of unrelated assets or significantly different assets, then an ICE match generated from a translation in a different asset may not have the desired level of quality implied by an ICE match. This option allows you to extend the context requirement of ICE matches to include the asset.
This option does not affect SPICE matches. This asset match requirement is disabled by default.
Metadata Match Requirement (require_metadata_match_for_ice )
This option allows you to impose the restriction that the ICE match process only considers TM entries that share a complete set of mapped attributes with the asset being translated. Just as in the match ranking process, every mapped attribute must have the same value as those associated with the asset being translated. If even one of these differs, then the TM entry will not even consider for an ICE match.
The use of metadata allows you to describe and effectively partition your data within a single TM. Now, you can use metadata as an additional context requirement for ICE matching.
This does not apply to SPICE matches. This option is disabled by default.
When might you want to use this option to control ICE matching? Consider the following scenario. In WorldServer, you have the ability to consolidate your TMs into a centralized TM. What was once a collection of isolated TMs is now a single centralized, bilingual TM. The former collection of TMs may have included TMs for different products. Now that these TM are consolidated, the natural boundaries between translations from the products have been lost. If translations from different products are to be stored in the same TM, then how can we use of translations from one product being restricted in its use for another product?
As long as the TM entries satisfied the ICE matching criteria, it has the potential to score an ICE match regardless of which product it is associated with. The match ranking criteria will prefer matches from the same product over those from another product in the event that he ICE match exists for the desired product. This assumes that an AIS property for product has been mapped to a TM attribute for the product and that the ranking options for mapped attributes have been enabled. However, if there is no ICE match available from the desired product, then the ICE match available from another product will be selected. This standard behavior may not be desirable. Matches from a different product may require review regardless of the ICE match status. Because the collection of ICE matches can include ICE matches from a different product, then that all ICE matches must be reviewed in order to prevent ICE matches from a different product being accepted without review. If you are able to isolate the ICE matches that did not need to be reviewed from those that do, then you would be able to save money by not unnecessarily reviewing the ICE matches that do not require review.
In this example the problem can be solved by requiring the mapped metadata of the TM entry to match the mapped metadata of the asset being translated. By enabling this ICE matching requirement, matches from another product will no longer be considered for an ICE match. They will still be available as exact match candidates.
Reviewed Match Requirement (require_reviewed_status_for_ice )
This option allows you to impose the restriction that the ICE match process only considers TM entries that have the “Reviewed” status. This option is enabled by default, and is critical when using the Live TM functionality. When not in the Live TM mode, all entries stored to the TM are automatically stored as “Reviewed.” This option applies to SPICE and ICE matches
While this option is exposed, SDL does not expect that you would choose to disable this. Nonetheless, you may have circumstances that may lead you to disable this option, if only temporarily.
Full usage context requirement (require_full_usage_context_for_ice )
This option allows you to impose the restriction that the ICE match process only considers TM entries that are a full usage context match to the segment being leverage. As noted earlier, ICE matching was based solely on the TM entry having been translated in the context of either the segment before or after the current segment being translated. The full usage context was only considered during the match ranking process, which means that in the absence of a full usage context match, a partial usage context ICE match could be leveraged for the ICE match.
This option simply provides you the means for further restricting the ICE match definition in order to enforce tougher context requirements. This option applies only to ICE matches, and is disabled by default.
Null (boundary) Usage Context Allowance (require_non_null_context_for_partial_ice)
ICE matches can result for boundary segments based on leveraging an exact match that is on the same boundary. This null context or boundary condition is defined by the lack of a previous and/or next segment. The condition would allow a boundary segment to score an ICE based purely on the fact that the exact match being leveraged is on the same boundary as the segment (thus void of the same previous or next segment.) In short, this means that void or null is an acceptable usage context value.
This option is disabled by default. When disabled, boundary ICE conditions are generally restricted to a partial usage context since only previous or next segments that exist are considered in the usage context definition. Enabling this option will allow the position of these segments to be significant, and result in possible full usage context matches.