[RFE#1736] feat: Alternative translation highlight

[chelobaka]

Pull request type

Please mark github LABEL of the type of change your PR introduces:

• Feature enhancement -> [enhancement]

Which ticket is resolved?

• Alternative translation highlight
  • https://sourceforge.net/p/omegat/feature-requests/1736/

What does this PR change?

• This PR implements new highlighter for marking segments with an alternative translation.
• GUI bits one might expect for a highlighter like changing color in settings and default color values for light/dark themes.

Other information

[miurahr]

OmegaT marker plugins implementations and marker API are incomplete.
When we want to extend something related to marker API, it is chance to refactor and enhance marker API.
One of places we should improve is marker preference.
We should allow marker plugin to extend preference without changing IEditorSettings class and also extending UI parts.
IMarker should provide a way to give preference API that marker implementation just return a name of marker, preference key and default values.

[t-cordonnier]

About marking alternative translations, let's remember that I had another proposal:
https://github.com/t-cordonnier/omegat/tree/mark-tra-alternative

In this proposal, alternative translations are marked two ways:

• as a context variable in translation info => advantage: the mark is visible not only for current segment, but also other ones
• as an extra character in the segment marker (only because I know some people wanted it)

The problem with using a marker is that you have to think about accumulation: what if the segment is alternative + coming from tm/auto?

[chelobaka]

OmegaT marker plugins implementations and marker API are incomplete. When we want to extend something related to marker API, it is chance to refactor and enhance marker API. One of places we should improve is marker preference. We should allow marker plugin to extend preference without changing IEditorSettings class and also extending UI parts. IMarker should provide a way to give preference API that marker implementation just return a name of marker, preference key and default values.

Sounds reasonable. Shall I continue with this PR the old way or the interfaces should be extended first? And I'd be happy to help if you need it.

[miurahr]

OmegaT marker plugins implementations and marker API are incomplete. When we want to extend something related to marker API, it is chance to refactor and enhance marker API. One of places we should improve is marker preference. We should allow marker plugin to extend preference without changing IEditorSettings class and also extending UI parts. IMarker should provide a way to give preference API that marker implementation just return a name of marker, preference key and default values.

Sounds reasonable. Shall I continue with this PR the old way or the interfaces should be extended first? And I'd be happy to help if you need it.

The work is proposed in #951
An improvement requires hard work to change many, so you can do it with old way, and I'll propose the change with your improvement in a place of configurations and menu items.

[Kazephil]

The Bundle.properties changes are fine.

I'll leave comments on the code itself to people who actually know what they're doing! 😄
Nice to see a new name among people submitting a pull request!

[chelobaka]

Not new exactly, but rarely seen for sure 😄

[miurahr]

Here is patches files omegat-alttranslationsmarker-patches.zip for your convenience.

[chelobaka]

Marker was registered in Plugin.properties as a marker. Moved it to plugins and added test files. Thank you!

[t-cordonnier]

Just did a quick test, the plugin works well but as I suspected there is the problem of accumulation: if I take a segment from tm/auto, and this segment is an alternative translation, then I see only the result of your plugin, the color saying that this comes from tm/auto is recovered by yours.