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

Hi Fredrik, Rodolfo, Arle, all,

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

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.

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.

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


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