Repository navigation
Mesnil Garcia de strands the particle under FAMILY_FIRST but folds it under FAMILY_FIRST_GIVEN_LAST #365
Description
Activity
- added a commit that references this issue
on Aug 9, 2026 Cross-reference: #367 proposes that a particle chain is a surname wherever it appears, whatever
name_orderwas declared.This issue is adjacent but distinct —
Mesnil Garcia dehas a trailing particle with nothing to chain onto, so there is no chain to place. #367 would not resolve it. Noting the relationship so neither is fixed in a way that contradicts the other.Revised direction after design review.
This issue proposes adding the middle position as a third site. A review of the underlying rule suggests the opposite resolution.
The rule as restated: a never-given particle cannot be a name, so it attaches to the family name — forward when it leads, backward across a family comma (#379). An ambiguous particle can be a name, so
name_orderdecides and the fork is reported. Which piece is the family name is settled by the comma and byname_order; the particle gets no vote.Under that rule a trailing particle with no comma has nothing to attach to, so it falls where
name_orderputs it — meaning the fix here is to drop theFAMILY_FIRST_GIVEN_LASTfold, not to extend the fold to MIDDLE.There is a second reading worth recording. Family-first order is opt-in, so a trailing particle under it could be treated as an implied family comma. But then the current pin is wrong in a different way: it folds while preserving input order.
Mesnil de FAMILY_FIRST -> family='Mesnil de' (today) family='de Mesnil' (if the fold is right) given='de' (if the fold is wrong)Today's output is neither.
FOLDED_TAGin_types._text_foralready performs exactly that reorder formiddle_as_family, so the middle option is buildable — measured, input tokens['Adams', 'John', 'Quincy']underFAMILY_FIRST+middle_as_familyrenderfamily='Quincy Adams'.Either resolution revises #359's stated decision that "a never-given particle keeps its particle whatever order the caller declared", and retires
test_post_rules.py::test_lone_never_given_particle_in_given_position_folds, whose comment exists specifically to guard against reading the rule as leading-particle-only. That should be explicit in the release log rather than arriving as a side effect.The two
_post_rules.pyparagraphs after the rules list want rewriting with whichever lands — the first has an unclear referent ("both rotations" means rules 2 and 3, which the list never calls rotations), and the second welds rotation guidance to particle-rule history.- added 2 commits that reference this issue
on Aug 16, 2026 Cross-reference: #404 proposes a principle — a particle that has no name word to attach to is not doing particle work, so it is positioned and rendered as ordinary text — that would resolve this issue as a consequence rather than as its own judgement. Worth deciding there before fixing this one field at a time.
- added a commit that references this issue
on Aug 22, 2026 Superseded by #467, which resolves this defect through a different reading than either proposal here.
The short version: this issue and its own revision comment both located the disagreement in P1, where the fix is a choice between two bad outputs. It belongs to P6, and the criterion is the SLOT the trailing particle lands in — only
FAMILY_FIRSTputs it in MIDDLE, where it has no meaning;FAMILY_FIRST_GIVEN_LASTputs it in GIVEN, where the caller's declaration says it is the given name. That protects the Vietnamese listing structurally rather than by a vocabulary carve-out, and needs no re-layout of the leftover.The measurement in this issue's opening — "464 inputs where the two orders differ in field content" — does not measure this shape. That is what permuting the given and middle positions does; it was 247 of 1094 when re-measured on 2026-08-30.
#466 implemented a third reading and was closed unmerged; its review record and measurements are on the branch
fix/365-trailing-particle-attaches.
The two family-first orders disagree about a never-given particle that lands in the middle position:
Under
FAMILY_FIRSTthe particle is stranded as a standalone middle name. UnderFAMILY_FIRST_GIVEN_LASTthe same input folds, because there the particle happens to land in the given position instead. A reviewer measured 464 inputs where the two orders differ in field content this way.Nothing chose this.
post_rulesrule 1b asks at two sites — the piece that opens the name, and a lone particle in the GIVEN role — and never at the middle position. The two orders simply permute which role the trailing particle falls into, and only one of those roles is inspected.Why it matters
The stated intent of #359, recorded in the rule's own comment, is that a never-given particle keeps its particle whatever order the caller declared. The literal invariant survives here (the particle is not reported as the given name) but the intent does not — a word the vocabulary says can never stand alone as a name is reported as a standalone middle name.
The fix, and the decision behind it
Adding the middle position as a third site is a one-clause change. What needs deciding first is whether folding is right for a trailing particle in general —
Mesnil dealready folds under both family-first orders via the GIVEN-role site, so the middle case is arguably just the same shape reached by a different permutation, and consistency argues for covering it.Needs a differential pass: it changes parse output for shipped policies.
Found during the review of #361, which deliberately scoped its prose to the leading piece and the lone given so as not to claim the middle position was covered.