#516 Allow unconfirmed translations

[Anonymous]

I would like to see OmegaT distinguish between translations that the user is not quite satisfied with (unconfirmed) and that the translation is satisfied with (normal, or so-called confirmed). There should be only two levels of confirmation, namely normal (not marked as unconfirmed) and unconfirmed (marked as unconfirmed).

1. Just as we currently have the [Fuzzy] marker that adds text to the actual translation, so too can we have an [Unconfirmed] marker that consists of a piece of text that is added to the actual target text.

Then we don't have to figure out a way to deal with unconfirmed segments in the fuzzy matching and in the internal segment mapping. Unconfirmed segments may even accidently end up in a user's or client's TM, but it won't matter because they'll be clearly labelled "unconfirmed" in the segment itself.

It is a little geeky, but so is [Fuzzy]. A user can then change a segment's confirmation status manually if he wants to, and he can easily do searches for unconfirmed segments even in TM viewers that do not support additional TMX features that may normally be used for state of confirmation.

2. Just as with [Fuzzy], the translator should be able to specify what he wants as his unconfirmation marker.

3. There should be two ways for a segment to become unconfirmed or confirmed again. One way is manually, the other way is automatically.

3.1 Manually: In the active segment, press Shift+Ctrl+Enter. OmT then checks to see if the target text begins with [Unconfirmed]. If there is no [Unconfirmed] marker, OmT adds it. If there is an existing one, OmT removes it.

3.2 Automatically: Automatic unconfirming should take place only if the user activates Unconfirm Mode in a menu item. So OmT's default behaviour is to never add or remove [Unconfirmed] automatically. If the user enables Unconfirm Mode, then OmT marks a segment as unconfirmed or confirmed under certain circumstances automatically.

3.2.1 Automatically using Next/Previous: If Unconfirm Mode is enabled, Ctrl+N, Ctrl+U and Ctrl+P should go next and previous but should also cause a normal segment to be marked as unconfirmed. In this mode, Enter and Ctrl+Enter should do nothing to normal segments and change unconfirmed segments into normal (confirmed) segments.

3.2.2 Optional (if it is relatively simple to implement): Under certain circumstances OmT can always mark a segment as unconfirmed, eg when he made changes to a segment and then moves away from that segment by double-clicking another segment.

4. A tag validation should pick up whether there are unconfirmed segments.

5. An additional implementation to 3.1 above, pressing Shift+Ctrl+Enter on a segment with a [Fuzzy] marker would cause the fuzzy marker to be removed. Pressing Shift+Ctrl+Enter again and again after that will then cycle between [Unconfirmed] and not unconfirmed only.

Issues:

* The user should be able to customise the [Unconfirmed] marker and OmT should be able to recognise it and add/remove it. Ditto the [Fuzzy] marker if item 5 is implemented.

* If a user messes up the marker, then it is his fault -- you can't expect OmT to do miracles. So if the user accidently deletes a letter and the segment ends up with [Uncnfirmed] instead of [Unconfirmed] in front of it, OmT will assume that it is not marked.

* Item 1, 2 and 3.1 can be implemented long before items 3.2 etc are implemented.

* Whether segments with [Unconfirmed] in it should be exported to TMX is a separate discussion. I certainly think that unconfirmed segments should be added to the project_save.tmx and should also be offered as fuzzy matches where relevant.

* It could be nice to have a View colour for unconfirmed (and possibly also fuzzy) segments. Red is nice.

* A shortcut for "Next incomplete segment" (say, Shift+Ctrl+U) may be useful. It would jump to the next segment that is either [Fuzzy] or [Unconfirmed].

* If a user has a TM with [Unconfirmed] in it but then decides to change his marker to something like [Incomplete] or whatever, he should not expect OmT to treat segments with [Unconfirmed] in it as unconfirmed. You can't expect OmT to read minds.

-- leuce

[Kos Ivantsov]

This RFE can be merged with [#948], I think.

[Didier Briel]

See [#948] for a similar RFE.

Didier