-
Notifications
You must be signed in to change notification settings - Fork 14k
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
[feature] Global customise-able d3 locale #3972
Comments
I agree this is a nice feature,recently I encountered this problem。 |
@alanmcruickshank |
@tristix - no work around as far as I know at the moment. This feature is relatively self contained so could be a good starter-feature if you fancy having a go at it? |
FYI there's an easy way to get backend configs to the frontend. Just add the Then it should show up in the redux state on the frontend. |
Any progress on this issue @alanmcruickshank? |
I think the bigger issue here would be to align locales in Superset and D3. D3 already supports localized number and time formats. There seems to be an alignment issue between Superset and D3 locales. For example, Brazilian Portuguese in Superset is PT_BR and the D3 pt-BR. I think the most robust solution would be to have each chart call the D3 locale based on the user's Superset locale when the chart is displayed. You can see in the sources below that D3 already has everything we need, we just aren't applying it to the user's selected locale. FYI @mistercrunch and @csc5k Sources: |
Being able to use D3's time-format as @craigappl described above would definitely be helpful. |
+1 to this feature |
Any update on this issue? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue |
@tristix I have found a way to change the default locale for the number formatting in the Docker image. You need to modify the file At this point I used sed to edit that file, like in these commands:
In this way the I am able also to change the file I am afraid that even if you are not using Docker, the only way is to rebuild everything. Hope this help, waiting for the new feature. |
Thanks @PeterCahn, it worked here.
|
+1 to this feature |
@mistercrunch, please reopen this issue. |
Any update? |
1 similar comment
Any update? |
Any updates? |
For anyone coming across this the easiest way is to build a new image for Superset: Dockerfile
|
Any updates on how to override locales for months? |
Feature description
The default locale (notably for currency values) is US English. For other countries where currency might be in Euros or Pounds (or who might want to use commas or stops differently), this makes number formatting hard.
To do this we would need to set a locale for d3 before we call
d3.format()
on anything as per the docs:https://github.com/d3/d3-3.x-api-reference/blob/master/Localization.md
I think this should be an option in
superset_config.py
so that it can be optionally set for any given deployment.As a bonus point, I think it could be neat to override locales for given metrics. This could be powerful for organisations which have data in multiple currencies. For example setting one column in yen, one in euros and one in pounds. If this is easy to implement we could just do this instead of enabling a global override locale.
Potential implementation
For the basic implementation we would need to pass through a json object which was set in a config variable to each visualisation.
in
superset_config.py
(for UK):and then somewhere in the visualisation javascript we would call:
where
definition
is that JSON object which we defined insuperset.py
column level formatting
If we wanted to also allow column level formatting instructions then one option is allowing a JSON payload on the
SqlMetric
model (and somewhere on the druid metric too?) which was then passed tod3.format()
as an override locale.@mistercrunch @graceguo-supercat @xrmx - does this sound like:
a) a good idea for a feature?
b) a good idea for implementation?
c) what's the best way to pass through the global locale config to the right javascript? I assume on page load but I don't know exactly where would make the most sense. Would appreciate some guidance.
Any other feedback welcome - I'm happy to do the legwork to actually implement it because we've got enough users that would value it.
The text was updated successfully, but these errors were encountered: