chore: Xliff1FilterTest with translate=no arg

[miurahr]

Xliff1Filter handles translate=no argument properly. This adds a case when data has a "translate=no" argument.

Pull request type

• Bugs

Which ticket is resolved?

What does this PR change?

• Add a case with a xliff 1.2 file with "translate=no" and "state=final"

Other information

Related issue

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

[miurahr]

@t-cordonnier could you investigate and update the filter to accept "translate=no" tag not to be source text?

[t-cordonnier]

I pushed a new commit which considers state=final like translate=no, as you wished That said please consider the following conversation: https://sourceforge.net/p/omegat/mailman/message/51783987/ I think that when locked segments will be supported, state=final should better be considered as a locked segment. In lot of CAT tools using XLIFF, "translate=no" is used for metadata (meaningless for the translator) while state=final means that we should not modify this translation, but it should be visible, it is an information for the user

[miurahr]

I pushed a new commit which considers state=final like translate=no, as you wished That said please consider the following conversation: https://sourceforge.net/p/omegat/mailman/message/51783987/ I think that when locked segments will be supported, state=final should better be considered as a locked segment. In lot of CAT tools using XLIFF, "translate=no" is used for metadata (meaningless for the translator) while state=final means that we should not modify this translation, but it should be visible, it is an information for the user

I agreed with your opinion and option 2b is appropriate. Could you change the filter and the core to behave as you describe?

[t-cordonnier]

I said "when locked segments will be supported", which is actually not the case. I plan to implement locked segments first for those coming from tm/enforce, and if it works I will study how to apply them also from filters. But I cannot say now when it will be done. For the moment I let you decide if you want to take this temporary correction or not.

[EDIT] I also take note that there is a general consensus on option 2b, and this is also my preference. I will come back to this when 2b is implemented for tm/enforce.

[miurahr]

I said "when locked segments will be supported", which is actually not the case. I plan to implement locked segments first for those coming from tm/enforce, and if it works I will study how to apply them also from filters. But I cannot say now when it will be done. For the moment I let you decide if you want to take this temporary correction or not.

OK, I'd like to merge here as temporary correction, and leave our discussion as a new feature-request ticket.

[miurahr]

I remember that BUGS#1220 "Unable to use XLIFF file as TM" ask us to use translations from xliff files even when entries has "status=final", in definition it will be expected, for a reference. Is the change here affect BUGS#1220?

[miurahr]

I've pushed #819 that seems acceptable for XLIFF to be TM when "state=final" as a database entry. Does #805 break #819?

[t-cordonnier]

Does https://github.com/omegat-org/omegat/pull/805 break https://github.com/omegat-org/omegat/pull/819?

With the actual method (with state="final" meaning that the segment does not appear), probably yes. With locked segments, depends on what the implementation will be, but I would say probably no.

So the real question is whenever we can consider, temporarily, that state="final" means "don't display the segment". I would say no.

Note that strictly speaking the ticket https://sourceforge.net/p/omegat/bugs/1215/

• is about Okapi filter, not StaX filter
• does not complain about the fact that segments with state="final" appear in the editor, but about the fact that they are translated as source, which seems, indeed, a bug (but bug of Okapi filter, not of OmegaT) So personally I don't think that pull request 805 is really correcting Sourceforge ticket 1215.

[miurahr]

I've proposed #882 to implement the "inactive/protected translation" on editor pane. In order to realize it, I extends STE to have a field "isFinal" and also extend IParseCallBack to accept "isFinal" boolean.

Could you check it and consider StaX filters to extend?

[miurahr]

I give up

[t-cordonnier]

In the meantime I have my own implementation of protected segments (also used for tm/enforce) but I must do some tests. I will tell you later.