feat(editor,filters2/xliff,core): inactive translation when XLIFF state="final"

[miurahr]

OmegaT have no feature to handle a protected translation, which is shown but no allow to edit. This is a proposal to extend OmegaT core and editor to handle a "final" state of translation.

A state is belong to "STE" not a translation. when STE is "final", OmegaT show it but locked as inactive.

Pull request type

• Feature enhancement -> [enhancement]

Which ticket is resolved?

What does this PR change?

• extend SourceTextEntry class to have "finalState" field
• extend EditorPane to show inactive translation when STE is final state
• extend IParseCallback#addEntryWithProperties to accept isFinal boolean
• extend filters2/XLIFF filter to recognize state="final" attribute
• Add unit test for filters2/xliff filter

Other information

#805

• Protected entries in XLIFF show translation as source text
• https://sourceforge.net/p/omegat/bugs/1215/

[github-actions[bot]]

❌ Run Gradle test failed:

[t-cordonnier]

@miurahr didn't I tell you that I was working on something similar when we discussed https://github.com/omegat-org/omegat/pull/805? Can't we try to coordinate to avoid doing same thing at same time?

I already started working on it. I did not publish because when the job is requested (and paid) by Manuel I always wait his first review. But I thougt I had alerted you that I was working on it and expected you to wait. Now if you want to compare: https://github.com/t-cordonnier/omegat/tree/locked-segments Note: in my case actually it is used for segments which come from tm/enforce. My idea was to also use the same method for xliff/final status later.

Except of that I did a quick test, both our methods seem to work and yours seems maybe simpler. But it would be good that users, not only developers, can test them to check that there is no problem with shortcuts when we are in a locked segment. Should I open a pull request as well?

[miurahr]

A editor and core change can break all the features in OmegaT, we should be careful and need to discuss a direction , and also requires thorough review process. We looks different place in OmegaT and both will be good start point to understand what is best for the project. A modification for filters2/xliff is only for the test case to show a core change is enough or not.

I'm not aware of tm/auto external TMX. @t-cordonnier could you pick necessary change from here and make a complete proposal for the feature?

Today, I just look into the core, and first trial seems working, so I raise a PR and ask a discussion.

[t-cordonnier]

A editor and core change can break all the features in OmegaT, we should be careful and need to discuss a direction , and also requires thorough review process.

I don't say the contrary, that is the reason why I would like that a user (i.e. not a developer but somebody who uses OmegaT on regular basis) tests both our solutions and tells us whenever the behaviour of the editor remains correct (in particular that the shortcuts continue to work, that he is not blocked in a segment without possibility to escape, etc)

For the moment my impression is that when I go into a locked segment using your solution, tags are not marked anymore and it seems difficult to go to another segment; But I would like the opinion of a translator before to conclude.

Once we are sure on that we will be able to say whenever the better is to take your solution and extend it to tm/enforce or take mine and extend it to xliff/final segments

[miurahr]

For the moment my impression is that when I go into a locked segment using your solution, tags are not marked anymore and it seems difficult to go to another segment; But I would like the opinion of a translator before to conclude.

I also think locked segment using my solution, then there is no mark in current segment and UX is worse. We need improve if we use some locked segment in UI, for example, to introduce new marker to indicate locked status.

[miurahr]

I've changed the PR status to draft to avoid accidental merge.

[miurahr]

There seems no further progress, I'd like to close here.

[t-cordonnier]

@miurahr Since I was working on something similar for Manuel Suto Pico, I asked him to test both your version and mine. Such a feature must be strongly tested because in case of bug it may prevent any possibility to leave a segment. So for the moment I would keep your implementation as an option if Manuel finds something wrong with mine. I asked him to test but unfortunately he most often has lot of simultaneous opened tasks, even related to OmegaT...

[msoutopico]

Manuel Suto Pico

You may mention me as @msoutopico so that I get notified. I'm looking into this now.

[msoutopico]

Hi @miurahr, I can test this patch, but could you please confirm what issue it's meant to resolve exactly? Thanks.

[msoutopico]

@miurahr I've had a look at your sample test file file-XLIFFFilter-state-final.xlf. The file is not valid XLIFF and it has a number of issues:

• trans-unit do not have mandatory id attribute
• xliff root node does not have the mandatory version attribute
• the state attribute should be used in target, not in trans-unit