Installation from config removes English if the installed profile does not have keep_english

Something like this?

I got the form working, but could use some guidance on additional text we need to display. (this will set your site language to x, update your config language when you install a module, etc)

Creating a UpdateLanguageSubscriber now, so you can't access the form if (for example) 'en' already is the default language or if you only have one language. And this needs tests (+ still need to update existing test). Then i'll attempt my first merge request / contribution in a decade or something, so gonna be fun.

And after all this we can update #3337864: Introduce a dedicated "Configuration default language" different from "Site default language" and add some bits in this new form (or something else).

Apologies, the correct screenshot:

Thanks for working on this @rob c, perhaps we could also consider linking to the documentation page https://www.drupal.org/docs/administering-a-drupal-site/multilingual-gui... which itself links to relevant issues? (under "4. Set a default language.")

Hey your all welcome. This one was (after reviewing a ton of issues) really bugging me, so i figured let's have a go at it. ( #3150540: Configuration langcode is forced to site default language etc. a long long list ).

I've added the link like you suggested and i have pushed the current code. Still needs more text i think (describing the impact of this change if 'keep_english' is not set). Out of time this week, but this needs more work before a full review, and still needs additional tests (a test profile with keep_english: true, test for the EventSubscriber - or go another route, etc) / need to rework the EventSubscriber, but at least we have something to look at now. Back at it next monday (maybe this weekend).

Thank you so much for a fast answer, and already adding the link, I think that looks great.

Multilingual support in Drupal works really well overall, but there are still edge cases and things that can be improved -- like weird things happening (as in this issue), or cumbersome processes like translating config, which I ran into myself last year (see #3549927: Streamline translation of Views block titles, custom menu titles, etc.: Allow Interface Translation). So all improvements are very welcome :)

I don!t understand this issue. I don't think keep_english in the profile has any consequence to default language change on the site later on. If you have keep_english then the INSTALLER will keep English on the site despite installing in a foreign language. If you install in a non-English language, English will not be present so you don't get confusing language selectors for example on monolingual foreign language sites :) You should perfectly be able to remove English on such sites. But if you install in English, then add a foreign language, then switch the site default to that foreign language on the UI, nothing will remove English? I don't think anything will.

> the INSTALLER

from issue summary:

> I've exported the config and *reinstalled* the site

This is a install-from-config edge case I assume, so that installer cleanup logic apparently runs then as well.

Right, that is why I don't understand how the default language switch form should / would help to warn about this or what has that have to do about it. So if I understand this right then the right title would be Installation from config removes English if the installed profile does not have keep_english which sounds like is by design? Or I don't understand this properly.

I asked my GPT codex LLM to analyze the problem:

In Drupal’s installer, “Use existing configuration” still goes through profile selection/loading, so keep_english can affect that path too.

1. Choosing “Use existing configuration” still sets a profile. In SelectProfileForm::submitForm(), when that option is chosen, the installer reads the profile from synced core.extension, sets existing_config = TRUE, and stores the profile in install state.
2. The installer still loads profile info before task branching. In install_load_profile(), profile info is loaded (including keys from profile info files like keep_english) whenever a profile is set.
3. Config installs skip profile extension-install steps, but not profile loading. For existing-config installs, tasks like profile module/theme install are replaced with config import tasks, but the profile-loading step still runs.
4. keep_english is read from shared installer state. The translation logic checks install_state['profile_info']['keep_english'] when deciding whether to remove English, and that logic is still part of the config-install flow.

Conclusion: yes, this behavior happens because the install profile is still used (loaded for metadata/state) during “install from existing configuration,” even though actual profile extension installation steps are skipped.

Questions as a human for this issue: Are there other parts of a profile that should be used in the config install? What does specifying the profile mean in a config based install? Should we expect part of the profile info not apply in config based install?

There is also special consideration in the install_finish_translations() step to protect config translation overrides when installing from config, so that kind of logic could apply to where the profile removes English.

  // When installing from configuration, sync custom translations to locale
  // storage, so they are protected later.
  if (!empty($install_state['config_install_path'])) {
    $batches[] = _install_config_locale_overrides();
  }

There is actually already install_config_revert_install_changes(), which is added in install_tasks() for the config install use case. This attempts to protect the English language with this:

    // At this point the configuration should match completely.
    if (\Drupal::moduleHandler()->moduleExists('language')) {
      // If the English language exists at this point we need to ensure
      // install_download_additional_translations_operations() does not delete
      // it.
      if (ConfigurableLanguage::load('en')) {
        $install_state['profile_info']['keep_english'] = TRUE;
      }
    }

So we do have an attempt to avoid this issue. Why does this not work? Is ConfigurableLanguage() cached and should be loaded fresh?