This is likely to be a large amount of work: d3-format doesn’t support specifying a locale string, and instead you’re responsible for loading your own locale definition using d3.formatLocale. It would therefore be better to using number.toLocaleString (Intl.NumberFormat) and rely on the browser’s implementation. But this would mean no longer using d3-scale’s tick format implementation.
So either we continue to use d3-format and are responsible for providing locale definitions for every conceivable locale (and almost certainly lacking parity with number.toLocaleString). Or we drop d3-format and its shorthand format specifier syntax and integration with d3-scale. 🤔
I guess the “easy” option would be to expose D3’s locale definition to the user (like Vega does), and then the user is responsible for it. Maybe that’s the best we can do in the short term but it certainly would be more satisfying if we could leverage the deep support for localization in modern browsers.
Fixes #384.
This is likely to be a large amount of work: d3-format doesn’t support specifying a locale string, and instead you’re responsible for loading your own locale definition using d3.formatLocale. It would therefore be better to using number.toLocaleString (Intl.NumberFormat) and rely on the browser’s implementation. But this would mean no longer using d3-scale’s tick format implementation.
So either we continue to use d3-format and are responsible for providing locale definitions for every conceivable locale (and almost certainly lacking parity with number.toLocaleString). Or we drop d3-format and its shorthand format specifier syntax and integration with d3-scale. 🤔
I guess the “easy” option would be to expose D3’s locale definition to the user (like Vega does), and then the user is responsible for it. Maybe that’s the best we can do in the short term but it certainly would be more satisfying if we could leverage the deep support for localization in modern browsers.