RE: [xliff] Source read-only or not?

["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: Tuesday, April 03, 2012 9:06 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Source read-only or not?
> 
> 
> > If source is not read-only, then it would be fine to throw away all
> > annotations and change the elements used for inline markup. Right?
> 
> Yes, it would be doable.
> 
> Like Fredrik I think the different forms of inline codes that are equivalent
> should be switchable (e.g. a <pc> to a <sc>/<ec>, or vice-versa). Changing a
> <sc> or a <ec> to a <ph> would not be allowed (since that would loose
> information). Maybe we need to expend a bit the section "Usage of <pc>
> and <sc>/<ec>" to include all inline codes.

Why put  a restriction for converting codes to <ph> if we are allowing changes? As it would be allowed to add inline codes, removing existing ones should also be allowed, then replacing <pc> or <sc>/<ec> with <ph> would be possible. 

Considering that <source> content would be modifiable, we cannot rely on it anymore for generating a partially translated document from an incomplete XLIFF that lacks some <target> elements. It will be necessary to either use the original unmodified XLIFF or to parse the source document again.
 
> Annotations are normally extra information rather than existing code
> (although the nature of translate and possible directionality markers may
> need to be clarified: some of those may come from the original format). So,
> removing or adding annotations in the source should be ok.

If annotations end inside <source> instead of staying outside using attributes to indicate start and end, I would make them completely ignorable, treating them in the same way XML comments are treated.

Anything that doesn't have origin in the source document and is not required for generating a translated document should be ignorable. 

> As for whether changing the source text is a good idea or not, I don't think
> XLIFF can be the judge of that. It may be bad to run a spell-checking step on a
> source text if you need to refer that content back to the original document at
> some point later, but it may be just fine (and useful) in other cases. People
> using tools need to decide those things, not the storage format.

In my experience, many translators prefer to correct typos present in <source> before storing the translation in the TM. For them it is certainly better to have a clean TM.
 
> The only control on text change I would see XLIFF trying to enforce would be
> the white spaces, using xml:space. (I'm not sure xml:space is perfectly
> adequate actually. Currently it's available on <source> and <target>, but it
> would be better to have such information at the <unit> level. But then
> xml:space would apply to all child elements (not just <source> and <target>.
> But that's a different topic).

Having the "xml:space" attribute at <unit> level will affect matches coming from TM that may need to be preserved as retrieved. That seems a bad idea.

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