OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

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


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


Inactive hide details for Yves Savourel ---05/11/2012 09:35:32 AM---Hi all, While trying to implement the <mrk> element on my tYves 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




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