841771 - Localizers should be able to save progress in a more obvious way

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Localization, enhancement, P2)

Description

[John Karahalis [:openjck]]

What problems would this solve?
===============================
Some localizers like to stop working part of the way through a translation. Perhaps this is because localizing an entire page can take so long.

I often see pages that are partially translated and was recently asked by a contributor how best to save a partial translation.

We do automatically save drafts, but it appears this is not enough. This is invisible. The user does not know that drafts are automatically being saved, as evidenced by the many partial translations out there.

Who would use this?
===================
Some (maybe even most) localizers.

What would users see?
=====================
Not exactly sure. Maybe a button marked "Save progress".

What would users do? What would happen as a result?
===================================================
If we go with the "Save progress" route, maybe clicking this button would store the progress of the translation on the server but not publish that progress to readers. At any point, the same localizer (or another localizer) could come along and pick up where that progress left off.

By storing this progress on the server, two things become possible:

1. The localizer could continue his work on another computer
2. Any editor could continue the work that was started by the original localizer

Is there anything else we should know?
======================================

Comment 1

[John Karahalis [:openjck]]

What do you think, guys?

Comment 2

[David Bruant]

In the normal editor, there is a "save and continue" button. Could that work?

Comment 3

[John Karahalis [:openjck]]

In comment 0, I was thinking about a feature that would only reveal the partial translation to editors. When the translation is complete, the whole thing would be visible to readers. The "Save and Continue" button would not solve that problem, because it would make the translation available to readers before it's finished.

Comment 4

[karabajic]

Here are some projects that tried to address translation UX/UI and translations workflow. It might be a good start to review some of their findings and try to incorporate them into Kuma translation workflow and UI. 

Mediawiki: Very good and extensive research done. Check following links. 

http://www.mediawiki.org/wiki/Translation_UX

http://www.mediawiki.org/wiki/File:Ux-Translate_user_workflow_design.pdf

http://www.mediawiki.org/wiki/Translation_UX/Development_plan

Drupal Translation Management Tool:

Job Overview: UI Implementation
http://drupal.org/node/1681012

Translation Management Tool Module Home Page:
http://drupal.org/project/tmgmt

Wordpress Multilingual: 

Translation Analytics Plugin: 
http://wpml.org/documentation/translating-your-contents/translation-analytics-plugin/

Comment 5

[John Karahalis [:openjck]]

This looks great! Does anything stand out as especially applicable for MDN? Which of these ideas do you think could most improve our localization workflow as it applies to this bug?

Comment 6

[karabajic]

Attachment: Translation Workflow | UI Prototype

Attached is the translation prototype mockup addressing issues reported by users. It is a hybrid of Kuma and some of the features found on mediawiki and drupal projects translation UX/UI and translation workflow mentioned in the comment 4. 

Improvements address following:

1. Bug 811056 - https://bugzilla.mozilla.org/show_bug.cgi?id=811056
2. This bug
3. Consistent UI for both editors of original (approved) document and translators
4. Granularity - break down parts of the page according to page structure - following page layout/DOM elements 
5. Side by Side editing - Presently, original is displayed together with translation next to one another and as an entire document (usability of translating long pages, mobile devices)
6. Visualization of the progress - both whole page as well as sections and indicate workflow state 
7. Create child pages, page history, find relevant pages translated as well as hierarchy, find all translated pages of original document
8. Provide Help for users - global translation guidelines as well as help on particular features/function within translation/editing environment
9. Page Status - Clearly indicate status of original as well as translation with ability to edit/update it

Feedback needed as well as ideas on both editing workflow:
1. Translation workflow (draft, pending, approved, review and so on)
2. Workflow Permissions - who approves, reviews, changes page status, etc.

Comment 7

[Florian Scholz (Open Web Docs)]

Sorry, overhauling our current l10n system is not going to happen any time soon.