Support all ISO 4217 currencies and locales

[britannio]

Alternatively, the currencies listed in https://support.google.com/googleplay/android-developer/answer/9306917 would suffice for my use case.

The missing currencies from that link are:

AED CLP COP CRC CZK DKK EGP HKD HUF IDR ILS LBP MYR PEN PKR RON SAR SEK SGD THB UAH UYU VND

[britannio]

https://github.com/bengourley/currency-symbol-map/blob/master/map.js may help

[bsutton]

Would you be door to submit a pr with an updated CommonCurrencies class.

I don't have the time to do this at the moment.

[britannio]

I'll look into it this week!

[britannio]

So far I've found https://github.com/google/closure-library/blob/master/closure/goog/i18n/numberformatsymbols.js based off of the CLDR.

[bsutton]

If your are going to port the code check the licence is compatible.

[bsutton]

I would be great if someone could help build out a full set of iso code.

[britannio]

I found https://pub.dev/documentation/intl/latest/intl/NumberFormat/NumberFormat.simpleCurrency.html which supports my use case. The intl package has ISO 4217 data that would be useful here.

[luissalgadofreire]

If I understand correctly, all that is required is to add more code snippets like the below to the CommonCurrencies class:

/// Australian Dollar
  final Currency aud = Currency.create('AUD', 2,
      pattern: 'S0.00',
      country: 'Australian',
      unit: 'Dollar',
      name: 'Australian Dollar');

There are a few sources out there with enough information to fill the above with at least close to all the ISO 4217 currencies.

This repository, for instance, has a MIT license and provides a JSON file with a format like:

{
  'AMD': {                          // ISO 4217 currency code.
     'name': 'Armenian Dram',       // Currency name.
     'fractionSize': 2,             // Fraction size, a number of decimal places.
     'symbol': {                    // Currency symbol information.
         'grapheme': 'դր.',         // Currency symbol.
         'template': '1 $',         // Template showing where the currency symbol should be located
                                    // (before or after amount).
         'rtl': false               // Writing direction.
     },
     'uniqSymbol': {                // Alternative currency symbol. We recommend to use it when you want
                                    // to exclude a repetition of symbols in different currencies.
         'grapheme': 'դր.',         // Alternative currency symbol.
         'template': '1 $',         // Template showing where the alternative currency symbol should be
                                    // located (before or after amount).
         'rtl': false               // Writing direction.
     }
  },
  ...
}

The accompanying library actually provides a formatter based on the above JSON.

I'll investigate a little further to validate and come back with a proper source.

If I find there is viable info with an appropriate license (again, the above is MIT), I might take some time to help out.

If this goes well, I suggest then adding the possibility of creating a currency with a simple static method like:

Currency.fromCode('USD')

This will make it easy to integrate with any source that simply provides an ISO 4127 currency code.

Better yet, create a Money instance like:

Money.fromIntWithCurrency(1000, 'USD')

instead of instantiating the currency before, manually.

[luissalgadofreire]

Yet another source with MIT license. This one is much more recent and seems to have more complete base info. Sample currency info provided:

{
    "name": "Afghan Afghani",
    "iso4217": "AFN",
    "isoNumeric": null,
    "symbol": "؋",
    "subunit": null,
    "subunitToUnit": null,
    "prefix": "",
    "suffix": "؋",
    "decimalMark": ".",
    "thousandsSeparator": ",",
    "decimalPlaces": 2,
    "shortName": "Afghani"
  }

[bsutton]

Thanks for the interest.

If I understated you correctly you are proposing that we ship a json file with the package and the proposed new method parses the json file and generates a currency.

Can I suggest an alternate method.

We use the json file to generate the common currency class.

The removes the overhead of parsing json and means we don't have to find a way to ship the json file with the package.

[bsutton]

We should expand the currency to include the additional fields

[luissalgadofreire]

Hmm.

After some investigation, I think it is a problem to want to keep currency formatting in this library.

Investigating further, the localization of a currency does not depend on the currency but on the locale. That means that one currency may be displayed differently depending on the locale. One can maintain a simpler JSON file with the main representation of a currency as per its (main) source country/region; but CLDR, the international standard, maintains a JSON file per locale/country, where all currencies are referenced for each locale/country. This makes it a huge source to maintain localization, best handled by a specialized library like Intl.

I would therefore tend to use this library for its precise calculation as per currency rules; and leave formatting to more specialized libraries.

Django's PyMoney, for instance, does allow formatting. But formatting, as you can see, requires passing a locale:

>>> from moneyed.l10n import format_money
>>> format_money(Money(10, USD), locale='en_US')
'$10.00'

But, underneath, that method above is a thin wrapper of Python's known babel localization library. In their documentation, you can see the following example, where USD is formatted differently according to locale:

>>> format_currency(1099.98, 'USD', locale='en_US')
u'$1,099.98'
>>> format_currency(1099.98, 'USD', locale='es_CO')
u'US$\xa01.099,98'

I would therefore recommend focusing on the proper math of manipulating money and leaving formatting to a specialized localization library, like intl.

To be honest, my interest in money2 is solely on the calculation side of it. I will leave the formatting to Intl. Still, it would be interesting to have the currencies predefined with the allowed decimal positions for proper money handling.

[luissalgadofreire]

As an alternative, because intl exists in the Dart world, one can try to simply wrap intl's NumberFormat in money2's formatting methods, just as PyMoney uses babel.

If intl does the job well, you can provide the convenience in money2 without needing to maintain formatting rules per locale.

[bsutton]

the localization of a currency does not depend on the currency but on the locale.

I don't think your interpretation is correct.

Common currencies provides the default formatting for a specific currency.

With money, if you want to format other currencies with your locale you can do this by providing a custom format.

It does make we wonder if we need a standard method to do this.

Money.formatUsing('usd')