Entries with translate='no' (locked) should be displayed in OmegaT

[YvesS]

Currently the locked entries are not shown in (or event sent to) OmegaT. But they are often useful to see for the translator.

We could lock them in OmegaT with <mrk mtype="protected"> and/or add a "LOCKED SEGMENT" comment. On merge, the filter would use the original source instead of the text coming from OmegaT, so that would be safe.

[Didier Briel]

An added benefit of using protected text is that it can be excluded from statistics.

Didier

[YvesS]

Using <mrk mtype="protected"> changes the entry into a single code, so the translator still doesn't see the text. Or am I missing something?

I suppose he can see the source if we just set the mrk on the target, but I'm not sure how useful that is. (And that may have effect on tags verification anyway).

[Didier Briel]

Using <mrk mtype="protected"> changes the entry into a single code, so the translator still doesn't see the text. Or am I missing something?

Perhaps. When using OmegaT's native XLIFF filter, all you have to do is using <mrk mtype="protected">. E.g., <source>This is where you find <mrk mtype="protected">protected words</mrk>.</source>

But we're talking about the Okapi plugin here, so you have to declare the text is protected yourself. You can look at XLIFFDialect.java to see how it is done. Basically, your protected text is declared as such:

   @Override
    public String constructShortcuts(List<Element> elements, List<ProtectedPart> protectedParts) {
[snip]

                ProtectedPart pp = new ProtectedPart();
                pp.setTextInSourceSegment(shortcut);
                pp.setDetailsFromSourceFile(tag.toOriginal());
                if (tagProtected) {
                  [snip various lines related to statistics]
                endif
               protectedParts.add(pp);

Didier

[YvesS]

I see that's a feature defined by the XLIFF filter rather than at the parsed level. Makes sense. I'll see what can be done then, but I doubt a plugin could do this because it has little control over the content other than setting the text with codes.

[Didier Briel]

The feature is only used by the XLIFF filter, but it's not only defined there. Normally, a plugin should be able to use protected parts, because they are based on ProtectedParts.java. See for instance in ParseEntry.java

 public void addEntry(String id, String source, String translation, boolean isFuzzy, String comment, String path,
            IFilter filter, List<ProtectedPart> protectedParts) {

If something is missing in the API, let us know.

Didier

[YvesS]

Ah, that's better. The main issue I often run into with the plugins is that I have to create a dummy set of classes with the same signatures as the OmegaT ones, and they get replaced by OmegaT's at runtime.

So if I don't keep up with the real code, I miss new features. For example I have only those methods:

void addEntry(String id, String source, String translation, boolean isFuzzy, String comment, String path,
        IFilter filter);

void addEntry(String id, String source, String translation, boolean isFuzzy, String comment, 
        IFilter filter);

(https://bitbucket.org/okapiframework/omegat-plugin/src/master/filters/src/main/java/org/omegat/)

It would be nice to have some kind of separate library the plugins can use, without having a dependency on the whole OmegaT project. But that is not a high priority, just a convenience.

Anyway: I'll look at the latest source code and try things out.

Thanks for the help. -yves

[YvesS]

It looks like ProtectedPart assumes the protected part is the same in the source and target. There is only a setTextInSourceSegment() method.

I suppose I could somehow put the target in the source and set that part as protected, I'll try different things. But maybe you have a better, proper, way to set the target?

[YvesS]

It seems the best compromise is to put the source text in the tool-tip (setDetailsFromSourceFile) and the target in the content (setTextInSourceSegment). This protects the whole content. The filter also doesn't use the text from OmegaT when creating the target, but re-use the original content.

The only concern left seems to be the TMX files: they may end up containing target/target pairs (e.g. if the translator forces a "same-as source" translation, or add text before/after the protected block).

[YvesS]

Added support for protecting state=final and translate=no entries on option. This resolves issue #2.

→ <<cset beefc810f268>>