Comment #15 on issue 459 by [email protected]: localeCompare
implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459
One way to deal with issues raised by iposva is to allow JS programmers to
explicitly
specify the locale (BCP 47. which does allows sorting order variations
within a
locale like German phone book vs German dictionary). There's a need for yet
another
parameter for the 'collation strength' (primary, secondary, tertiary and
so forth.
case-sensitivity, whether or not to take into account accents, etc)
However, I'm afraid taking this to ECMA may not work very well (it takes
too long for
one thing if I'm not mistaken). I agree with erik on that.
I wonder if W3C WebAPP WG can be a better venue for this and related issues.
issue 180 is about toLocaleDateString and other date/time format APIs
(chrome bug :
http://crbug.com/3607) not honoring the UI locale of Chrome, but again the
current
API are too limited to be useful.
OpenSocial defines some i18n APIs, but they're limited in other aspects (see
http://wiki.opensocial.org/index.php?title=Gadgets.i18n_(v0.9)). So, I
proposed
exposing some i18n APIs (that Chrome has a full access to) in Javascript
(but not as
a part of the language standard) at
http://crbug.com/28604
BTW, there are two Chrome bug reports on this issue ( http://crbug.com/19254
and http://crbug.com/35600 ) because we're different from all other
browsers (which
do honor the UI locale of a browser).
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
