Response to ECMAScript Proposal

[Norbert Lindenberg]

A few additional comments below.

Best regards,
Norbert


>> 4. Comments show the desire for a Globalization namespace, what is the reason for this?  Why not hang the services off objects that have the desired functoin,  such as String.collator (or 'new String.Collator()'), Date.format, Number.format etc?
>> 
>> These are the results of a number of discussions and compromises over time in the working group.
>> 
>> There are couple reasons:
>> 
>> 1. Decouple our work from main EcmaScript body and make API more like a library or ES6 module.
>> 2. Limit conflicts with existing code
>> 3. Future expandability - would you hang message/plural formatting on string class? What about Calendar?
> 
>  It seems that this makes i18n a "feature, not an architecture", which is unfortunate.

It is somewhat unfortunate. One way to improve this situation might be, once the internationalization API is in good shape, to propose changes in the ECMAScript Language Specification that align with and take advantage of the internationalization API. For example, we could specify that string1.localeCompare(string2) has to return the same value as (new Globalization.Collator(new Globalization.LocaleList()).compare(string1, string2), and string1.localeCompare(string2, locale) the same value as (new Globalization.Collator(new Globalization.LocaleList([locale])).compare(string1, string2). Such a spec would give the existing locale-sensitive functionality in the Language Specification some meaning, and at the same time make clear where to look for enhanced functionality.

>> 5. Using special objects is not JavaScript-like. Why isn't LocaleList a simple array, with functions which manipulate it?
>> 
>> The reason is that it does have specific semantics, and allows for the validation of the list one time, instead of repeating it.

In the August 17, we did discuss as a goal that LocaleList functions should be able to work on generic array-like objects. It's not clear yet whether we can accomplish that. And, as Nebojša indicated, we'd have to validate array elements in every function, while the language tags in a LocaleList would be validated once.

>> 6. Why isn't there any discovery of the default locale? Suggestion, expose HTTP "accept-language" as a LocaleList.
>> 
>> A target is for web applications that need to be able to set the locale independently of the AL. (I thought we did have a way to get the AL as a LocaleList, Cira. Did that disappear, or am I misremembering.)
>> 
>> There were problems with defining default locale:
>> 1. Not all platforms are browser based (client apps, servers)
> This is true, however those platforms would still have some notion of a default locale (such as a system control panel or environment setting), or the standard could define 'None' as the 'no locale set' case.
> 
>> 2. Application developer should detect user language and pass it to the API (see http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference - JavaScript can't access acceptLanguage list) - but we could potentially get navigator.language at some point.
>   
>   But.. as you said, JavaScript can't access acceptLanguage, and it also can't access the OS locale setting in a portable way.  Therefore, you are leaving the users of your proposal with no guidance or resources as to what to provide as the locale argument - they will need to use the platform specific options referred to in     that link, including making an HTTP request (!) to find out the value of accept-language.   How much better off are we, than where we are today?
> 
>   What are you referring to with regards to navigator.language?

Actually, we agreed in the August 17 meeting that new LocaleList() would create a locale list with the default locale ("the host environment’s current locale" in ECMAScript parlance), and the way I wrote this up in subclause 7.2.2 results in a LocaleList whose property 0 contains the language tag of the default locale. This hasn't been reviewed yet, so it may still change, but I think it addresses your comment at least to some extent (you get one locale, not a priority list). A "no locale set" case wouldn't be useful because applications still need to be able to format numbers and compare strings.

We did discuss a factory method that would convert a string in Accept-Language syntax to a LocaleList; I don't recall a decision to include it in this version of the spec.

>> 7. Does not specify what behavior is where no locale is given.
>> As I recall, there are vendors that do not want to be required to provide particular behavior if no locale is set. 
> 
>  It would seem that this should then be specified to have undefined results.

Tolerance for undefined results seems very low in TC39. A better solution would be to direct implementers towards something like the CLDR root locale as the lowest common denominator.
 
>> 8. We are concerned about a client environment simulating a different locale than the one the user has specified (at the desktop level). For example, new with a locale of "ja-JP" may have different results than new() [ default locale ] if the default locale is ja-JP, IF the user has customized their locale through a control panel.  Server side JavaScript would be a different situation, however.
>> 
>> That is one of the goals, to allow use of a different locale.
> 
>  We would assume there would be a goal of being able to provide the same behaviour as the host (desktop, mobile platform, server OS, etc), as a higher frequency operation than operations involving arbitrary locales.

At least with the current wording of subclause 7.2.2, there's no difference between new LocaleList(["ja-JP"]) and new LocaleList() with ja-JP as the default locale.