This was originally discussed as part of #2584603: PHP exception on manage fields after enabling Configuration Translation but was then split off. Please credit @claudiu.cristea.


After #2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated the language code of shipped configuration is equal to the site's default language and no longer always en. ConfigNamesMapper contains a fallback for configuration that fails to explicitly provide a language code but it still hardcodes en

Proposed resolution

Fall back to the site's default language instead.

Remaining tasks

User interface changes

API changes

Data model changes



tstoeckler created an issue. See original summary.

tstoeckler’s picture

Here's the patch from the referenced issue.

One thing that occured to me is that this still doesn't help you if you install e.g. in French - so that all the shipped configuration has the fr language code and then you change the default language to Spanish. I think then you can still get into a situation where this exception is triggered.

A different option would be to simply remove the exception and just pick the first language code. Certainly not ideal, but a lot better than bubbling the exception to the user. Maybe an assertion would be the better tool here?

Created the issue assigned to, you, @GáborHojtsy because I don't know who would be more suitable to give some input on this than you.

tstoeckler’s picture

Status: Active » Needs review
3.11 KB

It really is late here. Here's the patch now for realz. Again, this is not actually my patch but @claudiu.cristea's (kudos!)

Status: Needs review » Needs work

The last submitted patch, 3: 2584603-14.patch, failed testing.

Gábor Hojtsy’s picture

Status: Needs work » Closed (works as designed)
Issue tags: -sprint

I don't think this is what we want at all. If a file does not have a langcode, the DEVELOPER did not provide one and we expect development of code to happen in English not in whatever configurable language the site has. Locale also assumes the file to be English and rewrites it to be in another language if there are translations. Not having the same assumption about defaults at different places in core would also be dangerous.

I think this is a closed by design. Please explain why the current behavior is a bug in more detail if you believe so.

Gábor Hojtsy’s picture

I think I better understand the motivation after reading #2584603: PHP exception on manage fields after enabling Configuration Translation. So I think the concern is some files might not get the site default langcode? Looking at locale_system_set_config_langcodes(), it updates ALL the configs on the system to be the site's default langcode. That is invoked each time a module or theme is installed. It is true that would only update files that are shipped in some way. Once you add more configs, eg. a base field override, there is nothing to ensure they would be the same language. That is where #2584603: PHP exception on manage fields after enabling Configuration Translation may be on shaky ground indeed. Defaulting to a different language would not in fact help that AFAIS as related config files may be created with other languages on a site.