Language label logic when installing with language, adding and editing languages is confusing

We discussed this quite a bit yesterday. I have some vague recollection that the config entities may be mostly English due to some race-condition or inter-dependency with config language handling maybe. Like if the language of your config is XY and you just define XY with that config itself, it may cause problems. But not sure if that is the case or if we documented that somewhere. There is clearly no tests to ensure that or if this would fail or need to modify that test :D

1. Not sure if I remember any reason why this is as complex as it is. I guess we need better test coverage of the expectations.

2. +++ b/core/includes/install.core.inc
   @@ -1602,8 +1602,27 @@ function install_download_additional_translations_operations(&$install_state) {
   -    // Create the language if not already shipped with a profile.
   -    $language = ConfigurableLanguage::createFromLangcode($langcode);
   

   Rather than not using createFromLangcode() how about just using setName() on the result? Less logic here and perhaps easier to comment on.

3. +++ b/core/includes/install.core.inc
   @@ -1602,8 +1602,27 @@ function install_download_additional_translations_operations(&$install_state) {
   +      // Drupal does not know about this language, so we set its values with the
   +      // best guess. The user will be able to edit afterwards.
   +      $language = ConfigurableLanguage::create([
   +        'id' => $langcode,
   +        'label' => $langcode,
   +      ]);
   

   Needs testing I guess. Never seen a test for installing in a non-existent langcode.

The installer takes the predefined language list from core + if there is any .po file locally which is added onto the list AFAIR.

This looks pretty sensible. One thing I wonder is what should we do if the installer option keep_english is set to TRUE. Atm we leave the english language created during the install of the language module alone. I wonder if we should really be changing to be an english in the language of the site install.

And there are the other "languages" provided by the language module - UND and ZXX what about them?

Oh that's funky if you set keep_english to TRUE then the resulting config in the default collection is correct...

uuid: 0e907c54-2789-47dd-a188-826bb494f40c
langcode: de
status: true
dependencies: {  }
_core:
  default_config_hash: lBXDpdDPXQtrfTJQhr6MjRJJEEyYSoRJ0acdvHLsWeA
id: en
label: Englisch
direction: ltr
weight: 0
locked: false

and the language/en has the expected override...

label: English

Same is true for und and zxx languages so the approach in this issue is definitely correct.

i've tried to apply the patch from comment #30 to Drupal 9.3.0-beta2 but composer patches was unable to apply.

Regenerated #30 patch.

Regenerated #30 patch.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Does this require a change record?

Apologize if I missed it but has

Create additional languages with the translated label into the correct language (==langcode property). Look into creating a translation. Maybe that could be a follow-up because it is likely more complicated.

been addressed or a follow up made?

Also are the steps in the IS still the best way to test this?

Fun seeing my boilerplate message from when the #needs-review-queue started

Thanks @berdir for following up.

Verified the tests fail without the fixes
Applied the patch #36
Did an install of Standard profile with a different language other then English and no issues there
Added another language without issue.