The two family-first orders disagree about a never-given particle that lands in the middle position:
Mesnil Garcia de FAMILY_FIRST family='Mesnil' given='Garcia' middle='de'
Mesnil Garcia de FAMILY_FIRST_GIVEN_LAST family='Mesnil Garcia de'
Under FAMILY_FIRST the particle is stranded as a standalone middle name. Under FAMILY_FIRST_GIVEN_LAST the 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_rules rule 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 de already 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.
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.