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.

[amCap1712]

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

Do I understand it correctly there won't be any cases for needs-editing then or the cases not mentioned here are needs-editing?

But the two-field is confusing as well because most of the combinations do not make sense.
We could the hide the subfield when the state is set to a non fuzzy state? Then when a user chooses, Needs editing they can be shown another field that lets them specify Needs checking or Needs rewriting. But I am unsure if this is good UX :/

I took a look at Xliff states but I think we should avoid adding more granular states until users request.

[nijel]

"Needs editing" is more a superset of "Needs checking" and "Needs rewriting". I'm not actually convinced we need to expose all of these in the UI.

[amCap1712]

Hmm I see. I am a bit confused. Do we only want to expose "needs editing" to the user and track all states internally?

[nijel]

I think #2240 (comment) might be the best approach—it will show a detailed state, but the user should only select from a subset of the states. I don't really have a strong opinion here besides the need for more detailed states :-).