RE: [xliff] Source read only or modifiable?

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: Wednesday, May 23, 2012 11:25 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Source read only or modifiable?

Hi,
 
> >> 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.

When you do segmentation, you add elements to <unit>. When you add <mrk> elements, you add them to <source>. That's a completely different level in the XLIFF tree.

> 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?

Not a big  problem if they don't need to be preserved. Having to remove them is annoying as it means extra work for processing.

To make things worse, the description of <mrk> in the specification draft says it could have multiple nesting levels. That means extra levels of processing to get rid of undesired markup.


> > 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.

An important thing to keep in mind: elements from a module are optional and disposable. 

What would a tool that only supports "core" do with inline elements if they are in a module? Being them optional and disposable, the tool would have the right to remove all inline markup, probably making the XLIFF file unusable. That's too risky and justifies having inline elements in core.


> >> 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.

As said before, that information doesn't have to be in a <mrk> element. It could be stored outside <source> so it is not *absolutely* essential to consider <mrk> as an inline element.

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com