Native data - "outside" representation

[Yves Savourel <ysavourel@translate.com>]

Hi all,

I've worked a little bit on the representation of the native data outside the segment:
Here is a possible notation:

<nativeData>
 <data id='1'>data for code with nid='1'</data>
 Etc...
</nativeData>

We would have this (optional) element in any element that hold a separate <source>/<target> pair.
In the current representation that the TC is working with that would be in <unit> and <match>.

Assuming the original source is:

"Text with <span style="background-color: #FFFF00">some <b>bold</b> and <i>italic</i> and <b>bolded <i>italics</i></b> then just the highlight</span>."

Here is an example of the representation with native data within the inline codes:

  <unit id="tu3">
   <segment>
    <source>Text with <sc id="1">&lt;span style="background-color: #FFFF00"></sc>some <sc id="2">&lt;b></sc> bold<ec id="2">&lt;/b></ec> and <sc id="3">&lt;i></sc>italic<ec id="3">&lt;/i></ec> and <sc id="4">&lt;b></sc>bolded <sc id="5">&lt;i></sc>italics<ec id="5">&lt;/i></ec><ec id="4">&lt;/b></ec> then just the highlight<ec id="1">&lt;/span></ec>.</source>
   </segment>
  </unit>

Here is an example of the representation with the native data outside the inline codes:

  <unit id="tu3">
   <nativeData>
    <data id="so1">&lt;span style="background-color: #FFFF00"></data>
    <data id="so2">&lt;b></data>
    <data id="sc2">&lt;/b></data>
    <data id="so3">&lt;i></data>
    <data id="sc3">&lt;/i></data>
    <data id="so4">&lt;b></data>
    <data id="so5">&lt;i></data>
    <data id="sc5">&lt;/i></data>
    <data id="sc4">&lt;/b></data>
    <data id="sc1">&lt;/span></data>
   </nativeData>
   <segment>
    <source>Text with <sc id="1" nid="so1"/>some <sc id="2" nid="so2"/> bold<ec id="2" nid="sc2"/> and <sc id="3" nid="so3"/>italic<ec id="3" nid="sc3"/> and <sc id="4" nid="so4"/>bolded <sc id="5" nid="so5"/>italics<ec id="5" nid="sc5"/><ec id="4" nid="sc4"/> then just the highlight<ec id="1" nid="sc1"/>.</source>
   </segment>
  </unit>

Note that there is no optimization for now: each code is represented even if it's duplicated.

Note also that the inline codes in those examples are using a single id value for codes that have both opening and closing parts, as I'm testing the idea I've described here: http://lists.oasis-open.org/archives/xliff-inline/201107/msg00000.html, but this is unrelated to the native data representation.

A few questions about the outside-the-segment representation:

- I assume an entry with no inline codes does not have to have a <nativeData> element if it is empty, is that sound ok?

- Sometime an original code may have no native data, it could be the case when you are extracting from a 1.2 XLIFF file using <g> and <x/> and where all the code information may be mappeable to the XLIFF v2 code itself. In those cases there is no native data to store. Should we allow to not have a <data> element for those?


I've updated Rainbow to generate those files.

Here is a short reminder of what to do if you want to try the representation of various files:

- get the latest snapshot from http://okapi.opentag.com/snapshots
- drop your input files, set filters, encoding and locales
- select "Utilities" > "Translation Kit Creation"
- select "XLIFF 2.0"
- click "Options" to choose what inline representation to output, click "OK"
- select your output location in the "Output Location" tab
- click "Execute"

Happy 4th of July
-yves