Re: [xliff-comment] XLIFF 2.1 csprd02: text protection using native codes and <mrk translate='no'>

[David Filip <david.filip@adaptcentre.ie>]

Hello Chase,

great thanks for taking the time and reviewing the csprd02 of XLIFF Vesrion 2.1

On behalf of the XLIFF TC, I created this issue

https://issues.oasis-open.org/browse/XLIFF-23

from your comment.

Please follow the resolution/disposal of your comment on the above address

In case you want to follow up on the comment resolution please continue this conversation that is referenced from the JIRA issue under the following markmail link

http://markmail.org/thread/yhhz7tqsh4iz3hgv

The TC plans to resolve your comment tomorrow and to implement the solution in a new working draft by 27th February, 2017.

The reported issue is deemed editorial in nature.

Cheers and thanks again

dF

Dr. David Filip

===========

OASIS XLIFF OMOS TC Chair

OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin

Mobile: +420-777-218-122

On Fri, Feb 17, 2017 at 7:20 PM, Chase Tingley <chase@spartansoftwareinc.com> wrote:

This is a specific comment about one facet of the ITS module, although I think there is a more general version of the same argument that can be made about some of the other examples.

Section 5.9.8.1.2 talks about using the ITS translate attribute to control translation of content surrounded by inline codes in the source.  The example given is this one:

<p>Text <code translate='no'>Code</code></p>

The section outlines two methods for representing this as XLIFF <source>.  The first method is to represent the native <code> tag as an inline code, and use a <mrk> to handle the ITS:

<source>Text <pc id='1'/><mrk id='m1' translate='no'>Code</mrk></pc></source>

The second method is to include the <code> element's text child in the XLIFF code:

<source>Text <ph id='1'/></source>

A note occurring earlier in the document (section 4.2.3.2, discussing the <ph> element) mentions that this second method is possible, but discouraged:

It is possible although not advised to use <ph> to mask non translatable inline content. The preferred way of protecting portions of inline content from translation is the Core Translate Annotation. See also discussion in the ITS Module section on representing translatability inline..

In practice, I expect the discouraged second method to be the more common method of implementations.  There are two reasons for this.  First, it is simpler to implement, due to its simpler structure.

More importantly, it is closer to representing the meaning of the original source. The recommended structure separates the representation of the source markup as syntax from its meaning in the text, by pulling the ITS data out into a separate element.  As a result, the meaning of the source markup ("the contents of the <code> element are not translatable") is not preserved.  As far as I can tell (and hopefully I'm not missing something), there is no mechanism that prevents a Modifier from inserting additional text between the inline code and mrk tags, like this:

<target>Translation <pc id='1'/>additional text <mrk id='m1' translate='no'>Code</mrk> more additional text</pc></target>

Or from rearranging these things entirely, like this:

<target>Translation <pc id='1'/>additional text</pc> <mrk id='m1' translate='no'>Code</mrk></target>

Both of these produce targets that circumvent the intention of the its:translate attribute in the native source content.  The original source text is still protected, but the contents of the overall <code> tag are mutable, unless the merger takes additional steps beyond the specification (ie, inferring that the <pc> and <mrk> tags are bound somehow, and discarding sibling elements of the <mrk> that appear in the target and not the source).

This sort of subversion is probably unlikely, but in my experience implementors will go to some lengths to avoid accidents from happening later on, and so might opt for the discouraged <ph/> representation, in which the non-translatable region is truly off-limits.