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 8:20 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Source read only or modifiable?
> 


Hi,

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

 
> >>> If the tool that creates the XLIFF doesn’t add <mrk> elements, then
> >>> <mrk> elements should not be present when the XLIFF returns to the
> >>> original tool for generating the translated file.
> >>
> >> I disagree. Like with <segment>, the merging tool can strip the <mrk>.
> >> By definition they are not part of the content to merge.
> >
> > If that's not part of the original content to merge, then it is not an
> > essential inline element.
> 
> Exactly. It can be ignored by the merger tool.

It shouldn't be there in first place. If by bad chance it should be OK to completely remove.

 
> >> This is how <mrk> is defined in 1.2 ("The <mrk> element is usually
> >> not generated by the extraction tool and it is not part of the tags
> >> used to merge the XLIFF file back into its original format.") and I
> >> certainly hope that the same principle will carry over in 2.0.
> >
> > If it is not generated by the extraction tool, then it should not be
> > in core. It must live in an optional module.
> 
> The SC hasn't discussed yet if the different elements of the inline markup
> should be part of the core or their own namespace(s). So I don't have an
> opinion on this yet.

Inline elements for handling the markup present in the original document are different from extra markup used to hold annotations.

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.

> 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. In that case, there would be a need to use inline markup like <pc> to encapsulate the markup in the original document and that <pc> element may have a translate="no" flag. No need to use <mrk> for that.

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