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

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

Hi Yves,

Thanks for the reply - once more, I learned a lot :-)

Please find some comments below.

Cheers,
Christian
-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Dienstag, 5. Juli 2011 05:37
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Native data - "outside" representation

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

CL> I would see a certain danger (e.g. related to consistent modification) if some native code is
CL> stored in both the skeleton and the local-skeleton. I would also think that interoperability
CL> suffers if some tools work with the skeleton and others with the local-skeleton when it comes
CL> to native data.

CL> That's why I suggested to go for an exclusive OR when it comes to skeleton vs. local-skeleton.

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

CL> All points are convincincing (especially the first one). Thanks for correcting me.

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

CL> I understood your "XLIFF and native data" as follows:
CL> a. Sometimes, my XLIFF A at hand will not be derived from a native format, but rather from XLIFF B; we could term the XLIFF A "second order XLIFF".
CL> b. Talking about "native" in second order sounds kind of odd
CL> That's why I suggested to avoid the term "native" and just talk about container/skeleton.

Cheers,
-ys



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