Repository navigation
de Mesnil Jean reads Jean as part of the surname: the leading-particle fold takes the rest of the name #471
Description
Activity
- changed the title
[-]`de Mesnil Juan` reads `Juan` as part of the surname: the leading-particle fold takes the rest of the name[/-][+]`de Mesnil Jean` reads `Jean` as part of the surname: the leading-particle fold takes the rest of the name[/+]on Sep 1, 2026 - added a commit that references this issue
on Sep 8, 2026 - added a commit that references this issue
on Sep 8, 2026 Closing as by design (#517). The greedy reach under the default order stays, and the reason is now written down as a principle rather than a limit.
A
name_orderis a property of the data source, not of a string. A caller sets it to match how their records are written, and a declared family-first order outranks anything the parser could infer from the shape of one name (rules.md's Name order Background; it yields only to a vocabulary claim, O4, or a name's own script, W4). Under the default given-first order a string that opens with a never-given particle is a surname whose given name is simply absent, and surnames may be several words — Spanish double surnames above all — so the fold takes the rest of the name.de la Torre Vegais a surname-only string read right: familyde la Torre Vega.de la Cruz Juan Carlosis a family-first listing read under the wrong order, and the remedy is the declaration or the comma.Policy(name_order=FAMILY_FIRST)already gives familyde la Cruz, givenJuan, middleCarlos(#395), and the family comma fixes the surname whatever order is declared:de la Torre Vega, Juanreads familyde la Torre Vega, givenJuanunder both orders.de la Family Family Givenandde la Family Given Givenare undecidable under either order, which is what makes the comma the answer rather than a better heuristic.This supersedes only the REASON the 2026-08-17 P1 entry gave for the same outcome ("the parser cannot see language; write the comma"). That was right and weaker: the order is not a language judgement at all, it is a declaration about the data. The outcome, and the rest of that entry, stand. The #364 sentence "nothing ever argued for 'takes everything'" is answered in place.
rules.md#P1 carries the Accepted clause with both faces as executable examples;
de la Torre Vegajoined the contract corpus and, at the 1.4.0 baseline only, the already-recorded initials-view class, so that gate's count is 368 with the claim recorded. Nothing in the parser, the tests' expectations, or the ledgers moved.The one follow-up this leaves open is whether an undecidable particle-first shape should report an ambiguity; that is an
AmbiguityKindquestion and belongs with #449/#491/#348 if anywhere. Rationale:decisions.md#P1, the 2026-09-07 entry.- added a commit that references this issue
on Sep 8, 2026 - added a commit that references this issue
on Oct 8, 2026
Under the default (given-first) order, a name opening with a never-given particle has its ENTIRE remainder read as the surname:
Jeanis not part of that surname. The fold is reaching past the thing it is entitled to.The criterion
The fold takes the particle's own unit and ONE name word. Whether the name is surname-only is then decided by what is left over:
de la Vega,Mc Donald,dos Santos,De Groot,Ste Marie,de los Santos)The mechanism already exists: the family-first branch of
rules.md#P1has narrowed exactly this way since #395. Only the default order kept the wider reach, and nothing recorded a reason.Measured
10 parses, 5 names, default order only, over the 1094-name corpus × 3
name_ordervalues ×middle_as_familyoff and on. Every surname-only name is untouched; the conjunction join (de la Vega y Santos Juan) and the bound-given pair (ibn Awf abdul Rahman) stay whole.This is a v1 parity break, and that is why it is its own issue
Unlike the family-first work in #467 — where v1 has no
name_orderand so no answer to compare against — this changes the order every existing caller is on, and 1.4.0 has a definite answer that we currently match:Prototyped, the differential gate goes red at the 1.4.0 baseline with 5 unexplained diffs (the five names above), and
tests/test_particles.py::LastNamePrefixSplitTestCase::test_leading_non_first_name_prefix_with_middle_name_as_lastfails outright. Landing it needs ledger rules at all three baselines, the v1 test repointed, and a release note saying default-order behaviour changed — none of which should be bundled into a family-first fix.Scope note
The leftover must be laid out as the positions the declared order gives it, with the family slot already filled. The current code uses
_name_positions(order, len(rest) + 1)[1:], which is correct only where the family comes first; under the default order the family is last, so the slice takes the wrong roles.