Move language_admin_predefined_list to ConfigurableLanguageManager

Great improvement indeed.

+++ b/core/modules/language/lib/Drupal/language/ConfigurableLanguageManager.php
@@ -407,4 +407,21 @@ public function getLanguageConfigOverride($langcode, $name) {
+    asort($predefined);

Will this order by key? Shouldn't we order by the label?
Maybe it is even out of scope of this issue.

Its not changed in this issue. The native names of the languages may use various character sets, they may be left to right, Chinese, etc. Not sure there could be any sensible order of them if ordered by name/label.

Wait, no, its in the interface language. Well, maybe, ordering by their name would be good, but this issue just moves the existing code :) So as far as the scope goes RTBC.

i just couldnt let it go :P

Cool, looks good still :)

+1 RTBC.

Also created #2257199: ConfigurableLanguageManager::getUnusedPredefinedList() should return languages ordered by name instead of language code for discussing comment at #3.

Nice little clean-up. Committed to 8.x.

Yay, thanks!

+  /**
+   * Prepare a language code list for unused predefined languages.
+   *
+   * @return array
+   *   List of predefined language names keyed by langcode.
+   */
+  public function getUnusedPredefinedList();

Huh? What's an "unused" predefined list?

Why didn't we simply name that getPredefinedList(), which would correspond 1:1 to the @return value description...?

EDIT: Also needs a change notice, since API change.

Well, there is indeed some terminology mismatch here. LanguageManager already has a getStandardLanguageList() as used by this method. The method filters that list to the "unused" ones, that is the ones not yet saved as configured languages on the site. That is it returns all the predefined/standard languages that are not used on the site. getStandardLanguageList() already returns the full list. Naming this getPredefinedList() would be pretty confusing since its a filtered list of the languages included with Drupal based on live configuration. Therefore the result itself is not predefined :)

Sorry, I get it now — the method removes all languages from the predefined list that are enabled already. But hm, getUnusedPredefinedList() is a confusing name, because the context of "unused" and its relation to "predefined" is not clear.

listPredefinedWithoutEnabled()?

Something along that line would be more clear? Also note list vs. get; all of the get* methods appear to return Language objects, whereas this method simply returns a langcode/label mapping.

Alternatively, we could shoot for a full parity:

getStandardLanguageList() [LanguageManager]
↓
getStandardLanguageListWithoutEnabled() [ConfigurableLanguageManager]

Well, we should indeed ideally match terminology with standard vs. predefined.

So how about this?

Languages are not enabled in D7 they are added/removed. We just standardised that earlier with #2240463: Fix text: languages are not "enabled/disabled" anymore, they are added/removed. So not sure saying 'enabled' here would be a good idea.

Sorry, I wasn't aware of that terminology change. Given that,

getStandardLanguageListWithoutConfigured() would seemingly encompass the technical meaning + take that terminology change into account?

Looks good.

+   * Returns the standard language list excluding already enabled languages.

Sorry, missed this instance. s/enabled/configured/

Will cancel previous tests.

Would be a lot easier to follow this if the follow-up had been in its own issue. Committed/pushed to 8.x anyway.