Is there a localized territory name for each country code and locale known to ex_cldr?

[linusdm]

Hello,

I tried to update the ex_cldr dependency, and I'm running into an issue. I'm using the Territory module to get a list of country codes (using Cldr.Territory.country_codes/0), and then translate the codes using a certain locale. Since the upgrade there is a problem with the country code :CQ for locale 'nl'. The country code :CQ seems to be introduced since ex_cldr version 2.37, and has a translation for locale en, but not for nl. The ex_cldr_territories dependency is unchanged, and remained at version 2.6.0.

I can easily detect that the given country code has no localized version, that's no problem. But would have expected that there is a translation for each combination of known country code and locale known to ex_cldr. But maybe that's a wrong assumption.

Thanks for taking a look!

---

Steps to reproduce in livebook:

# Investigating missing country code CQ

```elixir
Mix.install([
  {:jason, "~> 1.4"},
  {:ex_cldr, "== 2.37.0"},
  # country code `:CQ` doesn't appear in version 2.36.0
  # {:ex_cldr, "== 2.36.0"},
  {:ex_cldr_territories, "~> 2.6"}
])

Section

defmodule Sample.Cldr do
  use Cldr,
    providers: [Cldr.Territory],
    locales: ["nl", "en"]
end

cq_country_code = :CQ = Cldr.Territory.country_codes() |> Enum.find(&(&1 == :CQ))

# all is ok here
Cldr.Territory.from_territory_code(cq_country_code, Sample.Cldr, locale: "en")

# raises exception
Cldr.Territory.from_territory_code(cq_country_code, Sample.Cldr, locale: "nl")

[kipcole9]

Thanks for raising the issue @linusdm.

CLDR 42 and easier (ex_cldr version 2.36 and earlier) only "published" locales that had full data coverage. CLDR 43 consolidated all of the known locales into a single release package (loosely speaking).

Which means that ex_cldr libs need to be tolerate of data being missing. I had to make several changes in various libs to work in that way.

In this particular case, given that CQ is marked as "reserved at the request of the UK" and that it represents the somewhat self-governing island of Sark (actually, it may be the last feudal territory on earth) I'm not too surprised that translations are missing.

Nevertheless that doesn't help you! Hopefully @Schultzer can join the conversation and we can establish a policy to be applied when translations aren't available.

For now (like right now) all I can suggest is to manually omit CQ from your list before populating the translations.

[linusdm]

That's a very interesting backstory! Right now I'm totally ok with having to deal with country codes that can not be localised.

Before I said that you can easily detect if a country code has a translation for a specific locale. That turns out to be not so trivial. As far as I can see the semantics of Territory.from_territory_code/2,3 have changed since since bumping ex_cldr to version 2.37 (which is unexpected, because the ex_cldr_territory package itself didn't change). When using the from_territory_code/2,3 function you would get {:error, {Cldr.UnknownTerritoryError, "The territory :CQ is unknown"}} when passing in an unknown country code in version 2.36. But since version 2.37 the function raises with:

** (FunctionClauseError) no function clause matching in Sample.Cldr.Territory."-inlined-from_territory_code/3-"/3
    Sample.Cldr.Territory."-inlined-from_territory_code/3-"/3
...

I understand that the country code is actually known in the latest version, so the error should not be Cldr.UnknownTerritoryError. But I'd expect a different error tuple, instead of a runtime exception (this is not the banged version of the function).

This is not at all urgent :) I will omit Sark from the list of possible countries, as it's very unlikely that someone from that territory will have an address there :)

[kipcole9]

What you're seeing is an artefact of the assumption that ask data was localized for all locales. That's no longer a valid assumption. So I had to adjust a lot of libraries to recognise that fact. And @Schultzer will need to do the same for ex_cldr_territories.

Most of the ex_cldr_* libs bake the data in to pattern-matched function clauses, hence why you probably see the function clause error.

[Schultzer]

Hello,

I tried to update the ex_cldr dependency, and I'm running into an issue. I'm using the Territory module to get a list of country codes (using Cldr.Territory.country_codes/0), and then translate the codes using a certain locale. Since the upgrade there is a problem with the country code :CQ for locale 'nl'. The country code :CQ seems to be introduced since ex_cldr version 2.37, and has a translation for locale en, but not for nl. The ex_cldr_territories dependency is unchanged, and remained at version 2.6.0.

I can easily detect that the given country code has no localized version, that's no problem. But would have expected that there is a translation for each combination of known country code and locale known to ex_cldr. But maybe that's a wrong assumption.

Thanks for taking a look!

Steps to reproduce in livebook:

# Investigating missing country code CQ

```elixir
Mix.install([
  {:jason, "~> 1.4"},
  {:ex_cldr, "== 2.37.0"},
  # country code `:CQ` doesn't appear in version 2.36.0
  # {:ex_cldr, "== 2.36.0"},
  {:ex_cldr_territories, "~> 2.6"}
])

Section

defmodule Sample.Cldr do
  use Cldr,
    providers: [Cldr.Territory],
    locales: ["nl", "en"]
end

cq_country_code = :CQ = Cldr.Territory.country_codes() |> Enum.find(&(&1 == :CQ))

# all is ok here
Cldr.Territory.from_territory_code(cq_country_code, Sample.Cldr, locale: "en")

# raises exception
Cldr.Territory.from_territory_code(cq_country_code, Sample.Cldr, locale: "nl")

I @linusdm did you try out HEAD?

I cannot replicate it on HEAD, and I assume the issue stems from my forgetfulness in publishing a new release.

[linusdm]

Just tried with {:ex_cldr_territories, github: "schultzer/cldr_territories", override: true}, but unfortunately raises a FunctionClauseError, the same as with the latest released version of ex_cldr_territories.

I've created a gist that you can import in LiveBook (import from url) to make it easier to reproduce: https://gist.github.com/linusdm/a97c599c031dcab8de9fbd6163eb8c4c

[Schultzer]

Just tried with {:ex_cldr_territories, github: "schultzer/cldr_territories", override: true}, but unfortunately raises a FunctionClauseError, the same as with the latest released version of ex_cldr_territories.

I've created a gist that you can import in LiveBook (import from url) to make it easier to reproduce: https://gist.github.com/linusdm/a97c599c031dcab8de9fbd6163eb8c4c

Thanks, I've published a new release that returns an error instead of raising a function clause error if there is no translation for a territory code in the locale.

[linusdm]

Yes! Works great now. Thank you for taking the time and fixing it!