Nothing checks that a shipped string is translated, so the French catalogue drifts

The module ships its French in translations/yoyaku.fr.po, and the rule is that a change ships its translations in the same commit as the string it adds. Nothing enforces that rule. It is kept by memory, and #3618469: Ten operator-facing strings are missing from the French catalogue, so a French site shows them in English is what that costs: ten strings arrived over a handful of merges and a French site read them in English until somebody happened to run an extractor by hand.

The check. A pipeline job that extracts the module's translatable strings and fails when one of them has no entry in the catalogue. Extraction is potx, the extractor localize.drupal.org itself runs, because knowing what counts is the hard half: label: in config/schema counts and the same key in config/install does not, .info.yml name and description count, and a plural is one entry to potx and two to gettext. A regex scan of this module once reported everything present and was wrong by ninety-four strings.

What is deliberately English goes in translations/untranslated.txt, one string per line with its reason, and only two kinds qualify. Log messages, which potx extracts because a logger call looks like any other call with a sentence in it, but which are read by whoever is fixing the site: the same doctrine the engine applies to a refusal, where what went wrong and what the visitor is told are two different sentences. And words core already answers, such as the breadcrumb's "Home", which core renders as "Accueil". Without that list the job is red on its first run and stops being read.

What it costs. drupal/potx as a development dependency, the first tooling dependency this module has taken. Pin ^2.0.0-alpha2 or later: 1.1.0 declares drush.services.yml: "^9", so Drush 13 will not expose it.

What it will not catch. A JavaScript call with a trailing comma after its last argument, Drupal.t('…',), which is what Prettier emits on a wrapped call and which potx drops silently. That is an upstream bug, open since 2020, and it hit nine of seventy-two JavaScript strings here once. So the check is strong over PHP and YAML and leaky over JavaScript, which is worth knowing rather than worth waiting for.

The job is not allow_failure, unlike the lint jobs: the French is a deliverable here rather than a nicety, and a check that goes red under a green badge is a check nobody reads.

AI-Generated: Yes (Claude Code proposed this while fixing #3618469: Ten operator-facing strings are missing from the French catalogue, so a French site shows them in English, and wrote the script, the allowlist, the job and the documentation on the merge request. I reviewed it before posting.)