Repository navigation
Should de Mesnil Juan be all surname, or family de Mesnil plus given Juan? #364
Description
Activity
- added a commit that references this issue
on Aug 9, 2026 Superseded in substance by #367, which states the general principle this is a consequence of: a particle chain is a surname wherever it appears, whatever
name_orderwas declared.If that principle holds, the chain in
de Mesnil Juanisde Mesniland it is the surname, sogiven='Juan'— the "stop at the first piece" reading this issue asks about. Deciding #367 decides this; deciding this in isolation would settle only one shape of the same question.Keeping it open as the concrete case, but #367 is where the decision belongs.
Correcting my earlier comment on this issue: this is not a consequence of #367, and I was wrong to say so.
de Mesnil Juangroups as[de][Mesnil][Juan]— three separate pieces, no chain. A leading particle deliberately never chains (_groupskips index 0 unconditionally, which is what keepsVan Johnsonparsing), so what pulls those pieces together is the fold inpost_rulesrule 1b, not a particle chain.#367 and its sibling are about a chain that exists and is placed in the wrong field. This issue is about how far the fold reaches when no chain is possible. Independent mechanisms, independent decisions — this one does not need #367 settled first.
- added a commit that references this issue
on Aug 16, 2026 Measured while deciding this in #386 — the blast radius here is one corpus name, not the ledger-wide re-examination this issue warns about.
Filtering the three differential corpora (782 names) to the shape that actually changes — no comma (so C1 takes it first otherwise), leading never-given particle, 3+ words:
de Mesnil Garcia family='de Mesnil Garcia' → family='de Mesnil', given='Garcia' de la Vega unchanged (one group, nothing after it) de Mesnil Jr. unchanged (Jr. is a suffix, so two name words)Most leading-particle corpus entries are comma forms (
de la Vega, Dr. Juan …) where the pre-comma text is the family by declaration, so the fold never runs. The "each ledger would need re-examining" warning was written without that filter.Decided in #386 as the alternative reading, both orders: the fold takes the particle and the one name word it attaches to.
- added a commit that references this issue
on Aug 18, 2026 - added a commit that references this issue
on Aug 22, 2026 - added a commit that references this issue
on Aug 22, 2026 - added a commit that references this issue
on Sep 8, 2026
A leading never-given particle makes the whole name a surname, however many pieces follow:
That is long-standing v1 behaviour in the default order (
handle_non_first_name_prefix), and #361 extends it to the family-first orders so all three agree.The question is whether the fold should take the whole name or stop after the piece the particle attaches to:
The alternative reads more naturally under
name_order=FAMILY_FIRST— the caller has declared that the family comes first, so the particle plus its following piece is the family and the remainder is the given name. It is harder to justify in the default given-first order, where "a leading particle means there is no given name" is the rule the fold exists to express.Why this is a new rule, not a fix
Stopping at the first piece exists in no order today. Implementing it means choosing one of:
name_order").tools/differentialprotects; the 751-name corpus is currently byte-identical at the 1.4.0, 2.0.0 and 2.1.0 baselines, and each ledger would need re-examining.Either way it wants its own differential story rather than riding on a fix.
Scope note
de Mesnil(two pieces) is unaffected —family='de Mesnil'under every reading. Only three-or-more-piece names differ, andde Mesnil Garciais one of the seven corpus names #361 already moves under the family-first orders.Split out of #361 so that PR stays a fix to the broken order-dependence rather than a redefinition of the fold.