Salesforce

How to set up a SPICE (SID) Matching configuration in WorldServer based on AIS properties

« Go Back

Information

 
TitleHow to set up a SPICE (SID) Matching configuration in WorldServer based on AIS properties
URL Name000010232
SummaryThis article explains how to configure your system to support the usage of SIDs
Scope/EnvironmentWorldServer
Question
How do I set up a SPICE (SID) Matching configuration in WorldServer based on AIS properties and what are the advantages?
Answer

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.)

Spice matching can be configured as follows:

  • the first requirement is that the AIS property can be mapped to a TM entry attribute. This article explains how. So make sure to configure this property in tm.properties accordingly:  map_ais_property_to_same_named_tm_attribute=true
  • configure a Custom AIS property as a text field or as a selector (usually a selector with pre-set SID values is the common choice)
  • the custom AIS property has to be suffixed by _tm_sid (!)
  • the AIS property can be defined as "inherited" (not mandatory) - if set to inherited, the value will have to be defined and inherited by higher-level folders (e.g. the directory CUSTOMER)
  • the value for _tm_sid can be either populated manually (e.g. at client or directory level) or automatically/programmatically - for instance by an automatic action
  • the SPICE matching properties of the tm.properties file need to be enabled (per default this is set to false) - see the "Leverage" section in tm.properties

Example from the tm.properties file configured to use SPICE matching:

Leverage
################################################################
# Leverage
################################################################
 
# Determines whether SIDs are utilized during the alignment process if they are
# available. SIDs must match in order for the segments to be aligned if both
# segments contain SID values.
enable_sid_based_alignment=true
 
# Determines whether to leverage available SIDs for SPICE matching.
enable_sid_lookup=true
 
# Determines whether standard ICE matching will be supported.
#enable_standard_ice_lookup=true
 
#  Determines whether the matching algorithm should prefer matches from an asset
# that provided a previous match, provided that the position of the segment in
# both assets matches.
prefer_previously_matched_asset=true
 
# Determines whether SID matches should be higher priority than ICE.
# Relevant only when both SPICE and ICE matches are being sought. Requires
# enable_standard_ice_lookup=true and enable_sid_lookup=true in order to have an
# impact.
prefer_sid_over_ice_matches=true
 
 
# Determines whether the ICE condition will require that the TM entry match the
# TM AIS context of the asset being translated. If this option is enabled, then
# no segments for new assets will be ICE matched. Note that path normalization
# will impact how the TM identifies assets, and therefore can impact ICE
# results when this option is enabled. This option does not apply to SPICE
# matches.
# Requires enable_standard_ice_lookup=true to have any impact.
#require_asset_match_for_ice=false
 
# Determines whether the ICE condition will require the TM entry to have the
# same attribute values as the corresponding mapped AIS properties. If enabled,
# all mapped attributes much match their AIS property counterparts. This option
# does not impact SPICE matches
# Requires enable_standard_ice_lookup=true to have any impact.
##require_metadata_match_for_ice=false
 
# Determines whether a full usage context is required for all ICE matches. For
# a full usage context, the TM match must have been translated between segments
# having the same content as those around the asset segment being translated.
# This option does not impact SPICE matches.
# Requires enable_standard_ice_lookup=true to have any impact.
#require_full_usage_context_for_ice=false
 
# Determines whether a null context should be enough to register a partial ICE
# match. This does not impact full context defined by a previous and next
# segment being null, as is the case for single segment documents.
# Added in WS 9.0.1
# Requires enable_standard_ice_lookup=true to have any impact.
#require_non_null_context_for_partial_ice=true
 
 
#Description: "Determines whether the ICE condition will require that the TM
# entry match the TM AIS context of the asset being translated when the asset
# only contains a single segment. If this option is enabled, then a single
# segment asset can only be ICEd if it has been previously translated. Note
# that path normalization will impact how the TM identifies assets, and
# therefore can impact ICE results when this option is enabled. This option
# does not apply to SPICE matches."
# Requires enable_standard_ice_lookup=true to have any impact.
#require_asset_match_for_single_segment_asset_ice=true
 
 
# Determines whether or not all TMs in the group will be searched unless
# an ICE match has been found. As TMs in groups are ordered and prioritized,
# WS will by default accept 100% matches found in higher priority TMs above ICE
# matches found in lower priority TMs. Enabling this options will force WS to
continue searching lower priority TMs until an ICE match has been found or
# all TMs have been searched. Enabling this could impact the performance of
# the leverage process depending on the TM group and the nature of the data
# stored within it.
#search_all_tms_in_group_for_ice=false

You have some control over how segment matching is conducted.

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 ICE over SID-based matching
  • prefer SID over ICE-based matching
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 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.
TM configuration options

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

prefer_sid_over_ice_matches=true

When SPICE matching is enabled, prefer it over ICE by default. If true, look for SPICE match before looking for ICE match. If false, seek ICE match first

Reference
Attachment 1 
Attachment 2 
Attachment 3 
Attachment 4 
Attachment 5 

Powered by