Documentation Center

The ping-pong effect

The ping-pong effect describes the behavior of the TM when customers seek both to employ the path normalization technology to relate various exposed versions of an asset, and to employ the basic translation regeneration capability of WorldServer. As described earlier, WorldServer TM technology allows customers to regenerate translations for past work long after substantial updates have been made to the data stored in the TM. This ability is based on storing translation sets associated with each asset within the TM. Within the TM, an asset is identified by the associated TM AIS context. As long as the TM AIS context does not change and is not shared, the customer can reliably regenerate the translation of past-translated work. If the asset changes, the system can reliably translate the unchanged content identically to the previous translation. This ability is directly dependent on each asset having its own set of translations within the TM.

The problem is that these capabilities are mutually exclusive. It will not always be possible to regenerate a previous translation version when using path normalization. Path normalization results in multiple assets sharing a single set of TM entries. It will cause TM entries for all versions except the most current versions to be expunged from the TM. The TM will only contain TM entries associated with the last translated asset for any given TM AIS context.

Note that this problem only occurs (practically) in the event that two or more assets sharing a TM AIS context are being updated and translated over an overlapping period of time. For example, multiple releases may be authored for the "same asset". The content may change for both over a given amount of time, and as they change, they are iteratively translated. If these assets are forced to share the same TM AIS context, each translation round will negatively affect the translation of the other. This back-and-forth behavior lends itself to the ping-pong effect name. This is illustrated in the following example.

Example

Let's assume we are working on Release #1 and that in a few days we will need to work on Release #2 before Release #1 has been released.

On Release #1 we translate a file (A). All segments are committed to TM so that the next time the file is parsed all segments are ICEd.

The file segments look like this:
Seg. 1: This is segment 1
Seg. 2: This is segment 2
Seg. 3: This is segment 3
A few days later Release #2 is ready to be translated. We translate file (A), which is updated with a few new segments:
Seg. 1: This is segment 1
Seg 4: This is a new segment 4
Seg. 2: This is segment 2
Seg 5: This is a new segment 5
Seg. 3: This is segment 3

The Linguist will translate the file and save it to the TM so that all strings are now ICE'd against the TM.

Just before finalizing Release #1, file (A) gets a fix on the code level that does not influence the value or any of the segmentation rules. The file will be submitted for translation using a WorldServer project. The workflow being used will auto generate the target file provided that the asset is all ICE’d.

However, file (A) no longer registers all ICE’d segments. The file will stop with 100% matches instead of ICE matches. If the Engineer or the Linguist commits the translation to memory, then the same file (A) on Release #2 will have its values changed to 100% when leveraged against the TM, instead of being completely ICE'd. If the TM is updated again with the translations from file (A) on Release #2, then the matches for file (A) on Release #1 will revert back to 100% when re-leveraged against the TM.

1 Note that this will happen if the file has not changed and it is forced to be re-leveraged by triggering segmentation. If file (A) in Release #2 was completely translated before additional work is done on file (A) in Release #1, then WorldServer would be able to generate the previously translated file. However, the slightest change to file (A) in Release #2 would result in the ping-pong effect.