feat(state): use needs-checking/needs-rewriting states

[amCap1712]

TBA

[amCap1712]

@nijel

[nijel]

Needs checking seems appropriate here.

[amCap1712]

@nijel

[nijel]

Needs checking for source, the target should get needs rewriting once the source is edited.

[amCap1712]

1. Wondering what needs states should be shown here. Since source strings can be marked as needs checking and target strings as needs rewriting, should the needs checking/rewriting be hidden when its not possible to apply them? Or should the user always be given the option to choose needs editing and then the backend chooses the right state to apply?
2. What about needs editing? IIUC, it can only come from gettext's fuzzy or possibly a failed pending change but the user cannot manually mark a unit as STATE_FUZZY. When should needs editing be shown to the user? Always or only when a unit is already in STATE_FUZZY.
3. If a unit is marked as needs checking/rewriting should the info be written to the disk as fuzzy state?

[nijel]

The ultimate goal here is to be able to distinguish what triggered the change from the state and what is the desired action. On the other side, we would rather not expose three similarly named states for selection to the translator. What about using one state selection with another input for detailed state, like outlined in #2240 (comment)?

In the end, what we're trying to represent is a subset of what state and state-qualifier from XLIFF can (see https://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#state). But the two-field is confusing as well because most of the combinations do not make sense. So they removed this in XLIFF 2 (there is subState, which is user-defined and not subject to the specification).

• Flag add-ons -> needs checking
• Report source string -> needs checking
• Source string changed in monolingual file (detected by Weblate) -> needs rewriting
• GNU gettext fuzzy -> needs rewriting
• XLIFF states might need to be investigated as well

That makes me think whether the names we currently have are clear enough to understand...

The states, IMHO, should be written to file when possible.

PS: Beware that any UI changes here will most likely run into conflicts with #16882.