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 translating Europe/Paris but only Paris. But the timezone is Europe/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 zones are 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 Москва́, not Moscow. 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 id="c0f15fd3fae3f15e2c7042d1622e0ed1" resname="Argentina - San Juan">
 +        <source>Argentina - San Juan</source>
 +        <target>San Juan</target>
 +      </trans-unit>

There are tons of cities called San Juan on this planet, but the most obvious one is the 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 filing CldrBug:10175 … and everyone, thanks for symfony!

The CLDR repository does not contain translations of the continent names

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

to @stof 's point, yes, @curry684 please contribute to CLDR if you can improve Dutch. The San Juan issue is being discussed at the CLDR bug above. The id Unknown is actually Unknown City 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.