Repository navigation
[Vulcan] Preserve surname particles after given-name initials - #23
Merged
iliaal merged 1 commit intoOct 21, 2026
Merged
Conversation
iliaal
deleted the
vulcan/nameparser-initial-surname-particles-20261016
branch
October 21, 2026 21:22
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix surname-particle binding when the given name has already been mapped to initials.
J. van Goghnow produces first nameJ., surnamevan Gogh, and prefixvan; previously it promotedvanto the first name and leftJ.as a middle initial.The default pipeline runs
InitialMapperbeforeLastnameMapper. The old particle gate only counted earlier raw tokens, overlooking a mapped initial.GivenNamePartas additional evidence that a recognized particle belongs to the surname. Keep the existing protected raw-token hook and the adjacent-particle/surname-only rules.Validation
On PHP 8.4.26:
LastnameMapper.phpwith its base version makes 17 of the 30 new cases fail. Restoring the fix passes all 30 cases and 193 assertions, with both test files unchanged.The sibling sweep found one production
hasUnmappedPartsBefore()caller; the patch stays in that particle gate. ExistingGivenNamePartconsumers already require nonempty output. All factory-built surname mappers use the same implementation.CI verified
CI run 38920253843 completed successfully for head
ad1c24a25b5c493d683a3b66c9bbfd09389e468c:All five job logs were reviewed. The PR merge-ref tree equals the tested head tree. The workflow-file scan is path-filtered and does not apply to these four changed files.
Independent review found no blocker and passed 1,106 additional assertions for explicit outputs, language/configuration reuse, sparse input, empty mapped names and protected-hook semantics. Local runtime verification used PHP 8.4; the other runtime versions were verified in the linked CI run. No performance claim is made.