Cldr.Locale.territory_from_locale

You're seeing just the function territory_from_locale, go back to Cldr.Locale module for more information.
Link to this function

territory_from_locale(language_tag)

View Source (since 2.18.2)

Specs

territory_from_locale(Cldr.LanguageTag.t() | locale_name()) :: Cldr.territory()

Returns the effective territory for a locale.

Arguments

  • language_tag is any language tag returned by Cldr.Locale.new/2 or any locale_name returned by Cldr.known_locale_names/1. If the parameter is a locale_name then a default backend must be configured in config.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"
:US

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:

  1. 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 as en-US or es-AR are used.

  2. 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.

  3. 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.

Link to this function

territory_from_locale(locale, backend)

View Source (since 2.18.2)

Specs

territory_from_locale(locale_name(), Cldr.backend()) ::
  Cldr.territory() | {:error, {module(), String.t()}}

Returns the effective territory for a locale.

Arguments

  • locale_name is any locale name returned by Cldr.known_locale_names/1.

  • backend is any module that includes use Cldr and therefore is a Cldr 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
:US

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:

  1. 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 as en-US or es-AR are used.

  2. 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.

  3. 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.