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
External access to locale definitions? #8
Comments
I think it’s simplest to include them by default and allow people to optimize file sizes by making a custom build to prune functionality if they so desire. Fixed in 0.3.0! |
Fantastic. Thanks! |
Following up on this, as I decided to take the locales out of the code and instead represent them as JSON files so they can be loaded dynamically. They are published to NPM, so one option is to load them from npmcdn: https://npmcdn.com/d3-format@0.6.0/locale/zh-CN.json You can replace the “0.6.0” with any semver range, or omit the @ and range entirely if you want the latest version: |
D3 locale definitions are very convenient, thanks! |
Prior to wide-scale ES6 adoption, the locale definitions are not externally available. For example, they are not included in the built ES5 files. Only the pre-specified default locale is included. It would be helpful to be able to access the locale definitions for convenient specification and switching. (Note that this applies to d3-time-format as well.)
We recently updated datalib to support runtime locale switching (in particular, this was requested by Wikipedia folks for their Vega graph support), but this requires passing in a full JSON blob of locale settings. To make these settings accessible, one options for us is to build out a separate repo that contains a registry of locale definitions (i.e., one that can be included as a project dependency). However, that would simply replicate the work you've done here, and so seems both inelegant and prone to inconsistency due to code drift.
Any plans / thoughts in this regard? One option might be to include the locales in the build (though bloating the file size). Another might be a parallel build that exports just the locale definitions, perhaps as a single JSON file keyed by locale id.
The text was updated successfully, but these errors were encountered: