Repository navigation
What should the patronymic rotations do under a non-default name_order? (Иван Петрович Сидоров under ru + FAMILY_FIRST reads family="Иван") #384
Description
Activity
- added a commit that references this issue
on Aug 16, 2026 - added a commit that references this issue
on Sep 8, 2026 Resolved on option 1 — the rotations are GIVEN_FIRST-scoped — and, unlike the option as written, it took a code change (#517).
The decision. The East Slavic and Turkic rotations (rules.md#O1, #O2) exist to restore the given-first reading a family-first listing hides. A caller who declares FAMILY_FIRST has already said it, so under a declared family-first order the rotations stand down and position decides. The divergent row from the issue —
Иван Петрович Сидоровunder the ru pack plus FAMILY_FIRST reading familyИван, givenПетрович— is the declaration being honored on natural-order input the caller said was family-first, and is recorded as an Accepted consequence, not a defect. It is pinned intests/v2/test_locales.py, in prose in the rule, because no example annotation combines a pack with an order (#470 decided prose in the Accepted clause is the right home).Why it was not "no code change". The design review measured that the rotation reads whatever word sits in the family slot regardless of the order assign read. Under FAMILY_FIRST that slot holds the FIRST word, so a patronymic-derived surname fired it: ru + FAMILY_FIRST read
Мицкевич Адам Юзефas familyАдамthrough 2.2.0, where plain FAMILY_FIRST reads familyМицкевич; likewiseoglu Ahmad Vali Aliwith Turkic handling read familyAhmad. The rotations are now gated on the order assign read (state.order, notpolicy.name_order, for the reason the P1 fold gives). No corpus name moves at any baseline — the corpora hold no three-word name whose first word carries an East Slavic ending and no four-word name whose first word is a standalone Turkic marker — and the firing controls are pinned under both family-first orders with the 2.2.0 readings recorded as the negative control, plus a reachability probe so the stand-down rows cannot go vacuous silently. It has a 2.3.0 release-note bullet, since it changes what 2.2.0 does for a supported configuration.Options 2 and 3, declined. Option 2 (order-aware rotations) would recompute what the declaration already carries. Option 3 (stand down with an ambiguity report) would fire on natural-order input inside a family-first source, which the caller cannot distinguish from a mis-declared record; a family-first listing carrying the trace reads the same under both orders, so there is nothing to report there.
Rationale:
decisions.md#O1and#O2, the 2026-09-07 entries, and rules.md's Name order Background for the principle both #471 and this issue now rest on.- added a commit that references this issue
on Sep 22, 2026
Background
The East Slavic and Turkic rotations (
rules.md#O1/#O2) reconstruct token position from assigned roles, which is faithful to v1 only under the default given-first order — a limit recorded since the v2 core landed (decisions.md#O1). The open question of how they should interact with non-defaultname_ordervalues rode #270, which closed 2026-07-28 with the order constants and no recorded answer for the rotations; no successor issue tracked it until this one.Current state (measured, 2.2.0dev)
Сидоров Иван Петровичfamily="Сидоров"(rotation fires)family="Сидоров"(positional; rotation guard sees no ending on Сидоров, stands down) — agreement is coincidenceИван Петрович Сидоровfamily="Сидоров"(natural order, no rotation needed)family="Иван",given="Петрович"— the patronymic becomes the given nameThe divergent row is the sharp end: a caller who declares FAMILY_FIRST and opts into the ru pack gets a confidently wrong reading of natural-order input, with no ambiguity report.
Options
rules.md#O1/#O2statements gain the scope clause; the divergent row becomes an Accepted consequence._effective_orderinstead of assuming given-first roles. Cost: new behavior surface with its own boundary questions (what does "rotate" even mean when the declared order already says family-first?).Open
Whether any real caller combines a patronymic pack with a non-default order — the packs themselves don't set
name_order, so the combination is always deliberate.