>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3617964. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !273 >>> <p>Refusals the engine raises are built with <code>sprintf</code>, name entity ids, and reach the booker word for word on a public page. They are not translatable, so a French site shows them in English, and they say things a booker cannot act on.</p> <p><strong>What a booker sees.</strong> Both observed on screen, the first in a browser test of the booking page and the second in a kernel run:</p> <ul> <li>"Slot tariff 12: 2 of 2 unit(s) left, 10 requested." from <code>BookingManager::assertLimit()</code>. The name is not read from the entity: the label is built as the words "Slot tariff" followed by the id.</li> <li>"Tariff 8 is not on offer on this booking channel." from <code>RequestBooker::assertOnOffer()</code>, which names the tariff id.</li> </ul> <p><strong>There are nine of them, not two.</strong> The leak is the catch rather than those two sentences: four places pass a caught message straight to a booker, and all four catch the base <code>BookingException</code>, so anything thrown under them is shown. Every refusal a booker can reach:</p> <ul> <li>The quota or the capacity that will not take the whole ask, in <code>BookingManager::assertLimit()</code>.</li> <li>A resource, and a tariff, not on offer on this booking channel, in <code>RequestBooker::assertOnOffer()</code>.</li> <li>A slot, and a tariff, deleted while a hold waited for its lock, in <code>BookingManager::reloadForCheck()</code>.</li> <li>A lock anchor that was missing and could not be written, in <code>LockAnchors</code>.</li> <li>Seats already taken when the hold went to claim them, in <code>SlotPlaces</code>.</li> <li>A place a booking save cannot hold, in <code>SlotPlaceHooks</code>.</li> <li>A hold that had lapsed before it could be confirmed, and an order no longer open for editing.</li> </ul> <p><strong>What is wrong with it.</strong> The strings are built with <code>sprintf</code> rather than <code>t()</code>, so they never reach the translation template. They put entity ids on a public page, where an id means nothing to a booker. And they name what the surface has already named: the message is shown beside the offer card that carries the label. <code>SeatingCloseness::message()</code> in yoyaku_placement is written the other way on purpose, and <code>Broken::refusal()</code> states the doctrine in its docblock: what the visitor is told is not what went wrong, and the id belongs to the log.</p> <p><strong>The fix.</strong> A refusal carries two sentences. <code>getMessage()</code> keeps the ids and the states, in English, for the log and the stack trace. What a booker may read is a translatable sentence attached beside it and read back through <code>getTranslatedMessage()</code>, named after core's own <code>UnmetDependenciesException</code>, which splits the same two sentences the same way. Surfaces ask one service, which returns the sentence when there is one and otherwise logs the technical message and answers with a generic one, so a message written for a developer cannot reach a page by accident. No new exception classes are needed: the existing subclasses already carry control-flow meaning, and the sentence is data on the base class.</p> <p><strong>Also found.</strong> The French catalogue carries "The slot is no longer available.", translated, with nothing in the codebase calling <code>t()</code> on it. An orphan of this same bug: the sentence was worth translating and could never be shown.</p> <p>Found while auditing the branch on <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3617848" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3617848</a></span>, which shows these messages on the offer cards it draws; it does not introduce them.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary, swept the engine for the other seven messages, and wrote the code on the merge request. I reviewed both before posting.)</p>