Documentation Center

Leverage Level Penalties

In addition to new ICE leverage options being added to WorldServer 9, new leverage level penalties have been added. Leverage level penalties affect the final match score based on factors that extend beyond source text differences. These penalties will allow you to restrict what will be considered an exact match and in most cases, these will affect ICE matches, and typically will not affect SPICE matches. Penalties that affect ICE matches will effectively cause such matches to be demoted not only from an ICE match, but the resulting match will result in a fuzzy match.

The following is a list of the supported leverage level penalties:
  • Maximum length penalty – Penalizes matches where the length of the target text of the match exceeds the defined allowable limit for the target segment.
  • Unreviewed match penalty – Penalizes matches that do not have the “Reviewed” status.
  • TM Group TM penalty – Penalizes every match coming from a specific TM within a TM group, including SPICE and ICE matches.
  • Asset mismatch penalty – Penalizes matches that are associated with a different asset.
  • Metadata mismatch penalty – Penalizes matches that do not have a complete set of matching values with the asset for all AIS-TM mapped attributes.
  • Reverse leverage penalty – Penalizes matches that are the result of the reverse leverage process.
  • Multiple exact match penalty – Penalizes exact matches (excluding SPICE and ICE) where there are multiple distinct translations for the identical source text.
Each of the above penalties and how they are useful are described in greater detail later.
Maximum Length Penalty (maximum_target_length_penalty)
The maximum length penalty is applied to matches where the length of the target text of the match exceeds the defined allowable limit for the target segment. The maximum length scenario typically involves situations where content must be restricted to a confined area, such as on a display screen. Penalizing such matches can prevent the accidental use of a match that may have been truncated due to the maximum length restriction. Since providing a translation that actually meets the length restriction takes additional work, it makes sense that such matches should not be leveraged as 100%. The value of this penalty should reflect the effort on average of making the change.
Effective use of this penalty requires an environment that is able to define and apply maximum lengths for the target segment. WorldServer generally does not provide a solution out of the box for assigning or determining maximum lengths for targets. This is something that has to be driven by your business requirements and customizations. However, once you have integrated maximum length support into your WorldServer environment, the use of this penalty can help you control how TM matches treated during the leverage process when the target side exceeds the established maximum length criteria for a segment.
This penalty affects all matches, including SPICE and ICE.
Unreviewed Match Penalty (tm_score_unreviewed_match_penalty)
This penalty is applied to a match that is being leveraged that does not have the “Reviewed” status. Depending on whether your WorldServer environment is using Live TM mode or not, you may have TM entries stored in your TM that do not have a reviewed status. Working in the non-Live TM mode, all matches stored to the TM are viewed. However, in Live TM mode, the stored TM entries may have various statuses, such as “Reviewed”, “Unreviewed” or “Rejected” depending on what is happening within the project. (Refer to the documentation on Live Translation Memory.)
This penalty is a good way to control how the leverage treats matches that do not have the “Reviewed” status. By default, non-reviewed matches will not result in ICE matches, but they may lead to 100% matches. This is generally all right, since 100% matches typically must be reviewed anyway. During the leverage process, matches resulting from these TM entries will lead to the target segment being auto populated because it is a 100% match.
Perhaps your treatment of 100% matches is different and your goal does not require 100% matches to be reviewed. In order to do this, you need to ensure that the 100% matches that get registered meet some baseline quality guidelines. In this case, you might want to minimally require that only 100% matches that have been reviewed. This minimal goal can be accomplished by setting the Unreviewed penalty to a value greater than 0.
This penalty affects all matches, including SPICE and ICE. If your intentions are to prevent ICE matches against unreviewed matches, then you should use the ICE restricting option instead.
TM Group TM Penalty
This penalty, which you configure in the user interface when you create or add to a TM Group, is applied to every match coming from a specific TM within a TM group, including SPICE and ICE matches. When configuring TMs within the TM group, you are able to assign penalties to each of the TMs. This penalty is not associated with the TM explicitly. Instead, they are related to the TM group’s use of the TM.
The use of a TM group generally means that you have already chosen to use multiple TMs to partition your stored translation data. Perhaps you have chosen to create TMs for different products or different departments within your organization. Regardless of the strategy you use, there is a question you must answer whenever attempting to leverage TM content in a context that differs from the context in which the data was created. This question is, “How appropriate is this content for the context (such as a different product line) with which I want to cross leverage it?” If, in this example, the products are very related and share common terminology and language, then the use of the TM may be very appropriate. In such cases, you may choose to freely use it without requiring any special consideration. However , if the terminology and language are not very similar, or even worse, are contradictory, you may want to restrict the leverage being performed against. In this case, you can set a penalty that will be exacted against every match from that TM when being leveraged in that TM group.
In essence, TM group TM penalties provide a means to establish relative quality metrics across different TMs within the TM group.
Asset Mismatch Penalty (tm_score_asset_mismatch_penalty)
This penalty allows you to penalize a TM match if it is not associated with the asset that is being translated. When assets are translated, matches are created that associated with that asset. As a result, the next time the asset is translated, WorldServer is able to bias the selection of matches based on whether they are associated with the newer version of the asset. If this penalty is set to a value greater than zero, then the leverage process will also penalize matches that are not associated with the asset being translated.
Take care when using this penalty, as it affects all matches except SPICE matches. Nonetheless, this option may be useful to you if your quality requirements must take the source asset into consideration when evaluating ICE and exact matches. If your intentions are to prevent ICE matches against matches from a different asset, then you should use the ICE restricting option instead.
Metadata Mismatch Penalty (tm_score_metadata_mismatch_penalty)
This penalty allows you to penalize matches that do not have a complete set of matching values with the asset for all AIS-TM mapped attributes. Instead of using physically different TMs to partition translation data, metadata can be used. For instance, you can use a mapped attribute to track the product with which the TM entry is associated. If the products are significantly different in the terminology used or in the language, you might want to further restrict the extent to which translations are cross leveraged. The use of this penalty allows you to do that.
This penalty affects all matches except SPICE matches. If your intentions are to prevent ICE matches against matches where the mapped metadata differs, then you should use the ICE restricting option instead.
Reverse Leverage Penalty (tm_score_reverse_leverage_penalty)
This penalty allows you to penalize all reverse leverage matches. In WorldServer, TM content can be leveraged in both directions—source to target, and target to source. This is referred to as bi-directional leverage support. The maximum leverage level supported for reversed leverage matches is 100%. If a reverse leverage match results in a 100% match, it is treated the same way a normal, forward leveraged match—it will be populated into the target segment. Depending on your quality metrics, this may or may not be acceptable. You may want them to only be treated as high fuzzy matches. If this is the case, then this penalty can be used to prevent reverse leverage matches from generating 100% matches, and thus, prevent the target segment from being auto populated with them during the leverage process.
Multiple Exact Match Penalty (tm_score_multiple_exact_match_penalty)
his penalty allows you to penalize exact matches that occur when there are other exact matches for the segment with differing translations. Exact matches are ranked using the same rules for ICE matches, and generally will provide the best available match.
Nonetheless, perhaps the existence of multiple translations for a segment implies the introduction of a quality issue. There is already the option to detect multiple exact match segments; however, the target segment will still be populated with the system's best guess for the exact match. If you are not comfortable with WorldServer choosing the best exact match for you, you could choose to penalize such matches so that they would be available to the translator as high fuzzy matches (or whatever leverage level as dictated by the penalty) instead of them being positioned solely for review as an exact match.
The use of this option requires that the view multiple exact matches option is enabled. This penalty does not affect ICE matches.