[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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] | [List Home]