Cldr.Locale.territory_from_locale
territory_from_locale
, go back to Cldr.Locale module for more information.
Specs
territory_from_locale(Cldr.LanguageTag.t() | locale_name()) :: territory()
Returns the effective territory for a locale.
Arguments
language_tag
is any language tag returned byCldr.Locale.new/2
or anylocale_name
returned byCldr.known_locale_names/1
. If the parameter is alocale_name
then a default backend must be configured inconfig.exs
or an exception will be raised.
Returns
- The territory to be used for localization purposes.
Examples
iex> Cldr.Locale.territory_from_locale "en-US"
:US
iex> Cldr.Locale.territory_from_locale "en-US-u-rg-cazzzz"
:CA
iex> Cldr.Locale.territory_from_locale "en-US-u-rg-xxxxx"
{:error, {Cldr.LanguageTag.ParseError, "The value \"xxxxx\" is not valid for the key \"rg\""}}
Notes
A locale can reflect the desired territory to be used when determining region-specific defaults for items such as:
- default currency,
- default calendar and week data,
- default time cycle, and
- default measurement system and unit preferences
Territory information is stored in the locale in up to three different places:
The
:territory
extracted from the locale name or defined by default for a given language. This is the typical use case when locale names such asen-US
ores-AR
are used.In some cases it might be desirable to override the territory derived from the locale name. For example, the default territory for the language "en" is "US" but it may be desired to apply the defaults for the territory "AU" instead, without otherwise changing the localization intent. In this case the U extension is used to define a regional override.
Similarly, the [regional subdivision identifier] (https://unicode.org/reports/tr35/#UnicodeSubdivisionIdentifier) can be used to influence localization decisions. This identifier is not currently used in
ex_cldr
and dependent libraries however it is correctly parsed to support future use.
Specs
territory_from_locale(locale_name(), Cldr.backend()) :: territory() | {:error, {module(), String.t()}}
Returns the effective territory for a locale.
Arguments
locale_name
is any locale name returned byCldr.known_locale_names/1
.backend
is any module that includesuse Cldr
and therefore is aCldr
backend module.
Returns
- The territory to be used for localization purposes or
{:error, {exception, reason}}
.
Examples
iex> Cldr.Locale.territory_from_locale "en-US", TestBackend.Cldr
:US
iex> Cldr.Locale.territory_from_locale "en-US-u-rg-cazzzz", TestBackend.Cldr
:CA
iex> Cldr.Locale.territory_from_locale "en-US-u-rg-xxxxx", TestBackend.Cldr
{:error, {Cldr.LanguageTag.ParseError, "The value \"xxxxx\" is not valid for the key \"rg\""}}
Notes
A locale can reflect the desired territory to be used when determining region-specific defaults for items such as:
- default currency,
- default calendar and week data,
- default time cycle, and
- default measurement system and unit preferences
Territory information is stored in the locale in up to three different places:
The
:territory
extracted from the locale name or defined by default for a given language. This is the typical use case when locale names such asen-US
ores-AR
are used.In some cases it might be desirable to override the territory derived from the locale name. For example, the default territory for the language "en" is "US" but it may be desired to apply the defaults for the territory "AU" instead, without otherwise changing the localization intent. In this case the U extension is used to define a regional override.
Similarly, the [regional subdivision identifier] (https://unicode.org/reports/tr35/#UnicodeSubdivisionIdentifier) can be used to influence localization decisions. This identifier is not currently used in
ex_cldr
and dependent libraries however it is correctly parsed to support future use.