(- 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 ☕ <[email protected]
<mailto:[email protected]>> је написао/ла:
A few comments from my perspective.
Mark
/— Il meglio è l’inimico del bene —/
On Mon, Sep 12, 2011 at 14:13, Steven R. Loomis
<[email protected] <mailto:[email protected]>> 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)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
