Labels that only shipped configuration carries are never checked, and 24 of them are untranslated

Problem

The per-project translations check reports two directions, and the "missing" one is fed by potx, which was never given config/install or config/optional. A string that only a shipped configuration entity carries was therefore never required to have a translation, and 24 of them had none in the catalog of the project that ships them.

What was untranslated

• Fifteen strings in orchestra_interaction_webform_examples: the flow labels Awaiting validation, Requested changes, Processed and Rejected, the three shipped status labels Being processed, Changes requested and Under review, the four sentences a requester reads about their own submission, the form title Request validation, and the bodies of the three Easy Email templates the module ships as config/optional.
• Paid and Expired, flow labels in orchestra_payment_example.
• Orchestra timestamp and the pattern Y-m-d H:i:s, the date format orchestra_ui installs.
• Four view labels and descriptions in orchestra_inbox_views and orchestra_views, and one message in orchestra_examples.

#3620615 fixed this for the two modules whose shipped strings it happened to touch, and each of those got a unit test asserting its own configuration was covered. Nothing generalized that to the rest of the project, which is why these 24 were still here. Those two per-module tests are removed: one mechanism now covers every module, and it is exercised against the whole tree rather than two modules having their own.

The rule for a string somebody else already translates

Feeding the shipped configuration directories to potx also reports wording that Drupal core itself ships and translates: Apply, Reset, Sort by, Asc, Desc, Items per page, - All - and the pager, all of it exposed-form and pager chrome serialized inside the views this project installs. locale keeps one string table for the whole site, so those already read in French from core's own catalog, and duplicating them per project would be wrong as well as unmaintainable.

The rule chosen is a second allow-list, translations/untranslated-in-config.txt, read only for a value a shipped configuration entity carries. It has to be separate from translations/untranslated.txt, which exempts a string everywhere: Apply is core's wording inside a shipped view and a button this project writes itself, and one list for both stopped the check asking for either. Each entry carries the reason it is there, and every one was checked against a French site's string table rather than assumed.

Other holes in the same script

• A translation context was not part of the key on either side, so a contextless entry satisfied a string locale looks up under a context. That is why the date format shipped with an entry that never applied: the site rendered the English pattern.
• The catalog reader took msgid and msgid_plural and never looked at msgstr, so an entry whose translation is empty or marked fuzzy counted as present while locale ignores it at runtime.
• Seven entries in orchestra_interaction_webform_examples could never be looked up at all. A webform stores its whole element tree as one string and webform's schema types that key as a single text value, so the translatable string locale registers is the entire document, not the '#title' values inside it. The entries are deleted, the reason is written down in the module's README, and the check now reports that class of entry.
• A shipped-config string was asked for against the project's declared dependencies only, one level deep. Installing a module installs its dependencies' dependencies too, so three projects were reading a smaller set of catalogs than they may rely on, two of them missing 105 strings.
• The flag saying where an extracted string came from was combined across every file it appears in, so a string written in code and also carried by shipped configuration was checked the looser of the two ways. Each obligation is now asked of the origin that owes it.
• Which values count as translatable depends on the config schemas potx finds, so the same commit reached a different verdict on a lean checkout than on a development root holding hundreds of contrib projects. The schema set is now derived from what this project ships, and the check asserts a budget on it, because potx re-reads core's schemas once per module it has seen files from.

AI-Generated: Yes (Claude Code was used to write the code and the tests on the merge request, to draft this issue summary, and to take the measurements it reports. I reviewed the code, the measurements and the wording before posting.)