elixir-cldr / cldr_currencies Goto Github PK

I ran into an unexpected error from current_currency_for_territory.

iex(1)> Cldr.known_territories() |> Enum.map(fn t -> t |> IO.inspect() |> Cldr.Currency.current_currency_for_territory end)                                                                                                            
:"001"
# .. cut for brevity
:AO
:AQ
** (ArgumentError) errors were found at the given arguments:

  * 2nd argument: not a tuple

    :erlang.element(1, nil)
    (ex_cldr_currencies 2.14.2) lib/cldr/currency.ex:869: Cldr.Currency.current_currency_for_territory/1
    (elixir 1.14.0) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
    (elixir 1.14.0) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2

I'm sure the nil where it finds no currency is a normal case and the function signature would make me think it should return nil for that case.

https://hexdocs.pm/ex_cldr_currencies/2.6.0/Cldr.Currency.html#current_currency_for_territory/1

Offending elem(1):

After adding the :extra_return option to my dialyzer warnings, I started getting strange errors relating to Cldr in my projects. It turns out that the culprit is the fact that the type spec of Cldr.Currency.Backend.currency_history_for_locale/1 does not match that of Cldr.Currency.currency_history_for_locale/1. Specifically, Cldr.Currency.currency_history_for_locale/1 returns {:ok, map()} on success, but the backend variant typespec says it just returns map().

The fix is straightforward, but I don't know how to go about writing a good test.

There are problems in other Cldr libraries as well, specifically I've found a similar issue with Cldr.Number.to_string!/2 and perhaps a few others. I'll open up issues in those repos as well.

In conversation with @lawik the requirement for a mapping from territories to current currencies emerged. The subsequent intent is to resolve the display names for both the territory and the currency. Cldr.Currency.display_name/2 will return the display name for the currency code.

To resolve the territory display name the Cldr.Territory.from_territory_code/3 will do the job but its API is different from the rest of ex_cldr. I will submit a PR to that lib to provide a Cldr.Territory.display_name/2 function to make this more uniform.

As of commit 347145 the functions Cldr.Currency.current_territory_currencies/0 and MyApp.Currency.current_territory_currencies/0 are added to return a mapping from a territory code to a currency type.

Example

iex> MyApp.Cldr.Currency.current_territory_currencies()
%{
  VN: :VND,
  MA: :MAD,
  NU: :NZD,
  LT: :EUR,
  ST: :STN,
  ...
}

Now we have the base data we can at least localise the currency name. The territory name is not in scope for ex_cldr_currencies so it can't be resolved here. Likely the most appropriate place is to provide a function in ex_cldr_html since it can (optionally) include both libraries.

Localising the display name of the currency

Now that we have the proper mapping we resolve the display name - at least for the currency.

iex> MyApp.Cldr.Currency.current_territory_currencies() 
...> |> Enum.map(fn {territory, currency} -> 
...>   {territory, Cldr.Currency.display_name!(currency)} 
...> end)
[
  EA: "Euro",
  AF: "Afghan Afghani",
  AU: "Australian Dollar",
  TV: "Australian Dollar",
  CS: "Serbian Dinar",
  ...
]

# Or in other configured locales
iex> MyApp.Cldr.Currency.current_territory_currencies() 
...> |> Enum.map(fn {territory, currency} -> 
...>   {territory, Cldr.Currency.display_name!(currency, locale: "de")} 
...> end)
[
  EA: "Euro",
  AF: "Afghanischer Afghani",
  AU: "Australischer Dollar",
  TV: "Australischer Dollar",
  CS: "Serbischer Dinar",
  ...
]

Next Steps

1. Create a PR for ex_cldr_territories to also provide a display_name/2 function to make it easy to resolve the display name for a territory
2. Implement a select function for the {territory, currency} combination in ex_cldr_html

6f5d0b4 breaks a project with ex_doc configured with the only option set. Fixed by adding override: true in my own project.

What's the benefit of having ex_doc as a dependency other than in dev mode here?

Dependencies have diverged:
* ex_doc (Hex package)
  the :only option for dependency ex_doc

  > In mix.exs:
    {:ex_doc, "~> 0.23", [env: :prod, repo: "hexpm", hex: "ex_doc", only: [:dev, :test], runtime: false]}

  does not match the :only option calculated for

  > In deps/ex_cldr_currencies/mix.exs:
    {:ex_doc, "~> 0.18", [env: :prod, hex: "ex_doc", repo: "hexpm", optional: false]}

  Remove the :only restriction from your dep
** (Mix) Can't continue due to errors on dependencies

Hello!

Thank you for your hard work.

It seems docs related to custom currencies can be improved. It's not clear why MFA function accepts two arguments. Also, it's not clear what this callback should return

For Cldr.Currency:

• annotated?/1
• current?/1
• expand_filter/3
• historic?/1
• tender?/1
• territory_currencies/1
• territory_currencies!/1
• unannotated?/1

The GitHub link for the project on hex.pm has a misspelling in the URL so it returns a 404 page; it appears to be missing an "r" in currencies.

Hi, first of all thank you for the wonderful library!

I was hoping that you could give a brief explanation of the %Cldr.Currency{} fields, in particular, cash_digits, cash_rounding, digits, iso_digits and rounding.

For some background, we have an in-house library to calculate payment distribution for our ecommerce application. Previously, the library was hardcoded to always round to two decimal places since we only supported these types of currencies. However, now we are adding support for JPY into our application. I made changes to the payment library to accept an option with the number of decimal places should be used for rounding. However, I am a bit confused which field should be used to grab the correct value in the application before calling out to the library.

By just looking at the output of Money.Currency.currency_for_code/1 for "JPY" or "USD" for our use case it has to be either cash_digits, digits or iso_digits. I'm currently using iso_digits to determine the number of decimal places to round with. Is this correct?