Response to ECMAScript Proposal
Steven R. Loomis
srl at icu-project.org
Mon Sep 12 16:35:24 PDT 2011
On 09/12/2011 03:19 PM, Nebojša Ćirić wrote:
> 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.
> 12. септембар 2011. 14.52, Mark Davis ☕ <mark at macchiato.com
> <mailto:mark at macchiato.com>> је написао/ла:
> A few comments from my perspective.
> /— 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
> a bit internally and came up with some response. Please feel
> free to respond to me or as appropriate.
> 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
> 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:
> 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
> 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
> 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
> potentially get navigator.language at some point.
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?
> 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
> 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
> 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.
> 9. No Parsing capability, just formatting.
> Yes, known limitation (see #3). Formatting is a much
> higher-frequency operation than parsing.
> 10. No way to format dates/numbers based on a pattern.
> Yes, known limitation (see #3).
> 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).
> 11. Overall this proposal seems to be much scaled back from
> the earlier proposals. Please comment on the planned future
> See #3
> Nebojša Ćirić
Thanks again for the quick feedback.
Steven R. Loomis (IBM)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss