Config overrides are loaded for English even when translate_english is false

That setting is only for interface translation, if your config language is not en you need to load english overrides. But maybe we can check the lang code instead?

There's many bugs in config translation and locale so I'm not sure we can guess anything until the flow is settled

IMO the cause here is #3150540: Configuration langcode is forced to site default language

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

We could do something like we do for the default language and add this to the container - see \Drupal\Core\DrupalKernel::compileContainer() and \Drupal\Core\DrupalKernel::getConfigStorage()... we could do something similar and then inject the container parameter into language.config_factory_override.

In fact I think think we should add something to container so that we can inject any config value into a service by adding something like %config:locale.settings:translate_english%.

Locale module could probably set a container parameter in a service provider, and then language module could look for that container parameter but allow for it not being set. This resolves #2 but not #1. That possibly feels like as far as we should go in this issue, then open follow-ups for the rest.

Makes sense to me - plus language module could provide a default that's then changed by the locale module.

The cache lookup reductions do look nice, to be fair, that's only going to be true for for one language though. I see we have no performance tests yet when accessing a different language, I don't remember if we discussed that before, but that seems like a useful thing to have? In a different issue of course?

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Know you're working on those tests right now. But seem to be conflicts in the performance tests now.

I was shocked when I saw how many queries this saves. Well done finding it.

...we also have to translate English when locale's 'translate_english' setting is on, even when it's the default language - at least as far as two tests are concerned.

Thank you for documenting this in a comment because I didn't understand that condition until I read #12.

My main concern is the code duplication from the new conditions in LanguageConfigFactoryOverride, especially given that the translate English condition is a bit unintuitive. Might it be a good idea to move these to a new function on the class that will return a boolean?

Do the changes to LanguageConfigFactoryOverride::loadOverrides() and LanguageConfigFactoryOverride::getOverride() need unit tests?

My feedback was addressed. It looks good to me.

I read through the MR and all comments, the fix makes sense to me and the change in cache get statistics is staggering. If we were earlier in the cycle I would consider asking for backport to 10.x, but at this stage it's likely not worth the effort.

Committed and pushed bd24c65d6e6 to 11.x and a735e53c8a2 to 11.3.x. Thanks!

I've opened the follow-up #3560992: Change 'language.translate_english' container parameter to FALSE as a default value

FYI: We were recently wondering in existing installations that we upgraded to 11.3.2 that English config translations are suddenly broken, see the following screenshot:

This is a regression caused by this issue. The affected projects have been upgraded from Drupal 8 on, so maybe it's an issue with mature Drupal installations, we're further investigating, if it needs to be fixed in the projects or in code here.
In the beginning these projects has "de" (German) as default language. Later on be switched to "en" (English) as default and primary language, because we ran into other core issues. Maybe that caused this edge-case?

I could imagine other people upgradting to 11.3 may also run into this...

If we turn the condition of $this->shouldSkipOverrides() into FALSE, everything works correctly as before the 11.3 upgrade.

I think this may happen because in cases like ours for historic reasons default configs (e.g. "sync/system.site.yml" example below) still have langcode "de":

_core:
  default_config_hash: AyT9s8OUcclfALRE_imByOMgtZ19eOlqdF6zI3p7yqo
langcode: de
uuid: 060ad019-4c88-4f3c-97cb-24ac6c5fc5d5
name: 'Drupal 11 CMS Bootstrap'
mail: info@example.com
slogan: 'Das hier ist Deutsch'
page:
  403: ''
  404: /search404
  front: /node/47
admin_compact_mode: false
weight_select_max: 100
default_langcode: en
mail_notification: ''

So it may need an update to correct all the different default configs and turn them into translations...

So I think this case happens, if someone switched the default language over time!

The (unwanted and wrong) quick-fix is to set

Enable interface translation to English

TRUE at
/admin/config/regional/language/edit/en so the condition would become FALSE.

But of course that's not what we want and is logically wrong because English is our default language.

So to fix the regression I think we need to update all default configurations to have langcode: en and make these real translations, not defaults.

Furthermore, IMHO I think we could and should simplify all this, by making English the hard-coded default language for Drupal and make everything else a translation, so that for example in config export everything in "sync/" will be en and all other translations go into their dedicated sync/language/XX folder. Database-wise the "collection" column would be empty for these. That would clarify and simplify things a lot logic-wise and code-wise.
I think I already read this idea somewhere in the related issues.

How should we sort out these issues?

Should we open a regression issue for #36 or solve it somewhere else?
I think for our case we'll write an update hook like written above for all legacy default configs that have langcode: de.

Here's the follow-up to fix the regression: #3568743: Convert / unify all default configs to the site default language

I ran into this too the same issue as @anybody, but I don't think the root cause in our case is a switched default language.

Our case is in Webforms. Webforms are created in either Dutch or English and then translated as needed. The site default language is English. Webforms created in English can be translated to Dutch. After updating to 11.3 Webforms created in Dutch cannot be translated to English anymore and existing translations are not picked up anymore. The proposed fix in #3568743: Convert / unify all default configs to the site default language won't help here since new webforms are created all the time, so running an update won't do the trick.

In our case we needed to switch on 'Enable interface translation to English' in the English language. Which makes sense because that is indeed what we want, but that setting wasn't needed before and is now, so still came as a bit of a surprise and took some debugging to figure out what was going on. So sharing here to maybe save others some time.

Thanks @lendude. I think my suggestion to generally store (base) config in english would be the best fix in general, as it would fix all those cases and simplify things a lot for developers and Drupal itself.