start

# Process Information and its management

## About Process: Players, Phases, Rights and Workflows

Efficient work on localisation - including strong reduction of the work-load and higher quality translations by translators with little experience - can be achieved by following a clear process for localisation within a well defined workflow.

Process and workflow can be defined and implemented using standard data formats for localisation, accompanied by translation management software capable of managing this process and enforcing workflow.

The use of specific workflows in localisation - in which the different steps that must be followed by a translation work are clear, and in which information is kept on what is happening at each step of the process – lead to:

- Automatisation of management tasks for localisation.
- Increase on the information available to localisation managers, giving them tighter control of the projects.
- Strong reduction of the amount of work needed in the localisation process.

The goal of storing this information is

- To reduce the work by knowing what work was done in the prior phases (for example, a reviewer only needs to review translations done after the file was last reviewed).
- To understand if new processes need to be performed (for example, if glossary information was included in an XLIFF file, and we can see that the glossary has been upgraded, then we need to run the process again to ensure that glossary information in the XLIFF file is correct).

A complete definition of the localisation process requires:

1. Definition of the roles that different players might play in translation.
2. Specification of the phases through which a translation effort might go through, considering multiple possible workflows.
3. Specification of different workflows; or of the components that these workflows are built with, including the rights of the different players to translate, advise, modify or approve a translation.
4. The above point requires the clear definition of the different possible rights that each player might have.

### The Roles

The roles that the different players might play in translation are:

1. Translator
2. Reviewer
3. Approver
4. Terminology manager
5. Translation memory manager

### Phases

A phase is a period of time in which one single type of operation is performed on a set of translatable data. It might be a long phase (such as in translating all the contents) or a very short phase (approving the contents for use). A phase is never interrupted by other phases, as soon as a new phase starts (for example review after translation), the prior phase is terminated, even if later a similar phase (more translation) might be started.

The different roles participate in specific phases:

1. A translator has as main role translating files from scratch (translation phase), but in many cases also has a role integrating proposals made by a non-authoritative reviewer who has made recommendations, which are then studied and edited by the translator (review edit phase).
2. A reviewer analyses the translation made by a translator, and either edits the translation (authoritative review phase) or makes recommendations on possible changes to the translation, which will be returned to the translator for his editing (non-authoritative review phase).
3. An approver (translation manager) indicates that the translation is finished and ready to be sent to the upstream customer or used to build a computer application (approval phase).
4. Terminology managers and Translation managers are not part of the real workflow cycle for a given translator, their role is to ensure that different projects will include and use correct terminology, or that the quality of the translation memory and its use are the desired ones.

This leads to a list of phases that might not be exhaustive, but so far covers all the manual phases presently considered in the workflows that we have analysed or know of. The list is:

1. Translation
2. Authoritative review
3. Non-authoritative review
4. Review editing
5. Approval

In addition to these manual phases, there are other processes that can add information to the translation. Some of them can be considered clearly as phases, while other are computer-assisted translation tools which support the work within a phase. These processes include:

1. Inclusion of translation memory data or automatic translations in the target fields of the translatable file.
2. Inclusion of translation memory data or automatic translations as comments or recommendations in the translatable file.
3. Inclusion of glossary data in the translatable file (as additional information), including words for which a translation is available and words for which the translation will have to be stored later as terminology (words identified as terminology for which no translation is yet available).
4. Automatic review of a translation, offering results directly to the translator on a user interface.
5. Automatic review of a translation, storing the results as comments in the translatable file.
6. Extraction of new translation memory data after the translation is approved.
7. Extraction of new terminology data after the translation is approved.

The first process directly affects the target field of the translatable files, and should definitely be considered as a phase, as it requires review by the translator or reviewer.

Processes that add information to the file are important to track when they are done in advance of the moment in which they need to be used. As an example, inclusion of TM and Glossary can be done as low priority computer processes that take place whenever the computer has time, but... the data might become obsolete if new TM information becomes available, requiring repetition of the process before the files are handed to the translator. Processes of enrichment of the translatable data should also be considered as phases.

The automatic review of translations - when used for showing data on the quality of the translation to the translator through user interface - is just part of the translation process, operating within the translation phase, and therefore cannot be a phase by itself. If the results are stored in the file itself, in order to pass the information from translator to reviewer or from reviewer to approver, then this could be considered as a phase.

Extraction of translation memory data or terminology from translated files does not really affect the localisation process itself, and should not be considered as phases in the localisation process.

Adding this information about automatic processes, a more complete list of phases would include:

1. Enrichment of localisable material.
2. Automatic translation
3. Translation
4. Automatic review
5. Authoritative review
6. Non-authoritative review
7. Review editing
8. Approval

A workflow is the combination (lineal or in parallel) of one or more of these phases. A given phase can be repeated inside a specific workflow (for example, a translation might be reviewed by several reviewers at the same time).

### Rights

A workflow not only gives the different steps that a translation must follow, in order to be considered complete and ready for the customer, it also needs to define which rights are given to each role.

For example, a translator working alone has in his/her workflow only one translation phase, and no more, but he must have the right to approve the translation, as a non-approved translation cannot be sent to the customer. In a more complex workflow, the translator might only have the right to create and edit the translations, but not of approving them. The difference between an authoritative reviewer and a non-authoritative one is simply having or not the right of editing the translation. A non-authoritative reviewer only has the right to add comments, but might not touch the translation.

What are the rights that might be considered in workflows?

1. The first and more important right is having the possibility of creating or editing a translation (modifying the target).
2. The second right is adding comments (reviews and others) to the translation, including grading its quality.
3. The third important right is approving the translation.
4. Other rights might be related to the power of the translator in more advanced systems. Such powers might include over-riding the obligation of using terminology that is provided or other quality tests that can detect possible technical problems in the translation.

### Workflows

A workflow is simply a sequence of phases that translatable content will follow during its translation or localisation. Each phase is assigned to a player, together with the rights that this player has in the work process.

Workflows might be as simple as one single translation phase by a translator who has the right to approve, or quite complex, requiring several phases of review, some of them mechanical and other performed by human reviewers.

A flexible workflow definition system must allow the administrator to define the phases that the process must follow, then assign rights to each type of player. Allowing choosing between a number of predefined workflows strongly simplifies the work of the administrator.

Examples of workflows might be:

1. Single Translator. An isolated translator translates and returns translation to customer.
2. Translator + Authoritative reviewer. Translator translates and sends to reviewer. Reviewer modifies translations and sends translation to customer.
3. Translator + Non-authoritative reviewer + Editing. Translator translates. Reviewer makes recommendations. Translator edits and sends to customer.

Translator + Non-authoritative reviewer + Editing + Approver. Translator translates. Reviewer makes recommendations Translator edits. Approver approves and sends to customer.

## Requirements for a Translation Management System that manages workflows

The implementation of the framework described above requires a computer system capable of the following management tasks:

1. Keeping track of the phases a piece of translatable contents has gone through, including the present state of the content (the last or present phase).
2. Organising a translation team by specifying the workflow and designating specific human resources to the the different tasks, assigning to them the role and rights that are necessary to perform the task assigned to them.
3. Defining the system for delegating rights. For example, the approver (normally a team coordinator) can include translators and reviewers in a project... but might also delegate to a translator the possibility of adding new non-authoritative reviewers who will check his/her work.
4. Assigning specific tasks to the different players, or allowing them to select specific tasks that they want to perform.

On top of these features, the system should also perform other computer-assisted translation functions, such as glossary and translation memory management, testing, statistics and definition and follow up of goals for teams. The data required to manage these functions includes:

1. Data on present and past phases, including which translations correspond the each phase.
2. Data on the chosen workflow for each project, defining the sequence of phases.
3. Data on roles and rights of all the members of each team.

If we define a set of translatable files that need to be translated to a given language as a “project”, the last two blocks of data reference the whole project, while the first block corresponds to each individual file. In this last case, keeping process information in the files themselves allows steps in the translation process that do not necessarily have to pass through the translation management system (such as a translator handing a file directly to a reviewer).

The only standard file format that has the necessary structures to handle process is the XLIFF format. Inside its XML structures it allows for the definition of phases and the assignment of a given message to a specific phase. This permit maintaining historical information about all the steps (phases) that the file has gone through. This information will be used by the translation management system to follow the required workflow for that project. The next section defines how the process data mentioned above can be stored in XLIFF files.