list.loading serves the raw English sentence "Loading records…" in eight of the nine packs (zh alone translated it) — plus 3 more prose values byte-identical to en #4376

Found while executing #3878 (ellipsis convergence) on branch claude/issue-3878-i18n-copy-trio — list.loading is one of the 35 keys that pass touched, and converging its glyph made the untranslated body of the value obvious. Out of #3878's scope (that card is about a glyph, this is about the sentence), so recorded separately.

Measured

list.loading, on origin/main at 2fea4d2fa:

Eight of nine packs serve the English sentence. zh is the only one that translated it. A Japanese, Korean, Russian or Arabic user reading a list view sees a Latin-script English sentence in the middle of an otherwise translated screen — and in ar it is left-to-right text inside a right-to-left layout.

The same probe over the whole pack set

A value byte-identical to en inside a non-Latin-script pack (zh/ja/ko/ru/ar) is untranslated with near-certainty, since a real translation cannot be byte-equal to the English. 26 keys match. Most are legitimate and should be left alone — proper nouns and format strings that are the same in every language:

name@example.com, Acme Inc., JSON, Webhook, v{{version}}, {{current}} / {{total}}, {{name}} ({{reason}}), Logo URL, Favicon URL, Beta, Freemium, headless, Powered by ObjectStack, {{object}}-import-template.

That leaves four that are real English prose and should be translated:

designer.undo / designer.redo are the arguable pair — some product vocabularies keep them English — but zh, ja, ko, ru and ar all have ordinary native words for undo/redo, and this repo translates every neighbouring designer action, so the identity reads as an omission rather than a decision. appDesigner.snakeCaseHint is unambiguous: a full English sentence with a parenthetical example.

Why no gate sees it

The same value-domain blind spot as #3582 / #3625 / #3810 / #3875, one more shape:

• all-locales-key-parity compares key sets and placeholder shapes, never values — all four keys are present in all ten packs with matching holes.
• scripts/check-i18n-call-site-keys.mjs asks only whether a key resolves. All four resolve.
• scripts/check-i18n-en-drift.mjs fires on an en value change. These values were identical from the day the packs landed, so no drift event ever existed.

Worth noting the probe used here is cheap and mechanical for the five non-Latin packs, where byte-identity is decisive: value === en[key] && /[A-Za-z]{4,}/.test(value). It is not sound for de/fr/es/pt, where identity can be genuine — which is exactly why list.loading needs the eight-pack count stated by hand. #3582 already measured that the inverse probe ("no ASCII English in a non-Latin pack") produces false negatives; this one is the narrower, decidable form, and could be a gate if the ~14 legitimate identities were listed as an allowlist. Recording that as an option, not a recommendation — the allowlist is the cost.

Anchor

Verified on origin/main at 2fea4d2fa. Related: #3878 (glyph convergence, where this surfaced), #3582 / #3625 (the two value-blind-spot defects that motivated the drift gate), #3810.

Generated by Claude Code