`kessai_server` ships a French catalogue that translates everything an operator reads: both permissions, all four consumer field labels and descriptions, both constraint messages, all four delete and rename guards with their plural forms, and the whole of the API limits form. Four strings are missing, and they are the four added with `KessaiServerRequirements`: - `Kessai consumer addresses` - `1 consumer holds an address nothing will follow` - `@count consumers hold an address nothing will follow` - the description beginning `These addresses are stored but are not somewhere a payment may travel…` A French operator opening the status report, which is where somebody looks when something is wrong and nobody can say what, reads that one warning in English. ## The guard that exists does not cover where this lives `DeclaredStringsAreTranslatedTest` was written against exactly this drift, and says so: > A French catalog drifts quietly. Nothing fails, nothing is logged, and the only symptom is a French page with English on it, which whoever added the string does not see because they are not reading the site in French. It covers link titles, config schema labels and `.info.yml`. `kessai_engine`'s `EntityStringsAreTranslatedTest` covers entity types and their fields. `kessai_views`' `PaymentsViewTest` covers the strings inside a shipped view. Between them they cover every declarative surface, and the test says what is left out: > What a module declares in PHP is not checked here, because finding it means parsing PHP. PHP is the largest surface of the four and the one a status report, a form, a log message and an exception all live on. It is where this gap is, and it is where the next one will be. ## Parsing it is affordable here Every translatable call in this project's production code passes a plain string literal as its first argument: `$this->t('…')`, `new TranslatableMarkup("…")`, `$this->formatPlural($n, '…', '…')`. There is not one call in `src/` anywhere in the project that builds its source string from a variable or a concatenation, so a reader that only recognises literals is not a reader that quietly passes what it cannot see: it either finds a literal or there is nothing there to find. Run over the tree as it stands, such a reader reports exactly the four strings above, and one more in `kessai_engine.api.php`, which is a documentation stub showing a caller what to write rather than code that runs. ## Also, found while writing it A route's `_title` is the last declarative surface none of the four cases reads. It is what the page it serves is called, and core runs it through the translation system exactly as it does a link's title. Every one this project declares is already translated, so a case for it lands green; what it closes is the surface, since an unguarded one is where the next gap goes. ## Proposed resolution - Translate the four strings in `modules/kessai_server/translations/fr.po`, including both plural forms. - Extend `DeclaredStringsAreTranslatedTest` with a case that reads the literal source strings out of each project's own PHP and holds them against that project's own catalogue, the way the three existing cases hold the declarative surfaces. Skip `*.api.php`, and say in the docblock which shapes the reader recognises and why that is all of them here. - Proven in both directions: the new case fails against the catalogue as it stands today. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)