xliff-inline — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
RE: [xliff-inline] Native data - "outside" representation
Hi, Looking back at one of Christian comments on the inline 'native' data representation. I wonder if this (or something derived from it) could not be an alternative for the representation of "ignorable"
> 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> One could imagine storing all the ignorables in a single element and using placeholders for the segment references. A sort of unit-level skeleton. <unit id='1'> <ignorable>
<src><s id='1'/> <s id='2'/></src> </ignorable> <segment id='1'>
<source>Text 1.</source> </segment> <segment id='2'>
<source>Text 2.</source> </segment> </unit>
Just a thought. I'm not sure if it's more advantageous than using the current proposed representation. But I guess that's a topic of the main TC list at some point. -ys
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]