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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Arle,

Thanks for going through the document.

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

It's the current state: we have touched on that question briefly when discussing sub-flows, but not reached a conclusion if/how it should be represented. So by default we don't have representation at this time.

Now should we or not have a standard way to do this?
I see the advantage in having a single way to represent it.
But at the same time I see it big restrictions: defining how tools should represent original data may restrict them on what they can/want to do.

Note that there is no obligation to have the original data, so the tools will have to be able to handle the case when no reference marker (standard or not) exists, anyway.

Note also that if you assume the sub-flow reference has a standard representation, we need to assume the whole original data also need to have a standard representation: do we want to go that direction? Basically this is about have a standard way to represent the skeleton.

Note also that sub-flows are not necessarily coming from inline codes. You can have for example an HTML title attribute in the start tag of <p> which is in the external skeleton and therefore may be invisible to the tools.


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

All the <mrk>-related parts in the table are currently incomplete since we are still working on how to represent those annotations.
But I get your point: we need to provide explanation even if it seems logical to the user reading the whole document.
In this specific case, we are simply consistent with the new markup. We'll have to decide of all names at some point. 


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

That the current annotation mechanism: type is a required attribute. We may want to make exception for this case as translate is indeed an attribute that is not directly related to the other info of <mrk>, so type is not technically needed if that is the only info for that <mrk>. That is we can have:

He is my <mrk type="term" translate="no">doppelgänger</mrk>.


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

Good catch.

-ys