Page tree
Skip to end of metadata
Go to start of metadata

Please see the screenshots below for basic explanations.


Detailed explanations, how the workflow system works

If a user opened a task for editing, no other user can edit it as long as the session of the editing user is valid and he does not close the task.

Workflow Roles

The translate5 basic workflow knows three workflow roles:

  • translator (translator, if it is a translation task)
  • 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 "reviewer".

So you could

  • only assign users to the role "translator"
  • or only to "reviewer"
  • or only to "translator" and "reviewer"
  • or only to "reviewer" 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.
  • translator
    • "translated": if an untranslated segment will be translated, it is set to translated. This is the initial autostate of already translated segments for reviewing tasks.
    • "translated auto": if an untranslated segment was translated by using the repetition editor in the frontend
  • reviewer

    • "reviewed": if the reviewer modifies and saves a segment.

    • "reviewed auto" if the reviewer modifies and saves a segment by using the repetition editor.

    • "reviewed untouched" if all reviewers are finishing the task, all segments not opened by reviewers are getting automatically this autostate.

    • "reviewed unchanged" if a reviewer opens and saves a segment without modification.

    • "reviewed unchanged auto" if a reviewer opens and saves a segment without modification by using the repetition editor.

  • translatorCheck
    • "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.

  • visitor
    • Since segments are readonly no autostate is changed

Workflow Steps

The translate5 basic workflow knows three workflow steps:

  • 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)
  • Review (2st step allocated by the role as an reviewer)
  • Second Review (3nd Step allocated by the role as a translatorCheck)

It is possible to allocate only users with the role as an editor (reviewer) 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 "Second Review" step, even if this makes no sense.

The valid status combinations to match a workflow step are:

translationreview (reviewing)secound review
role translator has status openrole translator has status finishrole translator has status finish
role reviewer has status waitingrole reviewer has status openrole reviewer has status finish
role translatorCheck has status waitingrole translatorCheck has status waitingrole 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.

Workflow Status of Tasks

Regardless of workflow status of task allocations, a task in itself has a status in the workflow. This status is affecting the task allocations:

  • Open: The task can potentially be edited by users.
  • In process: A user is currently editing this task. Thus, it is inaccessible to all other users for processing, but open for viewing.
  • End: The project manager finished the task. Regardless of the status of their task allocations, the users are not able to edit the task anymore.

Workflow Chain

For the workflow chain see the corresponding document.

  • No labels

1 Comment

  1. Aleksandar Mitrev Please rework this page according to the changed roles and autostates.