Skip to content
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

Proposal for Currency List #376

Closed
longlho opened this issue Sep 20, 2019 · 7 comments
Closed

Proposal for Currency List #376

longlho opened this issue Sep 20, 2019 · 7 comments

Comments

@longlho
Copy link
Collaborator

longlho commented Sep 20, 2019

Hi there,

Has there been any proposals on exposing Currency List and/or has this been discussed before? This is a very common use case in the finance world where list of currency (along w/ symbols & display names) has to be hydrated from the server side.

Thanks!

@sffc
Copy link
Contributor

sffc commented Sep 20, 2019

Currency display names are in https://github.com/tc39/proposal-intl-displaynames

For symbols, the problem is that there's no such thing as a universal symbol for a currency. The symbol depends on several factors:

  • Locale (the symbol can vary by locale, e.g. "$" vs "US$")
  • Numbering system (in Arabic, for example, the symbol when using Arabic-script numerals is different than when using Latin-script numerals)
  • Display context (in KRW, in some contexts you use "₩" and in others "원")
  • Position/format (sometimes the symbol is before, sometimes after, and sometimes even in the middle, like "100$50" for 100.50 CVE)

Can you provide more context for where this feature would be both useful and the correct thing to do from an i18n perspective?

@longlho
Copy link
Collaborator Author

longlho commented Sep 21, 2019

I think I'm talking about:

Google
image

Yahoo Finance
image

TransferWise
image

whereas in order to populate the list we typically have to hydrate down a Map<ISOCurrencyCode, Name> where name is localized and can be long/short/narrow. If the currency can be mapped to a country that'd be great as well. Does that make sense?

Reference:
https://github.com/unicode-cldr/cldr-core/blob/master/supplemental/currencyData.json
https://github.com/unicode-cldr/cldr-numbers-full/blob/master/main/de/currencies.json

@sffc
Copy link
Contributor

sffc commented Sep 21, 2019

If an application has a fixed list of supported currencies, they will be able to do something like,

const currencyCodes = ["ARS", "AUD", "BGN", "BRL", "CAD"];
const intlNames = new Intl.DisplayNames(undefined, { type: "currency" });
const currencyNames = currencyCodes.map((currencyCode) => {
  return intlNames.of(currencyCode);
});

Is there something you'd like to see that isn't already supported by the Intl.DisplayNames proposal?

@longlho
Copy link
Collaborator Author

longlho commented Sep 21, 2019

Ah that'd take care of the display name part. Thanks!
Ideally I'm also looking for which country uses which currency as well & default currency fraction (e.g for VND since smallest bill is 100VND it always has 0 fractions, vs USD)

@zbraniecki
Copy link
Member

You're looking for a database, not API. I don't think we should grow the API surface to cover geopolitical data like population, major languages or currencies... I think it's out of scope of JS core API

@sffc
Copy link
Contributor

sffc commented Sep 21, 2019

For what country uses the currency, that's specified by ISO as the first two letters of the currency code, so you can already infer that.

For default fraction digits, I'm not excited about exposing that in API. We've had problems before where people use the CLDR default fraction digits in order to decide the precision to store in a database, for example, and then the CLDR data changes, and it causes problems. Also, not all browsers will have the same data, and we should be conservative when adding ILD features that affect people's money. It's hard to think of a legitimate use case for that information that isn't already covered by formatToParts on Intl.NumberFormat, which respects the default fraction digits.

@longlho
Copy link
Collaborator Author

longlho commented Sep 22, 2019

gotcha tks for the context!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@longlho @zbraniecki @sffc and others