## Problem/Motivation `follow_site_default: true` reads as "keep the lock on whatever the site default language is", but it is only wired into two form submit handlers. `getLockedLangcode()` never consults it. That makes `locked_langcode` and `follow_site_default` able to contradict each other, and the contradiction is silent until someone saves a form. Concretely, with `locked_langcode: en` + `follow_site_default: true` on a site whose default language is `ar`: - The effective lock stays `en`. `follow_site_default` has no effect on its own. - The first submit of the language overview form (or the module settings form) moves the lock to `ar`, overriding the configured `en`, and queues the rewrite batch. Observed: 116 configuration objects rewritten, 102 translations updated, 96 removed. - Changing the site default by any other route — `drush cset system.site default_langcode`, a configuration import, the installer — does not move the lock. The follow behaviour hangs off that one form. This matters most for **distributions and recipes**, which have to write both keys statically and cannot know the site default at authoring time. A recipe shipping `locked_langcode: en` + `follow_site_default: true` is correct on an English site and latently wrong everywhere else. It is sharper with Canvas installed, because of the check added in #3613942: ```php $is_valid = $follow_site_default && $locked_langcode === $default_langcode; ``` A site installed in a non-English language then shows a red status-report error out of the box, and the only offered fix — saving the settings form — silently rewrites every configuration object to the site language. Two related notes: - The module's own defaults (`locked_langcode: null`, `follow_site_default: false`) also fail that check when Canvas is present, so a bare install is already in the error state until configured. - A config action that writes these settings updates *simple* config, so it does not fire the entity presave path and does not queue the rewrite batch. Existing drift is left in place. Verified: 4 already-drifted objects survived unchanged. ## Steps to reproduce 1. Drupal 11.4 with `language`, `locale`, `config_translation`, `content_translation`; add a second language. 2. Set `locked_langcode: en` and `follow_site_default: true` via `drush cset` or a config action. 3. Set the site default language to the second language. 4. Read `getLockedLangcode()` — still `en`. 5. Submit the language overview form once — `locked_langcode` becomes the site default and the rewrite batch runs. ## Proposed resolution Make the two keys stop contradicting each other. Options, in rough order of preference: 1. Have `getLockedLangcode()` honour `follow_site_default` directly: when it is `true`, return the site default and treat `locked_langcode` as a cache of it. The setting would then mean what its name says regardless of how the default was changed. 2. Failing that, make the Canvas requirement check accept `follow_site_default === true` on its own, so the `locked_langcode` value is not also required to match. 3. At minimum, document that `follow_site_default` is form-only, and validate the contradictory combination when it is written. Also worth considering for recipe authors: a way to express "lock to whatever the site default is at apply time" that does not require knowing the langcode statically. ## Environment `config_language_lock` 1.0.1 on Drupal 11.4.5, PHP 8.4, Drush 13.7.6. Behaviour read from `ConfigLanguageLockRequirementsHooks.php` and confirmed on a live site. --- This report was written with AI assistance, per the [Drupal AI policy](https://www.drupal.org/about/core/policies/core-change-policies/ai-policy).