#628 Manage different states for segments

[Didier Briel]

On behalf on Martin Kempf in the Yahoo list
(http://tech.groups.yahoo.com/group/OmegaT/message/18495)
<<
There should be more that two states for a segment, “translated” or “untranslated”. There would be for instance “to be reviewed” or “machine translation” or “terms to be researched”. These states would be mainly identified by a coloured border on the left: red for untranslated, orange for a rough or machine translation, yellow for “terms to be researched”, blue for proofreading necessary, then green for complete, verified, certified translation!

It would be nice to be able to modify the display for these different states, for instance display only blue, or everything but the green, etc.
Possibility the colours could even be customised, but it makes it more difficult if the project is move from one computer to another.

I imagine that it could be close to tags in Thunderbird, or close to OmegaT’s Team module from a programming point of view.

Didier pointed that it shouldn’t become a “clickodrome”, so possibly there are a number of automatic things to setup. For instance, if it’s a machine translation, the state is the right one from the start, i.e., orange. Or if one translates, then it becomes green, and if one has doubts on a term, the colour is changed manually, possibly via a keyboard shortcut.
>>

Didier
[#516]
[#765]
[#948]

[Kos Ivantsov]

[#948] (and its duplicate [#516]) and [#765] are closely related RFE's

[Briac Pilpré]

There is a very tentative implementation of this feature on the branch topic/briacp/segments-states where the state of a segment can be changed by right-clicking on it. The segment states are currently stored as props (<prop type="x-omegat-state">DRAFT</prop>) in the TMX file.

[msoutopico]

Here come a few suggestions, in case they can help produce a better functionality.

Assigning status when committing

I would expect the following behaviour: the user selects (or it's already selected when the project is loaded) the status that needs to be applied in the task to be carried out. For example, the user is a reviewer and receives a project where all segments should be translated (and have status "Translated"). The reviewer must assign status "Reviewed" to segments they reviews and that status is assigned to every segment they commit. In other words, committing assigns the status. It should be possible of course to assign any status manually, through right-clicking the segment and selecting the status from a drop-down menu or something like that.

Committing shortcut

Now Enter and Ctrl+Enter do move forward to the next and move backwards, and both register the translation, but probably it would be a good idea not to link leaving the segment and assigning the status. The status should be explicitly assigned, so that it's not assigned by mistake or when the user needs to check something somewhere else but is not done yet with the previous segment. A shortcut like Alt+Enter would be ideal to assign the (currently assigned) status and move forward to the next segment that has the inmediately lower status (or any lower status, perhaps an option applies here to cover all needs).

Statuses hierarchy

I think it's useful if we can use statuses in a hierarchical way, so that a project goes from lower rank to higher ranks. That helps to move through the project to the next segment that needs attention. If a reviewer is applying the "Reviewed" status, committing a segment should move forward to the next segment that has not been reviewed yet (which might have status "Translated"), jumping over any other reviewed ones. That allows a reviewer to go back and forth to different parts of the project (e.g. to see different contexts of a group of repetitions) and they are not forced to work in order, as it happens now.

Customization of status names

It would be great if it was possible to customize the list of statuses (or states, not sure what is the right term). For example, the default list of draft/translated/reviewed/final (saved in the user config folder), could be edited or overwritten by a project-bound list (saved in a properties file included in the project). For example, translated/reconciled/verified/revised/signed-off. Sometimes there might be a need to have more states, and sometimes other names already exist in established workflows so it can be confusing for users if they have to mentally map between two statuses all the time. For these two reasons, customization would be great.

Colors

Color borders on the left that don't conflict with background colors sound great. A cell on the left with a background color and some short text inside, such as MT (machine translation), ICE (in-context exact), ET (match from /tm/enforce), AT (match from /tm/auto), etc. would be even more useful. It would be great if both colors and the acronym could be customized (and project-bound, overwriting global settings).

Filtering

It would be extremely useful if the status could be used to filter in the OmegaT editor, e.g. if a user wants to see only segments with status "Reviewed" (which would hide Translated, Final, etc.). Or if they want to work on statuses lower than, say, Reviewed (that is, Transted, Draft, etc, anything below Reviewed). Any further operations like search and replace should affect only the segments that are being displayed (not the hidden ones).

Connnection with formats that accept status

For example, XLIFF. It would be great if these OmegaT statuses could be reflected in the target files when the file format is XLIFF, either in the <target>'s state attribute or the <trans-unit>'s approved attribute.

Stastistics

One last very important feature, perhaps related to filtering: segment statuses should entail that the statistics also provide information about different statuses, or at least about the status currently assigned. One of the main gaps of OmegaT for reviewers is that it's impossible to know how much progress they have made (unless they work sequentially, which doesn't have to be the case). Since the statistics only differentiate between translated and remaining, and since the starting point for a reviewer is that all segments are already translated, there's no way to track their work.

[msoutopico]

Added info about statistics to my previous post.