Tag tooltips do not show the locked text

[Manuel Souto Pico]

Preconditions

An OmegaT project (attached) including the following contents:

.
├── dictionary
├── glossary
├── omegat
│   ├── filters.xml
│   └── [e-mail]
├── omegat.project
├── source
│   └── aliasing_delivery_en.xls.json
├── target
└── tm

where the JSON file contains some untranslatable entity that needs to be locked, e.g. an interpolated variable:

• Diagram ({diagramCount})

and where the JSON filter definition contains a codeFinder rule that matches that entity:

• codeFinderRules.rule2=\{[^{}]+\}

so that the entity appears as a tag in OmegaT’s editor:

Steps to reproduce

1. Open the (attached) project in OmegaT
2. Hover over the tag

Expected results

A tooltip appears which displays the original text that was matched and locked with the codeFinder rule.

Actual results

A tooltip appears which displays the tag itself.

Comments

I am using a codeFinder example, but the same thing would apply to any tags regardless of how they are generated (e.g. if I used the Okapi HTML filter, the same thing would apply to tags that stand for HTML markup.

The expected results are the actual results when I use Okapi Rainbow to produce an XLIFF file out of the same JSON file. I include such XLIFF in the attached project for comparison.

‌

[Denis Konovalyenko]

@Manuel Souto Pico it loos like this is OmegaT related…

I was able to see the mentioned tooltip with the latest version (5.8.0 at the moment of writing):

‌

[Denis Konovalyenko]

@Manuel Souto Pico , I have rechecked the behaviour with the provided custom Okapi JSON filter parameters.

1. JSON

‌

2. XLIFF

‌

So, the issue has been reproduced for the JSON format file.

[Denis Konovalyenko]

@Manuel Souto Pico , it looks like the Okapi and OmegaT integration is based on org.omegat.filters2.IParseCallback interface and its org.omegat.filters2.IParseCallback#addEntry(java.lang.String, java.lang.String, java.lang.String, boolean, java.lang.String, java.lang.String, org.omegat.filters2.IFilter, java.util.List<org.omegat.core.data.ProtectedPart>) method, where source and translation are of java.lang.String type. That means that:

1. The content with all its codes and their meta-information (type, display text/tool-tip, etc) has to be represented as java.lang.String somehow. Both Okapi and OmegaT encoding/decoding meta-information support is required. For instance, Okapi supports attaching net.sf.okapi.common.resource.InlineAnnotation to a code. And it can be written to String in a special format (see net.sf.okapi.common.resource.TextContainer#contentToString for a wider picture). So, OmegaT has to extract the meta-information (annotations) and use it for tooltips (it would be better to introduce an interface for the meta-information as well).
2. Alternatively, the org.omegat.filters2.IParseCallback interface can be extended with another one (e.g. IParseCallback2) with an additional method for entailing code-related meta-information (can be just extended with a new method). This will require one or more interfaces for describing and linking (can be complicated) the meta-information as in the first case.

Still need to think this over in detail (especially the OmegaT part). As of now, I assume that the 2nd variant would look cleaner and lighter as the meta-information transformation layer would be omitted.

[t_cordonnier]

@Denis meta-information about the tags are in the last parameter typed List<ProtectedPart> : you must build a list where each tag comes with its description. For each ProtectedPart, use setTextInSourceSegment to define the tag and setDetailsFromSourceFile to define what should appear in the tooltip. No need to add a method in the callback

Example: see method “buildProtectedParts” in http://185.13.37.79:8003/index.php/p/stax-filters/source/tree/master/src/org/omegat/filters4/xml/AbstractXmlFilter.java and sample of use in http://185.13.37.79:8003/index.php/p/stax-filters/source/tree/master/src/org/omegat/filters4/xml/xliff/AbstractXliffFilter.java line 143

[Denis Konovalyenko]

@t_cordonnier thank you very much for the hints!

[Manuel Souto Pico]

Thank you, @t_cordonnier

[Denis Konovalyenko]

A related pull request #16 was opened.

[Manuel Souto Pico]

It seems @Denis Konovalyenko 's PR has been merged, so I guess this ticket can be closed as Resolved.