Skip to content

Should John Smith XYZ read XYZ as a credential when no wordlist has those letters? #516

Description

@derek73

parse("John Smith XYZ") reads middle Smith, family XYZ today, and so does parse("John Smith X.Y.Z."). Every post-nominal this library recognizes, it recognizes from a wordlist, so an unlisted credential is a family name — which is fine until the wordlist is wrong in the other direction, and #342 has just made it wrong for two words on purpose. Removing rai and cha in 2.3 cost John Smith RAI its credential reading, the accepted price of Aishwarya Rai keeping her surname. This issue asks whether shape and position could pay it back.

Two shapes, both position-scoped. (1) An ALL-CAPS acronym standing in the suffix position of a MIXED-CASE name: John Smith XYZ, John Smith, XYZ. The case contrast is the signal, so an all-caps name gives none — JOHN SMITH XYZ must keep reading family XYZ, and that carve-out is half the design. (2) A DOTTED acronym in that position regardless of case: John Smith X.Y.Z. and john smith x.y.z. should both read suffix x.y.z., because the periods carry the signal. Measured 2026-09-07, none of the four reads as a suffix today.

The dotted half is already half-implemented by accident, which is the strongest evidence here. The interior-period split (rules.md#S3) reads a trailing dotted token chunk by chunk, and a last chunk that is a Roman numeral (i, v, x) is suffix vocabulary, so John Smith X.Y.I. and John Smith R.A.V. DO read suffix while John Smith R.A.X. does not. Same shape, same position, different answer, decided by whether the last letter happens to be I, V or X. Nothing is pinned on that and it is not a feature.

Relation to #490, which proposed recognizing a credential by shape where it collides with existing vocabulary. This is #490's idea WITHOUT the collision part: the collision cases are the ones a wordlist already handles, and the gap is the letters no wordlist has. Recorded as a parking-lot bullet in decisions.md#suffix-acronym-collisions.

Relation to #383, which asks whether Jose E Maria Santos should join like Jose e Maria Santos does. That is the same signal read at a different position: a single letter is a conjunction only when the input is mixed case and the letter's case says so. Whatever criterion this issue settles on for "the input is mixed case and the word in question is upper case" is probably the criterion #383 wants too, and the two should share it rather than each growing one.

What needs deciding.

  • Whether an unlisted all-caps trailing token is a credential often enough to be worth the surnames it would eat (Vietnamese and Korean data is frequently upper-cased in whole records, which the mixed-case requirement is meant to exclude — is that enough?).
  • Whether the dotted form should be decided independently of the all-caps one, since the periods argue much harder.
  • Whether the roman-numeral fork should be unified with whatever lands or left alone as generational.
  • Whether either shape reports a suffix-or-name ambiguity.
  • Whether there should be a way to turn the new behavior off, and/or to force it to apply to all-caps or all-lower-case input, the way capitalized(force=True) overrides the mixed-case default for capitalization — and whether Should Jose E Maria Santos join like Jose e Maria Santos does? (the single-letter connective's Latin-capital veto was never adjudicated) #383's case-sensitive behavior should ride the same switch or a similar one.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions