-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide consistent locale-specific number formatting #59
Comments
This covers browser table only; as we migrate to React components, let's make sure we consistently display numbers the same way.
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 |
While this is exactly the behavior I'd ideally like to get, it turns out using One can play around with this jsfiddle to compare results across browsers. |
For me a simple Chrome on the other hand doesn't seem to detect my preferred language in 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. |
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 |
While this still doesn't offer a consistent and predictable experience due to browser inconsistencies when it comes to `toLocaleString()` implementation, it is the least bad option we can easily offer for the time being. Refs. #59.
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.
The text was updated successfully, but these errors were encountered: