- attached okp_ticket43_diagram_omt.omt
Tag tooltips do not show the locked text
Preconditions
An OmegaT project (attached) including the following contents:
.
├── dictionary
├── glossary
├── omegat
│ ├── filters.xml
│ └── okf_json@delta.fprm
├── 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
- Open the (attached) project in OmegaT
- 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.
Comments (10)
-
reporter -
@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):
-
@Manuel Souto Pico , I have rechecked the behaviour with the provided custom Okapi JSON filter parameters.
- JSON
2. XLIFF
So, the issue has been reproduced for the JSON format file.
-
@Manuel Souto Pico , it looks like the Okapi and OmegaT integration is based on
org.omegat.filters2.IParseCallback
interface and itsorg.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 ofjava.lang.String
type. That means that:- 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 attachingnet.sf.okapi.common.resource.InlineAnnotation
to a code. And it can be written toString
in a special format (seenet.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). - 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.
- The content with all its codes and their meta-information (type, display text/tool-tip, etc) has to be represented as
-
@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
-
@t_cordonnier thank you very much for the hints!
-
reporter Thank you, @t_cordonnier
-
-
assigned issue to
-
assigned issue to
-
A related pull request #16 was opened.
-
reporter It seems @Denis Konovalyenko 's PR has been merged, so I guess this ticket can be closed as Resolved.
- Log in to comment