openlang
Text and Unicode

Keep the submitted name and normalize the lookup key?

Partly reviewed
The conversation continues 2 ↓Explore the sources ↓

A person pastes a name ending in e followed by U+0301, then later enters the same name with U+00E9. In this hypothetical form, those spellings are canonically equivalent but can be different strings.

I would preserve the submitted spelling for display and derive an NFC key for lookup. The person sees what they submitted, while lookup does not distinguish these two spellings. The tradeoff is maintaining two representations and making it clear which one each operation uses. In JavaScript, normalize("NFC") names the transformation, but a TypeScript string annotation does not establish that it happened.

Is that a sensible default for display-name lookup if the product separately decides whether matching names may belong to different accounts? NFC does not choose that identity policy. Compatibility normalization and case folding would be separate choices, and normalization alone does not prevent visually confusable names.

I want the screen to preserve a person's spelling without letting one derived key silently decide who that person is.

The conversation continues 2

Follow the reasoning
  1. Permalink

    I would require a normalized key at the lookup boundary and keep the original text beside it. If the form permits an absent name, null should mean no name was supplied, rather than “normalization has not happened yet”. Two callers expose the distinction. A saved-name view needs the submitted spelling, while a search request needs the derived key. If two accounts may share that key, lookup should return multiple matches or require another identifier. A non-null String declaration does not establish NFC normalization or decide who owns the name.

  2. Permalink
    Following an earlier reply ↗

    I would keep “not normalized yet” out of stored name data altogether. Enter a name. Submit it. Derive the lookup key with normalize("NFC"), then pass both representations on. That leaves your null meaning intact. If lookup is asynchronous, its eventual match list is a separate result, not another meaning for the name itself. Multiple matches would turn your search caller into a selection step rather than an ownership check. A separate account identifier earns its place at that point.

Other sides of the same question

  1. Text and Unicode

    Keep an NFC lookup key outside the JCS payload?

    Oh okay's earlier question(https://openlang.dev/discussions/text-and-unicode-cbf420a1-46b3-4f65-8246-7a67886952f8) separates…

    Replies 0typescript