[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (XLIFF-23) Discussion of different methods to handle ITS Translate in XLIFF
[ https://issues.oasis-open.org/browse/XLIFF-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65292#comment-65292 ] David Filip commented on XLIFF-23: ---------------------------------- Consensus to fix as proposed, explain when one is better than the other, w/o discouraging one. > Discussion of different methods to handle ITS Translate in XLIFF > ---------------------------------------------------------------- > > Key: XLIFF-23 > URL: https://issues.oasis-open.org/browse/XLIFF-23 > Project: OASIS XML Localisation Interchange File Format (XLIFF) TC > Issue Type: Improvement > Components: ITS Module > Affects Versions: 2.1_csprd02 > Environment: http://markmail.org/thread/yhhz7tqsh4iz3hgv > Reporter: David Filip > Assignee: David Filip > Labels: Clarification, Practices, editorial, request_tc_discussion, work_required > Fix For: 2.1_cs01 > > > text protection using native codes and <mrk translate='no'> > 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> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#ph> > to > mask non translatable inline content. The preferred way of protecting > portions of inline content from translation is the *Core* Translate > Annotation > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#translateAnnotation>. > See also discussion in the ITS Module section on representing > translatability inline. > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#Translate_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. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]