Ensure number shorthands are localized

[mozgzh]

The issue

Currently, shortened formats are not localized. For example 1,000 becomes 1k, 10,000 becomes 10k but 'k' isn't the right character for thousand in many languages. Same goes for short hand time, 1 hour becomes 1h which again isn't necessarily the correct shorthand.

The solution

The goal is to use the newly minted standardized toLocaleString function provided in ECMAScript 2022 (includes polyfil that allows for including this feature in more browsers). Deferring the logic to a standard API means going forward, no more hacky and non-localized shorthands!

After changes are implemented:

• Tool tip (onHover) stats are now localized, both the date and hours stat
• Y axis is also localized
• Add basic unit tests to help ensure specific formats are being respected

English as locale, with different language stats being selected:

Ru as locale, different language stats selected:

[ftyers]

This is really great! :) One question though, does toLocaleString() depend on locale support in CLDR? If so, what will the backoff be for languages/locales not (yet) in CLDR? Also, how many of the deployed and in-progress languages are supported and how many are unsupported?

[mozgzh]

This is really great! :) One question though, does toLocaleString() depend on locale support in CLDR? If so, what will the backoff be for languages/locales not (yet) in CLDR? Also, how many of the deployed and in-progress languages are supported and how many are unsupported?

Supported languages/number formats are implementation dependent. I'd speculate that no implementation will cover all possible language conventions for number formatting. The JS Spec implementation section mentions CLDR and the limitations of the API. That being said, it will likely cover a majority of languages we currently implement.

The default for the API, if a language is not supported, is to fallback to what the current environment supports, so for browsers, it'd be the language the user has configured in their settings. However, I was thinking since the current is to default to English where we don't support the language, it might make sense (open to discussion!) to retain that default, and ensure a consistent experience across languages and allow for better testing/consistency.

[ftyers]

I checked and CLDR covers maximum around 2/3rds. Here are some of the unsupported locales.

ace ady an arn bxr cak co gom ht ie izh kaa kbd knn kpv lij mhr mos mrj nia oc pap-AW quc quy scn syr tl tw ty uby udm vec ab ba cnh cv dv gn kmr mdf myv nan-tw pa-IN rm-sursilv rm-vallader tig vot

Would it be hard to define a fallback language per locale? Or are these defined anywhere? For example, a speaker of K'iche' quc or Mapudungun arn might prefer a fallback to Spanish rather than English.

[mozgzh]

Would it be hard to define a fallback language per locale? Or are these defined anywhere? For example, a speaker of K'iche' quc or Mapudungun arn might prefer a fallback to Spanish rather than English.

For this fix, I am aiming to just improve a specific gap in localization on the language chart, so I don't know if it'd be in scope to manage fall backs for a language. That being said, if we start to notice more areas of the app that lack localization formats (time, numbers, dates, etc) for a specific demographic, we could try building something a little more robust with custom fallbacks and such. Maybe the next step will be to audit for such things and come up with a more concrete fix.

[ftyers]

In the Russian example there should be a space between the numeral and the "abbreviation" (which is not actually an abbreviation, it's just spelt out), e.g. 9месяцев = "9months" I've seen "9 мес." for "9 mo", but it might be just better to put a space between all of them. In English "9 mo" would be fine instead of "9mo" I guess. Also, is the Y-axis localised there? Should it be ч. instead of h?