Problem/Motivation

I found this in a legacy project so not sure how this happened but it's really ugly to debug.

The situation:

$ drush cget system.site
name: 'Foobar GmbH'
langcode: de
default_langcode: de
...

sshd-3657828677-m3whw:/var/www/html/docroot$ drush cget system.site --include-overridden
name: Drupal
langcode: de
default_langcode: de
...

As we see (also in config/sync), we have conflicting config and default-language-overridden config.
What now happens:
* User sees one site name (the overridden)
* Any attempt to change the site name only changes the un-overridden value

This makes some config stale, thus the site unusable, so prio is major or critical.

How to reproduce (untested)

I guess this is an instance of the admin/config/regional/language warning "It is not recommended to change the default language on a working site.". (Which is a big understatement here.)

* Install an english site with site name "Drupal"
* Enable german language
* Translate german site name to "Foobar"
* Change default language to german

Workaround

TODO: Merge and delete exported default-language-overrides.
(Just copying won't help as config may be overridden partly.)

Untested:

drush cex -y # if not done already
cexdir=../config-sync

lang=$(drush cget system.site default_langcode --format=string)

# Merge all default-language-translations and delete them
for filename in $cexdir/language/$lang/*.yml; do
  basename=${filename##*/}
  configname=${basename%.yml}
  # drush cset configname "" - --format=yaml <$filename # wont work...
  drupal yaml:merge $cexdir/$basename $cexdir/$basename $filename
  # Restore 4->2 spaces indent.
  sed 's/^\( \+\)\1\1\1/\1\1/' -i $cexdir/$basename
  rm $filename
done

# Give all untranslated config default language
langyml=$(mktemp)
echo "langcode: $lang" >$langyml
for filename in $cexdir/*.yml; do
  drupal yaml:merge $filename $filename $langyml
  # Restore 4->2 spaces indent.
  sed 's/^\( \+\)\1\1\1/\1\1/' -i $filename
done

# Optionally select which of the changes you want.

drush cim

Proposed resolution

a) Ensure integrity
Merge and drop any default-language-overrides:
* When saving config
* When changing default language
* When importing config
* (any other?)
...to ensure there are no default-language-overrides.

b) Alternatively, allow to translate to default language.

c) Alternatively, store all un-overridden config in neutral ("und") language
At first thought, this looks like the most elegant solution to me.
It draws a clear line between config and its translation, making eg distribution update workflows simpler of even feasible at all.
TODO: Consider if this drops legacy from the D7 way of thinking, or if this resolution has other drawbacks.

Code to check

* \Drupal\language\LanguageListBuilder::submitForm
* \Drupal\language\EventSubscriber\ConfigSubscriber::onConfigSave

Remaining tasks

* Find out how to reproduce
* Make it a failing test
* Code the above resolution

User interface changes

None

API changes

None

Data model changes

None

Comments

axel.rutz created an issue. See original summary.

geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Issue summary: View changes

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dksdev01’s picture

Looks like I am also having similar issues. thanks

geek-merlin’s picture

#11: I see this is related but i do not see this as dup.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ckaotik’s picture

I'd also like to mention #2905295: Configuration language being overwritten during module install as a slightly related issue.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

lorenzs’s picture

Another related issue describing in comment #17 of issue 2896235#comment-13432784

This should defnitely be looked at.

semiaddict’s picture

FYI, I have attached a patch in the related issue #2896235 which might fix this one as well.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

extralooping’s picture

We had problems with configuration language always set to default language when exporting with drush, which led to translations not working correctly. The patch by @semiaddict from #2896235 fixed that for us.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

larowlan’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +Bug Smash Initiative

The last few reports indicate this is solved by another issue? Can we mark this as closed (duplicate)? Thanks

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

I tested this on Drupal 10.1.x, standard install in English with Italian added. I used the steps to reproduce in the issue summary and the wasn't able to replicate the problem.

With the default language set to Italian the system.site config was

$ ddev drush cget system.site
langcode: en
uuid: a8b92449-4c80-42df-92e9-5df758be8979
name: 'english dev1-web'
...
weight_select_max: 100
default_langcode: it

$ ddev drush cget system.site --include-overridden
_core:
  default_config_hash: VDJxTZtQR21qB4lvOq8zszJZLvLKrSPQpdn2E3T71Ww
langcode: en
uuid: a8b92449-4c80-42df-92e9-5df758be8979
name: 'it foo - dev1-web'
'''
weight_select_max: 100
default_langcode: it

I think that this has been fixed since this was opened.

Therefore, I am closing as outdated. If that is incorrect, re-open and add a comment.