OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XLIFF 2.1 csprd01: <ph> processing requirements


Hello,

in http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd01/xliff-core-v2.1-csprd01.html#pc Processing Requirements state why <pc> must not be used to represent standalone code.

Could you please add a similar Processing Requirement for <ph>? It should explain why <ph> MUST NOT be used for well-formed spanning code (opening and closing tag are represented by separate <ph>).

For example if it's used to represent <bold> from HTML, agent cannot validate (without additional editing hints):
- correct order, which can produce </b>…<b>
- removal of either opening or closing tag
- tag nesting
- leaving tag pair empty

In case Extractor decides to drop opening tag at the beginning of the segment as "redundant", such as
<source>bold<ph id="1" disp="/bold"> text</source>
a correct formatting cannot be guaranteed if word order is different in target language
<target>text tučným<ph id="1" disp="/bold"></target>

Similarly, Processing Requirements should describe that <ph> should not be used for locking of inline content otherwise represented by well formed spanning code.

E.g.
<span translate="no>some text</span>
as
<data id="d1">&lt;span translate=&quot;no&gt;some text&lt;/span&gt;</data>

<source>following should not be localized: <ph id="1" dataRef="d1" /></source>

<mrk translate="no> should be suggested as preferred solution.

Thanks,
Jan


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]