Re: Comment on Widget Interface...

  Hi Addison - our Widget Interface spec is blocked, pending feedback 
from the I18N community regarding Marcos' proposal below.

Would you please provide feedback by October 20 (the day before our next 
voice conf)?

-Art Barstow

On Oct/5/2010 12:10 PM, ext Marcos Caceres wrote:
> hi Addison,
>
> On Thu, Sep 30, 2010 at 8:57 PM, Phillips, Addison<addison@lab126.com>  wrote:
>>> Are you talking about a script using navigator.language?
>> Not really, unless you expect navigator.language to be how widget containers expose the runtime locale.
>>
>> Widget P&C describes how a widget is packaged (which can include localization) and how it is configured (what the widget container should do when it "unpackages" and runs the widget). The container determines what the locale is going to be for the widget (which, as you pointed out in your earlier reply, is implementation specific). This, in turn, affects what language the 'name' or other fields returned by the Widget Interface are in. I'm suggesting that you need to provide programmatic access to this value, which may be distinct from navigator.language. Text direction for those fields might also need to be exposed.
>>
> Ok, so there are essentially three problems we need to tackle here:
>
> 1. Exposing the actual language which was used (during Step 7 in P&C)
> to choose the localize the content for name and description (we don't
> expose). We have this bit - this is solved:
>
> [[
> 9.1.5. Rule for Getting a Single Attribute Value
> ...
>    E. Let lang be the language tag derived from having processed the
> xml:lang attribute on either element, or in element's ancestor chain
> as per [XML]. If xml:lang was not used anywhere in the ancestor chain,
> then let lang be an empty string.
>
>    F. Associate lang with result.
> ]]
>
> And similarly in section "9.1.8. Rule for Getting Text Content". [2]
>
> Essentially, for each element or attribute that is displayable, we
> have an abstract object (a so called 'localizable string)' that is
> represented as:
>
> {string: ' unicode |  ltr marker | rtl marker | lro marker | rlo marker |',
>     lang: "language tag | empty string"}
>
> 2. Given the liberal way that P&C selects languages, we could end up
> with each attribute in the widget object containing different
> languages:
>
> widget.name; /*in English*/
> widget.shortName; /*unlocalized*/
> widget.description; /*in French*/
>
> So, we basically need to extend DOMString:
>
> interface LocalizedString : DOMString {
>      readonly attribute DOMString lang;
> }
>
> Then:
>
> widget.name.lang === "en";
>
> 3. At runtime, upon getting an attribute from the Widget object (e.g.,
> widget.name), you need to display that properly. The case is:
>
> $("#somePElement).innerHTML = widget.name; //in Arabic
>
> To display it properly, we need something like the algorithm described in:
> http://www.iamcal.com/understanding-bidirectional-text/
>
>
> WDYT?
>
> [1] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-single-attribute-valu0
> [2] http://www.w3.org/TR/widgets/#rule-for-getting-text-content
>
>

Received on Tuesday, 12 October 2010 12:17:03 UTC