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

[Yves Savourel <ysavourel@translate.com>]

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

Why? Wouldn't the skeleton file and the local storage complement each other. After all we don't disallow skeleton file if the inline codes store the native data inside the code.


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

I'm not sure if I understand the goal of storing the extracted text positions in the storage of the native codes.

- It cannot be used to merge back since the order of the code may change in many cases.

- accessing just the native data, for example to use it for the re-creation of the original string, is difficult because you have to find its boundaries rather than a node.

- I'm not sure how allowing other XML namespaces in it (that would be the only way to allow XML in it no?) is helpful. It would complicate the way you access the data.


> 3. The "no storage location if no inline markup" becomes
> hairy if during translation native data needs to be created.

Presumably the XLIFF tool regenerate those entries. But I see what you mean.
I have nothing against having empty storage. Just wondering if they could be simplified. It's not a frequent occurrence in any case.


> 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 

Not sure I understand.
The data in that location would be the original data for the inline codes from the viewpoint of the filter that created the initial XLIFF, no? It maybe HTML if the input file is HTML, XLIFF if the input file is XLIFF, TS if the input file is Qt-TS, etc.

Cheers,
-ys