Dear Rodolfo and all,
Let me clarify what I was trying to do in my email where there is <mrk its:translate='no'>:
I was trying to give an example to Kevin that illustrated that using ITS was not necessarily possible everywhere and I used its:translate to do that.
"... It's not always possible. For example:
In the inline markup we have <mrk translate='yes'>...</mrk> why not use <mrk its:translate='yes'>?
The answer: ..."
And I proceeded to explain why it was *not possible* in this instance.
> Also, one premise we defined is not to allow extensions
> for things XLIFF already provides.
> If XLIFF defines the "translate" attribute, a replacement
> from ITS should not be allowed.
In this occurrence the idea was to see if the attribute of a standard namespace (its:translate) could or could not replace (not "exist in addition to") the 'translate' we currently use. It would not be an extension, it would be simply using different namespaces for the core, just like we use xml:lang and xml:space.
In the case of its:translate it's not possible IMO.
But technically I don't see anything wrong with re-using different specialized standard namespaces--when it's applicable--to compose the core (or a module). We are not talking at all about custom extensions here.
One of the guiding principles of the inline markup requirements is to re-use when it make sense: (https://wiki.oasis-open.org/xliff/OneContentModel/Requirements#ConsiderotherStandardsratherthanre-inventingthewheel).
> And don't force me to use ITS when a simple
> attribute like "translate" can be included in XLIFF.
So we can use xml:lang but not its:someattribute? Even when both part of W3C Recommendations... It's an interesting viewpoint. I'd like to hear the rationale behind that, some day when we have time. But I'm afraid I won't get into the debate today: I'm in vacations since a few minutes... :)
Happy July to all.
Cheers,
-yves