On 2.8.0 a compiler warning is generated when compiling the app Cldr module:

warning: MyApp.Cldr.List.wrap/1 is undefined or private

This wouldn't be a problem but is generated when compiling the app, not ex_cldr_territories and if you have a strict no warnings policy on your code (e.g. mix compile --warnings-as-errors) like we do it fails in CI.

Unicode Consortium released CLDR version 33 today and I have updated ex_cldr, ex_cldr_numbers, ex_cldr_lists, ex_cldr_dates_times, ex_unitsandex_money` to use the new data.

There aren't any new locales but I can see there are changes and additions to territory information. I found this upgrade to have no issues in any of my code so hopefully the same for you.

Just bump your version requirements to {ex_cldr, "~> 1.5.0} and hopefully you're good to go.

Hi! Thanks for the amazing work with this lib... I was reviewing this old code today and I noticed that when calling known_territories I get an exception: No default :ex_cldr backend is configured. The same doesn't happen when calling known_languages... IIRC configuring the backend in config.exs is discouraged and I don't remember it being necessary 🤔.

defmodule MyBackend.Cldr do
  use Cldr,
    locales: ["en", "pt"],
    default_locale: "en",
    providers: [Cldr.Language, Cldr.Territory]

  def language_options() do
    languages = __MODULE__.Language.known_languages()

    languages
    |> Enum.map(fn {key, %{standard: name}} -> {name, key} end)
    |> Enum.sort()
  end

  def valid_languages() do
    languages = __MODULE__.Language.known_languages()
    Enum.map(languages, fn {key, _} -> to_string(key) end)
  end

  def location_options() do
    territories = __MODULE__.Territory.known_territories()

    territories
    |> Enum.map(fn {key, %{standard: name}} -> {name, key} end)
    |> Enum.sort()
  end

  def valid_locations() do
    territories = __MODULE__.Territory.known_territories()
    Enum.map(territories, fn {key, _} -> to_string(key) end)
  end
end

Here's the mix file:

 {:ex_cldr, "~> 2.38"},
 {:ex_cldr_languages, "~> 0.3.3"},
 {:ex_cldr_territories, "~> 2.7"}

Upgrading from 2.1.0, which passed Dialyzer fine. 2.2.0 produces this:

lib/myapp/cldr.ex:1: Invalid type specification for function 'Elixir.MyApp.Cldr.Territory':'from_subdivision_code!'/2. The success typing is (binary() | #{'__struct__':='Elixir.Cldr.LanguageTag', 'backend':=atom(), 'canonical_locale_name':=binary(), 'cldr_locale_name':='nil' | binary(), 'extensions':=map(), 'gettext_locale_name':='nil' | binary(), 'language':=binary(), 'language_subtags':=[binary()], 'language_variant':='nil' | binary(), 'locale':=map(), 'private_use':=[binary()], 'rbnf_locale_name':='nil' | binary(), 'requested_locale_name':=binary(), 'script':='nil' | binary(), 'territory':=atom(), 'transform':=map()},[{'locale',binary() | #{'__struct__':='Elixir.Cldr.LanguageTag', 'cldr_locale_name':='nil' | binary() | map(), _=>_}},...]) -> <<_:16,_:_*8>>
done in 0m33.77s
lib/myapp/cldr.ex:1: Invalid type specification for function 'Elixir.MyApp.Cldr.Territory':'translate_subdivision!'/3. The success typing is (binary(),#{'__struct__':='Elixir.Cldr.LanguageTag', 'cldr_locale_name':=binary() | #{'__struct__':='Elixir.Cldr.LanguageTag', 'backend':=atom(), 'canonical_locale_name':=binary(), 'cldr_locale_name':='nil' | binary(), 'extensions':=map(), 'gettext_locale_name':='nil' | binary(), 'language':=binary(), 'language_subtags':=[binary()], 'language_variant':='nil' | binary(), 'locale':=map(), 'private_use':=[binary()], 'rbnf_locale_name':='nil' | binary(), 'requested_locale_name':=binary(), 'script':='nil' | binary(), 'territory':=atom(), 'transform':=map()}, _=>_},binary() | #{'__struct__':='Elixir.Cldr.LanguageTag', 'backend':=atom(), 'canonical_locale_name':=binary(), 'cldr_locale_name':='nil' | binary(), 'extensions':=map(), 'gettext_locale_name':='nil' | binary(), 'language':=binary(), 'language_subtags':=[binary()], 'language_variant':='nil' | binary(), 'locale':=map(), 'private_use':=[binary()], 'rbnf_locale_name':='nil' | binary(), 'requested_locale_name':=binary(), 'script':='nil' | binary(), 'territory':=atom(), 'transform':=map()}) -> {'error',{'Elixir.Cldr.UnknownLocaleError',<<_:64,_:_*8>>} | {'Elixir.Cldr.UnknownSubdivisionError',<<_:64,_:_*8>>}}
lib/cldr/backend.ex:277: The call 'Elixir.MyApp.Cldr.Territory':from_subdivision_code(_@4::atom() | binary(),_@5::'nil' | binary()) breaks the contract ('Elixir.Cldr.Territory':binary_tag(),[{'locale','Elixir.Cldr.Territory':binary_tag()}]) -> {'ok',binary()} | {'error','Elixir.Cldr.Territory':error()}
lib/cldr/backend.ex:523: The pattern {'ok', _@6} can never match the type {'error',{'Elixir.Cldr.UnknownLocaleError',<<_:64,_:_*8>>} | {'Elixir.Cldr.UnknownSubdivisionError',<<_:64,_:_*8>>}}
lib/cldr/backend.ex:896: The call 'Elixir.MyApp.Cldr.Territory':from_subdivision_code(_@5::<<_:16,_:_*8>>,_@3::<<_:16,_:_*16>>) breaks the contract ('Elixir.Cldr.Territory':binary_tag(),[{'locale','Elixir.Cldr.Territory':binary_tag()}]) -> {'ok',binary()} | {'error','Elixir.Cldr.Territory':error()}
done (warnings were emitted)
Halting VM with exit status 2

Many APIs are using 3-letter codes instead of 2-letter equivalents. Also, all teritories have their numeric codes (not only teritories like Europe etc).

For starters we can provide these codes in the info function but I think it's possible to support all these three code formats everywhere.

This is whats need to be done for the 1.0 release.

• update mix.exs to depend on {:ex_cldr "~> 1.0"}
• write release notes
• add CHANGELOG.md

👋

These subdivisions seem to be missing from en locale:

DZ-49
DZ-50
DZ-51
DZ-52
DZ-53
DZ-54
DZ-55
DZ-56
DZ-57
DZ-58
ET-SW
FI-01
FR-BL
FR-CP
FR-MF
FR-NC
FR-PF
FR-PM
FR-TF
FR-WF
GB-NNH
GB-WNH
ID-PD
ID-PE
ID-PS
ID-PT
IN-CG
IN-OD
IN-TS
IN-UK
IS-HUG
IS-SKR
KP-15
KZ-10
KZ-11
KZ-15
KZ-19
KZ-23
KZ-27
KZ-31
KZ-33
KZ-35
KZ-39
KZ-43
KZ-47
KZ-55
KZ-59
KZ-61
KZ-62
KZ-63
KZ-71
KZ-75
KZ-79
ME-25
NL-AW
NL-CW
NL-SX
PH-MGN
PH-MGS
SH-TA
US-AS
US-GU
US-MP
US-PR
US-UM
US-VI

Copied from elixir-cldr/cldr#209

Summary

When resolving the names associated with a subdivision, such as uspr, no name is returned even though it's a valid subdivision code. This is because uspr is an alias to the territory PR (Puerto Rico). It can also be the case that a subdivision is deprecated and therefore it is also aliased.

CLDR provides a database of aliases that is returned by Cldr.Config.aliases/0 which is a map, including the key :subdivision under which the subdivision aliases are stored.

This issue is to request that Cldr.Territory.from_subdivision_code/2 resolve aliases to either base subdivision or, in situations like the above, territory code.

Suggested approach

1. Add Cldr.Territory.subdivision_aliases/0 which encapsulates the alias information. This information can be obtained at compile time from Cldr.Config.aliases[:subdivision]
2. Which resolving a subdivision, recursively resolve the subdivision name through the aliases until no more aliases are found.
3. If the result is a territory code (an uncased atom) then use that territory code. If the result is a string its a subdivision code, use the subdivision code.
4. Resolve the territory name - subdivision or territory

Subdivision alias data

Today, Cldr.Config.aliases/0 will return subdivision aliases as strings no matter whether they are territories or subdivisions. By definition, territories should be of the type t:Cldr.Locale.territory_code/0 which is an uncased atom. The following code is suggested to overcome this bug (which will be fixed in the next ex_cldr release:

  @subdivision_aliases Cldr.Config.aliases()
    |> Map.fetch!(:subdivision)
    |> Enum.map(fn 
      {k, v} when is_binary(v) ->
        if String.length(v) == 2, do: {k, String.to_atom(v)}, else: {k, v}
      other -> other
    end)
    |> Map.new()
    
  def subdivision_aliases do
    @subdivision_aliases
  end

I know this is really nitpicking, but the project description is currently pointing at https://github.com/kipcole9/cldr when it should point to https://github.com/elixir-cldr/cldr.

The following fails:

MyApp.Cldr.Territory.from_territory_code!( :de, style: :short)

@Schultzer Really appreciate your collaboration on this.

What CLDR provides

There are four sources of data that CLDR provides:

• Territory containment (common across all locales). The source data is in the cldr repo as a submodule from https://github.com/unicode-cldr/cldr-core/blob/c48314ac492abd6498875eed9e68524e92684bf2/supplemental/territoryContainment.json
• Territory Information (common across all locales) The source data is in the cldr repo as a submodule from https://github.com/unicode-cldr/cldr-core/blob/c48314ac492abd6498875eed9e68524e92684bf2/supplemental/territoryInfo.json
• Localised territory names. The source data is in the cldr repo as a submodule from (using english as an example) https://github.com/unicode-cldr/cldr-localenames-full/blob/6da7f01576bbf5116fe5f73071c6e5c30d6437ea/main/en/territories.json
• Subdivision data which contains territory names below the "country" level which is not in the ex_cldr repo.

What cldr_territories could provide

1. Localised territory names - which is where you have started. These names are only available for "country" level names (not subdivisions)
2. Territory includes - which would return the territories within a given territory. The repo includes only country level data. CLDR also includes subdivisions - some work would be required by me to include it.
3. Territory parent - the parent of the given territory - same as for inclusion
4. Territory info - returns the population, GDP, language usage etc from territory info - this isn't locale specific

API thoughts

Just some ideas for discussion (based upon the Twitter ruby cldr implementation to which we have both referred):

# Return a map of all known territories in the given locale
# @spec Cldr.Territory,known_territories(Cldr.Locale.name) :: %{territory_code: String.t, ...}
iex> Cldr.Territory.known_territories(locale \\ Cldr.get_current_locale)
%{"001": "World", TL: "East Timor", TM: "Turkmenistan", ...}

# Return the territory name for a given territory code
# @spec Cldr.Territory.from_territory_code(territory_code, options] :: String.t
iex> Cldr.Territory.from_territory_code(:GB, locale: "en")
"UK"

# Get the territories parents.  Note that a territory
# may have more than one parent
# @spec Cldr.Territory.parent(locale_name, options) :: [territory_code, ...]
iex> Cldr.Territory,parent(:GB)
[:EU, :"154"]

# Get territory subdivision
# @spec Cldr.Territory.contains(locale_name, options) :: [territory_code, ...]
iex> Cldr.Territory.contains(:EU)
[:AT, :BE, :CY, :CZ, :DE, :DK, ...]

# and for a subdivision below country.  A few challenges here:
# 1. Work required (by me) to have the data provided in the repo and in ex_cldr
# 2. Localised data (beyond english) is very sparse
# 3. The data is not hierarchical - for example it mixes (for GB) county and city names
# Personally I think this may be better deferred until a later release
# @spec Cldr.Territory.contains(territory_code) :: [subdivision_code :: String.t, ...]
iex> Cldr.Territory.contains(:GB)
["gbeaw", "gbeng", "gbgbn", "gbnir", "gbsct", "gbukm", ...]

# Get the territory info
# @spec Cldr.Territory.info(territory_code) :: Map.t
iex> Cldr.Territory.info(:GB)
%{gdp: 2788000000000, literacy_percent: 99, population: 64430400, ...}

Thoughts?

@Schultzer Had a spare moment on a plane and thought maybe adding unicode flags to cldr_territories might be worth while (I know I have a couple of use cases). I created a simple module below, happy to do a PR if that suits you.

defmodule Cldr.Territory do
  @flags File.read!("priv/flags.csv")
  Enum.each String.split(@flags, "\n"), fn line ->
    case String.split(line, ",") do
      [flag, territory] ->
        def flag_for(unquote(String.to_atom(territory))), do: {:ok, unquote(String.trim(flag))}
      [_] ->
        nil
    end
  end

  def flag_for(territory) do
    {:error, {Cldr.UnknownTerritoryError, "Unknown territory #{inspect territory}"}}
  end

  def flag_for!(territory) do
    case flag_for(territory) do
      {:ok, flag} -> flag
      {:error, {exception, reason}} -> raise exception, reason
    end
  end
end

The flags file is nothing more than:

🇦🇨,AC
🇦🇩,AD
🇦🇪,AE
🇦🇫,AF
🇦🇬,AG
🇦🇮,AI
🇦🇱,AL
🇦🇲,AM
🇦🇴,AO
🇦🇶,AQ
🇦🇷,AR
🇦🇸,AS
🇦🇹,AT
🇦🇺,AU
🇦🇼,AW
🇦🇽,AX
🇦🇿,AZ
🇧🇦,BA
🇧🇧,BB
🇧🇩,BD
🇧🇪,BE
🇧🇫,BF
🇧🇬,BG
🇧🇭,BH
🇧🇮,BI
🇧🇯,BJ
🇧🇱,BL
🇧🇲,BM
🇧🇳,BN
🇧🇴,BO
🇧🇶,BQ
🇧🇷,BR
🇧🇸,BS
🇧🇹,BT
🇧🇻,BV
🇧🇼,BW
🇧🇾,BY
🇧🇿,BZ
🇨🇦,CA
🇨🇨,CC
🇨🇩,CD
🇨🇫,CF
🇨🇬,CG
🇨🇭,CH
🇨🇮,CI
🇨🇰,CK
🇨🇱,CL
🇨🇲,CM
🇨🇳,CN
🇨🇴,CO
🇨🇵,CP
🇨🇷,CR
🇨🇺,CU
🇨🇻,CV
🇨🇼,CW
🇨🇽,CX
🇨🇾,CY
🇨🇿,CZ
🇩🇪,DE
🇩🇬,DG
🇩🇯,DJ
🇩🇰,DK
🇩🇲,DM
🇩🇴,DO
🇩🇿,DZ
🇪🇦,EA
🇪🇨,EC
🇪🇪,EE
🇪🇬,EG
🇪🇭,EH
🇪🇷,ER
🇪🇸,ES
🇪🇹,ET
🇪🇺,EU
🇫🇮,FI
🇫🇯,FJ
🇫🇰,FK
🇫🇲,FM
🇫🇴,FO
🇫🇷,FR
🇬🇦,GA
🇬🇧,GB
🇬🇩,GD
🇬🇪,GE
🇬🇫,GF
🇬🇬,GG
🇬🇭,GH
🇬🇮,GI
🇬🇱,GL
🇬🇲,GM
🇬🇳,GN
🇬🇵,GP
🇬🇶,GQ
🇬🇷,GR
🇬🇸,GS
🇬🇹,GT
🇬🇺,GU
🇬🇼,GW
🇬🇾,GY
🇭🇰,HK
🇭🇲,HM
🇭🇳,HN
🇭🇷,HR
🇭🇹,HT
🇭🇺,HU
🇮🇨,IC
🇮🇩,ID
🇮🇪,IE
🇮🇱,IL
🇮🇲,IM
🇮🇳,IN
🇮🇴,IO
🇮🇶,IQ
🇮🇷,IR
🇮🇸,IS
🇮🇹,IT
🇯🇪,JE
🇯🇲,JM
🇯🇴,JO
🇯🇵,JP
🇰🇪,KE
🇰🇬,KG
🇰🇭,KH
🇰🇮,KI
🇰🇲,KM
🇰🇳,KN
🇰🇵,KP
🇰🇷,KR
🇰🇼,KW
🇰🇾,KY
🇰🇿,KZ
🇱🇦,LA
🇱🇧,LB
🇱🇨,LC
🇱🇮,LI
🇱🇰,LK
🇱🇷,LR
🇱🇸,LS
🇱🇹,LT
🇱🇺,LU
🇱🇻,LV
🇱🇾,LY
🇲🇦,MA
🇲🇨,MC
🇲🇩,MD
🇲🇪,ME
🇲🇫,MF
🇲🇬,MG
🇲🇭,MH
🇲🇰,MK
🇲🇱,ML
🇲🇲,MM
🇲🇳,MN
🇲🇴,MO
🇲🇵,MP
🇲🇶,MQ
🇲🇷,MR
🇲🇸,MS
🇲🇹,MT
🇲🇺,MU
🇲🇻,MV
🇲🇼,MW
🇲🇽,MX
🇲🇾,MY
🇲🇿,MZ
🇳🇦,NA
🇳🇨,NC
🇳🇪,NE
🇳🇫,NF
🇳🇬,NG
🇳🇮,NI
🇳🇱,NL
🇳🇴,NO
🇳🇵,NP
🇳🇷,NR
🇳🇺,NU
🇳🇿,NZ
🇴🇲,OM
🇵🇦,PA
🇵🇪,PE
🇵🇫,PF
🇵🇬,PG
🇵🇭,PH
🇵🇰,PK
🇵🇱,PL
🇵🇲,PM
🇵🇳,PN
🇵🇷,PR
🇵🇸,PS
🇵🇹,PT
🇵🇼,PW
🇵🇾,PY
🇶🇦,QA
🇷🇪,RE
🇷🇴,RO
🇷🇸,RS
🇷🇺,RU
🇷🇼,RW
🇸🇦,SA
🇸🇧,SB
🇸🇨,SC
🇸🇩,SD
🇸🇪,SE
🇸🇬,SG
🇸🇭,SH
🇸🇮,SI
🇸🇯,SJ
🇸🇰,SK
🇸🇱,SL
🇸🇲,SM
🇸🇳,SN
🇸🇴,SO
🇸🇷,SR
🇸🇸,SS
🇸🇹,ST
🇸🇻,SV
🇸🇽,SX
🇸🇾,SY
🇸🇿,SZ
🇹🇦,TA
🇹🇨,TC
🇹🇩,TD
🇹🇫,TF
🇹🇬,TG
🇹🇭,TH
🇹🇯,TJ
🇹🇰,TK
🇹🇱,TL
🇹🇲,TM
🇹🇳,TN
🇹🇴,TO
🇹🇷,TR
🇹🇹,TT
🇹🇻,TV
🇹🇼,TW
🇹🇿,TZ
🇺🇦,UA
🇺🇬,UG
🇺🇲,UM
🇺🇳,UN
🇺🇸,US
🇺🇾,UY
🇺🇿,UZ
🇻🇦,VA
🇻🇨,VC
🇻🇪,VE
🇻🇬,VG
🇻🇮,VI
🇻🇳,VN
🇻🇺,VU
🇼🇫,WF
🇼🇸,WS
🇽🇰,XK
🇾🇪,YE
🇾🇹,YT
🇿🇦,ZA
🇿🇲,ZM
🇿🇼,ZW

CLDR 35 is out and I've published ex_cldr version 2.6 which uses that data. I note there are updates to territory data in the release. No release for cldr_territories should be required since you're using ~> 2.0 as the version dependency. So feel free to close the issue. I bumped minor version only because the data that is returned by some functions is data dependent on CLDR release.

I think the base of cldr is stable enough to have {:ex_cldr, "~> 1.0"} instead of {:ex_cldr, "~> 1.0.0"}. This way one can use 1.2 without the need to override the version requirements for all packages.

@Schultzer @kipcole9

In my use-case there's a need for abbreviated US state names and I don't see the ex_cldr_territories supporting this. Those are considered subdivisions in CLDR so I wonder if you guys have any intention to add the subdivision abbreviations in the future, for if not, I'll do it in my app on an on-demand basis.

For the time being I'm simply splitting the "us" prefix from the rest of the subdivision string and using the remaining part in upper case. This works for the US subdivision codes as they derive from the state name abbreviations, but it certainly won't work with I'd say vast majority of other territories and their subdivisions.

I'd also like to hear your thoughts on this one in general.

Thanks,

Damir

@Schultzer @kipcole9

First of all, thanks for the hard work on i18n and l10n.

Can the territory extend with nationality? I already looked at the project CLDR, but I didn't find it.

I recently started getting this dialyzer failure:

mix dialyzer



deps/ex_cldr_territories/lib/cldr/backend.ex:465:pattern_match
The pattern can never match the type.

Pattern:
{:ok, _}

Type:
{:error, {atom(), binary()}}

________________________________________________________________________________
deps/ex_cldr_territories/lib/cldr/backend.ex:486:pattern_match
The pattern can never match the type.

Pattern:
{:ok, _}

Type:
{:error, {atom(), binary()}}

________________________________________________________________________________
deps/ex_cldr_territories/lib/cldr/backend.ex:543:pattern_match
The pattern can never match the type.

Pattern:
{:ok, _}

Type:
{:error, {atom(), binary()}}

_______

versions:
elixir 1.17.0-rc.0
erlang 27.0

lib versions:
dialyxir 1.4.3
ex_cldr 2.38.1
ex_cldr_territories 2.9.0

elixir: 1.16.2
erlang: 26.2.4
OS: MacOS 14.4.1

I'm running into issues compiling this package after updating to the latest releases of ex_cldr. I get the following error message.

==> ex_cldr_territories
Compiling 3 files (.ex)

== Compilation error in file lib/cldr/territory.ex ==
** (Protocol.UndefinedError) protocol Enumerable not implemented for :AW of type Atom
    (elixir 1.16.2) lib/enum.ex:1: Enumerable.impl_for!/1
    (elixir 1.16.2) lib/enum.ex:166: Enumerable.reduce/3
    (elixir 1.16.2) lib/enum.ex:4396: Enum.map/2
    lib/cldr/territory.ex:16: anonymous fn/1 in :elixir_compiler_2.__MODULE__/1
    (elixir 1.16.2) lib/map.ex:257: Map.do_map/2
    (elixir 1.16.2) lib/map.ex:257: Map.do_map/2
    (elixir 1.16.2) lib/map.ex:251: Map.new_from_map/2
    lib/cldr/territory.ex:14: (module)
could not compile dependency :ex_cldr_territories, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile ex_cldr_territories --force", update it with "mix deps.update ex_cldr_territories" or clean it with "mix deps.clean ex_cldr_territories"

I'm guessing that there's been some API change somewhere that has not been fixed upstream. Let me know if you need any more info or help debugging.