-- 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
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.
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
Additionally the .localeCompare() returns unexpected values in that it should only return 1, 0 ,-1 currently it is return a comparison of the char code points. "a".localeCompare("Z") should return -1 but instead returns 7 which is the charcode of "a" - charcode of "Z"
Return Value:
0 : It string matches 100%.
-1 : no match, and the parameter value comes before the string object's value in the locale sort order
1 : no match, and the parameter value comes after the string object's value in the locale sort order
Is it not possible to maybe have something like this?
var b = 'b';
b.localeCompare('ä'); // compare using whatever the user locale is
b.localeCompare('ä', 'de'); // compare using german locale, regardless of
user locale
and
var num = 123.45;
num.toLocaleString(); // returns '1.234,5' if your locale is norway (comma
decimal point, period thousand separator)
num.toLocaleString('us'); // returns '1,234.5' regardless of your locale
This would take into account both
1) those who want to actually display to the user what the user is familiar
with, and
2) those who want to display it in the format of a specific locale.
Is it not possible to maybe have something like this?
var b = 'b';
b.localeCompare('ä'); // compare using whatever the user locale is
b.localeCompare('ä', 'de'); // compare using german locale, regardless of
user locale
and
var num = 1234.5;
num.toLocaleString(); // returns '1.234,5' if your locale is norway (comma
decimal point, period thousand separator)
num.toLocaleString('us'); // returns '1,234.5' regardless of your locale
This would take into account both
1) those who want to actually display to the user what the user is familiar
with, and
2) those who want to display it in the format of a specific locale.
the fact that locale affects this is only half the problem, the other is that it isnt currently using any ICU collation, just using the character values (as mentioned above the raw UTF16 character value), thats why "
> "a".localeCompare("A"); > 32
in chrome, whereas in firefox
> "a".localeCompare('A');
-1
It seems like it would be hard to implement a subset that implemented collation properly even for just the ascii character range without just implementing the full unicode collation algorithm *, which would be a pretty massive job, if anyone has pointers / suggestions I am open to them though, the app I am building requires ICU collation, even if its only a single locale that is implemented
"The result is intended to order String values in the sort order specified
by the system default
locale, and will be negative, zero, or positive, depending on whether S
comes before That in the sort order, the
Strings are equal, or S comes after That in the sort order, respectively."
The result must be -1, 0 or 1, just as other browsers have implemented it.
Please fix it. This should be a bug not a feature request.
Reading a few paragraphs further in the spec: "The actual return values are
implementation-defined to permit implementers to encode additional
information in the value, but the function is required to define a total
ordering on all Strings and to return 0 when comparing Strings that are
considered canonically equivalent by the Unicode standard." So there is
*no* requirement for -1 and 1, and any JavaScript code depending on this is
simply wrong.
It does not directly address the behavior of the existing localeCompare()
with a single input param. Instead, it provides an enhanced API with a
second parameter for 'locale' name. The same is true of toLocaleString (for
objects like Date).
The implementation above does not yet implement localeCompare() with a
locale parameter, yet. It can be implemented in multiple ways. Either
changing V8 directly (with a dependency on v8-i18n) or v8-i18n can override
localeCompare() without touching v8 proper.
To be precise, the behavior in v8 won't change with the aforementioned CL.
However, in Chrome, it'll behave as expected because Chrome has v8-i18n
that overrides toLocaleXXX with a correct locale-sensitive version.
-- You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Confirmed v8-i18n does indeed correct the behavior.
-- You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
