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 :-)
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 >>> >>> >> >> >
