Profile configuration overrides should be able to override module configuration always

So we're still downloading translations for every locale test that's enabling translations in the UI at the moment?

1. +++ b/core/lib/Drupal/Core/Config/ConfigInstaller.php
   @@ -113,12 +113,12 @@ public function installDefaultConfig($type, $name) {
          // Gets a profile storage to search for overrides if necessary.
   -      $profile_storage = $this->getProfileStorage($name);
   +      $profile_storages = $this->getProfileStorages($name);
   

   Comment is still singular.

2. +++ b/core/lib/Drupal/Core/Config/ConfigInstaller.php
   @@ -223,19 +223,22 @@ public function installOptionalConfig(StorageInterface $storage = NULL, $depende
       *
       * @return array
       *   An array of configuration data read from the source storage keyed by the
       *   configuration object name.
       */
   -  protected function getConfigToCreate(StorageInterface $storage, $collection, $prefix = '', StorageInterface $profile_storage = NULL) {
   +  protected function getConfigToCreate(StorageInterface $storage, $collection, $prefix = '', array $profile_storages = []) {
   

   Are we allowed to change a protected method or not? :)

3. +++ b/core/modules/config/src/Tests/ConfigInstallProfileOverrideTest.php
   @@ -92,12 +92,12 @@ function testInstallProfileConfigOverwrite() {
        }
    
        // Install the config_test module and ensure that the override from the
   -    // install profile is not used. Optional configuration can not override
   +    // install profile is used. Optional configuration can override
        // configuration in a modules config/install directory.
        $this->container->get('module_installer')->install(['config_test']);
   

   Ha ;)

   "We are at war with Eastasia. We've always been at war with Eastasia."

Regarding the protected methods and whether BC can be broken, there is discussion of that on #2116841: [policy] Decide what the Drupal Public API should be and how to manage it but not yet on #2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation.

Adding the RC targeting reasoning to the summary.

Discussed with alexpott and agreed that this makes sense as an RC target. There is no direct disruption for RC, just expanded functionality, but it would not be advisable to change the behavior after RC.

Steps to review:

1. copy core/modules/locale/config/install/locale.settings.yml to core/profiles/minimal/config/optional/locale.settings.yml
2. edit core/profiles/minimal/config/optional/locale.settings.yml
3. change translate_english: false to translate_english: true
4. $ drush si minimal -y
5. $ drush en -y locale
6. $ drush cget locale.setting

Expected result:

cache_strings: true
translate_english: true
javascript:
  directory: languages
translation:
  use_source: remote_and_local
  default_filename: '%project-%version.%language.po'
  default_server_pattern: 'http://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po'
  overwrite_customized: false
  overwrite_not_customized: true
  update_interval_days: 0
  path: sites/default/files/translations
  import_enabled: true

Before:

$ drush cget locale.settings
[...]
translate_english: false
[...]

After:

$ drush cget locale.settings
[...]
translate_english: true
[...]

Good job :)

Committed/pushed to 8.0.x, thanks!

That needs change record because solves a lot of problems for distributions and profiles