Skip to content

Ph. D. Van Johnson has no surname: a leading suffix displaces the particle like a title used to #371

Description

@derek73

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.

Why #367 fixed only the title half

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.

Split out of #367 so that PR stays one mechanism.

Activity

  1. self-assigned this
    on Aug 10, 2026
  2. added this to the v2.2 milestone on Aug 22, 2026
  3. derek73 commented on Aug 29, 2026

    @derek73
    OwnerAuthor

    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.

  4. added 2 commits that reference this issue on Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions