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

Files: 

Comments

webflo created an issue. See original summary.

webflo’s picture

webflo’s picture

webflo’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 2: 2687001-1.patch, failed testing.

Gábor Hojtsy’s picture

Issue tags: +D8MI, +language-config

locale_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?

mkalkbrenner’s picture

Let 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.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.