Hi Eric and Suresh,
Thanks for the comments! Some replies below, but obviously we should discuss in
more detail on Monday.
Norbert
On May 18, 2012, at 17:00 , Eric Albright wrote:
> Comments on behalf of Suresh and me:
>
> Section 6.2.4 DefaultLocale
> o We would like to be able to return a priority list here and not just a
> single item. While many implementations may have just a single item, those
> that are built on top of Windows 8 will have available a list of languages
> that the user has declared to understand instead of just a default user
> locale that we have had up until now. Since this is internal, I believe
> changing the name to DefaultLocales and returning an array will allow
> implementations to do either:
>
> The DefaultLocales abstract operation returns an array of string values
> representing a priority list of the structurally valid (6.2.2) and
> canonicalized (6.2.3) BCP 47 language tags for the host environment in
> descending order of priority. This may return a single item representing the
> current locale.
To me the default locale of an implementation and the user's preferred
languages are two different things. The default locale must be supported and a
single locale so that we can fall back to it when none of the requested locales
are supported. The user's preferred languages can be several, and they may
include languages that an implementation doesn't support.
Also, while on the client side information about the user's preferred languages
may be obtained from the operating system (or from browser preferences), that
doesn't work on the server side. Instead, there they come as part of a request
(query parameters, subdomain names, or Accept-Language) or are obtained from
databases or web services.
> · Section 12.1.1 InitializeNumberFormat
> o Step 10: When initializing NumberFormat, the internal property [[locale]]
> should point to [[dataLocale]] or [[locale]] retruned by ResolveLocale
> abstract operation. For e.g. ResolveLocale returns the following object for
> the supplied language tag ta-IN-u-nu-tamldec
>
> {
> _dataLocale : "en-US",
> _nu : "tamldec",
> _locale : "en-US-u-nu-tamldec"
> }
>
>
> Should the [[locale]] of NumberFormat point to _dataLocale or _locale ?
> According to the spec it is _locale. I think it should point to _dataLocale.
Do you mean the current spec doesn't reflect what was discussed before, or that
we made the wrong choice?
At this point, [[locale]] is specifically constructed to give the application
information about the parts of its requested language tag that are supported
and are going to be used. This was first proposed by Rich Gillam in the
2011-07-26 meeting, and documented in section 6.1.2 of my first spec draft on
2011-08-10
http://norbertlindenberg.com/ecmascript/internationalization-api.html
It then got discussed in the meeting on 2011-08-17, where the minutes have the
hint "u-co-kn=no => should show up in ROpt and RLT" and a colorful table just
above:
https://docs.google.com/document/pub?id=1-NytPBbsO7dLvt0C2psJkF1Wtt3QdKF3NQAHksF5fyc
> o Step 31: The default value for UseGrouping is set to true. Shouldn’t it
> be implementation specific default ?
Not according to what I proposed and what was accepted on 2011-08-17:
http://norbertlindenberg.com/ecmascript/internationalization-formats.html
Is there any reason why it should be?
> · Section 13.3.2 Intl.DateTimeFormat.prototype.format
> o Step 5 & 6 : NumberFormat is constructed without any options. Since this
> will construct the NF object with UseGrouping ON by default the formatted
> dates will have grouping shown for years which look odd. For e.g. we would
> see years like 2,001 instead of 2001. This should specify UseGrouping OFF.
That's indeed a bug. Thanks for finding it!
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
