Re: [xliff-inline] v1.2 to v2.0 mapping

[Arle Lommel <alommel@gala-global.org>]

Yves, this is great and very useful. I have been tied up with other things for some time and have not been able to keep up with the Inline SC work as I should, but that should change now. Since I've not been as active as desired, I am not entirely clear on some details, but my feedback may be useful because my eyes are somewhat fresh.

A few comments:

#1. In the discussion about sub-flows, I note the following:

Note: the placeholder "#2#" is only an example of possible representation: 2.0 does not provide a standard way to represent sub-flows references in the original data.

Is this just something we have yet to address or is it something we aren't planning on addressing? I'm not clear how to read this. I'm hoping that it is the former: that we just haven't solved this yet. In looking at this issue, I would argue that we need to define a standard way to represent these sub-flow references or we will end up in a situation where we have mutually incompatible ways of handling this. In other words, leaving this undefined will do exactly what XLIFF 2.0 is supposed to not do: leave things too loose.

#2. I think that the document needs some explanation of changes that aren't transparent. For example, we have examples of <mrk> that are identical except for whether they use mtype or type. To the end user the motivation for a transformation from one to the others is not at all clear since the examples appear to be changes in attribute names only. In such cases where the motivation is not obvious, I think we need to document it carefully if the changes are not to appear capricious.

Other examples where the changes could look capricious include:

• ctype maps to type
• equiv-text maps to equiv

#3. Why the transition from 

translate this but <mrk mtype="protected">do not translate this</mrk>

to 

translate this but <mrk type="trans" translate="no">do not translate this</mrk>

?

Without documentation, I'm wondering why something like this wouldn't work:

translate this but <mrk translate="no">do not translate this</mrk>

It would seem the important semantic bit is in the translate attribute (and this would correspond to the proposed translate attribute for HTML5). I'm not clear what type="trans" adds here. I'm sure there is a reason, however.

#4. In the “<mrk> with comment” section there is a minor error:

He is my <mrk type="comment" value"This basically means 'alter-ego'"><mrk type="term">doppelgänger</mrk></mrk>.

Should read

He is my <mrk type="comment" value="This basically means 'alter-ego'"><mrk type="term">doppelgänger</mrk></mrk>.

Best,

-Arle