Hello Art, Marcos, and Webapps,
During our teleconference yesterday [1], I was tasked with formally replying to
this request on behalf of the Internationalization WG.
I would still like to see the 'locale' field restored to the interface. It's
important to be able to query which locale the widget is running in (especially
in the face of upcoming ECMAScript internationalization changes) so that the
caller can match it if necessary.
I agree with Marcos's approach to returning the @lang. Marcos concluded with
this comment:
> >
> > 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/
Most user-agents have implemented the Unicode Bidirectional Algorithm (which is
what Cal is describing), so that isn't the issue, so much as the fact that
sometimes the algorithm needs a little help. The problem is that the base
direction of a string is sometimes necessary to get the correct behavior from
strings.
For excellent illustrations of this, see [2].
Using Unicode Bidi control characters is one way to manage this, but in a
markup context, the 'dir' attribute is really preferable. If you're going to
create LocalizedString, it should have both a lang and dir attribute that can
be queried. Having @dir in P&C will help the Widget engine display the string
properly too.
I look forward to seeing the resulting spec published. Please let me know if
you need any assistance from me in making progress.
Thanks,
Addison
[1] http://www.w3.org/2010/10/13-i18n-minutes.html
[2] http://www.w3.org/International/articles/inline-bidi-markup/
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)
Internationalization is not a feature.
It is an architecture.
