RE: Comment on Widget Interface...

Hi Art,

I have scheduled this topic for our telecon tomorrow.

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@nokia.com]
> Sent: Tuesday, October 12, 2010 5:16 AM
> To: marcosc@opera.com; Phillips, Addison; public-i18n-core@w3.org
> Cc: public-webapps
> Subject: 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 16:13:23 UTC