W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

RE: Directionality Scope/inheritence issue (same as translatability)

From: Yves Savourel <ysavourel@translate.com>
Date: Thu, 23 Mar 2006 09:55:05 -0700
To: <public-i18n-its@w3.org>
Message-ID: <000b01c64e9a$89359c80$8f05a8c0@Breizh>

Hi Felix, all, 

>> The only difference is that a selection using a local rule 
>> stops when it finds an existing local rule, while the global 
>> rule overrides any global rule already set (and does not 
>> assume anything about local rules since they will be processed 
>> after the global rules).
> or put it differently: Global rules don't know inheritance in 
> the document tree. We could try to teach them, but I don't know how ...

Mmmm... Maybe we need to make sure we are all clear on what the global rules behaves first.

If I have:

<par class='nt'>some text <b>bold text</b> end of text</par>

And a rule

<its:translateRule its:translate='no' its:selector="//*[class='nt']" />

My understanding is that the content of <b> *does not* get translated.

If so, it means global rules do know about 'inheritence' (if you define this as the fact a child element gets the ITS information
set to its parent by the rule).

>> Having a separate selector and a realize-by value that is 
>> relative XPath expression is the same as have the selector 
>> with that relative path added to the absolute root. In 
>> other words, your notation simply breaks down the absolute 
>> path. But what purpose breaking the XPath expression serves?
>> I can't think of any.
> Sorry, I would rather have only a realize-by value, s.t. like
> <its:dirRule its:dir="rtl" its:realized-by="//@dir['rtl']"/> 
> so no need to breaking the XPath expression.
> ...
> ...and I would use the attribute "its:realized-by" instead of 
> "its:selector". With "//@dir['rtl']" in the "its:realized-by" 
> attribute you describe what markup should be replaced by ITS 
> markup. With "//*[@dir='rtl']", you don't.
> You can think of the function of "its-realized-by" as a @match 
> attribute in XSLT, in a template which realizes the markup 
> replacement:

I don't think you can do this because there will be cases where the native markup will not be the same node type as the ITS
equivalent. For example: you could have a <code> element that contains non-translated data inside a <para> element. Users will want
to use the 'realize-as' with it because <code> is really equivalent to <code its:translate='no'>. So I'm not sure you can point to
an attribute in all cases. To take other data categories, we may have the reverse: for example, a rubyText-like native construct
that is an attribute rather than an element like in ITS.

Received on Thursday, 23 March 2006 16:55:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC