Currency display based on locale

[johanjvrens]

In South Africa we use the Currency Symbol R, not ZAR, we use ZAR as the currency code.

[paulrosenzweig]

It seems like the issue here is that we always pass "en" as the locale to Intl.NumberFormat.

en

Intl.NumberFormat('en', { style: 'currency', currency: 'ZAR'}).format(123.45);
// "ZAR 123.45"

en-ZA

Intl.NumberFormat('en-ZA', { style: 'currency', currency: 'ZAR'}).format(123.45);
// "R 123,45"

I think it'd make sense to use the current locale rather than hardcoding "en".

[paoliniluis]

I believe this one is closed, so if @johanjvrens can confirm we can close this issue, thanks!

[flamber]

@paoliniluis It's still showing ZAR instead of R of Symbol on 0.38.3/master

[paoliniluis]

The plot thickens:

• just a few currencies work as they should (USD, EUR and a few more), but the issue happens also with Argentine Pesos (which should display AR$, symbol, but displays ARS, code, and many many more.
• we never use the "symbol_native" field (why?)
• tried changing the locale using MetabaseSettings.get("site-locale") in the Intl.NumberFormat() function, but didn't work, as the locale is en and not en-ZA as @paulrosenzweig states above

[noahmoss]

Another example of incorrect currency i18n: we currently support using the symbol for the Vietnamese đồng, but it should come after the number rather than before it.

The main issue seems to be that we're counting on the ability to parse the output of Intl.NumberFormat so that we can apply other format settings to the number, like decimals and separator style. This is why en is always being used as the locale.

One solution could be to let Intl.NumberFormat fully handle currency formatting. This might require disallowing most other number format settings for currencies. It also might be surprising in some cases: for example, if the current user's language is Arabic, numbers will be formatted in Arabic script:

>> new Intl.NumberFormat("ar", {style: "currency", currency: "USD"}).format(123.123)
"١٢٣٫١٢ US$"

This might not be the desired formatting to be used in an Excel export, for example, that might be intended to be read by others who don't know the language.

Maybe a decent middle ground could be to have a locale or language dropdown that allows you to choose the locale for formatting a specific column, but I'm not sure how intuitive that would be. Or a dropdown that lets you choose the desired format from a list of examples, like we have for date/time columns.

Alternatively, we could handle all currency formatting in Metabase code. This would require expanding our currency list to include info about whether the symbol is a prefix/suffix, whether there are spaces between the symbol and the number, etc. This would let us use currency symbols where they don't currently work. But this might be very error-prone and hard to maintain, and it wouldn't adapt to different locales, so we'd have to choose only one format for each currency.

[bshepherdson]

I've created a new epic #27576 to capture this issue, the prefix/suffix part Noah mentioned above, and several other problems.

tl;dr is that we have the tools to do a much better job of localizing currency values, and I want to clean them up soon.