Skip to content

What should the patronymic rotations do under a non-default name_order? (Иван Петрович Сидоров under ru + FAMILY_FIRST reads family="Иван") #384

Description

@derek73

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-default name_order values 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)

input ru pack (default order) ru pack + FAMILY_FIRST
Сидоров Иван Петрович 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 name

The 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

  1. Declare the rotations GIVEN_FIRST-scoped by design — a resolution note, no code change: the rotations exist to restore the default reading from a family-first listing, so combining them with a declared family-first order is redundant at best. rules.md#O1/#O2 statements gain the scope clause; the divergent row becomes an Accepted consequence.
  2. Make the rotations order-aware — the guard reads positions through _effective_order instead 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?).
  3. Stand the rotations down under any non-default order, with an ambiguity report — conservative; the caller who declared an order gets the declaration, and the conflict is at least visible.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions