serge-community / zing

Translation server for continuous localization.
https://evernote.github.io/zing/
GNU General Public License v3.0
59 stars 32 forks source link

Provide consistent locale-specific number formatting #59

Open julen opened 8 years ago

julen commented 8 years ago

In some places .toLocaleString() has been introduced.

This method accepts a locale code as its first parameter (even an array of locales for matching). We must set this parameter to the UI locale in effect and probably provide a thin wrapper formatting function so that we get the same experience everywhere. Otherwise, the OS locale will always be used, and has high chances to mismatch Zing's UI locale.

iafan commented 8 years ago

Note that we don't want a server-side-based consistency. Numbers are formatted according to user current locale settings, and that's the desired behavior. We only need to display numbers consistently for a given user throughout the site (to make sure that all numbers we display are passed through .toLocaleString(). Same applies to dates and currencies.

iafan commented 8 years ago

Otherwise, the OS locale will always be used

While this is exactly the behavior I'd ideally like to get, it turns out using .toLocaleString() without parameters might default to en-US in some browsers. We could use navigator.language to determine the preferred language, but this is ultimately not the same thing as OS-wide preferred locale settings. Having said that, I'd prefer to keep things simple and use .toLocaleString() unless locale formatting preferences are implemented for the user (but I believe this is not worth the trouble).

One can play around with this jsfiddle to compare results across browsers.

julen commented 7 years ago

For me a simple .toLocaleString() is what offers the worst results. It uses en-US both in Chrome and Firefox; Safari says it's using my own system locale, but the formatting doesn't match.

Chrome on the other hand doesn't seem to detect my preferred language in navigator.language. Firefox at least does, and displays the formatting as I would expect it.

I wouldn't consider a trouble implementing this as a user preference, but rather a need, as it's the most reliable way to get an experience that matches the user's expectations (same as with timezones). Zero configuration would be ideal for sure, but it doesn't provide acceptable results IMHO.

iafan commented 7 years ago

I don't think people switch browsers often, so the end result is not that bad — it is still consistent within a browser and more readable than with no formatting at all. I'm not saying that we shouldn't implement this preference (and this indeed seems like the only option can ultimately offer the best results), but I also have a feeling that even if we spend time implementing this setting, little to no people will bother to change it. So I'd make the zero configuration to work reasonably. If you want to make a wrapper function and use .toLocaleString(navigator.language) and if that provides slightly better results at least in some browsers, let's do this first.