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
{{ message }}
Repository navigation
Ph. D. Van Johnson has no surname: a leading suffix displaces the particle like a title used to #371
A leading suffix displaces a particle out of leading position exactly as a title used to before #367, so the chain fires and the name ends with no surname:
Ph. D. Van Johnson given='Van Johnson' family='' suffix='Ph. D.'
That is the same defect #367 was filed for (Sir Van Johnson → given Van Johnson, family ''), reached through a suffix-shaped leading piece rather than a title-shaped one.
The transparency scan steps over a piece that can only be a title. Suffix pieces are deliberately not skipped, and the reason is real but was recorded backwards in that PR (corrected in #370): skipping them moves Van out of the family and into the middle for the shapes whose leading piece assign puts in given:
shipped suffix-skipping variant
Ph.D. Van Johnson given='Ph.D.' family='Van Johnson' given='Ph.D.' middle='Van' family='Johnson'
II van Gogh given='II' family='van Gogh' given='II' middle='van' family='Gogh'
Esq. van Gogh given='Esq.' family='van Gogh' given='van' family='Gogh'
So a blanket "skip suffixes too" trades one defect for another. Ph. D. Van Johnson gains a family name; III van Gogh and Esq. van Gogh get worse.
The distinction that matters is what assign does with the leading piece: Jr. Van Johnson is already correct because jr is in TITLES and the piece is a title. The broken shapes are the ones where the leading piece is suffix-shaped but lands in given.
Measured scope
The suffix-skipping variant is a no-op over all 751 differential corpus names and passes the full suite, so there is no baseline evidence either way — the decision rests entirely on which of the shapes above matters more.
Suggested framing
Rather than skipping suffix pieces wholesale, the question is whether a leading piece that assign will not treat as a name should participate in the leading-particle exception at all. That is a narrower rule than either alternative and would need its own measurement.
Pinned by tests/v2/pipeline/test_group.py::test_a_suffix_shaped_leading_piece_is_not_stepped_over as of #370, so a change here announces itself rather than passing silently — before that test, the mutation flipped this decision with a green suite.
Suffixes never begin a name. Position trumps matching. None of the examples are supported name shapes, nor reasonable ways to express a real person's name. I think "Ph. D. Van Johnson" should parse as given="Ph." middle="D." family="Van Johnson", and the shipped examples of the other 3 examples are acceptable, except for "Esq. van Gogh".
"Esq." ends in a period at the beginning of a name, which should qualify it to be treated as a title, leaving "Esq. van Gogh" -> title="Esq.", given="van", family="Gogh", while "Esq van Gogh" -> given="Esq", family="van Gogh".
We could consider including an ambiguity since we can recognize that "Ph. D." and "II" might be a misplaced suffix.
Potentially we could also add a rule or decision to clarify that we should deprioritize changes for unsupported name shapes, and always identify when names are unsupported name shapes so that we know we can change how they parse without breaking the supported name shapes, and only consider them if they fall out naturally or easily from support for the 3 supported name shapes based on the other rules.
Activity
derek73 commentedon Aug 29, 2026
Suffixes never begin a name. Position trumps matching. None of the examples are supported name shapes, nor reasonable ways to express a real person's name. I think "Ph. D. Van Johnson" should parse as given="Ph." middle="D." family="Van Johnson", and the shipped examples of the other 3 examples are acceptable, except for "Esq. van Gogh".
"Esq." ends in a period at the beginning of a name, which should qualify it to be treated as a title, leaving "Esq. van Gogh" -> title="Esq.", given="van", family="Gogh", while "Esq van Gogh" -> given="Esq", family="van Gogh".
We could consider including an ambiguity since we can recognize that "Ph. D." and "II" might be a misplaced suffix.
Potentially we could also add a rule or decision to clarify that we should deprioritize changes for unsupported name shapes, and always identify when names are unsupported name shapes so that we know we can change how they parse without breaking the supported name shapes, and only consider them if they fall out naturally or easily from support for the 3 supported name shapes based on the other rules.
fix(group,docs): the four-agent review findings on #371, measured
Merge pull request #474 from derek73/fix/371-suffix-never-begins-a-name
fix(group): a suffix never begins a name (derek73#371)