RE: [xliff-inline] Native data - "outside" representation

["Lieske, Christian" <christian.lieske@sap.com>]

Hi Yves,

Thanks for driving this forward.

Here are some thoughts of mine that your work has fostered ...

1. If we go for a storage location within a "trans-unit", we may want to be explicit about the "divison of labour" between a possible skeleton file, and the storage location. Example: a skeleton file is not allowed if you work with storage locations in "trans-unit"

2. Looking at the similarities between the storage location and the skeleton, three ideas come to mind:

	a. call the storage location "local-skeleton"
	b. define it not in the same way as "skeleton" (most importantly, allow XML to be included)
	c. work along the lines of some existing skeletons (special markers, in locations with translatable text)

		"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>."

		<local-skeleton>
			<x id="1"/> <span style="background-color: #FFFF00"><x id="2"/>  <b><x id="3"/> </b> <x id="4"/>  <i><x id="5"/> </i> <x id="6"/> <b><x id="7"/> <i><x id="8"/> </i></b> <x id="9"/> </span><x id="10"/>
		</local-skeleton>

3. The "no storage location if no inline markup" becomes hairy if during translation native data needs to be created. However: If I remember correctly, previous discussion has shown that we currently do not address this requirement.

4. "native data" for extraction from XLIFF: if we call the storage location "local-skeleton" it does not matter whether we look at real data, or real data that already has been converted to XLIFF 

Cheers,
Christian

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Montag, 4. Juli 2011 09:33
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Native data - "outside" representation

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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php