3

This fiddle return the correct value of "5,5" in both IE and FF but in Chrome it returns "5.5"

Fiddle: http://jsfiddle.net/4tvSH/

Globalize.culture("sv-SE");
alert(Globalize.format(5.5));

Is there a bug in the Globalize plugin?

edit:

This is strange, in Web.Config (MVC3) I have this

<globalization enableClientBasedCulture="true" />

Which means that the client sets the culture, both chrome and FF reports sv-SE, so the Globalize culture loaded is sv-SE like in the fiddle above.

But if i debug the code above on line 767 in Chrome

return culture.name.length ? value.toLocaleString() : value.toString();

value.toLocaleString() will return en-US format

This works, but its a hack..

//Fixes a bug in Globalize/Chrome where Globalize.format returns en-US format even with sv-SE
if($.browser.webkit == true) {
    Globalize.orgFormat = Globalize.format;
    Globalize.format = function(value, format) {
        if(format == null) {
            format = "N";
        }

        return this.orgFormat(value, format);
    };
}
Anders
  • 17,306
  • 10
  • 76
  • 144
  • format="N" differs from format=null because all numbers have 2 digits after the decimal separator even if they are 0. – Roberto Jul 19 '12 at 12:29

1 Answers1

0

Chrome does indeed seem to handle value.toLocaleString() in a different way from firefox, however I believe this should be considered as a Globalize bug.

I have corrected this behaviour in my Globalize fork, which was as simple as removing that toLocaleString iirc.

Razor
  • 27,418
  • 8
  • 53
  • 76
  • Just as a note, my fix has less performance impact on slower browesers like IE7. IE has correct behavior with the tostring method and if you use the custom globalize code in a datatable it will be reallt slow with just over 30 items in the table – Anders Jun 04 '12 at 07:07