`ar` writes the participle جارٍ/جاري two ways pack-wide (92:8) — 8 values outside the #5972 group are ungated

[claude]

Found while implementing #5972 (per-language uniformity for the merged Loading… group). Filed unassigned, out of that card's scope: #5972 is fenced to the ten keys whose en value is byte-identically Loading…, and only 2 of these occurrences were inside that fence. #5972 is not addressed by this card and remains open on its own.

What was measured

packages/i18n/src/locales/ar.ts writes the standalone منقوص active participle two ways:

• جارٍ — final yāʾ dropped, tanwīn (U+064D) on the rāʾ. The prescriptive MSA indefinite form.
• جاري — the yāʾ retained (U+064A). The definite/annexed form, widely used informally.

They are one word, two spellings, differing by a single code point at the end of the first word — not two translations. Counted with a Unicode-aware standalone-word match (positive and negative controls run, including the التجارية substring trap that an ASCII-boundary regex falls into):

spelling	occurrences in ar.ts
جارٍ (U+064D)	92
جاري (U+064A)	8

After PR for #5972 converged the two in-group keys (common.loading, detail.loading), the remaining 8 are all outside that group, so nothing gates them:

key	ar value	en value
grid.loading	جاري تحميل الشبكة…	Loading grid…
grid.refreshing	جاري التحديث…	Refreshing…
chart.loading	جاري تحميل الرسم البياني…	Loading chart…
console.initializing	جاري تهيئة التطبيق…	Initializing application…
console.loadingSteps.connecting	جاري الاتصال بمصدر البيانات	Connecting to data source
console.loadingSteps.loadingConfig	جاري تحميل الإعدادات	Loading configuration
console.loadingSteps.preparingWorkspace	جاري تجهيز مساحة العمل	Preparing workspace
console.actions.retrying	جاري إعادة المحاولة…	Retrying…

Why this is same-screen visible

console.loadingSteps.* are the three boot steps rendered as a list, and console.initializing is the heading above them — four values, all جاري. But chart.loading and grid.loading render inside a console that has already used جارٍ for dashboard.loading, list.loading, detail.loadingAttachments and console.ai.*. So the two spellings of the same word appear in one session, and on the dashboard in one viewport.

Why no gate sees it

Same blind spots #3878 documented: all-locales-key-parity compares key sets and placeholder shapes, check-i18n-call-site-keys.mjs only asks whether a key resolves, and check-i18n-en-drift.mjs fires on an en value change — the en side of all eight is untouched and always has been. Value-level orthography in a non-Latin pack is invisible to all three.

Suggested shape, if this is taken

Normalise the 8 to جارٍ (92:8 majority, and the prescriptively correct indefinite form), then widen the #5972 pin from "one rendering per language across one group" to "one spelling of this participle across the ar pack" — the same move de-quote-pairing-3876.test.ts made when its per-key list became a pack-wide rule.

⚠️ Worth an Arabic reader's confirmation before acting. The judgement that جارٍ is correct here rests on the participle being indefinite; a phrase where it is annexed would legitimately keep the yāʾ, and none of the 8 above looks annexed, but that is a reading, not a measurement.

---

Generated by Claude Code

[huangyiirene]

Triage: lands in packages/i18n/src/locales/ar.ts plus packages/i18n/src/__tests__/ellipsis-glyph-3878.test.ts ⇒ domain:ui. Type Bug: one word, two spellings, and the card establishes same-session and same-viewport visibility — console.initializing + the three console.loadingSteps.* render جاري as a heading-plus-list, while the dashboard around them has already used جارٍ for dashboard.loading, list.loading, detail.loadingAttachments and console.ai.*. That is a user-visible defect, not a tidy-up.

The measurement is credited as done properly: a Unicode-aware standalone-word match with positive and negative controls run, including the التجارية substring trap an ASCII-boundary regex falls into. That is the reverse-check discipline, and it is why the 92:8 count is usable as a premise rather than a claim.

⛔ Stale premise, corrected (same line as #6611): the card says "#5972 … remains open on its own." #5972 closed at 2026-08-27T13:54:21Z, ~27 minutes after filing. So "After PR for #5972 converged the two in-group keys" is now a landed fact rather than a pending one — read the pin from the tree, ⛔ not from this card's description of it.

pm:queue. The convergence direction does not actually depend on settling the prescriptive question, which is what keeps this out of the decision inbox: whichever spelling is "right", one word rendered two ways in one viewport is the defect, and جارٍ is both the 92-occurrence majority and what #5972's converged in-group keys already landed on — so it is simultaneously the minimum-diff target and the pack's de-facto standard.

⇒ The one premise that is a reading rather than a measurement, carried as the dev's first check: none of the 8 listed values sits in an annexed (definite / construct) position. The card is explicitly honest that this is a reading — an annexed phrase would legitimately keep the yāʾ. ⛔ Do not blanket-normalise on the 92:8 count alone. If any of the 8 is annexed, that value is excluded with a named exemption row and a stated reason, not converged — and the card reports which. Getting this wrong replaces an orthographic inconsistency with an actual grammatical error, which is strictly worse.

⚠️ On "worth an Arabic reader's confirmation": that is not an escalation to the maintainer — it does not turn on product semantics or contract shape, and parking it in the inbox would buy nothing, since the inbox is not an Arabic desk either. It is a competence requirement on the implementer. The dispatching seat should say so in the dispatch order and require the annexation check to be shown per value, ⛔ not asserted in aggregate.

Follow-through worth keeping in scope: widen the pin from "one rendering per language across one group" to "one spelling of this participle across the ar pack", mirroring the move de-quote-pairing-3876.test.ts already made when its per-key list became a pack-wide rule. Without that, the same 8 can drift straight back — and the card documents exactly why nothing would notice: all-locales-key-parity compares key sets and placeholder shapes, check-i18n-call-site-keys.mjs only asks whether a key resolves, and check-i18n-en-drift.mjs fires on an en change, while all 8 have an untouched en. Value-level orthography in a non-Latin pack is invisible to all three. That gate blind spot is the durable half of this card.

⚠️ Serial constraint — shared hot file with #6611, which lands in the same package and the same pin file. The five fold gates and the exclusion list (⛔ #5972 is closed and is not a family member) are written out on #6611; this seat reads them as passing, and the fold-or-serial call belongs to the objectui seat.

---

Generated by Claude Code

[os-sales]

Claim: PM loop round R2 (2026-08-28), concurrency raised to 5 by maintainer instruction
Session: 8ca04858-ea8e-5b85-9182-de59aa49e00c
Branch: claude/issue-6610-ar-participle-consistency
Worktree: objectui-issue-6610
Domain: domain:ui
File surface: packages/i18n/src/locales/ar.ts plus whatever pin the fix needs, and a changeset if the gate says one is owed. ⛔ Stop on breach and report.
Container and model: S, mode:subagent, model: opus
Clause-2: no — translation values, no contract surface.

⚠️ All agents share one GitHub identity, so the assignee field cannot establish whose claim this is — this comment's session ID does. If you find an earlier Claim: from a different session that is not spent, stop and report.

⛔ The part that is not mechanical

The card measures a 92:8 split for the participle. ⛔ A 92:8 majority is not automatically the correct spelling — it is a distribution, and this seat cannot rule Arabic orthography from a count. Two possibilities and they need separating before anything is rewritten:

1. the 8 are errors and should join the 92; or
2. the 8 are correct in their own grammatical context (the participle's ending is not invariant across syntactic positions) and the 92 are what needs looking at.

⇒ Establish which, with evidence, before editing. If the answer is not determinable from the strings and their contexts, that is a needs-user-decision shape and you stop and report it rather than picking the majority.

⚠️ The card says the 8 values sit outside the #5972 group, i.e. outside whatever gate that card established. Read #5972 first: whether these 8 should be pulled into that gate is likely the more durable fix than editing them once.

⛔ Fences

packages/i18n is free — PR #6662 (the 25-key retirement) merged at 12:05Z. ⚠️ Cut from a fresh origin/main: that PR deleted keys from all ten packs including ar.ts, so any line number written before 12:05Z is stale.

⛔ Do not touch the other nine packs unless the parity gate forces it, and if it does, say so.

Held elsewhere this batch: packages/app-shell (#6535, #6559), packages/plugin-grid (PR #6670), packages/types + renderers/complex/data-table.tsx (PR #6673), packages/sdui-parser + packages/plugin-list (#6598).

Measurement

Report per value, not as a total — a total of 8 is satisfied by one string appearing 8 times. Every zero needs a positive control in the same query shape; git ls-tree any path before accepting its zero.

---

Generated by Claude Code

[claude]

os-dev-report

{
 "issue": 6610,
 "status": "done",
 "branch": "claude/issue-6610-ar-participle-consistency",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6675",
 "premise_still_valid": true,
 "summary": "DIRECTION IS DETERMINABLE, AND IT IS NOT THE MAJORITY ARGUMENT. Re-measured the census from source on origin/main @ f55d6661 with a Unicode-aware tokenizer (skeleton = token minus marks/tatweel): جارٍ 92, جاري 8 as 8 DISTINCT values, one occurrence each - so the total is not one string counted eight times. Negative control: a naive substring count of the four letters جاري returns 15 values, the 7 extras being التجارية/التجاري, جاريًا, جارياً and الجارية - the exact trap. Positive control: the same counter classifies the four #5972-landed values (common/detail/lookup/dashboard.loading) as جارٍ. POSSIBILITY 2 (the 8 are contextually correct) WAS FALSIFIED, NOT OUT-VOTED, on four measurements. (1) The pack already distinguishes syntactic position CORRECTLY: three values keep the yaa and all three require it - console.ai.connectionStalled جاريًا and empty.appNotAvailableDescription جارياً are the khabar of لا يزال / ما زال, hence accusative, and marketplace.installedAdditiveNote الجارية is attributive on a definite noun. A yaa-blind pack could not have got these right, so جارٍ elsewhere is position-sensitive rather than a house tic. (2) None of the 8 is in such a position: every one is the participle OPENING its string (token index 0, so nothing governs it into the accusative), none carries ال, and in none is the participle the mudaf - the masdar after it is the delayed subject of a fronted indefinite predicate. (3) THE DECIDER - both syntactic frames occur on BOTH sides of the split, five of the eight with a word-for-word twin: grid.refreshing 'جاري التحديث…' against list.refreshing 'جارٍ التحديث…' is an exact minimal pair, identical apart from that one code point, and two spellings of one phrase cannot both be contextually correct. (4) Zero of the 92 follow an accusative governor, and that zero is a measurement because the SAME detector flagged all three yaa-keeping values in (1). So the 8 were the errors; converged to جارٍ, pack now 100:0. THE GATE QUESTION, ANSWERED BY MEASUREMENT: the 8 should NOT be pulled into #5972's group, and the reason is structural rather than stylistic. That gate DERIVES its population from en (value === 'Loading…') and asserts the derived set is exactly its ten named keys; none of the 8 has that en value (Loading grid…, Refreshing…, Loading chart…, Initializing application…, Connecting to data source, Loading configuration, Preparing workspace, Retrying…), so adding them would break the derivation check that is that gate's own anti-vacuity guard - widening #5972 requires WEAKENING it. Instead took the move de-quote-pairing-3876.test.ts already made and that the #3878 file names as its own precedent: a per-key list becomes a PACK-WIDE invariant. New ar-participle-orthography-6610.test.ts holds no standalone جاري, no جارى (alef maqsura), no bare جار with the tanwin dropped, anywhere in ar - so a ninth value fails BY KEY NAME with nobody editing the file, which is the durable half the eight-value edit alone would not have bought. It also pins the three legitimate yaa occurrences WITH their grammar, which is the more important half: it is what notices a later normalise-the-pack sweep flattening a correct distinction into a real grammatical error. ellipsis-glyph-3878.test.ts changes only in its ar note (its present-tense 'the other 8 are filed separately' is now false); NO assertion in it is touched, weakened or added to. EXAMINED AND DELIBERATELY NOT FOLDED IN, both recorded in the PR body and the pin header rather than dropped: (a) GENDER AGREEMENT - nine values put the masculine participle before a feminine masdar (إعادة, إضافة, تهيئة, الموافقة, المعالجة) where strict agreement wants جارية; the impersonal frozen جارٍ is standard MSA UI register and, load-bearing, the pack applied it UNIFORMLY on both sides of this split (7 of the 92, 2 of the 8), so it was never a distinguishing factor here and is not a same-screen inconsistency - ruling it needs the Arabic desk this seat is not, so it is named as explicitly outside the file's green rather than swept. (b) chart.loading HAS NO CONSUMER (grepped the dotted key, the strings.x object-access form that hides console.* from key greps, and dynamic t() template construction) - but it is ALREADY a standing needs-review row in check:i18n-dead-keys, whose report says every hit wants a sampled human check before deletion per objectui#4658, so filing a card would duplicate a tracked line; noted next to its pin row with what to delete if it is ever retired. CLAIM CHECK: only two comments on the card - the 2026-08-27 triage and the PM's 2026-08-28 claim carrying this session id. No earlier unspent claim from another session.",
 "tests": "All on the final commit 161494d4 with a clean tree (git status empty), through scripts/pm/os-verify-lock.sh; the union re-ran AFTER the last commit. Union verdict, which certifies the whole && chain: 'VERDICT command-exit 0 - held the lock 62s (1m02s) - waited 268s (4m28s)'. Exit codes captured by redirect-then-capture, never after a pipe; every gate below is quoted from ITS OWN printed verdict line, not from $?. (1) pnpm exec vitest run --maxWorkers=2 packages/i18n/ -> 'Test Files 58 passed (58)' / 'Tests 927 passed (927)'; 58 equals the 58 test files on disk under packages/i18n, so the new file is in the run. NOTE: the first attempt used pnpm --filter @object-ui/i18n exec vitest and was REFUSED by this repo's guard (objectui#3378 - a package-dir vitest root silently runs @object-ui/console's 22 files and reports them as green); re-run from the repo root as the guard instructs. (2) pnpm --filter @object-ui/i18n run type-check (tsc --noEmit && tsc -p tsconfig.test.json), clean - green only after pnpm --workspace-concurrency=2 --filter '@object-ui/i18n^...' build. NOT-MEASURED CHECK CLEARED: tsc -p tsconfig.test.json --listFiles lists locales/ar.ts, ar-participle-orthography-6610.test.ts AND ellipsis-glyph-3878.test.ts in the program (lines 111/115/419 of 642), so the typecheck really covers the new file. (3) GATES, each with its own line: check:control-bytes 'OK (scanned 5519 tracked text file(s); skipped 85 binary)'; check:i18n-keys 'Every in-scope call-site key resolves against the en pack (2831 keys)...'; check:i18n-drift 'No en value changed in this range.'; check-changeset-presence '3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major 'No changeset declares a major bump.'; check-changeset-fixed 'All workspace packages are in the changeset fixed group.'; check-changeset-overwrite 'No pre-existing changeset was modified or deleted.'; check-lint-coverage 'lint coverage: 46/46 packages linted, 0 with outstanding errors (0 total).'; check-vi-mock-specifiers 'OK (3890 tracked source file(s), 2187 test-named...)'; check-shell-escape-residue 'OK (4/4 root(s) resolved... 0 occurrence(s) outside a fence)'. check:i18n-dead-keys ran but self-declares 'This is a REPORT, not a gate', so it is NOT counted as a gate result. Gate family derived from .github/workflows/ by hand: objectui has no scripts/pm/dispatch-gates.mjs, and that script lives only in objectstack and answers only about its own tree, so pointing it here would have returned objectstack's families with exit 0 and been silently wrong. (4) CONTROL-BYTE HAND SCAN on top of the gate, since the diff is a file full of non-ASCII: grep -naP '[backslash-x00-backslash-x08...]' over all four changed files returned exit 1 (no match). (5) LINT IS A DECLARED NARROWING with all three pieces of evidence: eslint . inside packages/i18n, the only package touched; population read from ESLINT'S OWN SELECTION via --format json = 84 files, 0 errors, 34 pre-existing warnings, all three edited/new source files present at 0/0; invariance = eslint.config.js configures NO type-aware linting (grepped parserOptions/projectService/project: - zero rows), so a change confined to packages/i18n cannot move the verdict on any file it does not itself contain. The repo-wide farm is CI's run. (6) ABLATION - 3 legs, each PREDICTED BEFORE IT RAN, from the COMMITTED tree, with trap restore EXIT INT TERM on absolute paths resolved from git rev-parse --show-toplevel. NO REBUILD NEEDED AND NONE COULD HAVE MASKED A RESULT: the pin imports '../locales/index', a RELATIVE SOURCE import rather than the package exports field, and packages/i18n has no vitest.config.* of its own, so nothing resolves through dist/ - Leg A proves this empirically by mutating only ar.ts with no build and going red. EACH MUTATION PROVEN ON DISK by counting the injected text AND the removed text at the anchor, NOT by a bare git diff --stat: the fix is an equal-length substitution (U+064A and U+064D are both two UTF-8 bytes), so the file's byte count never moved and a size check would have proven nothing. Each restore proven by an empty git diff HEAD; tree verified clean at the end. Leg A, revert console.loadingSteps.connecting to the yaa spelling - predicted red naming the key, observed RED with the offender assertion firing '1 value(s) still use a retired spelling' plus 'ar console.loadingSteps.connecting moved'. Leg B, normalise console.ai.connectionStalled (جاريًا, where the yaa is REQUIRED) to جارٍ - predicted red on the yaa-is-correct pin ONLY with the pack-wide rule staying GREEN, because جارٍ is not an offending form and the sweep structurally cannot see this defect; observed exactly that, '1 failed | 3 passed'. That asymmetry is the protective pin's whole reason and is now demonstrated rather than asserted. Leg C, break the matcher itself (skeleton made a no-op) - predicted red in the CONTROLS block first, observed RED there ('expected جارٍ to be جار') ahead of the pack-wide rule, so a matcher that stops matching fails its own controls instead of reporting a clean pack. ONE UNPREDICTED DIAGNOSTIC, REPORTED NOT SMOOTHED: on the first Leg A the non-vacuity floor was toBeGreaterThanOrEqual(100) - today's exact count - so reverting one value tripped it at 99 and the reader saw 'no جارٍ found at all' instead of the offender list that names the key. An exact-today floor is a ratchet pretending to be a proof of life; commit 8636f62a slackens it to 80 with the reasoning recorded in the file, and Leg A was RE-RUN and now fails on the offender assertion as it should. (7) PR BODY SANITIZER SELF-CHECK, MEASURED NOT ASSERTED: read the stored body back in full and diffed it against what was sent - identical except for the trailing newline GitHub strips (16352 chars sent, 16351 stored, line-level diff empty). It contains ZERO left-angle-bracket characters, so there was nothing for the sanitizer to eat, and all 6 headings, 41 table rows and the session-URL footer are present.",
 "mcp_calls": "2 - issue_read get and get_comments on #6610. Repo-scoped REST was probed first and worked (HTTP 200, and an authenticated /user probe also 200), so #5972 plus its comments, the open-PR serial check, the PR creation and the body read-back all went through REST; gh is absent from this container. No search_issues call was needed because nothing was filed.",
 "open_questions": [],
 "out_of_scope_findings": [
 "NOT FILED (deliberate, reason given): chart.loading has no consumer - grepped the dotted key, the strings.x object-access form that hides console.* from key greps, and dynamic t() template construction. It is ALREADY a standing needs-review row in check:i18n-dead-keys, whose report states every hit wants a sampled human check before deletion per objectui#4658, so a card would duplicate a tracked line. Recorded next to its pin row in ar-participle-orthography-6610.test.ts with what to delete if it is ever retired.",
 "NOT FILED (deliberate, reason given): ar gender agreement - nine values put the masculine participle before a feminine masdar where strict agreement wants جارية. The impersonal frozen جارٍ is standard MSA UI register, and the pack applied it UNIFORMLY on both sides of this split (7 of the 92, 2 of the 8), so it is not a same-screen inconsistency and was never a distinguishing factor for this card. Ruling it needs an Arabic reader, which filing would not summon; recorded in the pin header as explicitly outside that file's green. PM: say the word and it is a one-line file."
 ]
}

---

Generated by Claude Code