Re: Comment on Widget Interface...

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


-- 
Marcos Caceres
Opera Software ASA, http://www.opera.com/
http://datadriven.com.au

Received on Tuesday, 5 October 2010 20:23:50 UTC