Uploaded image for project: 'OASIS XML Localisation Interchange File Format (XLIFF) TC'
  1. OASIS XML Localisation Interchange File Format (XLIFF) TC
  2. XLIFF-14

<ph> processing requirements

    XMLWordPrintable

    Details

    • Proposal:
      Hide

      Consider adding PR or Warning
      Consider Advanced validation impact

      Show
      Consider adding PR or Warning Consider Advanced validation impact
    • Resolution:
      Hide

      Consensus January 17, 2017:
      using <ph/> to encode spanning codes is against defintions and business logic of the standard, hence adding explicit PRs and/or Constraints to prevent that is not a change of core, just a clarification.
      Therefore we will add the necessary Constraints/PRs to explicitly prohibit such use of <ph/> as described in the comment.

      Show
      Consensus January 17, 2017: using <ph/> to encode spanning codes is against defintions and business logic of the standard, hence adding explicit PRs and/or Constraints to prevent that is not a change of core, just a clarification. Therefore we will add the necessary Constraints/PRs to explicitly prohibit such use of <ph/> as described in the comment.

      Description

      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"><span translate="no>some text</span></data>
      …
      <source>following should not be localized: <ph id="1" dataRef="d1"
      /></source>

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

        Attachments

          Activity

            People

            • Assignee:
              DavidFilip David Filip [X] (Inactive)
              Reporter:
              DavidFilip David Filip [X] (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: