Hi,
From my recollection of the discussions, the reason we decided to special treat “translate” was that it is would very often be use together with
other properties. So to keep the amount of tagging down we said that it would be an independent property of the <mrk>.
Regards,
Fredrik Estreen
From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org]
On Behalf Of Yves Savourel
Sent: den 14 maj 2012 04:24
To: 'David Walters'
Cc: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] mrk and translate
Hi David,
<mrk> does allow multiple attributes. But I’m just wondering why we treat ‘translate’ like a special case.
I’ve found a relatively easy solution to implement the current proposal, so this issue (if there is one) is less important to me now. But the question about consistency
is probably still valid.
Cheers,
-yves
From: David Walters
[mailto:waltersd@us.ibm.com]
Sent: Friday, May 11, 2012 9:07 AM
To: Yves Savourel
Cc: xliff-inline@lists.oasis-open.org
Subject: Re: [xliff-inline] mrk and translate
It seems rather restrictive to not allow multiple attributes for <mrk>. Other standards, like DITA, allow the "translate" attribute on most, if not on all elements. We might come
up with more attributes for the <mrk> element in the future, so you could be setting a precedence on how these could be handled.
David
Corporate Globalization Tool Development
EMail: waltersd@us.ibm.com
Phone: (507) 253-7278, T/L:553-7278, Fax: (507) 253-1721
CHKPII: http://w3-03.ibm.com/globalization/page/2011
TM file formats: http://w3-03.ibm.com/globalization/page/2083
TM markups: http://w3-03.ibm.com/globalization/page/2071
Yves
Savourel ---05/11/2012 09:35:32 AM---Hi all, While trying to implement the <mrk> element on my test library, I keep running into a side e
From:
Yves Savourel <ysavourel@enlaso.com>
To:
<xliff-inline@lists.oasis-open.org>
Date:
05/11/2012 09:35 AM
Subject:
[xliff-inline] mrk and translate
Sent by:
<xliff-inline@lists.oasis-open.org>
Hi all,
While trying to implement the <mrk> element on my test library, I keep running into a side effect of using <mrk> for (sometimes) two purposes.
We said that the 'translate' attribute can be always set on <mrk>. So an annotation for 'translate/don't-translate' would be:
<mrk translate='no'>text</mrk> (type='generic' is the default)
We could also have:
<mrk translate='no' type='term'>some term</mrk>
Which means the annotation a) identifies the content as a term, and b) set it to 'don't translate'.
Or we can have:
<mrk type='term'>some term</mrk>
Which means the annotation just identifies the content as a term and the translate context is not changed.
The issue with being able to always set translate is that when you write the XLIFF string it's difficult to know if it really needs to be output or not. One would need to keep a stack of the translate context to do so. That is not something easy to do in
many cases (think XSLT for example).
It would not be reasonable to always output the attribute either: that's technically fine, but users don't want to see un-necessary info (and it messes up compares).
So I wonder if our assumption that having <mrk> carry two distinct metadata at the same time is right. Maybe we should use one <mrk> for each annotation.
There would nothing wrong with saying that when <mrk> has a 'translate' attribute it can't have any other attributes (and vice-versa).
That would allow us to have one annotation per <mrk> only and avoid all the monkey-rigging currently needed to know what attributes to output.
So
<mrk translate='no' type='term'>some term</mrk>
Would be:
<mrk translate='no'><mrk type='term'>some term</mrk></mrk>
Obviously there are drawbacks as well: more <mrk> elements. Also, because we're using XSD 1.0, no way to specify this using conditional type assignment like 1.1 would allow. But "translate or type" can be expressed in our processing expectation, like other
cases for other elements.
Any thoughts?
-yves
---------------------------------------------------------------------
To unsubscribe, e-mail:
xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
xliff-inline-help@lists.oasis-open.org