Skip to content

양. 지훈 splits the given name in half #323

Description

@derek73
parse("양 지훈")    # given 지훈, family 양            correct
parse("양. 지훈")   # given 양., middle 지, family 훈   wrong

지훈 is one given name. The second form cuts it in two.

This is exactly the harm _script_segment._is_post_nominal's docstring names — "지 is a listed surname, so 양 지훈 … would have its own given name split in half" — and the guard that prevents it is standing right there, unable to fire.

Why it cannot fire

_split_surname_site picks its site by effective_script(...) in scripts. effective_script("양.") returns None, because the trailing period defeats the wholly-one-script test, so the site scan steps straight past 양. and lands on the given name. The guard downstream never gets asked.

effective_script("양")   -> hangul
effective_script("양.")  -> None
is_suffix_strict("양.")  -> True     (since #320)

That last line is what makes this newly visible rather than newly broken: #320 made _is_post_nominal("양.") return True, so the predicate now says "this is a post-nominal" while the caller structurally cannot ask it. Output is identical on master, so this is not a regression — but the branch created the half-state that makes the gap legible.

양 and 군 are the shipped vocabulary's designated risk class (config/suffixes.py singles them out — 양 is a top-tier Korean surname), which is why this shape is worth fixing rather than filing as a curiosity.

Two candidate fixes, and the choice matters

  • Teach the surname site to consult is_suffix_strict alongside effective_script.
  • Make effective_script tolerant of a trailing period.

The second is broader and would interact with the normalization question in #322.

Found while reviewing #320 (PR #321).

Activity

  1. added this to the v2.2 milestone on Aug 2, 2026
  2. removed this from the v2.2 milestone on Aug 30, 2026
  3. modified the milestones: 2.4, v2.3 on Sep 9, 2026
  4. added 2 commits that reference this issue on Sep 11, 2026
  5. derek73 commented on Sep 11, 2026

    @derek73
    OwnerAuthor

    Closed by #522 (merge commit 555270e, 2.3.0 unreleased).

    The second candidate fix, and it was broader than filed. _vocab._normalized_for_script now strips a trailing full stop (any of the four in _lexicon.FULL_STOPS) before classifying, so 양. 지훈 reads family 양., given 지훈, and the period stays on the word it arrived with. The None that effective_script("양.") used to return had three readers, not one: the surname site (this issue), the order rule in assign (양 지훈. had fallen to positional; family-first survives now), and the segmenter's neighbour precondition. The first candidate -- consulting is_suffix_strict at the site -- would have rescued 양. and left 김. 민준 cut, so the classification route was the right one; and the surname site itself turned out to need the same treatment (it matches its head on the stop-stripped core, otherwise 김. matched its own head and became 김 + .).

    Two adjacent readings moved with it, by the same #320 premise (the classified scripts have no initials and no period abbreviations): the glued-period honorific peels (김민준씨. -> family 김, given 민준, suffix 씨.; 田中さん. -> family 田中, suffix さん.), and rules.md#H2's abbreviation shape declines a word carrying a no-initials script, so a lone 田中. is the family name rather than a title. Hangul never reaches that shape test (hangul segmentation runs first), so its witness is Han.

    Recorded limits: a leading stop hides a token from the surname site (as before) but not from the honorific peel; a bracketed ASCII-period CJK credential (김민준.) John Smith is unwrapped and divided; halfwidth kana is outside the script table. All in decisions.md#cjk-full-stops with recompute recipes; 17 differential-corpus names move, every one a tolerated row this bundle added.

  6. self-assigned this
    on Sep 11, 2026
  7. added 5 commits that reference this issue on Sep 22, 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