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

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

     [ https://issues.oasis-open.org/browse/XLIFF-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Filip updated XLIFF-14:
-----------------------------

    Due Date: 6/Feb/17  (was: 1/Dec/16)

> <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
>              Labels: request_tc_discussion
>             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)