Is there a facility to translate the Long timezone names to another language?

[tjchambers]

I have an app where I wish to allow the user to pick a timezone i.e. "America/Louisville" from a dropdown list on a form. I can easily get all those timezone names IN ENGLISH. I realize that in cldr/common/main/*.xml there are exemplar cities translated into other languages in the .XML source.

I am doing this in a Phoenix app and would like to translate the dropdown for instance for Japanese users so they can see the Kanji equivalent of "American/Louisville" for example in the dropdown. I believe at least the cities are translated in the .xml files, and I presume also in the .json content in ex_cldr.

Please advise.

[Schultzer]

If the data is there I see no issue in added a function that takes a timezone and replaces the region and the subdivision based on the from and to locale.

You might want to consider putting in ex_cldr_territories as there are other functions there that deals we translating region and subdivision. Although I leave the decision to @kipcole9 as he has a better knowledge of the data available and the rest of the libraries.

[tjchambers]

Given that the data is shared was wondering whether this should be a separate repo e.g. ex_cldr_timezones .

[kipcole9]

I've been actively avoiding this topic for years now. And I should have known that @tjchambers would eventually come asking very good questions that don't have easy answers :-)

Random thoughts

My normal default response to UIs that ask users to pick timezones is to say "don't do that" because most users don't understand timezones. Prefer instead to ask for a city name, resolve that to lat/lng and use something like tz_world to resolve the timezone. However this does require a geocoding library as well. and one that includes localised place names. So not that easy.

CLDR does localise timezone names for metazones so being able to translate a zone will often be possible and I will add this to ex_cldr_dates_times because by the spec, I should already be using this data for certain date formats.

From a UX point of view, I'm not sure how to handle the case where multiple zone names apply to the same zone. There are a lot of them: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

And then there's daylight savings time .....

Proposed work

I will add functions to return localised display names for a timezone. These are typically of three types: generic, standard and daylight. In this first implementation the developer will need to decided which one they want. Its going to take a little time to wrap my head around CLDR resolves timezone names to metazones with fallbacks.

I will also aim to map a DateTime.t to a localised timezone name.

@tjchambers, would that be enough to get started with? Comments and suggestions most welcome.

[kipcole9]

I think I've got a path forward but there is quite a bit of work to do - the hardest part is decoding the spec but the best way I've found it just to do work and puzzle it out as we go.

1. The data from supplemental/metaZones.xml needs to be added to ex_cldr. That will trigger a release of that base library. This file does two things:
   a. Map to the correct timezone data for a given date/time - basically select the correct metazone.
   b. Resolve the preferred timezone name for a given locale. For example, for a timezone America/Eastern the preferred name for "the world" is America/New_York but for the CA (Canada) locale the preferred zone is America/Toronto.

2. Then the right data needs to be baked in ex_cldr_dates_times. Thats straight forward.

3. Once we have the preferred timezone and correct metazone, retrieval of the display names is reasonably straight forward. I do need to work out how the CLDR fallback mechanism works here, and how the default works. Non-trivial usually, but not impossible.

[tjchambers]

I want to be clear about what I in particular am trying to achieve and that is to let a user pick their timezone, but do so in their language. SO my app is using the locale ja_JP and I need the list THEY see to be in Kanji. Short of doing my own ja translation of the list or translating the list on the fly, I was looking to leverage the predefined translations I found in the .xml content for these designations.

What I do not need (or do not believe I need) is to "guess" from the locale their current timezone - I am already leveraging other code to do so. From that you might surmise "Why do you need them to pick it if you already know it?" and that would be an excellent question. However they may need to override it for various reasons, like putting themselves into another persons timezone for the purposes of determining a date for a scheduled event from the other person's perspective.

In any case I want to be clear that I am looking for an "official" way to present that timezone list in the language of their locale.

Thanks for your attention on this.

[kipcole9]

Understood @tjchambers, I was just rambling a bit in my response.

Based upon what I see in the CLDR data there is a localised timezone display name that could be displayed. Thats not strictly the same as a translated timezone. But it would present in a UI a localized name than is then mapped to the actual timezone name.

Does that seem workable for you?

[tjchambers]

If you could direct me to what I think you are describing I could certainly examine that. You know that large dataset much better than I. I am fine with self servicing it but want to contribute back if it is something valuable to others.

[kipcole9]

You could do the following in the iex to see the data:

iex> locale = Cldr.Locale.Loader.get_locale(:en, %Cldr.Config{locales: :all})
iex> locale.dates.time_zone_names.metazone

You'll see a map in which a typical entry would look like:

"lord_howe" => %{
    long: %{
      standard: "Lord Howe Standard Time",
      generic: "Lord Howe Time",
      daylight: "Lord Howe Daylight Time"
    }
  }

[kipcole9]

In case I wasn't clear earlier, I will most definitely make the overall timezone data available as part of the API of ex_cldr_dates_times. To help your use case, the first thing I'll focus on is making a mapping between a timezone ID and its display names.

This still requires mapping through metazone data that is not currently in ex_cldr (coming from supplemental/metaZones.xml) to the locales timezone data to the relevant metazone. Every time I have to parse XML I have to relearn how to get sweet_xml to do its thing so thats the first step for me.

[kipcole9]

I've created a new repo that encapsulates the metazone data. There are two new relevant functions:

• Cldr.Config.metazones/0
• Cldr.Config.metazone_mapping/0

These functions are required to make further progress in ex_cldr_dates_times which will be the next place of work.

If for some reason you're interested in what the data looks like, then feel free to configure ex_cldr from this git repo. Nothing else has changed - just the addition of the metazone data and the config functions to read it.

[kipcole9]

Added:

• Cldr.Config.metazone_ids/0
• Cldr.Config.primary_zones/0

Which I believe concludes encapsulating the necessary data - now on to work on ex_cldr_dates_times.

[kipcole9]

And ... now I've added the functions in ex_cldr_dates_times to access all of the CLDR timezone-related data.

The next step is to decode the standard and implement it.

The first function I'll aim for is Cldr.DateTime.Timezone.display_name/2 which will return a localised timezone name according to the standard. That should address the specific requirement discussed here. Then I can further implement the rest of the standard.

[kipcole9]

Good progress this week and its now ready for your early review.

Configuration

1. Configure from GitHub as {:ex_cldr_dates_times, github: "elixir-cldr/cldr_dates_times"}. That will also configure a beta version of a new ex_cldr release. If you need to manually check that it is {:ex_cldr, GitHub: "elixir-cldr/cldr-2.43.0-dev"}.

Usage

1. Check the Changelog
2. The functions you are probably most interested in are:
   a. Cldr.DateTime.Timezone.location_format/2
   b. Cldr.DateTime.Timezone.non_location_format/2
   c. Cldr.DateTime.Timezones.exemplar_city/2
3. For a UX where you want users to select timezones in localised language, I suggest non_location_format/2 with the default type: :generic but of course thats up to you.

Examples

Non-location format

iex> Cldr.DateTime.Timezone.non_location_format("Australia/Sydney")
{:ok, "Australian Eastern Time"}

iex> Cldr.DateTime.Timezone.non_location_format("Asia/Shanghai")
{:ok, "China Time"}

iex> Cldr.DateTime.Timezone.non_location_format("Europe/Rome", locale: :ja)
{:ok, "中央ヨーロッパ時間"}

Location format

iex> Cldr.DateTime.Timezone.location_format("America/Phoenix", format: :short)
{:ok, "Phoenix Time"}

iex> Cldr.DateTime.Timezone.location_format("Europe/Rome", locale: :ja)
{:ok, "イタリア時間"}

iex> Cldr.DateTime.Timezone.location_format("America/New_York", locale: :fr, type: :daylight)
{:ok, "New York (heure d’été)"}

Exemplar City

iex> Cldr.DateTime.Timezone.exemplar_city("Australia/Sydney")
{:ok, "Sydney"}

iex> Cldr.DateTime.Timezone.exemplar_city("Europe/Kiev")
{:ok, "Kyiv"}

iex> Cldr.DateTime.Timezone.exemplar_city("America/Indiana/Knox")
{:ok, "Knox, Indiana"}

iex> Cldr.DateTime.Timezone.exemplar_city("Europe/Kiev", locale: :ja)
{:ok, "キーウ"}

Work still to do

• More tests and docs
• Add Cldr.DateTime.Timezone.gmt_format/2
• Revise Cldr.DateTime.Formatter to use these new functions
• Some mechanism to select candidate timezones for UX use - suggestions warmly welcomed

[kipcole9]

I've added a lot of tests, and added Cldr.DateTime.Timezone.gmt_format/2 so to-do is a bit closer to:

• Refactor existing ISO 8601 formatting code
• Revise Cldr.DateTime.Formatter to use these new functions
• Some mechanism to select candidate timezones for UX use - suggestions warmly welcomed

[kipcole9]

Some thoughts on selecting timezones in an UI. Comments and suggestions very welcome.

• There are many names for common timezones. America/Vancouver is the same zone as America/Los_Anglese. It's not very effective to present both of these as choices.
• It's probably better to display the "best fit" zone for a given locale. So someone in the en-CA locale would see America/Vancouver and someone in the us-US locale would see America/Los_Angeles
• Not all zones have multiple names (aliases) but there is always one (and only one) "golden zone" name for a given zone. So that becomes the default name to be presented for a given locale.
• The zone name is localled for presentation to the user in the generic location format or the generic non-location format.
• When selecting zones in a UI, clarity is important. Therefore I propose omitting the offset-based zones like "Etc/GMT+5" but keeping GMT and UTC since they are commonly used and widely understood.
• Typically I think the expectations is to select the "wall time" time zone. This is referred to as the "generic" time. I imagine there are use cases to specify "Australian Eastern Standard Time" and "Australian Eastern Daylight Time" but it doesn't feel natural to do so. "Australian Eastern Time" seems a better fit for UX.
• The data is structured to make it straight forward to filter time zones by their prefix (America, Europe, Asia, Pacific, Africa, Indian). Are there other requirements that should be build into ex_cldr_dates_times?

[tjchambers]

From what I can see these comments are excellent. The implementation is straightforward and intuitive. It more than meets what I need at the moment and because it is using public data it is consistent - not reliant on an on-the-fly approach. Excellent work.

[tjchambers]

https://github.com/elixir-cldr/cldr_dates_times/blame/5be08255f2c0022964755e38b392e2f1f42b2645/lib/cldr/format/date_time_timezone.ex#L73

Am not sure that this is a correct statement as the summer time s/b GMT-7 I believe.

[kipcole9]

Fixed.

[tjchambers]

https://github.com/elixir-cldr/cldr_dates_times/blame/5be08255f2c0022964755e38b392e2f1f42b2645/lib/cldr/format/date_time_timezone.ex#L136 small typo "THe"

[kipcole9]

Fixed.

[tjchambers]

It might be useful to indicate somewhere in the doc that no attempt is made to support or process NATO military times zones. I am aware the the "Z" format overlaps with UTC but the other alphabet is not supported or part of this afaict. I am referring to https://en.wikipedia.org/wiki/Military_time_zone

[kipcole9]

Would it be helpful to provide function that translates nato timezone names to their "Etc/UTC....." equivalent? There seems to be a 1:1 mapping for that? Its not the same as translation for sure - so making a note about that makes sense.

[kipcole9]

I noted the lack of NATO time zone support in the moduledoc.

[tjchambers]

It seems like a YAGNI for now. Noting it I think is very appropriate as it should not be "expected".

[tjchambers]

https://github.com/elixir-cldr/cldr_dates_times/blame/5be08255f2c0022964755e38b392e2f1f42b2645/lib/cldr/format/date_time_timezone.ex#L485 type "daatabase"

[kipcole9]

Fixed.

[tjchambers]

https://github.com/elixir-cldr/cldr_dates_times/blame/5be08255f2c0022964755e38b392e2f1f42b2645/lib/cldr/format/date_time_timezone.ex#L503 typo "datababase"

[kipcole9]

Fixed.

[tjchambers]

https://github.com/elixir-cldr/cldr_dates_times/blame/5be08255f2c0022964755e38b392e2f1f42b2645/lib/cldr/format/date_time_timezone.ex#L624 typo "t:"

[tjchambers]

I may have been incorrect about this one - this format of "t:...t()" is one I have not seen before.

[kipcole9]

That's an ex_doc way of linking to a type definition (as a apposed to a function definition).

[kipcole9]

https://hexdocs.pm/ex_doc/readme.html#auto-linking