Internationalization: Building Software for Multiple Languages and Currencies
Key takeaway
Translation is the small part. The expensive parts are storing money and time correctly, formatting by locale rather than by language, and designing layouts that survive text expanding by 30%. Retrofitting these is several times the cost of building them in from the start.
Teams usually meet internationalization as "we need a Spanish version", and discover a fortnight later that the date format, the currency rounding, and the address form are all wrong too.
Get these right in the data model
- Store money as a minor-unit integer with an explicit currency code — never a float, never currency implied by the user's country.
- Store timestamps in UTC with the originating time zone recorded separately when the local time matters (appointments, business hours).
- Don't assume address structure. Postcodes, states, and even street-number position vary; a flexible address model saves a painful migration.
- Allow full Unicode in names and text fields, including in indexes and comparisons.
Locale is not language
A user may read Spanish but live in Mexico, get paid in dollars, and expect a particular date format. Separate the language of the interface from the formatting locale and from the currency. Format numbers, dates, and currencies with the platform's locale library rather than with your own string handling — this is the single most common source of embarrassing bugs.
Interface work people forget
- German and Finnish text routinely run 30% longer than English — fixed-width buttons will break.
- Right-to-left languages need mirrored layouts, not just translated strings; use logical CSS properties from the start.
- Never concatenate sentences from fragments — grammar, plural rules, and word order differ. Use full strings with named placeholders.
- Pluralisation has more than two cases in several languages; use a library that handles plural categories.
- Sorting and search must be collation-aware, or alphabetical lists will look wrong to native speakers.
Commercial and legal differences
- Tax rules differ by market and may require displaying prices inclusive of tax.
- Payment methods vary sharply by country — card-first assumptions lose conversions in many markets.
- Privacy, consent, and invoicing requirements differ per jurisdiction.
- Support hours and expectations change; a time zone is an operational commitment, not a setting.
How much to do up front
Even if you launch in one market, get the data model, formatting, and string externalisation right from day one — that's a small fraction of the effort and removes nearly all the retrofit cost. Defer actual translation and market-specific payment work until a market is real.