- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Tue, 5 Oct 2010 12:12:20 +0100
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: "Addison Phillips" <addison@lab126.com>, "Arthur Barstow" <art.barstow@nokia.com>, "public-webapps WG" <public-webapps@w3.org>, public-i18n-core@w3.org
On 5 Oct 2010, at 01:28, Charles McCathieNevile wrote: > On Mon, 04 Oct 2010 23:32:46 +0200, Scott Wilson <scott.bradley.wilson@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? It used to be: http://www.w3.org/TR/2009/WD-widgets-apis-20090423/ It was removed in later revisions. > > 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.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 >>>>> >>>>> >>>> >>>> >>> >> >> > > > -- > 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
Received on Tuesday, 5 October 2010 11:36:18 UTC