I disagree with this.

I agree it could be useful to exclude it from a language drop down list in a form component.
But the codes should not be excluded from the list of languages. At the very least it should be possible to get the language name with Languages::getName().

Here is the full list of the 22 entries we are talking about:

  'en_US' => 'American English',
  'en_AU' => 'Australian English',
  'de_AT' => 'Austrian German',
  'pt_BR' => 'Brazilian Portuguese',
  'en_GB' => 'British English',
  'en_CA' => 'Canadian English',
  'fr_CA' => 'Canadian French',
  'sw_CD' => 'Congo Swahili',
  'fa_AF' => 'Dari',
  'pt_PT' => 'European Portuguese',
  'es_ES' => 'European Spanish',
  'nl_BE' => 'Flemish',
  'es_419' => 'Latin American Spanish',
  'es_MX' => 'Mexican Spanish',
  'ar_001' => 'Modern Standard Arabic',
  'ro_MD' => 'Moldavian',
  'sr_ME' => 'Montenegrin',
  'zh_Hans' => 'Simplified Chinese',
  'fr_CH' => 'Swiss French',
  'de_CH' => 'Swiss High German',
  'zh_Hant' => 'Traditional Chinese',
  'nds_NL' => 'West Low German',

How can you get f.ex. "Dari", "Traditional Chinese" or "Simplified Chinese" without this list?

It is also very useful as a reference to which language and locale combinations that actually defines a separate language.

fr_CA is different from fr_FR and fr_CH. That's not the same language.

Or would you list f.ex. "Flemish" as "Dutch (Belgium)"

Or would you list f.ex. "Flemish" as "Dutch (Belgium)"

Using "Dutch (Belgium) / French (Belgium) is common yes (at least in technical implementations), but i agree these names (e.g. Flemish) are also common in general. So the data has value, fair :)

At the very least it should be possible to get the language name with Languages::getName().

This takes a ISO language code, en_AU is not a language code (en is). So im skeptical about solving it in the Languages domain.

However, we could leverage this data when translating a locale, e.g. a lookup for specialized language names around here:

I agree for the locale selector Flemish (Belgium) would be better then Dutch (Belgium), for the language selector i'd expect Dutch only (https://en.wikipedia.org/wiki/Flemish - it's a dialect really)

What about these lines in the list of locales:

It clearly shows that zh_Hans and zh_Hant should be considered separate language codes that can be combined with a separate country code.

Hans/Hant is the script code, to me for both the language is "Chinese".

Same for en_US vs en_GB, we consider it the "English" language.

'es_419' => 'Latin American Spanish',
'ar_001' => 'Modern Standard Arabic',

are also entries that does not follow the language_country pattern.

I think all this is data that is worth exposing to the programmers.
Then they can easily filter out what they don't need. But it is impossible to add what is not there in the first place.

are also entries that does not follow the language_country pattern.

they do :) 419 /001 are valid region codes as well, so part of the locale still.

Yes, but my point is that this is special language/region combinations that has their own names as languages in the ISO 639-1 specification. I think we should keep them. Otherwise it will also be a BC break.

true, we removed codes before though. But yes, it's tricky and technically a BC break / but maybe a bugfix also 😓

From a best practice point of view, i'd argue the usefulness of the language selector itself. Using the locale selector avoids these issues and will provide the language code as well (but based on context).

I am sorry, I do not follow you. What do you mean by "language selector", "language code" and "locale selector"?

see e.g. #28833

when we exclude "language codes" from the Intl component, we directly impact the form type (what i call the language selector)

Well, the form type can implement it's own filter. This is useful in many other programming situations than just a language selector in a form.

What is then the "locale selector" you are talking about?

At the very least it should be possible to get the language name with Languages::getName().

This takes a ISO language code, en_AU is not a language code (en is). So im skeptical about solving it in the Languages domain.

But ISO 639-1 claims that en_AU is a language code.

What is then the "locale selector" you are talking about?

The locale form type :)

not sure the form should filter the list itself, it's the same data domain. So the question should be answered in the Intl component IMHO.

But ISO 639-1 claims that en_AU is a language code.

Can you share a reference for that?

Also, locale names are not the same as language names. If I want a name for a language, I would not expect to have to look for it among the locale names.

locale names are not the same as language names

but a locale name includes the language name

If I want a name for a language, I would not expect to have to look for it among the locale names.

what about updating Languages::getName to take a locale then, it seems reasonably because a language code also qualifies as a locale.

What is then the "locale selector" you are talking about?

The locale form type :)

Ok. Good that we got that cleared up.

not sure the form should filter the list itself, it's the same data domain. So the question should be answered in the Intl component IMHO.

I think it should filter the list, if it finds it useful to have a shorter list. Then other use cases can benefit from the full list.

But ISO 639-1 claims that en_AU is a language code.

Can you share a reference for that?

Sorry, I guess you are right about that. It is not a part of the standard. I assumed it was because it was in the data we got from the source bundle.

I guess this is the authorative list for the ISO 639 standard: http://www.loc.gov/standards/iso639-2/php/code_list.php

but a locale name includes the language name

Ok. Fair enough. (But a bit roundabout way to get the language name.)

what about updating Languages::getName to take a locale then, it seems reasonably because a language code also qualifies as a locale.

Yes, I find that reasonable. It should take a language code or a locale and return the best fit for a language that it can find.

We could also either add an argument to getNames or add another method, so we can both get an exhaustive list of all possible arguments to getName and also (less important in my opinion) a more reasonable limited list for use in a language selector.