Chapter 17·Strings, names, and input·~8 min
Addresses, names & 'first name / last name'
Hungarian names are surname-first; Icelandic ones are patronymics, not family names. Japanese addresses go biggest-to-smallest. UK postcodes are alphanumeric; Brazilian CEPs use dashes.
The problem
Most signup forms ask for a "First name" and a "Last name." The pair encodes one naming convention as if it were universal: Hungarian users write their surname first; Spanish-speaking countries write {given} {paternal-surname} {maternal-surname}; Icelandic users have no family name at all. Addresses vary as much, in field order, postal code shape, and what counts as a "city". The bug surfaces as failed delivery, failed KYC, or a CSV export the finance team can't process.
How it works
Why name and address forms reject real customers
"First name / last name" is not a neutral pair of boxes. It is a claim that names come in two ordered parts, given first. Hungarian and East Asian names lead with the family name, and Spanish tradition carries two surnames. Icelanders use patronymics and sort their phone book by given name. Some people have one name. Every one of those users meets the form and has to lie to it.
Addresses encode a theory too. A Japanese address starts with the postal code and narrows (prefecture, city, block, recipient last): the mirror of Western envelope order. German house numbers follow the street name, and UK postcodes are alphanumeric with a space. The pattern behind all of it: field structure, order, and validation are per-country data, not universal facts with regional exceptions.
The design move is to collect for purpose. To greet someone, ask what to call them: one field. To ship, render the destination country's format and validate by its rules. Data collected "to be safe" is the data that turns away a paying customer whose reality the schema did not anticipate.
The demo
Try these, in order
Each step reproduces one specific failure in the demo below.
- 1Switch the country from United States to Japan and read the form top to bottom. The order inverts: postal code (〒) first, then prefecture → city → block, recipient last with 様. The envelope preview shows largest-to-smallest: the mirror of Western order.
- 2Switch to Germany. Friedrichstraße 17: house number after the street name. A form with separate “street number” + “street name” columns already encodes the wrong order for most of Europe.
- 3Switch to the United Kingdom and look at the postcode. M14 5SR: alphanumeric, variable length, with a space. Every “5 digits” regex rejects it.
- 4Read the name-structure card: Spanish, Hungarian, Icelandic, mononym. Two surnames, family-name-first, patronymics sorted by given name, single names. Most CRM first_name/last_name columns have room for none of it; the “sort as” row shows what gets lost.
- 5Under “Run a persona through this form”, keep the persona on Japanese (family-given) and the “Form schema” on “First + Last, both required”. The database stores first_name: Nakamura, last_name: Haruki. The family name landed in the first-name box. Downstream, the mail-merge reads “Dear Haruki,” and the contact list files this person under H instead of N. Switch the schema to “Single full-name field + optional 'sort as'” and every render corrects itself.
- 6Set the “Persona” to Mononym / single-name with “First + Last, both required”. Submit is blocked: the required last-name box is empty, so the form stores nothing. The schema does not mis-render this person: it rejects them outright. The single-field schema stores the name without complaint.
Sign-up form (as locals expect it)
On the envelope
Alice Johnson
1600 Pennsylvania Ave NW Apt 4B
Washington, DC 20500
Rendered from the form values, in this country's line order.
City, state, and ZIP share one line, comma-separated. USPS prefers all caps for envelope automation.
The "First Name / Last Name" trap
Patrick McKenzie's Falsehoods Programmers Believe About Names lists forty falsehoods. A required last-name field breaks on these six.
Sort by family name. Address informally with the given name: 'Dear Alice'.
Use both surnames. Sort by the paternal surname. 'Márquez' alone is a wrong citation: write 'García Márquez' or 'García'.
The family name comes FIRST in native order. Western media still flip many Japanese names (e.g. 'Haruki Murakami'). In 2019 the Japanese government decided that its own documents keep family-first order in Roman script, effective January 2020.
Family-first in native order, like Japanese, and unique in Europe. Composers' English biographies sometimes flip to 'Béla Bartók'; native catalogs do not.
Stage names, many Indonesian names (e.g. Sukarno, Suharto), and some legal contexts have exactly one name. Required-field validation on 'last name' blocks these users.
The patronymic ('Guðmund's daughter') changes per generation. Iceland sorts the phone book by GIVEN name: alphabetical by Björk, not Guðmundsdóttir. CRM software that filters by 'last name' fails Icelandic users.
Run a persona through this form
Pick one of the six people above and a storage schema. Everything below is computed from the fields that schema keeps.
What the database stores
Where it renders downstream
Mail-merge greeting
Dear Haruki,
not this person's surnameAvatar initials
N.H.
computed from the stored name
Directory files under
Haruki
should file under NakamuraThe contact list, both ways
Sorted by the stored key
- Béla, Bartók
- Guðmundsdóttir, Björk
- Haruki, Nakamura
- Johnson, Alice
- (rejected: Madonna)
- Márquez, Gabriel
Sorted as each convention expects
- Bartók Béla
- Björk Guðmundsdóttir
- García Márquez, Gabriel
- Johnson, Alice Margaret
- Madonna
- Nakamura Haruki
The left list is what a CRM shows. The right list is where each person expects to find themselves.
Form-design rules
- For names, store at minimum
fullName(one freeform field). Optionally storepreferredName(the name to use in greetings). Do not split "first/last" without a hard reason. - For addresses, use country-aware field schemas (Google's i18n-address registry ships JSON for every country). Do not build one canonical schema and only translate the labels.
- Allow Unicode in name and address fields, including non-ASCII characters like ö, ñ, '.
- Do not require a state where the country has none (most of Europe), or a 5-digit postcode (Iceland uses 3 digits, Canada is alphanumeric).
- Display names per locale convention: given name first in the West, family name first in CJK and Hungarian. Use
Intl.PersonNamewhen it ships in the runtime.
The short version
Collect the fewest, loosest fields each country needs. Validation rules imported from the home market reject real customers at the moment they try to pay.
What to do about it
- Use a single "Full name" field unless a specific reason forces a split. When a split is unavoidable, use
givenNameandfamilyNamewith locale-aware ordering. The ordering data lives in CLDR person names (UTS #35 part 8), which ICU exposes asPersonNameFormatter; no browser ships anIntlAPI for it yet. - For addresses, use the Google libaddressinput dataset (or one of its open mirrors). It defines field order, required fields, postal code shape, and admin levels per country.
- Never validate names against regex. Real names contain apostrophes, hyphens, spaces, accents, non-Latin characters, and (occasionally) numbers.
- Keep the legal name editable separately from the display name. The name on an ID is often not the name a person wants shown.
Where this comes up
Who it concerns
Moments
- ·Designing signup, KYC, or checkout flows
- ·Building a CRM or admin tool
- ·Reviewing form validation rules
Field note
Patrick McKenzie's “Falsehoods Programmers Believe About Names” (2010) is the canonical list: people have one name, a first and a last, names in ASCII, names that do not change… all false, all embedded in CRM schemas anyway. Address forms fail the same way: required “state” fields, 5-digit postal validation, house-number-first assumptions.