Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
I have a site with three language (EN, DE, ES). DE is the default language. The language stored in some config files changes from en to de on import.
Proposed resolution
The langcode should not change.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#2 | 2687001-1.patch | 2.06 KB | webflo |
Comments
Comment #2
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedComment #3
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedComment #4
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedComment #6
Gábor Hojtsylocale_system_set_config_langcodes() changes langcodes for all prior shipped configuration when modules or themes are installed. It should not change it when config is imported (that is when modules are not installed as part of the import). Your test installs a module, so no wonder it goes into locale_system_set_config_langcodes(). Looks like this is by design but you don't like how its designed :) Let's discuss?
Comment #7
mkalkbrennerLet me describe the situation we face in #2686575: Generated schema contains duplicate field types if Site is installed in different language than English which is not about the installation process:
When you enable an additional language on your drupal site the corresponding Solr field type config for that language gets imported automatically. These configs / their yml files contain the language attribute set to the language they are targeting.
If the site was initially installed using English, every imported Solr field type config keeps it's language, not matter what the current default language is.
If the site was initially installed using a language different than English, the language of every imported Solr field type config is converted into the default language.
So we see a big difference here instead of a consistent behavior. No matter what the right solution is (keeping the language of the config or converting the language to sites default language), it needs to be the same in both scenarios.