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:
-
Some segments will have been pre-translated with ICE matches. Normally,
the translator can ignore these segments altogether.
-
Some segments will have been pre-translated with 100% matches and
autotranslated segments. Depending on the business process being
used, the translator may also ignore these segments altogether or
make any appropriate changes.
-
Many segments will have no existing translation (although may have
suggested translation memory matches).
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 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:
-
Some segments will have been populated with ICE matches. Normally,
the reviewer can ignore these segments altogether. These segments
will have a translation status of
Reviewed.
-
Some segments will have been populated with 100% matches and autotranslated
segments. Depending on the business process being used, the reviewer
likely needs to review and approve these segments. These segments
will have a translation status of
Pending Review.
-
Many segments that have manual translations provided by the translator.
These segments will have a translation status of
Pending Review.
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:
-
Most segments will have passed review. The translator can ignore
these segments.
-
Some segments might have been rejected by the reviewer, and will
have a translation status of
Rejected.
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 and Workflow Phase to Group Steps.