Thanks for creating this great PR @c960657! 🎆 I think both the PR and the rest of the Intl component should be improved, API-wise (see #18368). Do you want to work on that?

@webmozart I agree that the Intl component could be improved or perhaps superseded by one or more new components.

It's a bit unclear to me what the purpose of that package is – it provides a copy of a subset of the CLDR datasets (with some opinionated blacklists of pseudo-currencies, pseudo-countries etc.), a partial reimplementation of PHP's ICU DateFormatter for English only, as well as code for parsing ICU data files and converting them to various Symfony-specific file formats.

CLDR contains a lot of useful data that I would like to see exposed. Symfony will probably never get support for all the different data, but it should make it easy to fetch the relevant bits from the CLDR data files.

I would be interested in working on this, provided that we can agree on a clear direction. I'll add some comments and suggestions to #18368.

Is the data contained in this PR build based on the same ICU version than the other data already in the component ?

If yes, this gets a 👍 from me. If no, we need to recompile the data first.

Same goes here what I commented in the other PR: the translation quality appears to be sub par and inconsistent, and in that case, no matter the usefulness of the PR itself, we should not want to do it imho.

There are several databases that are kept up to date independently that can provide this data. Why burden Symfony with it?

@jakzal could you have a look at this one please? you're the one doing most of the updates :)

I don't think it is fair to say that the CLDR translations are poor. CLDR is backed by Microsoft, Google and Apple (among others) who use the data in their software. They all spend considerable ressources on providing high-quality data for a large number of locales.

The blame is on me for using the data the wrong way. Since I submitted this PR last year, I have learned a lot more about the CLDR data and the CLDR spec while contributing to the Punic library.

The Olson database contains timezone definitions but does not specify how they should be displayed to end users. Symfony simply shows the raw timezone identifier with / and _ replaced with dash and space, respectively. This strategy works most of time for English, but it does not handle apostrophes, periods and accents, e.g. Antarctica/DumontDUrville is displayed as “DumontDUrville” rather than “Dumont d’Urville” (search for examplarCity in root.xml for more examples). So even for English, CLDR may help improve matters.

The Olson database does not designate a name for each timezone apart from the timezone identifier (e.g. Europe/Berlin). There are several naming schemes for timezones; for instance, “Berlin time”, “German time” and (to some extent) “CET” are different names for the same timezone. The CLDR spec defines several naming schemes, such as generic non-location format and generic partial location format, that describes how to combine the CLDR strings into end-user facing strings.

A sidenote, not really related to this issue: If you are creating UI that allows users to select a timezone, showing all 400 Olson timezones is probably not the most user-friendly approach. Many of the Olson timezones are duplicates, in the sense that they (in recent years) have identical offsets and DST rules, e.g. Europe/Berlin and Europe/Paris. It makes sense to group the zones in the UI, e.g. like in the Microsoft Windows timezone selector. CLDR includes two such groupings; the one used in Windows, and another called metazones.

So, how does all this apply to Symfony?

In order to build a multi-locale appliation that handles dates and timezones, you would usually use a l10n library such as PHPs Intl extension, the Punic library or similar (Symfonys Intl component is not a l10n library in this respect). These packages often provide translated timezone names. E.g. the Intl extension allows you to get the localized city name like this IntlDateFormatter::formatObject(new DateTime('now', new DateTimeZone('Europe/Rome')), 'VVV', 'it') // returns "Roma".

So it seems there is little benefit in adding the timezone names to the Intl package.

(I guess the same applies to the other data currently provided by Symfonys Intl component, but
as mentioned above, it is unclear to me what the purpose of the Intl package is)

The reason I created this PR in the first place was to allow the timezone form component to be localized (PR #17628). Perhaps a better approach is to use PHPs Intl extension directly at run-time when generating the dropdown (with fallback to English if the Intl extension is not installed). What do you think of this?

@c960657 my apologies if I inferred the quality of your work as a whole was poor, I merely reviewed the proposed changes and concluded that the work being submitted here was not generically usable in its current form. And therefore should not (yet) be a core part of Symfony as it would cause technical debt and BC issues if it were corrected later.

@curry684 No offense taken :-) It seems we agree that this data is available through other libraries and thus does not belong in Symfony.

shall we close then?