Closed kipcole9 closed 1 year ago
@tomciopp I've opened a PR that resolves the subdivision aliases. I would be pleased if you could try out the branch and see if it works for you.
{:ex_cldr_territories, github: "Schultzer/cldr_territories", branch: "resolve-subdivision-aliases"}
{:ex_cldr_territories, github: "Schultzer/cldr_territories", ref: "809349580526ed8eff1d6e4a557fdf4110d20c7d"}
@Schultzer Yes, this code now works as expected.
@Schultzer Yes, this code now works as expected.
Thanks, I've pushed the changes to master.
Copied from https://github.com/elixir-cldr/cldr/issues/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 becauseuspr
is an alias to the territoryPR
(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
Cldr.Territory.subdivision_aliases/0
which encapsulates the alias information. This information can be obtained at compile time fromCldr.Config.aliases[:subdivision]
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 typet: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 nextex_cldr
release: