- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Thu, 30 Sep 2010 20:37:45 +0100
- To: "Phillips, Addison" <addison@lab126.com>
- Cc: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
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.barstow@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 >> >> > >
Received on Thursday, 30 September 2010 19:38:25 UTC