Locale override subscriber should re-init context to clear caches

Needs tests. Settings needs review for bot.

Thanks for cross-testing manually. I think it would be very valuable to have automated tests for this. I tried to whip together something but it does not fail! I cannot really figure out why. Anybody have insights? Based on what we do manually to reproduce the issue, the test should fail, right? No?

BTW the reason we did not have tests for this is that all the config override tests (including locale) are unit test based, so they are not meant / targeted to test the full cycle of an override getting into the output of the webpage. That is why I needed to open a totally new webtestbase based test.

I've seen @nevergone reproduce the bug and express his joy seeing it fixed with the patch BTW :) That does not save us from needing to produce a failing test :) Also adding #SprintWeekend tag for sprint weekend.

+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigLocaleOverrideWebTest.phpundefined
@@ -0,0 +1,53 @@
+  /**
+   * Tests translating the site name.
+   */
+  function testSiteNameTranslation() {

The name of the method is not good anymore :)

+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigLocaleOverrideWebTest.phpundefined
@@ -0,0 +1,53 @@
+    config('system.timezone')->set('user.configurable', TRUE)->save();

There is no explanation why you do this?!

+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigLocaleOverrideWebTest.phpundefined
@@ -0,0 +1,53 @@
+    // The English regional settings page should not have a default timezone of
+    // Europe/Paris.
+    $this->drupalGet('admin/config/regional/settings');
+    $this->assertNoOptionSelected('edit-date-default-timezone', 'Europe/Paris');
+
+    // The French regional settings page should have a default timezone of
+    // Europe/Paris.
+    $this->drupalGet('fr/admin/config/regional/settings');
+    $this->assertOptionSelected('edit-date-default-timezone', 'Europe/Paris');

This is pretty odd. If the admin page shows the localised version of the setting, that would be a problem. The regular admin pages should not show localised settings at any time. (Date formats have some custom implementation for this for some reason, but the rest of the forms should use the override free context).

So testing for this actually exposes the bug that overrides are actually used on this form. The prior test I did did not use the admin forms, but instead see the effect on frontend output.

Is there another setting we can test with that has an easily testable frontend effect? I've seen people reproduce the site name issue and I reproduced and debugged it myself. So it is strange it would not be useful in the test...

Make sense :) Thanks for keeping it to the site name override, which is the most natural example to work with :) Only found two issues.

+++ b/core/lib/Drupal/Core/Config/Context/ConfigContext.phpundefined
@@ -63,6 +63,8 @@ public function __construct(EventDispatcher $event_dispatcher) {
+    // // Reset existing overrides and get a UUID for this context.
+    $this->overrides = array();

Too much // :D

Also core/modules/config/tests/config_test/config/locale.config.fr.system.site.yml missing from both test only and the other patch.

#15 problems still stand.

Looks great to me now :) The fix wil also make #1934712: Merge system.timezone config object into system.date work where another failing test reproduces the issue, so that should be two great reasons to commit :)

#18: 1934964.config-context-reinit.18.patch queued for re-testing.

#18: 1934964.config-context-reinit.18.testonly.patch queued for re-testing.

Upping to major since even though you can save translations for your site name and other basic things, they will never be used on display until this is fixed.

Thanks!