OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff-comment] Re: [xliff] Version Control Commit by DavidFilip

>> The more general issue with content in CTR entries is that we take it 
>> out of context (from a markup viewpoint). But the actual data after 
>> parsing is what we really need to store. So, if we have this:
>>   <target>...data<em startRef='m1'/> text</target>
>> We can store it like this:
>>   <item property='content'><mrk id='m1' translate='no'>...data</mrk> text<item>
> I don't think this is a good idea, the stuff between start of <target> and 
> the unhandled isolated <em/> is actually text too and not untranslatable data. 
> Remember we store data in <originalData> and we don't allow to store mix them 
> with inline content.. 

Maybe I should have provided more context in the example: "... data" is non-translatable text.
The <mrk id='m1' translate='no'> is just the corresponding data that span of content.

My point is: If a segment has an isolated <sm/> or <em/>, we can just complement it with the corresponding start in the CTR <item>. My more general point being that <item> is a representation of the object model, not of the unparsed original XLIFF markup.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]