Response to ECMAScript Proposal
(- icu-core)
On 09/12/2011 03:19 PM, Nebojša Ćirić wrote:
(+es-discuss)
Hi Steven, I've moved the discussion to the official es-discuss list. See my comments below.
Thanks. I've attempted to join the list at this address.
септембар 2011. 14.52, Mark Davis ☕ <mark at macchiato.com <mailto:mark at macchiato.com>> је написао/ла:
A few comments from my perspective.
Mark /— Il meglio è l’inimico del bene —/
On Mon, Sep 12, 2011 at 14:13, Steven R. Loomis <srl at icu-project.org <mailto:srl at icu-project.org>> wrote:
Hello Mark and Cira, We discussed the proposal <https://docs.google.com/document/pub?id=1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7OVsdQBw_h5ASnM&ndplr=1 <https://docs.google.com/document/pub?id=1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7OVsdQBw_h5ASnM&ndplr=1>> a bit internally and came up with some response. Please feel free to respond to me or as appropriate. , Steven ------------------------ Response to ECMAScript/JavaScript i18n proposal. 1. What are the target scenarios for this proposal? Where, how would it be used? How does it solve the problems outlined in section 4.2 of the proposal?Cira, I think it would be useful to add more of this information to the intro.
I agree.
In short, ECMAScript i18n is seriously deficient, and there is widespread need for better ECMAScript support. You can't, for example, do something as simple as sort a list of user names on a page, or format a currency value. 2. The results of globalization operations are not defined, if one implementation has different results from another, what problem is solved? It would be no better than what we have today. While it would be great to have precisely predictable results, typically it is sufficient to have reasonably good results from each browser. For example, even though for symbols and punctuation IE and ICU differ, they both sort (say) Serbian letters according to reasonable user expectations. So it is vastly better than code point order.The same problem exists with different versions of ICU. I agree with Mark, we are fine as long as you get locale acceptable result.
This is related to the discussion of #6 default locale below. The question is, what is defined as locale acceptable? Different versions of ICU are specified as collating according to a certain version of the UCA+CLDR tailorings.
3. Collation tailoring is not addressed. True. Only a subset of the overall functionality is specified in the first release. The goal was to release useful functionality in a first release, and then follow up with more functionality later (eg break-iterators, etc.)
That is helpful, thanks. Perhaps that could be noted in the proposal?
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:
- Decouple our work from main EcmaScript body and make API more like a library or ES6 module.
- Limit conflicts with existing code
- 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.
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. 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:
- 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.
- Application developer should detect user language and pass it to the API (see 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 to navigator.language?
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.
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.
A few additional comments below.
Best , Norbert
- 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:
- Decouple our work from main EcmaScript body and make API more like a library or ES6 module.
- Limit conflicts with existing code
- 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.
- 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.
- 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:
- 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.
- Application developer should detect user language and pass it to the API (see 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 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.
- 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.
- 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.
(+es-discuss)
Hi Steven, I've moved the discussion to the official es-discuss list. See my comments below.
I agree.
The same problem exists with different versions of ICU. I agree with Mark, we are fine as long as you get locale acceptable result.
There are couple reasons:
There were problems with defining default locale:
We actually had it, and I don't think it was #3 that cut it out. We just felt that pattern format is not very user friendly and that skeleton as JSON object expresses the meaning much better. It may be more verbose than dense ICU pattern but it may be easier for web developer to digest. I think that ActionScript incorporated similar solution with collation for example (preset, easy to understand enums vs strenght).