I'm not sure whether this is a valid bug, because I'm not sure that localeCompare is meant to be consistent across platforms. The following testcase: "\u767E\u5EA6\u77E5\u9053".localeCompare("Creative Commons"); returns 1 on Windows and Linux trunk builds. It returns -90 on Mac trunk builds. Tony noticed this because it caused the search engine ordering code, which uses localeCompare to sort the engines, to behave differently on Linux compared to Mac.
Oh, I guess the browser probably ends up using the implmentation at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsJSEnvironment.cpp&rev=1.394#720 ? Probably not a JS bug, then...
Indeed, I get the same result with the following testcase: var localeService = Components.classes["@mozilla.org/intl/nslocaleservice;1"]. getService(Components.interfaces.nsILocaleService); var localeCollator = Components.classes["@mozilla.org/intl/collation-factory;1"]. getService(Components.interfaces.nsICollationFactory). CreateCollation(localeService.getApplicationLocale()); localeCollator.compareString(0, "\u767E\u5EA6\u77E5\u9053", "Creative Commons");
Assignee: general → smontagu
QA Contact: general → i18n
Good catch! It looks like we are still using the old OS9 collation routines, not the Unicode-aware ones for OSX. The latter were checked in back in bug 95282, but I haven't done the code archæology to figure out if they were never turned on in the build or turned off accidentally at some later date. Turning them back on at this point is rather scary, since I don't know how much testing they've ever had. Can we target this for after 1.9?
I tried turning on the Unicode collation and almost immediately ran into crashes, and in fact it turns out that it was turned off in bug 128323 because of crashiness.
Jungshik went down this road a few years ago...
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 255192
You need to log in before you can comment on or make changes to this bug.