This page describes a proposal to AJAXify the Pootle editor, in order to get a much pleasant and faster translation experience. Here we will analyze the current situation and suggest what could be done and how can it be achieved.
Pootle's editor is powerful in the way that it displays useful information about the current unit to the translator. Anyhow, navigation and submission between units is not as fast as a user would want to, as it requires doing an
POST request each time the user clicks on the
This is far from ideal – makes users wait and they may feel frustrated about the way they are working. As of today, only a single translation can be submitted/suggested at a time, so this is a limitation Pootle has that makes its users work slower.
Ideally translators should be able to work fast (ie, navigate fast between units) at the same time they get the most powerful features Pootle currently provides, including terminology suggestions, suggestions made by other users, quality checks, alternative source language texts and other comments and context information.
Navigation should be easily done with the keyboard, similar to what it is done in Virtaal. Going to a particular unit by clicking with the mouse must be possible too.
The current unit should always have the most relevant information, the same as it's displayed right now. The remaining units on screen should only display source and target texts.
Translators should be able to toggle information being displayed for the current unit that may not be relevant for them, as shown in the following table:
|Suggestions||Alternative Source Languages|
|From other users||Lang1|
|From MT services||Lang2|
|From a TM||Langn|
When a unit is edited (the translation, the comments or the status) and the translator moves to the next unit by clicking the
Submit button, or with accesskeys, Pootle should automatically save the changes to the
When the translator wants to move to the previous unit and the contents have been edited, TODO
Translators also want to change working scenarios fast, so providing a direct path from the editor for filtering the work is also important. Usual filtering options may include (but may not be limited to) the following:
|Filter by Status||Filter by Quality Checks|
|All (translated + incomplete)||accelerators|
|Incomplete (untranslated + fuzzy)||escapes|
|Units with suggestions||…|
Choosing a filtering option should present the translator with a list of the matching units, with the option to have them displayed in context and with easy navigation through the matched units.
There should be a
Show me more context option on each unit which would display
n more units for context purposes. These units must be visually distinct in order to differentiate that those units don't represent the set of filtered units.
There are several implementation options in order to get the proposed editor.
While it is ideal to have all the stuff described here working right now, we should aim to achieve things step by step.
POST) data to a unit
iin the client data structure
nview units for