#3621975 gave the **Claims** menu link a `Payment` context and moved the catalogue entry with it, so the context-less `Claims` is no longer translated anywhere. The claims view still carries one: ```yaml style: type: table options: caption: 'Claims' ``` That caption is the one the listings hide visually and a screen reader announces, so on a French site the claims table is now announced in English. Its three siblings each caption the table with their own title (`Payments`, `Refunds`, `Reversals`), and the claims view's title is `Payment claims`, which is translated. ## Why nothing said so `PaymentsViewTest::testEveryTranslatableStringIsInTheCatalog` walks the view's translatable strings and looks each one up in the union of every catalogue, **by source text alone**. The `Payment`-context entry has the same text, so the caption passed. Locale keys on the pair, so the page did not. That test is one of several that read the project's own files on every run and assert about the words in them, which is a linter's job in the wrong tool: - `DeclaredStringsAreTranslatedTest` (five cases) and `FrenchCatalogTrait`, which walk every links, routing, schema, info and PHP file and every catalogue; - `EntityStringsAreTranslatedTest`, the same question asked of entity labels; - `PaymentsViewTest::testEveryTranslatableStringIsInTheCatalog`; - `NamedFilesResolveTest`, which checks file names mentioned in comments, and whose second case exists to prove the first one read something; - `MetricsPageTest`, which greps the generated `docs/metrics.md`; - `SectionIconTest::testTheStylesheetTargetsTheClassCoreGenerates` and `::testTheStylesheetHandsTheTunedGlyphToGin`, which read the stylesheet as text: PHP cannot evaluate a cascade; - `testSchemaLabelsMatchTheForm` in `KessaiSettingsFormTest` and in `WorldlineAccountFormTest`, which pin two English strings equal; - the half of `PaymentsViewTest::testEachViewDependsOnTheModuleProvidingItsRecords` that reads the shipped YAML. ## What the extractor finds orchestra already answers the translation question in a lint lane: `scripts/check-translations.php` runs potx, the extractor localize.drupal.org itself runs, per interface translation project, and keys on context. Run unchanged over kessai at `b5053c5` it reports, besides the caption: - **Two strings translated two ways.** `Enabled` is `Activée` in `kessai_engine` and `Activé` in `kessai_client` and `kessai_simulator`; `Notice limits` is `Limites des avis` in `kessai_client` and `Limites des notifications` in the contract. Locale keeps one string table for the site, so whichever module was installed last decides the word everywhere. The engine's `Enabled`/`Disabled` label a payment account, which is masculine in French. - **Two refusals localize.drupal.org never offers a translator.** potx reads a constraint's messages from the properties whose name ends in `message`, which is also how core names every extra message a constraint carries (`$wrongTypeMessage`, `$missingMessage`). `ConsumerOriginConstraint` calls its two `$notAnOrigin` and `$notEncrypted`, so both reach French only through the catalogue shipped here. - **Two misfiled entries.** `Refund` and `Reversal` in `kessai_views/translations/fr.po` appear in none of that module's files; the engine, which declares them, translates them already. - **One constraint label never looked up.** `ConsumerOriginConstraint` declares `Kessai consumer origin` with the `Validation` context core gives every constraint label, and the entry in `kessai_server/translations/fr.po` names no context, so locale never matches it. - 48 log messages with no French. They are for an operator reading the log, and the lane allow-lists them with that reason, as orchestra does. So are `Default`, `Page` and `ID`, which views serializes into every shipped view and core translates. ## Proposed resolution - Caption the claims table `Payment claims`, like its siblings. - Settle `Enabled`/`Disabled` on `Activé`/`Désactivé` and `Notice limits` on `Limites des avis`; drop the two misfiled entries; give the constraint label's entry its context. - Rename the two constraint message properties to `$notAnOriginMessage` and `$notEncryptedMessage`. - Ship orchestra's `scripts/check-translations.php` with a `translations` job, `drupal/potx` as a development dependency, `translations/untranslated.txt` for the log messages and `translations/untranslated-in-config.txt` for core's three. - Delete the tests listed above. `testEveryListingThisModuleShipsIsServedTheStylesheet` keeps its assertion and finds the listings through the view storage instead of a glob over `config/install`. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code on the merge request. I reviewed and ran the work myself before posting it.)