Segment Status in a Translation and Review Workflow

The translation process typically involves a back-and-forth “translation and review” cycle between one or more translators and one or more reviewers. The translators translate some text. That text is then passed to the reviewers who either accept or reject the translations. If the reviewer rejects the translation, then it goes back to the translator for correction. This back-and-forth process continues until both the reviewer and translator agree on a final translation for every segment.

Depending on how you are using WorldServer, this cycle may be defined inside of the WorldServer workflow (with separate Translate and Review steps with a cycle between them), or this cycle can be done within a single step where the translator and reviewer are exchanging the data back and forth.

Segment status is used to indicate whether translation work needs to be done an a segment. If the segment status is Reviewed, no work needs to be done. If the segment has no status, or the status is Rejected or Pending Review, it needs attention.

For any translation workflow, there must be a segmentation and leverage step, which is accomplished with the Segment Asset automatic action. During this process, target segments with 100% or ICE matches from the translation memory are automatically populated.

The Segment Asset action can be configured to set the status for these ICE and 100% matches. You can set the Set Translation Statuses? and Maximum Translation Status for 100% Matches arguments to the Segment Asset automatic action to Yes and Pending, respectively, and ICE match segments will be set to Reviewed and 100% match segments and autotranslated segments will be set to Pending Review when the asset is first segmented. This action allows these segments to flow through the normal translation review process correctly. Without an action like this, all segments begin with No Status when you open a file in the Browser Workbench.
Note: In live translation memory mode, this status is assigned, without the need for an automatic action, during the initial population of the target segments. When the translation memory is leveraged, and assets are pre-populated with best-matching ICE and 100% matches, TM entry review statuses are propagated back to the populated asset’s segments. The relationship between the status of the entry in the translation memory and the status the segment in the workbench is pre-populated with when the asset is opened is shown in this table:
TM Entry Status Leverage Score Segment Translation Status Set To…
Reviewed ICE Reviewed
Reviewed 100% None (configurable)

Pending Review (by default)

Reviewed (configurable but not recommended)

Pending Review 100% Pending Review
Note: There is a TM property with which you can reduce score of unreviewed matches to below 100%.
Rejected 100% Rejected
Note: See the Live Translation Memory Mode topic for information on a TM property with which you can reduce the score of unreviewed matches to below 100%.
Pending Review ICE Pending Review
Note: This is not the default behavior, and must be configured in tm.properties.
For information about live translation mode, see the Live Translation Memory Mode online help topic.

If you exchange translation kits (Project and Return Packages) with Studio, WorldServer converts segment translation status values as follows:

When you export a translation kit (WorldServer project package) from WorldServer
SDL WorldServer SDL Trados Studio 2011
No Status (empty target) Not Translated
No Status (non-empty target) Draft
Pending Review Translated
Reviewed Translation Approved
Rejected Translation Rejected
When you import a translation kit (WorldServer return package) from Studio
SDL Trados Studio 2011 SDL WorldServer
Not Translated No Status
Draft No Status
Translated Pending Review
Translation Approved Reviewed
Translation Rejected Rejected
Sign-off Rejected Rejected
Signed Off Reviewed

The simplest translation and review case is one in which there is a WorldServer workflow that includes separate steps for Translate and Review. Under this model, the Translate step would be assigned to the appropriate translator who would perform their work. After the translator completes work on a task, the task would then flow to the appropriate reviewer. The reviewer would make a determination as to whether the translation was approved or not and would either reject the work, sending it back to the translator, or approve the work, letting it proceed through the workflow.

When the translator is assigned a task, the asset is likely to have segments in the following states:

The primary job of the translator is to work through all of the untranslated segments and provide translations for them.

During this process, the translator may find some segments that they have questions about and are unsure how to translate. For example, they may be unsure of the meaning of a word in the source segment or have a multiple choices on how to translate the segment. For these segments, the translator needs to collaborate with the project manager or someone similar to discuss these segments and come up with a proposed translation. This can be handled using WorldServer and workflows, by routing the task back to someone who can answer the questions, and having the task go back and forth between that person and the translator until a suitable answer is achieved. Another possibility is that all of this communication happens outside of WorldServer (for example, using email). The end result is that the translator ultimately comes up with a translation for the segment.

By the time the translator is done with his or her work, every segment should have a proposed translation. The translator would then set all of the segments he or she has translated to Pending Review (using the Tools > Translation Status menu) and “complete” the task, sending the work onto the reviewer.

When the reviewer is first assigned a task, the asset is likely to have segments in the following states:

The job of the reviewer is to go through all of the segments that need to be reviewed and either accept them as final or reject them. A reviewer who rejects a segment will probably provide some reason for rejecting the segment or will actually provide a new suggestion for the translation. After the reviewer has gone through all of the segments, he or she completes the task. If there are any segments that have been rejected, the task should go back to the translator.

When the translator is reassigned the task, the asset is likely to have segments in the following states:

For each rejected translation, the translator can accept the reviewer's proposed changes or come up with a new translation for the segment based on the comments from the reviewer. In either case, the translator completes the task, sending it to the reviewer for their approval once again. This back-and-forth process continues until there are no outstanding issues and the translation is accepted.

Alternatively, rather than using the WorldServer workflow to pass tasks between a translator and reviewer, this process may be performed “outside of WorldServer” by simply passing a translation kit back and forth. For example, when the translator has completed the initial task, he or she could export a new XLZ file, passing it to the reviewer, without going through WorldServer. The reviewer could import the XLZ file, perform the review, and then export a new XLZ. This process could go back and forth until a final translation is agreed upon at which point the translation kit is uploaded to WorldServer and the workflow is once again used.

To control who can alter statuses in the translation and review workflow, you can use the Step Type option. See Using Step Type to Control Status.