Response to ECMAScript Proposal

Mon Sep 12 16:35:24 PDT 2011

(- 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.

> 12. септембар 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.
>
>         Regards,
>         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:
>
> 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.

>         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:
> 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?

>         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.

>         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
>         direction.
>
>
>     See #3
>
>
> -- 
> Nebojša Ćirić

Thanks again for the quick feedback.

Steven R. Loomis (IBM)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110912/3277c9da/attachment-0001.html>