[BUG] Incorrect handling of decimals in non-English locale

[Noxville]

Hey there, I've got a report from some users of a site I run that there are weirdly distorted/broken/incorrect series drawn in a simple line graph. I am unable to reproduce the bug myself, but I believe it's related/based on lang/locale since the people with the issue are all Polish.

My guess is that there's some bug that's interpreting decimal separators incorrectly; so I'm hoping this is a well-known problem with some trivial fix.

Bug behaviour: https://pbs.twimg.com/media/DkVoHqqX0AIzewF.jpg:large
Expected behaviour: http://datdota.com/ratings/top?type=glicko2

• Chart.js version 2.1.4
• Chrome and Firefox

[etimberg]

I think the issue with this is that the data is given to the chart as strings that are locally formatted. I don't have a Polish locale to test, but I did try this:

const original = 1000.02;
const localeString = x.toLocaleString('pl'); // "1000,02"
const parsed = parseFloat(y); // 1000
const coerced = +y; // NaN

My hunch is that the strings are formatted as '1000,02' that should be parsed into 1000.02. I don't think Chart.js should be responsible for this transformation since it's too heavy to apply to all users. It should be very easy to do before the data is sent to the chart. Even better would be to send the data as numbers already

[Noxville]

Hey there, thanks for looking at this @etimberg

The data isn't represented as strings, but as numbers, e.g.:

datasets: [ { data: [1936.09, 1940.55, 1962.75, 1959.32, 1955.99, 1952.77, 1949.64, 1946.60] } ]

The representation of this cannot be at fault - since the data is rendered server-side into the DOM on page load (https://gist.github.com/Noxville/9e9c698148befebc8960abcff5d1094e if you're interested to see, but basically just specific number-formatted).

[benmccann]

@Noxville can you reproduce with a newer version of Chart.js? 2.1 is pretty old

[Noxville]

Hey there @benmccann - took a bit of time to get back to you.

I have bumped the version up (2.9.3) and asked some of the affected users to test to see if it fixed anything. I also installed one of the affected languages (Polish) on my PC, and I don't have the issue.

Still an okay example page for the bug: https://datdota.com/ratings/top?type=elo64
Example of the view from the user today: https://twitter.com/KarpajDota/status/1214606409511424005

Here are some of the example machines tested on:

#1
OS: Windows 7
OS Lang: Polish
Browsers: Chrome & IE
Browser Langs: Polish

#2
OS: Windows 10
OS Lang: English
Browsers: Chrome & Edge
Browser Lang: Polish

#3 ...
Various Android & iOS mobile devices

[benmccann]

Hmm. It's strange that you can't reproduce when changing your locale to Polish. I'm not sure what we can do without a reproducible test case...

Your _datasets.gsp uses formatNumber which takes a locale. Do you think your Polish user could send you the output of view-source to verify that the dataset is really being created the same in all languages?

[kurkle]

The decimal separator comes from locale. (We use comma here in Finland too)

[kurkle]

And to add bit more data, I'm on windows 10, using english (us) in both windows and browser. regional settings are finnish. Brave works ok, but for Chrome the decimal separator is wrong. So I guess your site is determining this automatically?

[Noxville]

Hey, this is a bit baffling for me - I assumed that (primarily due to effective caching) the server-side rendered html would be unchanged no matter the locale. Was difficult for me reproduce, but clearly I was wrong. Thanks for the help everyone!