Lesson 17·Unit 5 · Strings, names, and input·Personal data & form fields·Lv 301·~8 min
Addresses, names & 'first name / last name'
Hungarian names are surname-first. Spanish people have two surnames. Icelandic 'last names' are patronymics, not family names. Japanese addresses go biggest-to-smallest. UK postcodes are alphanumeric; Brazilian CEPs use dashes. Your CRM is wrong about half the world.
By the end
- ·Lay out a name and address form in the order the destination country uses.
- ·Pick a name schema that survives mononyms, double surnames, and family-name-first order.
- ·Validate postal codes per country, rather than making the world match your home market.
The problem
Most signup forms ask for a "First name" and a "Last name." That covers roughly the population of the United States. Outside that: Hungarian users write their surname first; Spanish-speaking countries write {given} {paternal-surname} {maternal-surname}; Icelandic users have no family name at all. Address formats vary just as much: different field orders, different postal code shapes, different ideas of what "city" means. The bug usually surfaces as failed delivery, failed KYC, or a CSV export your finance team can't process.
How it works
Your form is a theory about people
"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. Spanish tradition carries two surnames. Icelanders use patronymics and sort their phone book by given name, and some people have one name. Every one of those users meets your 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 you collect "to be safe" is the data that turns away a paying customer whose reality your schema did not anticipate.
See it yourself
Try these, in order
Each step triggers a specific failure you should recognize on sight.
- 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. Now re-read your CRM's first_name/last_name columns and the “sort-as” row here.
- 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
Edit any field on the left. The envelope re-renders 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. Greeting card: '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 Nobel went to 'García Márquez'.
The family name comes FIRST in native order. Western media still flip many Japanese names (e.g. 'Haruki Murakami'). In 2020 the Japanese government formally requested that English transliteration keep family-first order.
Family-first in native order, like Japanese, and unique in Europe. Composers' English biographies sometimes flip to 'Béla Bartók'. Native catalogs keep the native order.
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. The demo computes everything below (the stored record, the mail-merge greeting, the avatar initials, the directory position) from the fields the 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 your CRM shows. The right list is where each person expects to find themselves.
Practical 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" unless you have 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 if the country has none (most of Europe). Do not require a 5-digit postcode (Iceland uses 3 digits, Canada is alphanumeric).
- Display names per locale convention: Western convention puts the given name first, while CJK and Hungarian put the family name first. Use
Intl.PersonNamewhen it ships in your runtime.
If you remember one thing
Collect the fewest, loosest fields each country needs. Validation rules imported from your home market reject real customers at the moment they try to pay you.
What to do about it
- Use a single "Full name" field unless you have a specific reason to split it. If you must split, use
givenNameandfamilyNamewith locale-aware ordering:Intl.PersonNamehandles this in modern browsers; for older runtimes use the CLDR personNames data. - 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.
- Allow editing of the legal name separately from the display name. A user may have a different name on their ID than the one they want shown in your UI.
Use this with
Stakeholders
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.
Quick check
3 questions · pass at 2+
Question 1/3
In what order is a Japanese postal address written?
Question 2/3
A form splits “Gabriel García Márquez” into first_name = first word, last_name = last word. What does it store, and what breaks?
Question 3/3
A checkout requires a 5-digit numeric postal code. Which real customers does it reject?