[OASIS Issue Tracker] (XLIFF-14) <ph> processing requirements

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

David Filip created XLIFF-14:
--------------------------------

             Summary: <ph> processing requirements
                 Key: XLIFF-14
                 URL: https://issues.oasis-open.org/browse/XLIFF-14
             Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
          Issue Type: Improvement
          Components: other
    Affects Versions: 2.1_csprd01
         Environment: http://markmail.org/thread/egfedolqa5l4u3et
            Reporter: David Filip
            Assignee: David Filip
             Fix For: 2.1_csprd02


FROM: Ján Husarčík <jan.husarcik@gmail.com> 

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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)