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
Comment #2
geek-merlinComment #3
geek-merlinComment #4
geek-merlinComment #5
geek-merlinComment #6
geek-merlinComment #7
geek-merlinComment #8
geek-merlinComment #9
geek-merlinComment #10
geek-merlinComment #11
andypostLooks it duplicate of #2791405: When installing a site in a language besides English, the site name is not saved and reverts to "Drupal"
So better to close and proceed in #2925203: LocaleConfigSubscriber can result in data loss during install
Comment #14
dksdev01 commentedLooks like I am also having similar issues. thanks
Comment #15
geek-merlin#11: I see this is related but i do not see this as dup.
Comment #17
ckaotikI'd also like to mention #2905295: Configuration language being overwritten during module install as a slightly related issue.
Comment #19
lorenzs commentedAnother related issue describing in comment #17 of issue 2896235#comment-13432784
This should defnitely be looked at.
Comment #20
semiaddict commentedFYI, I have attached a patch in the related issue #2896235 which might fix this one as well.
Comment #22
extraloopingWe 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.
Comment #26
larowlanThe last few reports indicate this is solved by another issue? Can we mark this as closed (duplicate)? Thanks
Comment #29
quietone commentedI 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
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.