We’ve managed to properly set the correct time zone using this guide but there’s no hint to the possibility of doing the same with other data formats.
I was wondering if there’s any way to do the same with:
- Number formatting (. for thousands and , for decimals)
- Currency formatting (€)
- Time formatting (24h instead of AM-PM)
Currently, single-number questions (i.e., scalars) can be formatted using the chart options modal to add prefixes (such as €), and to change the delimiter style (e.g., to 1.000,24). But we don’t yet have global settings for these kinds of things or for time/dates.
This issue is somewhat related: https://github.com/metabase/metabase/issues/3791
As is this one: https://github.com/metabase/metabase/issues/3201
Just managed to change my SQL query to the right format using this:
This gives me the number in 12.345,67 rather than 12,345.67
To get the currency behind the number I use concat to do it:
SELECT CONCAT (sum(amount/100), " EUR")
–> 123 EUR
Hope that helps!
The problem with that approach is that the query now returns the value as a string. So anything where you need to do any formula with your field afterwards, such as a
SUM may now return an correct value. (i.e., it may parse your 12.345,67 as 12.34567 which is not really what you intended)
True, it is not the perfect solution (I hope metabase offers those time and currency formats soon). For me it works as I use the concat and format syntax only at the very end, after I made all the calculations.
Is anybody else reading these feature requests, or are we putting them in the wrong place? It’s awfully silent here.
https://github.com/metabase/metabase/issues/7122 I guess this is the github issue you can use to check progress - it seems that something is planned for v0.30. Fingers crossed!
No, my impression is that the Metabase team is listening - and also engaging in here as they are able to. It’s just that there is a long list of open issues aka “much stuff” (here the full thing sorted by votes with those labeled
Database Support filtered out as those mostly seem to be community contributed): https://github.com/metabase/metabase/issues?q=is%3Aopen+is%3Aissue+-label%3A"Database+Support"+sort%3Areactions-%2B1-desc
So, this might all seem pretty depressing if your pet issue comes a few pages down but if you on the other hand look at the pile of already closed issues you’ll see it’s bigger. So I guess that’s just the nature of (open source) things.
edit: In addition the project has coarse grained Roadmap page on GitHub at: https://github.com/metabase/metabase/projects/1
Sorry for giving the impression of silence or that we’re not reading these, @eljakim. We definitely are. We’ve been a bit heads-down recently trying to get 0.29 out to all of you, but this specific issue is definitely one that we’ve heard a lot from our users outside of the US, and one that we do plan on addressing.
One of the other large efforts we’ve been undertaking with regard to internationalizing Metabase is making it possible for the community to provide translations for the UI, so while that doesn’t fix this particular issue, I hope it’s clear we do care about making Metabase friendly and great no matter where you’re located geographically.