Closed qsantos closed 1 year ago
OK, let's go for the toLocaleString
only. This would simplify things
Alright, I'll open a PR then! Of course, if it turns out that some users actually want the original behavior, we can always backtrack and restore the options.
Hello @m1l! I open this issue to continue the discussion following #40 regarding
useComma
anduseSpaces
.The current implementation of
formatNumber
is:Depending on
useCommaAsDecimalSeparator
, it uses the German or American locale to convert the number to a string. Then, whenuseSpacesAsThousandSeparator
is true, it replaces the thousand separators by a space.However, simply calling
v.toLocaleString()
, instead ofv.toLocaleString('de-DE')
orv.toLocaleString('en-US')
is much faster, and would already format the number correctly according to the user's locale set in their browser. For instance, in a Firefox profile set in French:My preferred resolution would be to simply switch to the default locale, and make away with
useComma
anduseSpaces
:An alternative to keep the old behavior for users who purposefully changed
useComma
anduseSpaces
would to add a switchuseDefaultLocale
. When the setting is first added, it would default totrue
, unlessuseComma
anduseSpaces
have been changed by the user. Then,formatNumber
would look like this:What do you think?