Label the CJK honorific rows for the issues they depend on - #363
Merged
Conversation
29 rows carried fix(#307) or fix(#308) alone while the ledger describes the same shapes as compounding with #271, and cases.py has had compound notation since #273 for exactly this pattern -- one issue enables, #271 orders. Which rows, and against which issue, is measured rather than assumed. Re-parsing each row with script_orders and segment_scripts removed -- the documented way to restore 2.0's reading -- and then removing the HAN entry, the HANGUL entry and hangul segmentation one at a time: 26 rows change -> compound with fix(#271) 3 rows do not -> left single-issue 0 rows depend on the HIRAGANA entry, so #272 appears nowhere That last one is worth stating because the Japanese rows look like #272 cases and are not: 田中 さん and 山田太郎様 key on HAN order, since the name pieces are Han and the kana is only the honorific being peeled. The three exempt rows are the ones whose notes already explained why they are different, and each now says so in the sweep's terms: latin_stem_glued_kana_honorific and its hangul twin leave a LATIN remainder, which never reaches the order table; ko_honorific_after_comma has a comma, which decides the family before segmentation would. Recording that is the point -- a future sweep that sees 26 compound and 3 single-issue rows should find the reason in the row, not re-derive it. Ordering is fix(#307) + fix(#271), matching the two feat(#273) + fix(#271) rows rather than the issue's example string, which proposes the reverse. The existing pair reads causally -- what creates the shape, then what orders it -- and the issue's own argument is consistency with that precedent. Nothing consumes these strings but pytest failure messages, and nothing cross-checks them against the ledger's `issue` values, so the sweep cannot break a guard.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #363 +/- ##
=======================================
Coverage 98.50% 98.50%
=======================================
Files 44 44
Lines 2883 2883
=======================================
Hits 2840 2840
Misses 43 43 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Closes #324.
29 rows carried
fix(#307)orfix(#308)alone while the ledger describes the same shapes as compounding with #271, andcases.pyhas had compound notation since #273 for exactly this pattern — one issue enables, #271 orders.Which rows, measured
The issue warned that a blind sweep would fix one row into a different inconsistency, which is why #320 left it alone. So the dependency is measured, not assumed: re-parse each row with
script_ordersandsegment_scriptsremoved — the documented way to restore 2.0's reading — then remove theHANentry, theHANGULentry and hangul segmentation one at a time.fix(#271)HIRAGANAentry#272appears nowhereThat last row is worth stating, because the Japanese cases look like #272 and are not:
田中 さんand山田太郎様key on HAN order — the name pieces are Han, and the kana is only the honorific being peeled.The three exemptions are now deliberate
Each is a row whose note already explained why it differs; each now says so in the sweep's terms, so a future reader finds the reason in the row rather than re-deriving it:
latin_stem_glued_kana_honorific(Andersonさん) andlatin_stem_glued_hangul_honorific(Anderson선생님) — a Latin remainder never reaches the order tableko_honorific_after_comma(김민준, 씨) — the comma decides the family before segmentation wouldOne departure from the issue text
The issue's example string is
fix(#271) + fix(#307); this usesfix(#307) + fix(#271), matching the two existingfeat(#273) + fix(#271)rows. Those read causally — what creates the shape, then what orders it — and the issue's actual argument is consistency with that precedent. Easy to flip if you'd rather have #271 lead.Scope
Labels only.
classificationis consumed by nothing but pytest failure messages, and nothing cross-checks it against the ledger'sissuevalues (tools/differential/README.mdcalls the correspondence a convention; no test enforces it), so the sweep cannot break a guard.Full suite 3096 passed; mypy and ruff clean; differential harness clean at 0 unexplained.
🤖 Generated with Claude Code