Relaxed Tag Parity

Starting with Studio 2011 and WorldServer 2011 (release 10.1), the default WorldServer environment (using Studio file types and Studio-aligned translation memory mode) relaxes the requirement for tag parity in translation unit (TU) segments. That is, some tags may be present in the translation target without a requirement that they be in the translation source, or vice versa.

Studio 2011 creates return packages for WorldServer 10.1 without enforcing tag parity. Things to note:

Translation units which have tags that are out of parity are excluded from WorldServer in-context exact (ICE) matches.
WorldServer resolves target-only tags through an automatic mechanism in the associated WorldServer filter configuration for the file type, in general. If the configuration does not use a Studio file type, or has another issue, leverage penalties will be applied.

Note: If you work in WorldServer's Browser Workbench, you may notice temporary non-sequential placeholder ID numbering for non-parity segments brought in from translation memory. The ID sequence generally resolves once a server round trip takes place for the segment (such as when you save an asset, or add a segment comment), if not before.

Legacy tag parity behaviors/settings

When you create a return package for a WorldServer version before 10.1, Studio 2009 and 2011 both check for tag parity, the previous default behavior. The return package creation will fail in Studio if tag differences exist in that case. Importing an out-of-parity return package into pre-10.1 WorldServer environments will also fail.

If you do want to enforce tag parity in source and target translation units for a particular Studio file type, most file types have a Tag Check control that you can use to verify tag parity, the behavior prior to WorldServer 10.1.