Localisation: building software for more than one language
What it takes to make software work in several languages and regions, why it is cheap at the start and expensive later, and what to decide first.
The short answer
Software for more than one language involves two things with confusingly similar names. Internationalisation is building the software so that it can be adapted: no text hard-coded in the interface, formats for dates, numbers and currencies that follow the user’s locale, layouts that tolerate longer words and different scripts, and a data model that knows which content varies by language. Localisation is doing the adapting for each language and region: translating the text, checking the formats, adjusting addresses and legal content. The first is cheap at the start and very expensive later. The second is a recurring job with a process. The decisions to make early are which languages and regions, who translates, how content is managed and whether the data itself is multilingual.
What changes per language and region
| Element | What varies | What the software must do |
|---|---|---|
| Interface text | Every label, message, error, email | Externalised into translation files; keys, not strings, in code |
| Text length and direction | German longer, Chinese shorter, Arabic right to left | Flexible layouts; direction-aware components |
| Dates, times, numbers, currencies | Formats, separators, calendars, time zones | Locale-aware formatting everywhere; store in neutral form |
| Addresses, names, phone numbers | Field order, required parts, validation | Per-region forms and validation |
| Content and data | Product names, descriptions, documents, categories | Multilingual fields where needed; fallback rules |
| Legal and regional | Terms, taxes, consent, units | Per-region content and rules |
| Search and sorting | Accents, collation, stemming | Locale-aware search and sort |
| Emails and notifications | Language per recipient | Templates per language; recipient’s preference stored |
Deciding first
- Languages and regions, now and plausibly later, and which is the fallback.
- Who translates and reviews: internal native speakers, an agency, machine translation with review.
- Where translations live and how they flow: files in the repository, a translation platform, a content system.
- Which data is multilingual: per entity, a decision that shapes the data model.
- Regional rules: taxes, addresses, legal text, consent, which vary by region rather than language.
- How users choose: detected, chosen, remembered, per account.
The ongoing process
New features add strings; strings need translating before release; translations need review; a glossary keeps terms consistent; screenshots help translators see context; the pipeline checks that no language is missing a key. It is a small, steady process rather than a project, and the tooling exists to make it routine. Businesses that treat each new language as a one-off suffer with every release; those with the process add a language when the market opens.
What this means for you
Internationalise from the first screen even if you ship in one language: externalised text, locale-aware formats, flexible layouts, a data model that knows which content is multilingual. Decide languages, translators, content flow and regional rules early. Localise as a steady process with review and a glossary. It is inexpensive at the start and a rewrite at the end, and the difference is decided before anyone notices.
Frequently asked questions
We only need one language now. Should we still prepare?
Yes, cheaply: keep all interface text out of the code in translation files from the first screen, use locale-aware formatting for dates, numbers and currencies, and design layouts that tolerate longer text. That costs almost nothing during the build and turns adding a language later from a rewrite into a translation task.
Is machine translation good enough for the interface?
As a first draft reviewed by a native speaker, often yes. Unreviewed, it produces labels that are technically translated and practically wrong: the wrong sense of a word, the wrong tone, text that no longer fits the button. Use it to speed the translator, not to replace the review, and keep a glossary of your terms so they are translated consistently.
What about the data, not just the interface?
That is the decision that gets missed. Product names, descriptions, categories and documents may need versions per language, which changes the data model. Decide per entity whether it is multilingual before building; adding a language dimension to data later is a migration, not a setting.