Response to ECMAScript Proposal

[Nebojša Ćirić]

(+es-discuss)

Hi Steven,
 I've moved the discussion to the official es-discuss list. See my comments
below.

12. септембар 2011. 14.52, Mark Davis ☕ <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>wrote:
>
>> Hello Mark and Cira,
>>
>>  We discussed the proposal <https://docs.google.com/**document/pub?id=**
>> 1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7**OVsdQBw_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.


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


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

>
>
>> 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.
>
>
>>
>> 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.
>
>
>>
>> 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ć
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110912/5b278a5d/attachment.html>