Re: Issue 459 in v8: localeCompare implementation differs from other browsers

[codesite...@google.com]

Comment #14 on issue 459 by christian.plesner.hansen: localeCompare
implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

Issue 622 has been merged into this issue.

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

[codesite...@google.com]

Comment #15 on issue 459 by js...@chromium.org: 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).

[codesite...@google.com]

Comment #16 on issue 459 by abyssoft: localeCompare implementation differs

from other browsers
http://code.google.com/p/v8/issues/detail?id=459

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

[codesite...@google.com]

Comment #17 on issue 459 by alexdbars: localeCompare implementation differs

from other browsers
http://code.google.com/p/v8/issues/detail?id=459

same bug here:

var sH = "Estilo";
document.write(sH.localeCompare("Brick ")); 3
document.write(sH.localeCompare("Yellow ")) -20
document.write(sH.localeCompare("Estilo")); 0

[codesite...@google.com]

Comment #18 on issue 459 by alexdbars: localeCompare implementation differs

from other browsers
http://code.google.com/p/v8/issues/detail?id=459

same bug here in Google Chrome 5/6/7:

[codesite...@google.com]

Comment #19 on issue 459 by tor.val...@gmail.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

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.

[codesite...@google.com]

Comment #20 on issue 459 by tor.val...@gmail.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

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;

[codesite...@google.com]

Comment #21 on issue 459 by veg...@chromium.org: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

Issue 1970 has been merged into this issue.

[codesite...@google.com]

Comment #22 on issue 459 by d...@arandomurl.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

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

* http://www.unicode.org/reports/tr10/

[codesite...@google.com]

Updates:
Labels: Type-FeatureRequest

Comment #23 on issue 459 by yan...@chromium.org: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

Marking as feature request as the current implementation does not violate
the spec.

[codesite...@google.com]

Comment #24 on issue 459 by paulbenn...@gmail.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

"The Spec" (ECMA -
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf)
states:

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

[codesite...@google.com]

Comment #25 on issue 459 by sven...@chromium.org: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

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.

[codesite...@google.com]

Comment #26 on issue 459 by highstr...@gmail.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

still hasn't been fixed in chrome 19.... wth, issue started on Oct 6, 2009
and it hasn't been resolved yet?

HOW IS THIS A FEATURE REQUEST? this is clearly a BUG.

[codesite...@google.com]

Comment #27 on issue 459 by bart.ver...@gmail.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

Please point out why this is a bug.

You need to apply to the implementation requirement, not to "how other
browser's" implement it.

Other browsers implemented this according to the specs. And so did Google.

[codesite...@google.com]

Comment #28 on issue 459 by js...@chromium.org: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

Despite what I wrote in comment 15, we did take this to the ECMAScript
standard group (ECMA TC39) and have made a significant progress.

See http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api for the spec
and http://code.google.com/p/v8-i18n/ for our implementation (that is a
part of regular Chrome build).

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.

Moreover, note that ECMAScript i18n module introduces intl.collator ( see
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts )
that offers more fine-grained support for collation. It's implemented in
v8-i18n project and usable in chrome canary build.

[codesite...@google.com]

Comment #29 on issue 459 by jungs...@google.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

This bug is being fixed now. See https://codereview.appspot.com/6591072/

[codesite...@google.com]

Comment #30 on issue 459 by jungs...@google.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

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.

[codesite...@google.com]

Updates:
Status: WorkingAsIntended

Comment #31 on issue 459 by yan...@chromium.org: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

yes. refer to v8-i18n.

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

[codesite...@google.com]

Comment #32 on issue 459 by abyss...@gmail.com: localeCompare

implementation differs from other browsers
http://code.google.com/p/v8/issues/detail?id=459

Confirmed v8-i18n does indeed correct the behavior.