On Mon, 04 Oct 2010 23:32:46 +0200, Scott Wilson
<scott.bradley.wil...@gmail.com> wrote:
Actually, just to totally contradict myself, we implemented the locale
attribute of the Widget interface and forget to take it out again when
it was removed from the spec :-)
The functionality Addison wants would most logically be defined in The
Widget Interface, no?
cheers
On 30 Sep 2010, at 20:37, Scott Wilson wrote:
On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
Hi Art,
No, I don't think it does. While the means by which the (user/system
default) locale is determined may be implementation dependent, it is
still necessary that the runtime determine what it is. The Widget
interface thus needs to provide access to what it is. Otherwise how
can the script calling the interface determine what language it is
getting for the name, shortname, etc.? Or what locale the widget is
actually using in its runtime? Obtaining this would be useful if the
script were to request content or data formatting remotely (or do so
locally using the JavaScript I18N extension that is being developed).
At present in Wookie we generate a widget instance using localization
parameters passed to our API, so the information you get from the
widget interface will be localized. However for things like making AJAX
calls to other services, you are correct that this information will not
be available in the Widget runtime - seems like a reasonable UC.
Thanks,
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.bars...@nokia.com]
Sent: Thursday, September 30, 2010 6:18 AM
To: Phillips, Addison
Cc: public-webapps
Subject: Re: Comment on Widget Interface...
Hi Addison,
On 9/7/10 6:06 PM, ext Phillips, Addison wrote:
Hello Webapps WG,
(This is a personal comment and is not necessarily indicative of
the I18N WG's opinion)
In Section 5 (The Widget Interface), the interface provides for
retrieving values such as 'name', 'shortName', etc. In Widgets P&C,
these can be localized in the configuration document (I assume that
the configuration document in this document means the same document
as P&C??). There is no mention of whether or how this value is
localized or if the locale/language is subject to programmatic
control (I assume not, since it is not mentioned).
Could there be an explicit mention of the language/locale and how
it interacts with user-agent? Can/should there be an accessor for
language? How about a way of querying the value by locale?
Support for locale was part of the Widget Interface spec but as we
worked through the localization model for the Packaging and
Configuration spec, we decided to remove it (at least for this
version
of the spec). The Packaging spec includes the gist of the
rationalization for this decision:
[[
http://www.w3.org/TR/widgets/#step-5--derive-the-user-agents-locale
As there are numerous ways a user agent can derive the end-user's
preferred languages and regional settings, the means by which those
values are derived are beyond the scope of this specification and
left
up to the implementation.
]]
I suppose one could argue the Widget Interface implies the above
indirectly (via the reference to P&C spec). However, I don't see
any
harm if the above text were copied into the Interface spec. Would
doing
so address your concern?
-Art Barstow
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
