You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A leading never-given particle makes the whole name a surname, however many pieces follow:
de Mesnil Juan family='de Mesnil Juan' given=''
de Mesnil Garcia family='de Mesnil Garcia' given=''
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:
today alternative
de Mesnil Juan family='de Mesnil Juan' family='de Mesnil', given='Juan'
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:
Both orders — the default order changes too. That breaks the v1 parity tools/differential protects; 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, and de Mesnil Garcia is 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.
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.