[finding] After #3878 merged the two ellipsis groups, `Loading…` is one 10-key group and de renders it four ways (ko two, ar two) — #3880's "two-key typo" no longer describes it

[yinlianghui]

Filed from the #3880 dispatch (PR #5971). Unassigned, and deliberately not a re-file of #3880's de half — the shape it described no longer exists, and what replaced it is a different decision.

What changed under the card

#3880 recorded a two-key de typo: common.loading Wird geladen... against detail.loading Laden..., both with an ASCII ellipsis, and its 2026-08-09 triage queued exactly those two values while fencing off "every U+2026 variant" as #3878's territory.

#3878 then landed (PR #4378) and converged all ten packs on U+2026. Both of those keys are named in that pass's own census — CONVERGED_KEYS in packages/i18n/src/__tests__/ellipsis-glyph-3878.test.ts — and there is now no ASCII ... in any value of any pack (that test gates it repo-wide).

The side effect nobody re-measured: the ASCII group and the U+2026 group merged. The en value Loading… was 8 keys; it is now 10, and the two keys #3880 named are inside it. So the card's fence ("fix the ASCII pair, leave the U+2026 variants alone") no longer partitions anything — the pair is U+2026 variants now.

Measured on main @ 2aff580b5

Every key whose en value is byte-identically Loading…, grouped by flattening all ten packs and comparing exact values:

key	de	ko	ar
lookup.loading	Wird geladen…	로딩 중…	جارٍ التحميل…
common.loading	Wird geladen…	로딩 중…	جاري التحميل…
fields.recipient.loading	Wird geladen…	불러오는 중…	جارٍ التحميل…
grid.import.historyLoading	Wird geladen…	불러오는 중…	جارٍ التحميل…
grid.bulk.loading	Wird geladen…	불러오는 중…	جارٍ التحميل…
detail.loading	Laden…	로딩 중…	جاري التحميل…
report.loading	Laden…	로딩 중…	جارٍ التحميل…
dashboard.loading	Wird geladen…	로딩 중…	جارٍ التحميل…
auth.device.loading	Lade…	로딩 중…	جارٍ التحميل…
approvalsInbox.loadingMore	Lädt…	불러오는 중…	جارٍ التحميل…

Tallies:

• de — four spellings: Wird geladen… ×6 · Laden… ×2 · Lade… ×1 · Lädt… ×1
• ko — two: 로딩 중… ×6 · 불러오는 중… ×4
• ar — two: جارٍ التحميل… ×8 · جاري التحميل… ×2 (a diacritic difference — جارٍ vs جاري — on common.loading and detail.loading, which may be a third, separate class)
• es, fr, pt, ru, ja, zh: unanimous ×10

Why this was not fixed under #3880

Fixing only detail.loading, the key the card named, would leave report.loading — the identical German spelling at an equally same-context site — untouched. That is an arbitrary half-pass over a group the 2026-08-09 adjudication never saw.

And the argument that settles #3880's Done group cleanly does not transfer here. There, all four call sites were the same dialog-footer button and all nine other packs were unanimous, so a 3:1 majority vote was safe. Here six packs are unanimous but three split three different ways, which is much weaker evidence of a typo, and at least one member has a plausible genuine context:

• approvalsInbox.loadingMore — the key name says "loading more" (a continuation load, not an initial one) even though its en value is plain Loading…. de Lädt… and ko 불러오는 중… may be deliberate for that. Whether the en value is the real defect here — an initial-load string reused for a continuation — is worth deciding before touching any translation.
• auth.device.loading — de Lade… (first person) is a distinct register from Wird geladen… (passive) and may be intentional on a device-pairing screen.

That is exactly the trap #3880 exists to record: 58% of shared en strings in this repo are translated differently per key on purpose, so a sweep is the wrong default. This one needs a decision per member, not a majority vote.

Suggested disposition

Triage as one decision covering the whole 10-key group, in this order:

1. Decide whether approvalsInbox.loadingMore's en value should stay Loading… or become its own string (Loading more…). If it changes, it leaves this group and check-i18n-en-drift.mjs will ask the nine packs to follow.
2. Decide whether auth.device.loading's register is intentional.
3. Only then converge the remainder — de, ko and ar — on their majority.

Doing 3 before 1 and 2 bakes in whatever the answer turns out to be.

Related

• [finding] 「同一 en 字符串必须同一译文」不能做成门禁:281 组共享 en 值里 164 组至少有一个包刻意分开译 —— 记下分母,并点出其中两组像是笔误 #3880 — where this was first noticed, as an ASCII two-key pair; its 281/164 shared-string census stays there as documentation and is explicitly not a gate (164 of those groups diverge legitimately).
• [finding] en 包 32 个值用 ASCII "..." 结尾、113 个用 U+2026 "…" —— 同一屏上省略号两种字形,且九包各自跟着抄 #3878 / PR fix(i18n): one ellipsis glyph across the ten packs, es usted single-form, pt de-contraction (#3878 #3875 #3877) #4378 — the glyph convergence that merged the two groups. Glyph only; it never touched wording, so this is not a regression from it.
• PR fix(i18n): the es pack says Listo at all four Done sites (#3880) #5971 — the [finding] 「同一 en 字符串必须同一译文」不能做成门禁:281 组共享 en 值里 164 组至少有一个包刻意分开译 —— 记下分母,并点出其中两组像是笔误 #3880 dispatch, which delivered the es Done half and reported this half's premise as falsified.

[os-zhuang]

Triage (half-annotation repair): titled [finding] but carried only the lane label — finding added so the observation is visible to the first-touch grading queue.

---

Generated by Claude Code

[claude]

Concentrated triage round: finding → pm:queue, Task, domain:ui stands. The #3878 merge made Loading… one 10-key group and left per-language internal inconsistency (de four renderings; ko/ar two each). Fix ruled at grading: converge each language pack to ONE rendering per language across the merged group, chosen by that pack's majority/most-idiomatic form (translation copy consistency, no contract change), and extend the #3878 census test to pin per-language uniformity for this group. Read the full thread at claim (one comment). If a language genuinely wants context-dependent variants, that is a fork — report, do not pick.

---

Generated by Claude Code

[os-sales]

Claim: PM loop round 1
Session: session_01CRJge11jso9TpXRWFt1Z49
Branch: claude/issue-5972-loading-group-per-language-uniformity
Worktree: objectui-issue-5972
Domain: domain:ui
File surface: packages/i18n/src/locales/ + packages/i18n/src/__tests__/ellipsis-glyph-3878.test.ts + a changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — translation copy consistency inside existing keys. No key is added or removed, no schema moves, no published face widens.
Serial constraints cleared: packages/i18n/** — no in-flight claim and no open PR in this lane touches it. Concurrent sibling: #6236 in packages/components/src/renderers/form/ + packages/types (disjoint by full path). Open lane PRs #6587 (plugin-grid), #6589 (plugin-gantt), #6604 (app-shell/studio-design), #6607 (app-shell/metadata-admin) — all disjoint.

⛔ Read the thread before the body: the body's "Suggested disposition" is SUPERSEDED

The card body proposes deciding approvalsInbox.loadingMore's en value and auth.device.loading's register first, and converging only afterwards. Triage ruled otherwise at grading, and that ruling is the one to implement.

Adjudication (not re-litigable)

Triage, concentrated round 2026-08-25, on this card — finding → pm:queue, Task, domain:ui:

Fix ruled at grading: converge each language pack to ONE rendering per language across the merged group, chosen by that pack's majority/most-idiomatic form (translation copy consistency, no contract change), and extend the #3878 census test to pin per-language uniformity for this group. Read the full thread at claim (one comment). If a language genuinely wants context-dependent variants, that is a fork — report, do not pick.

Two things follow, and the second is the one that matters:

1. The unit of work is the whole merged 10-key group, per language — ⛔ not the two keys [finding] 「同一 en 字符串必须同一译文」不能做成门禁:281 组共享 en 值里 164 组至少有一个包刻意分开译 —— 记下分母,并点出其中两组像是笔误 #3880 originally named. A half-pass over the group is the failure this card was filed to prevent.
2. The escape hatch is explicit and you are authorised to use it. The card body argues that approvalsInbox.loadingMore (a continuation load, de Lädt…, ko 불러오는 중…) and auth.device.loading (de Lade…, first person, on a device-pairing screen) may be deliberately different. If your measurement supports that, report the fork — ⛔ do not pick. Reporting it is a good run, not an incomplete one.

PM mechanism assumptions — measure them; your reading beats mine

Measured by the filer on main @ 2aff580b5, and not re-verified by me on today's tree:

1. The group is exactly 10 keys whose en value is byte-identically Loading…. Re-derive it by flattening the packs and comparing exact values — ⛔ do not trust the card's table as the population. The group's membership is the whole basis of the ruling.
2. The tallies (de four renderings, ko two, ar two, six packs unanimous). ⚠️ The ar split is a diacritic difference (جارٍ vs جاري) on two keys — the card itself flags it as possibly a third, separate class. If it is, say so rather than folding it into the majority vote.
3. #3878 converged all packs on U+2026 and there is now no ASCII ... in any pack value, gated repo-wide by ellipsis-glyph-3878.test.ts. That test is your extension point — ⛔ do not weaken its existing assertions while adding the per-language uniformity pin.

⭐ The pin you add must be able to go red: a uniformity assertion that passes because it found nothing is the failure mode here. Assert the group is non-empty and has the expected membership before asserting uniformity over it.

Fence

⛔ This is a copy change inside existing keys. Do not add or remove keys, do not touch en values (changing approvalsInbox.loadingMore's en is the forked outcome, to be reported, not taken), and do not touch the glyph convergence.

---

Generated by Claude Code

[claude]

Claim: os-dev (dispatched, PM loop round 1)
Session: session_01CRJge11jso9TpXRWFt1Z49
Branch: claude/issue-5972-loading-group-per-language-uniformity
Worktree: objectui-issue-5972 (cut from origin/main @ 22ba9271f)

Note on the identity bit: I run as a subagent of the dispatching PM session, so my session ID is byte-identical to the claim above it. The distinguishing identity for this claim is therefore the branch, which is new and pushed empty as of this comment.

Working the grading ruling from the 2026-08-25 concentrated triage comment (per-language uniformity across the whole merged 10-key group), not the body's superseded "Suggested disposition". Re-deriving the group population on today's tree before touching anything.

---

Generated by Claude Code