Segment identifiers (SIDs) allow customers to explicitly define the context for a given segment. WorldServer has added support that allows these values to be used, provided that the proper file type requirements have been met. This chapter of our RWS Documentation Center provides more extensive details on the background and use of SIDs within the WorldServer environment.
In WorldServer, a SID (Segment Identifier) is a label that defines the usage context in which a segment is to be translated. Applying a SID to a segment identifies the context for the segment. By default, SID support is enabled in WorldServer, though it cannot be used without an installed SID-based file type.
WorldServer supports SIDs in the following ways:
- Defines how SID markers should be used in customer content
- Leverages only properly defined SID markers
- Enforces boundaries defined by proper SID usage
- Associates defined SIDs with translation pairs
- Enforces supported uniqueness requirements
- Leverages SID content against SID TM entries
The segment identifier (SID) support in WorldServer requires a custom file type configuration that:
- Searches the starting and ending tags of the source asset for a unique identifier.
- Activates SID in WorldServer with the unique identifier.
- Associates the unique identifier with one or more TM matches.
In WorldServer 10.4 and later versions, the following File Types support SIDs:
1- Java Resources File Type
2- Custom XML (Embedded Content Processor) File Type but not if the Embedded Content Processor is enabled, please refer to this article for more details.
3- Custom XML (Legacy Embedded Content) File Type
4- JSON File Type (Added in WorldServer 11.4.x)
Note: for SIDs to be displayed with files segmented with the Custom XML (Embedded Content Processor) File Type, a specific rule needs to be enabled in the Filter Configuration. Please refer to the online documentation about this. You can find it here.
The same procedure applies to Custom XML (Legacy Embedded Content) File Type
These global properties need to be set to true in tm.properties for SIDs to be enabled:
enable_sid_lookup=true
enable_standard_ice_lookup=true
The property that governs segment matching settings is called prefer_sid_over_ice_matches. It works only when both SID-based matches and ICE matches are enabled (enable_sid_lookup=true and enable_standard_ice_lookup=true).
- If you set the value of the prefer_sid_over_ice_matches property to false, WorldServer will look for ICE matches first. This involves preferring a more localized usage context of translation. If there are no localized ICE matches, you might still have SID-based matches; however, as soon as a localized ICE match is available, WorldServer will prefer it.
- If you set the value of the prefer_sid_over_ice_matches to true, WorldServer will look for SID-based (also known as segment preferred in-context exact or SPICE) matches first. Preferring SPICE matches over the standard ICE matches means that you want to establish more consistent, universal translations for content. The SID defines the context entirely, negating the normal match ranking strategy. There can only be one SPICE match for a given SID + source text combination, so there is no need for ranking. In this scenario, ICE matches become secondary and are used only when SPICE matches are not available.
Note that you can configure SPICE Matching independently from file types by mapping the relevant AIS property to a TM entry attribute. This article provides exact instructions:
How to set up a SPICE (SID) Matching configuration in WorldServer
