ci(i18n): cover every shipped locale, not the four in a constant

[ryanbr]

Implements #844.

The gate covered half the shipped languages

Tools/i18n_audit.py:34 is LANGS = ["de", "es", "fr", "pt-PT"]. The Apple catalogs ship eight non-English localizations.

catalog	de/es/fr/pt-PT	it	ru	zh-Hans	zh-Hant
Strand (3255 keys)	100 %	3086	3110	3136	3086
StrandDesign (95)	100 %	14	41	20	14
NOOPWatch (52)	100 %	49	50	49	49
NOOPWatchComplications (30)	100 %	5	30	5	5

The four gated languages are at 100 % in every catalog. The four ungated ones are missing up to 85 % — StrandDesign ships 14 of 95 Italian, the watch complications 5 of 30. That is the gate doing its job where it is pointed, and nothing happening where it is not.

Android is the same shape: ANDROID_LOCALE_DIRS hardcodes the same four, values-zh exists on disk, is never compared, and sits 43 keys behind. That is how #834 passed CI while adding a key to four of five locale files.

The fix

Both lists are discovered rather than declared — Apple languages from the union of each catalog's own localizations, Android dirs from values-* on disk. A locale is covered the day it appears, not the day someone remembers to update a constant.

LANGS keeps zero tolerance and is untouched. Those four are perfect precisely because they are hard-gated, and this must not regress that.

The newly-covered locales carry 1019 real pre-existing gaps, so they gate against a ratcheting allowance. Switching them on hard would red-check every open PR on lines nobody touched — the exact #514 failure this workflow's own comments warn about. Counts rather than key lists, same reasoning as doc_comment_lint_baseline.txt (#849): a key list goes stale on every edit and trains people to regenerate it unread. It ratchets down, printing IMPROVED when a count drops.

Verification

green on main                                            -> exit 0  (1019 tracked)
remove one values-zh key            (43 -> 44)           -> exit 1
remove one StrandDesign Italian string (81 -> 82)        -> exit 1
remove one values-de key                                 -> exit 1  (zero tolerance intact)

The last one matters most: this touches the only job currently gating PRs, so the existing hard behaviour had to be shown unchanged.

Worth noting my first probe didn't fire — it had removed app_name, which is explicitly exempt. The gate was right and the test was wrong; re-run with a real key it fails as intended.

What this deliberately doesn't do

It translates nothing. It stops the hole growing and makes the debt countable. Whether it/ru/zh-* should ship at 14/95 or be withheld until filled is a product call — I'd rather you make it than have it implied by a linter.

[ryanbr]

Re-reviewed my own change; three fixes pushed, no behaviour change.

1. The app_name exemption was defined twice — once inside android_strings_xml_gaps, and again inline in the new discovered-locale check. That is exactly the two-definitions-of-one-rule pattern refactor(sleep): one stage-key canonicalisation, not two kept in parity by comment #829 removed this morning, and I reintroduced it hours later. It would have let the hard-gated path and the discovered path disagree the first time anyone added a second exempt key. Hoisted to ANDROID_EXEMPT_KEYS, used by both.

2. The new check re-parsed every catalog the loop above had just loaded — a second full parse of a 3255-string file for nothing. The extra-locale counts are now collected inside that existing loop.

3. --update-baseline does not touch the new allowance file, which was silently misleading given the tool now has two baselines. Its help says so now. Hand-lowering is deliberate: shrinking the allowance should be an explicit act, not a side effect of regenerating something else.

All four gate cases re-verified after the refactor — green on main, fires on a removed values-zh key (43→44), fires on a removed StrandDesign Italian string, and de still hard-fails on one missing key.

[ryanbr]

Third pass, and this one found a real bug — by reading the merged file instead of trusting the patch I had applied.

The new section keyed its summary on the GLOBAL failed flag. So a PR that broke a German string — or tripped any earlier check — saw the locale section print no verdict at all. No OK, no counts, nothing. That reads as "this section did not run", which is the worst thing a gate can tell someone trying to understand a red build. Scoped to a local flag; it now always states its own result:

de broken -> exit=1, and the section still reports:
  OK no new gaps in the non-focus locales (1019 tracked, ratcheting down)

Also added STALE reporting. An allowance for a target that no longer exists — locale removed, catalog dropped — can never be satisfied and silently inflates the tracked total. It is now surfaced for removal rather than left to rot.

Six behaviours verified after the change: green on main; fires when the zh gap grows 43→44; fires when a StrandDesign Italian string is removed; de still hard-fails on one missing key; a fabricated values-xx allowance is reported STALE; and clean after restore.

Both jobs green.

[ryanbr]

Fourth pass — looked at what sits next to the change rather than only at the change, and found the same blind spot in the reporting path.

catalog_summary() iterated the same hardcoded LANGS. So the human-readable coverage report read missing=0 across the board while four locales sat at up to 85 % untranslated. That is very likely why this went unnoticed for so long: anyone who ran the audit to check coverage was shown a clean sheet.

It now reports every locale the catalog ships:

StrandDesign (95 keys):   de 0  es 0  fr 0  it 81  pt-PT 0  ru 54  zh-Hans 75  zh-Hant 81
Strand (3255 keys):       de 0  es 0  fr 0  it 168 pt-PT 0  ru 149 zh-Hans 118 zh-Hant 168
NOOPWatchComplications:   de 0  es 0  fr 0  it 25  pt-PT 0  ru 0   zh-Hans 25  zh-Hant 25

The gate and the human-readable view have to see the same set of languages, or the view quietly reassures you about the ones nobody is checking. It also turns the summary into the burn-down dashboard for the 1019 tracked gaps, which is what you would actually want to look at while closing them.

Gate behaviour unchanged and re-verified: green on main, fires when the zh gap grows, de still hard-fails on one key. Both jobs green.