xliff-inline — archive

[Christian Lieske]

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