Skip to content

initials() ignores the folded-word ordering that the family field applies (der, y van gives y. d. v. vs the facade's y. v. d.) #408

Description

@derek73

initials() iterates tokens in written order, while the family field renders FOLDED_TAG carriers first. Where both apply, the two disagree — and so do the 2.0 and v1 APIs:

p.parse("der, y van").family        # 'van der'    folded-first
p.parse("der, y van").family_base   # 'van der'
p.parse("der, y van").initials()    # 'y. d. v.'   <- written order
HumanName("der, y van").initials()  # 'y. v. d.'   <- field order

Why

_render.py's initials() walks tokens_for(role) and never applies the reorder that _text_for does for folded tokens. The v1 facade builds initials from last_list, which is already field-ordered, so the two paths diverge.

Scope: pre-existing, and wider than particles

Reachable on master without particles at all:

Parser(policy=Policy(name_order=FAMILY_FIRST, middle_as_family=True)).parse("Smith Juan Vega")
  family='Vega Smith'   initials()='J. S. V.'

Ordering folded-first in initials() — mirroring _text_for — moves 9,878 of 134,040 measured parses, mostly middle_as_family under non-default orders. That is a larger footprint than the change that surfaced it, which is why it is filed rather than folded in.

#404 made it visible for particles: an all-particle family now contributes initials, so where #379 also attached a tussenvoegsel to that family the order shows. 87 constructed inputs, no corpus name; the release log records it.

The fix

Apply _text_for's folded-first ordering in initials() so the initials follow the field. Then the v1 and 2.0 paths agree without the facade needing its own ordering rule, and R1's "folded family words render before the rest of the family" holds for every view rather than for the string views only.

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions