The localization interface is cumbersome. Even it allows to translate pages and make them look them good, it needs a lot of non-needed work to reach this goal. Newbies need a lot of mentoring and most of them are quickly discouraged.
Performing simple tasks like editorial review is a pain.
As part of the plan to reach 1000 wiki editors / month in 2014, we need to make the use of the l10n interface much more easy, so that we stop loosing as many wannabe-translators. At the same time, it will increase their productivity and the quality of their work: more docs participates in the increase Firefox/Firefox OS marketshare company goals.
The increase in l10n community resulting in these better things will build over the months. To reach a number significant enough to allow us to reach the 1000 editors/month goal, we need this asap. Given we are in June and the amount of work to be done, we set a realistic deadline for September 30th, 2014. Past this deadline, fixing this bug won't have a significant impact to reach the goal we were given.
Goal
- Improve L10n contribution levels and retention rates by making the user experience less tedious.
- This will help us reach our 1,000 editors per month goal by boosting our contributions across multiple locales. We estimate we will gain approximately 5-7% of our new L10n editors through improved retention of users.
- Non-goal: Completely revamp the localization UX.
Risk
- Low. Even if it doesn't lead to improve the participation significantly, it will improve the productivity of current edits.
- It is a collection of bugs that can be done independently. Partially done is already useful.
Bugs
| 776048 | Tags with diacritics and tags without diacritics are mixed. | High |
| This lead to erroneous tags spontaneously added to thousand of page. A simple orthographic mistake by a casual editor propagates very quickly to a lot of articles. Non-mistakes also lead to incorrect tags added.
This bug also shows blatantly that l10n is an afterthought and not a strong commitment. | ||
| 777434 | Mechanism to hide the English text. | Critical |
| Translations happens in different phases, and in different ways. Some people copy the English text in the translated area and translate it. Similarly, some people are performing the editorial review of the translated text and do not need the English text.
More, in both these use cases, the display of the English text makes the translated area very small and make it very difficult to perform the task. A button (or other widget) to toggle the side display of the English original will solve both problem. | ||
| 777988 | Translate CKEditor | Medium |
| CKEditor buttons are labelled in English. They should be in the language of the interface | ||
| ? | CKEditor should spellcheck by default | Critical |
| A good deal of the editorial reviews contributions are basic orthographic mistakes that would have tagged by a spellchecker. This is especially the case when we get young editors. | ||
| ? | Editor box should use Firefox spellcheckers. | High |
| Regular editors have heavily configured dictionaries: it contains name of Mozilla products and often used terminology. Default spellcheckers are far far less good and impair the speed of translation. | ||
| 777988 | Add a link to edit the English version of the document (in the translation interface) | Medium |
| When translating a document we also carefully read the English original. We often find typos and similar problems. To get to the English edition interface is cumbersome, so we often just don't fix the typo. A link to open the English edition interface will solve this.
Warning: we don't want the ability to edit the English page inside the translation interface; this leads to numerous errors where the English version is replaced by the translated one by mistake. | ||
| 968153 | TOC dropbox doesn't work in edition interface | Critical |
| Basic bug | ||
| 899665 | Add the opportunity for a translator to subscribe to the English document in the translation interface | Critical |
| We need this on the translation interface (a checkbox near the bottom?). We should make it clear that it is a way to keep the translation up-to-date! | ||
| 1024649 | Diff picker for the English version. | Critical |
| As soon as an edition is done, the diff picker switch to it. But editors sometimes fix a typo or another problem, and not necessary the whole diff. It is important that they can get the diff of what they want to really edit. | ||
| ? | Bottom of the English and Translated sides are not aligned | High |
| There are common widgets at the bottom of the English and translated sides of the translation interface, like the tag widgets. This make it very complex to compare and fix any error (like a different set of tags). By aligning what is after the text, it will ease this. | ||
| 1002059 | Ability to display the source code on the English side of the translation interface | Critical |
| Part of the page depends on "class" and "style" attribute. The only way to know which ones to add to the translated articles is to look at the source code of the English page. This is trivial in CKEditor, but very complex on the English side (which is not editable). We need a widget to toggle the view of this side to display the HTML source.
Warning: we don't want the ability to edit the English page inside the translation interface; this leads to numerous errors where the English version is replaced by the translated one by mistake. | ||
User Stories
Localizer
- Make the interface convenient to use.
- While the side-by-side comparison of English and translated content is useful, the lost width makes editing difficult and makes it hard to judge what the content will actually look like. A solution needs to be found.
Notes
- There's a lot of low-hanging fruit, as well as some larger problems that need to be addressed.