Table of Contents
Please see the screenshots below for basic explanations.
Detailed explanations, how the workflow system works
The translate5 basic workflow knows three workflow roles:
- translator (translator, if it is a translation task)
- proofreader reviewer (first or only editor),
- translatorCheck (second editor, if needed),
- and visitor (not part of the workflow chain; can only view content).
These workflow roles can be combined as needed. They can be used on their own or in combination with the others. Only "translatorCheck" always has to be combined with "proofreaderreviewer".
So you could
- only assign users to the role "translator"
- or only to "proofreaderreviewer"
- or only to "translator" and "proofreaderreviewer"
- or only to "proofreaderreviewer" and "translatorCheck"
- or to all three roles
Segment autostates created by the workflow roles
On editing a segment the segment gets an autostate, depending on the role of the user:
- Role independent:
- "blocked": segments which are not editable / translatable are marked as blocked by the import process.
- "not translated": non translated segments are set to this state by the import process.
- "translated": already translated segments are set to this state by the import process.
- "pretranslated": pre-translated segments, either pre-translated in translate5 (via configured language resources) or if an already translated segment is imported, some formats provide information if the segment was pre-translated in an external tool. Such segments are marked as "pretranslated" then too.
- "translated": if an untranslated segment will be translated, it is set to translated. This is the initial autostate of already translated segments for proofreading reviewing tasks.
- "translated auto": if an untranslated segment was translated by using the repetition editor in the frontend
"reviewed": if the proofreader reviewer modifies and saves a segment.
"reviewed auto" if the proofreader reviewer modifies and saves a segment by using the repetition editor.
"reviewed untouched" if all proofreaders reviewers are finishing the task, all segments not opened by proofreaders reviewers are getting automatically this autostate.
"reviewed unchanged" if a proofreader reviewer opens and saves a segment without modification.
"reviewed unchanged auto" if a proofreader reviewer opens and saves a segment without modification by using the repetition editor.
- "reviewed translator": if the translator opens and saves the segment, regardless if he changed anything.
- "reviewed translator auto": if the translator opens and saves the segment, regardless if he changed anything, triggered by repetition editor.
- Projectmanager (editing a segment without any workflow role)
"reviewed pm": if the pm modifies and saves a segment.
"reviewed pm auto" if the pm modifies and saves a segment by using the repetition editor.
"reviewed pm unchanged" if a pm opens and saves a segment without modification.
"reviewed pm unchanged auto" if a pm opens and saves a segment without modification by using the repetition editor.
- Since segments are readonly no autostate is changed
The translate5 basic workflow knows three workflow steps:
- "Translating" No Workflow (The initial workflow step. This workflow step is active when no users are associated to the task)
- Translation (1st step allocated by the role as an translator)
- "Proofreading" Review (2st step allocated by the role as an proofreaderreviewer)
- "checking of editing" Second Review (3nd Step allocated by the role as a translatorCheck)
It is possible to allocate only users with the role as an editor (proofreaderreviewer) to a task in the workflow - then the first and third workflow steps are omitted.
In general the used workflow steps are depending on the chosen user roles, so if no translation is needed, no translators are chosen, no translation step is performed.
The workflow step of a task changes if:
- All users of one role (other roles are not considered then) are finishing their workflow step (by setting the task to finish). The next step in the workflow chain is chosen.
- If a user association is added, changed or deleted, the combination of all user state and roles of that task is used to determine the workflow step of the task. This enables the PM to start an untranslated task in the "translator checkSecond Review" step, even if this makes no sense.
The valid status combinations to match a workflow step are:
|translation||proofreading review (lectoringreviewing)||translator checksecound review|
|role translator has status open||role translator has status finish||role translator has status finish|
|role lector has reviewer has status waiting||role lector reviewer has status open||role lector has reviewer has status finish|
|role translator_check translatorCheck has status waiting||role translator_check translatorCheck has status waiting||role translator_check translatorCheck has status open|
The role as a visitor is not allocated to any workflow step. It has no function in the workflow chain.
A user with the role as a project manager is able to open a task in the workflow for viewing at any time. He is able to edit any task, which is not currently opened by another user.
Workflow Status of Task Allocations
Each allocation of a user with a role to a workflow step has a workflow status. The translate5 basic workflow knows the following workflow statuses:
- Open: The task can be currently processed by the user. For API usage use the value "open".
- Waiting: The user can process the task as soon as it is his turn in the workflow (he can view it, though). For API usage use the value "waiting".
- Finished: The user completed the processing of the task and thus cannot open it for processing anymore (he can view it, though). For API usage use the value "finished".
- Unconfirmed: The user first have to confirm the task before working on it. For API usage use the value "unconfirmed".
To confirm a task, just open the userState with state "edit". That implies if the user should open the task for reading only before confirmation, the userState "view" should be used.
The project manager is able to change each task allocation for each user at any time.
For the workflow chain see the corresponding document.
Via API jobs (task user associations) can be created to set-up the workflow in a task.
The following workflow step values has to be used via API:
|Step in the UI / documentation||value to be used via API|
The values for the status fields are straight forward as in the documentation above, but all in lower case: