[xliff-comment] Another possible solution for reformat

[Doug <doug@ektron.com>]

The current structure of trans-unit limits source and target to plain text
and XLIFF placeholders.

<trans-unit id="00001" translate="yes">
  <source>Unable to store persistent object</source>
  <target>Unable to store persistent object translated</target>
</trans-unit>

One proposed option is to encapsulate the text and other format elements,
like coord, font, and style, within a <source-info> element and place the
text (with placeholders) within <text> tags.

<trans-unit id="00001" translate="yes">
  <source-info>
    <text>Unable to store persistent object</text>
    <coord>
      <x reformat = “no”>x </x>
      <y reformat = “no”>y</y>
      <cx reformat = “yes”>cx </x>
      <cy reformat = “yes”>cy</y>
    </coord>
  </source-info>
  <target-info>
    <text>Unable to store persistent object translated</text>
    <coord>
      <cx>cx </x>
      <cy>cy</y>
    </coord>
  </target-info>
</trans-unit>

The problem with this option, although it is arguably the cleanest
structure, is that it does not maintain compatibility with XLIFF 1.0.
Granted the transform from XLIFF 1.0 is not difficult.

The structure below does not strictly maintain compatibility, but the
migration path is obvious. The <source-info> and <target-info> tags are
optional. That is, the XLIFF 1.0 structure is permitted. I believe this
makes it easier to write code or XSLT to handle both XLIFF 1.0 and XLIFF
1.1. Unfortunately, code written for XLIFF 1.0 would likely need to be
changed to support XLIFF 1.1 because <source> may not be the direct child of
<trans-unit>. The real advantage to this structure is the clear migration
path because the <source> and <target> tags are preserved instead of being
renamed as <text>.

New extended structure:

<trans-unit id="00001" translate="yes">
  <source-info>
    <source>Unable to store persistent object</source>
    <coord>
      <x reformat = “no”>x </x>
      <y reformat = “no”>y</y>
      <cx reformat = “yes”>cx </x>
      <cy reformat = “yes”>cy</y>
    </coord>
  </source-info>
  <target-info>
    <target>Unable to store persistent object translated</target>
    <coord>
      <cx>cx </x>
      <cy>cy</y>
    </coord>
  </target-info>
</trans-unit>

-OR- Old basic structure:

<trans-unit id="00001" translate="yes">
  <source>Unable to store persistent object</source>
  <target>Unable to store persistent object translated</target>
</trans-unit>

The original XLIFF 1.0 structure would also be allowed. The schema would
specify the <source-info> and <target-info> tags as optional if <source> and
<target> were the sole children. That is, if <coord> or other format element
is used, the <source-info> and <target-info> would be required. Pattern
matching for TM would only be performed on <source> and <target> content.

Another, more psychological, benefit to making <source-info> and
<target-info> optional is that if an application only requires text and no
format elements, the structure becomes simple. One of my complaints with XML
Schema is that it requires twice as many tags as I would expect. We should
remove the question "Why do I need <source-info> and <source>?". With XHTML,
the <tbody> element is required, but most people used to older versions of
HTML don't like it. It appears on the surface to be an extraneous tag. It
also breaks a lot of HTML parsing code that assumes <tr> will be a child of
<table>.

The bigger issue of whether XLIFF 1.0 compatibility is required or not is
beyond my ability to answer. From a practical point of view, it depends on
how many applications of XLIFF 1.0 exist beyond the XLIFF TC members. How
widely has XLIFF 1.0 been adopted? If XLIFF 1.0 has not been implemented
outside the TC, then compatibility is not a consideration and the use of
<text> would be preferred.


Regards,

Doug D

Ektron, Inc.
+1 603 594-0249
http://www.ektron.com