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] Source read only or modifiable?


>>>>> Annotations using <mrk> alter source text.
>>>> No more than <segment> elements.
>>> An annotation does not represent anything included in the original 
>>> document. It is neither original text nor formatting information 
>>> that needs to be preserved.
>> Exactly. So we agree that adding/removing annotations does not modify 
>> the content.
> No, we don't agree. Adding an annotation means altering
> the original. The key is the verb: "add".

When we re-segment we also "add" <segment>/<source> tags, and that (as we agreed) does not "modify" the original extracted content.

So how can adding <mrk> is any different? If we strip out the <segment>/<source> and the <mrk> tags we get the same original content we had before adding them. The annotations are just a layer on top of the original extracted content, just like <segment>/<source>. Please, point me the difference.

In any case, it seems that we do agree on one thing: Ignoring the <mrk> is fine for the merger tool. So what is the problem with having them at that stage?

> The Inline SC should propose whether to have inline 
> elements as part of the core or in a separate schema, 
> we know that. Nevertheless, if inline elements live 
> in their own schema, annotations should live in a 
> different one.

Maybe, maybe not. If the elements for inline codes have their own namespace, they don't have to follow the core prescriptions. We'll see what the SC come up with. It may think having all the inline markup in a single namespace is simpler. I have no opinion on that yet.

>> Note that annotations can be generated by the
>> extraction tool, and some can be important to the 
>> translation process (e.g. <mrk translate='no'>). 
>> So there might be a case for <mrk> to be part of 
>> the core if the other inline elements are.
> That would be only possible if the original document includes 
> something that says a given span of text should not be translated.

Not necessarily. An extraction tool can do many things: some can pre-segment, some can process the content to add <mrk translate='no'> based on a black-list of do-not-translate texts. There is no original code to anchor the translate attribute in that case.


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