hi Addison,
On Thu, Sep 30, 2010 at 8:57 PM, Phillips, Addison <addi...@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
