Enhancing Translation Workflow

Warning!

These are some thoughts about enhancing the translation workflow for the CT-Project - nothing official Torben 15:07, 30 April 2011 (PDT)

Description of the current translation workflow

The documentation team publishes an article in the knowledge base and posts a link here.
A translator stumbles across the article and posts the target url here and /or here to indicate the beginning of the translation process.
When the article is translated the translator indicates it by posting the target url here and/or here.
A second translator (Editor) figures out by magical means that an article has been translated and needs editing. The editor edits the article. (This step is not documented).
A Linden is being informed that a translated and edited article is ready to be published. This is done via the Linden Poke Stick (not yet available so we use email). The localized article gets published which is perhaps documented here and/or here.

The documentation team updates an article in the knowledge base.
A translator stumbles over the updated article and updates the localized version of the article. (No workflow/No documentation)
A second translator (Editor) finds the updated version or is somehow informed of the update and edits the localized article version. (No workflow/No documentation)
A Linden is being informed that a updated and reedited article is ready to be republished. The localized article gets republished. (No workflow besides above mentioned poke stick/No documentation)

The workflow is incomplete for new articles and nonexistent for article updates.
- Translators and Editors need some basic wiki syntax skills to follow the workflow - the process for editing is not defined.
- Copying and pasting wiki code to push an article through the workflow steps is time consuming, especially for those users that don't work with wiki regularely.
The single steps of the workflow are not documented. While it is possible to figure out who did which changes via the page history, this will become more and more complicated with each article added (so far 86 edits in 7 weeks).
- At some point it will be impossible to figure out who put the swear words into that popular article. (I know this is not exactly true as Lithium also allows to browse the edit history. Still it would make more sense to have a central place to document the translation workflow.)

There is no way to find out when an article has been updated but comparing release dates in the knowledge base and manually comparing the english article with the localized version.
- This is a major cause of frustration for volunteers and Lindens alike.
- Basically all localized articles are outdated. We have tried to keep articles up-to-date on the old platform and the wiki. This led to absurd tables and versioning templates which rendered useless by the sheer amount of articles. The current version of keeping articles up-to-date (CT_Project_Overview/1#0) gives a good impression of the last useless attempt.

For best results we need defined workflows for translations and updates. The workflow should not require extra knowledge and should be as easy to follow as possible.
Documentation should happen automatically where possible.
Translators, Editors and Lindens should have means to easily be informed of changes and updates.
We already use/have used JIRA for community translations. With little adjustments it would be possible to implement a solid workflow, have all changes documented and keep informed.

The documentation team publishes a new article and creates a CT-issue.
- The CT-issue contains a link to the knowledge base article, a deadline (if applicable) and sets the priority (Time-Sensitive for important articles with deadlines, Important for articles that need to be published fast and Trivial for all other articles)
A translator creates a sub-task for his/her language and starts the translation.
The sub-task is pushed through the workflow (see translation workflow)
When all sub-tasks are closed (all localized articles are published) the CT-issue is set to Published

The documentation team updates an article and sets the status of the linked CT-issue and it´s sub-tasks to Needs Update.
A translator picks up the updated article, updates the localized version and the sub-task is pushed through the workflow again.
When all sub-tasks are closed (all localized articles are updated) the CT-issue is set to Published

Ready for Translation:Default status (Resolution Unresolved)
- Transitions:
  - Start Translation (Should assign the issue to current user and change status to Translation in Progress)
Translation in Progress (Resolution Unresolved)
- Transitions:
  - Translated (Should unassign the issue and change status to Translated)
  - Set on Hold (If Linden attention is needed, change status to On Hold and Resolution to Incomplete)
  - Abort Translation(Status: Ready for Translation;Unassigned;Resolution: Unresolved)
Translated
- Transitions:
  - Start Editing (Should assign the issue to current user and change status to Editing in Progress)
Editing in Progress
- Transitions:
  - Edited (Should assign the issue to a Linden;Status:Ready to Publish)
  - Set on Hold (If Linden attention is needed, change status to On Hold and Resolution to Incomplete)
  - Abort Editing (Status: Translated; Unassigned; Resolution: Unresolved)
Ready to publish
- Transitions:
  - Published (Status:Published; Resolution:Released;Unassigned)
Published
- Transitions:
  - Update needed (Status:Needs Update; Resolution: Unresolved)
Needs Update
- Transitions:
  - Start Updating (Status: Translation in Progress; Assign to current user)
On Hold
- Transitions:
  - Continue Translation (set Status back to Translation in Progress)
  - Continue Editing (set Status back to Editing in Progress)

Translators:
- See CT-Project
- Create Sub-Tasks in CT-Project
- Transitions:
  - Start Translation
  - Translated
  - Abort Translation
  - Set on Hold
  - Continue Translation
  - Update needed
  - Start Updating
Editors:
- Same permissions as Translators and
- Transitions:
  - Start Editing
  - Edited
  - Abort Editing
  - Continue Editing
Lindens:
- The Allmighties should be the only ones for
- Transitions:
  - Published

While changing the CT-Project to the workflows and permissions described above it would make sense to think about the following:

Archive old CT-issues
Streamline CT components to the supported languages
- Remove obsolete components
- Add [Language] - Knowledge Base component
- Add [Language] - Viewer/Web Strings component
- Add [Language] - Miscellaneous
Put everything related to L10n and translations into the CT-Project
- Allow trusted users (those that can move issues between projects) to clone/move l10n issues to CT
- Allow Translators to create issues for l10n issues.
  - I alone have reported 210 issues of which more than 90 percent are l10n/translation issues. They are spread over the different projects and I tend to believe it would make sense to have them all at one place and also the number of bugs is nothing we´re proud of ;)