Names, addresses, and formats

Ask for the information the task needs. Avoid designing a form around an assumed English name or US address and making everyone else explain why they do not fit.

Personal names

A person may use one name, several family names, a patronymic, or a name whose family part comes first. Spaces do not reliably identify the parts. Do not infer gender, marital status, or the preferred form of address from a name.

Use one full-name field when the task needs only display or contact. If separate components are necessary, label their purpose clearly and support the target cultures. Ask how to address the person when that matters. Preserve their spelling, diacritics, script, capitalization, and order; do not “correct” a name into an English pattern.

Postal addresses

Not every address has a street name, house number, state, or postal code. Fields and required labels should fit the destination country and the service actually using the address. Preserve letters, spaces, and leading zeros in postal codes. They are identifiers, not quantities.

Permit enough space for a usable address. Do not promise delivery from a form that cannot represent the supplied destination. Example addresses in documentation should be clearly fictional or drawn from an appropriate approved source.

Dates, times, and money

An example such as 03/04/2026 is ambiguous internationally. In prose, write a named month when the locale and format would otherwise be unclear. In machine-readable examples, follow the specified syntax exactly. Distinguish a displayed local date from a stored timestamp.

Name the time zone when readers must coordinate an event. Avoid using seasons as dates for a worldwide audience. Use a currency code when a symbol could refer to more than one currency. Never change a quoted price, tax condition, or contractual amount while localizing its display.

Use locale formatters for dynamic data. Keep decimal separators, digit grouping, unit spacing, and measurement symbols consistent with the target. A narrow no-break space or other separator is data worth preserving, not a typo to normalize away blindly.

Review examples

Check a single name, a multiword name, a non-Latin name, a postal code with a leading zero, and an address without a street number. Check a date with an explicit month, a timezone transition when relevant, and an amount whose currency symbol is ambiguous. These are review cases, not claims that a given product already supports every case.