>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3616523. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !252 >>> <h3>Problem/Motivation</h3> <p>A constraint policy's booker-facing wording is authored prose, and where that prose is stored decides whether it can be translated. A policy attached to a resource type is stored in the type's <code class="language-php">third_party_settings</code>, so it is configuration and Config Translation handles it. The same policy attached to one of the three content hosts (<code class="language-php">yoyaku_resource</code>, <code class="language-php">yoyaku_resource_tariff</code>, <code class="language-php">yoyaku_slot_tariff</code>) is stored as JSON in the <code class="language-php">policies</code> base field, and neither Config Translation nor Content Translation can see inside a serialized value. The settings form dealt with that by dropping the field on every host but the type, so those three could not word a refusal at all.</p> <p>Nothing was broken: leaving the setting empty falls through to the sentence the plugin ships, which is translated in the module .po file and is plural aware. What was missing is a translated override on a content host, and the same gap blocked any future policy that puts a sentence to the booker rather than a refusal.</p> <h3>Proposed resolution</h3> <p>A <code class="language-php">yoyaku_message</code> config entity holds an id, a label, the text and the usage keys it may serve. A policy setting stores a reference to one instead of the prose itself, so Config Translation covers it once and every host reads the translated value. Giving the entity its own administration screens is also what makes it translatable, since Config Translation discovers a config entity type by its edit-form link template, so no new module dependency is involved.</p> <p>Usage keys are published by the installed policies rather than typed by an operator. A policy declares the key it offers a message for, defaulting to its own plugin id, so a module shipping a new policy extends the vocabulary by existing and there is no enum in the engine for anyone to maintain. The key is multi-value on the message, so one sentence can serve two policies. A policy offers only the messages carrying its own key, and a mismatch is refused on save.</p> <p>Placeholder validation sits on top of that filter rather than replacing it. Each policy declares what it substitutes beside its usage key, and that one declaration is read both by the settings form, which names the placeholders under the choice, and by the message form, which refuses a sentence using anything the policies carrying it would not fill in. An unsubstituted <code class="language-php">@limit</code> therefore cannot reach a booker verbatim. An address written into a sentence is not read as a placeholder.</p> <p>A reference on a resource type gains a real config dependency, so the delete screen names the types a message is in use on, and deleting the message empties the reference rather than taking the resource type with it. A reference inside the <code class="language-php">policies</code> field is invisible to the dependency system, so a dangling id behaves exactly as an empty setting does and falls through to the sentence the plugin ships. So does a message that is no longer written for the policy reading it. That matches the posture the policy manager already takes for an attachment naming a plugin that no longer exists.</p> <p>The free-text branch goes away rather than staying as a fallback. The project is pre-1.0 and ships no update hooks, so reinstalling is the upgrade path.</p> <h3>Fixed along the way</h3> <p>Two defects found while building this, both corrected here. The policy settings form never called the plugin own <code class="language-php">validateConfigurationForm()</code>, so the per-booker family check that a season names the day it counts from had never run. And <code class="language-php">transaction_quantity_limit</code> offered the <code class="language-php">@tariff</code> placeholder without passing it where an attachment reaches more than one tariff, which is exactly the case the validation above exists to prevent.</p> <h3>Remaining tasks</h3> <ul> <li>Review the merge request.</li> </ul> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code, tests and documentation on the merge request. Every linter and the module test suite were run on it and the pipeline is green; I am reviewing the work before it is merged.)</p>