On the master branch we should use the new TimezoneBundle in the Intl component, see PR#17636.

I'm not convinced to translate timezone identifiers. Do you have an example app where this is done this way? Drupal does not translate them either.

Also this does not actually translate the timezones but only a subset of regions and cities. So you are not translatingEurope/Paris but onlyParis. But the timezone isEurope/Paris.

Also this is definitely not a bug fix but a new feature.

I'm not convinced to translate timezone identifiers. Do you have an example app where this is done this way?

Google Calendar.

Mediawiki, Twitter and Tumblr, on the other hand, shows the English names in all locales.

The addition of timezone translations to Unicode Common Locale Data Repository is a fairly new thing. That may be part of the explanation why using the translated city names is not more widespread.

Other than web apps, there is also the timezone selector in Microsoft Windows, the city names are shown in the system language.

Drupal does not translate them either.

They zonesare translateable in Drupal (at least versions 7 and 8), though I have not found a locale that actually translates them.

Also this does not actually translate the timezones but only a subset of regions and cities. So you are not translating Europe/Paris but only Paris. But the timezone is Europe/Paris.

The TimezoneType currently only displays the city names (included in an optgroup with the continent name), not the entire identifier, e.g. the dropdown contains "New York", not "America/New_York". The patch does not change that.

In most locales, some city names are not translated, either because they do not have a name in the specific language (usually only large cities have that), or because they simply have not been translated yet. In the CLDR files, the name from the "en" locale is used as a general fallback. I think this is a reasonable choice given the circumstances.

I think that the city names in the TimezoneType control should be shown in the current language, just like the country names in the CountryType control. This is particularly relevant when timezone and current language match (i.e. when the language is spoken in the city that identifies that timezone), because most users will select such timezones (i.e. a lot of Italian-speaking users will use the Europe/Rome timezone).

For example, assume we have an Russian-language site that is visited by an Russian user living in Moscow, i.e. all text on the site is in Russian. In a CountryType control, the user will see the Russian-language name for Russia,Росси́я. As an end-user (who does not speak English and is not familiar with the Olson database), I would expect the TimezoneType control to containМосква́, notMoscow. I would find it strange to see the English name for the Russian capital on a site where all other texts are in Russian.

I would consider it a new feature

Indeed

I'm far from convinced by the quality of the source data. I briefly reviewed the Dutch translations as it's my native language, and I found a lot of weird things, like "Unknown" being translated to "onbekende stad", which is "unknown city". Also, country names are indeed stripped despite being relevant most of the time:

 +     <trans-unit resname="Argentina - San Juan"> +        <source>Argentina - San Juan</source> +        <target>San Juan</target> +      </trans-unit>

There aretons of cities called San Juan on this planet, but the most obvious one isthe capital of Puerto Rico, not the much smaller and less known province capital this time zone is named after. In a different time zone than Puerto Rico too (1 hour later).

So 👎 it is.

@curry684 you could contribute to CLDR to improve their Dutch translations. This would benefit all projects relying on it.

@c960657 thanks for filingCldrBug:10175 … and everyone, thanks for symfony!

The CLDR repository does not contain translations of the continent names

Actually it does. It has translations for theUN M.49 numeric region codes alongside territories. So,ZA = South Africa,002 = Africa, etc.

to@stof 's point, yes,@curry684 pleasecontribute to CLDR if you can improve Dutch. The San Juan issue is being discussed at the CLDR bug above. The idUnknown is actually UnknownCity because that is the context of use.

Hope this helps.

Given that there is doubt about the current quality of the data (still relatively new in CLDR) and the fact that you cannot opt-out, I fear that people will complain about that. As it's possible to do it as a bundle, it would be a good first step. I'm closing this one in the meantime.