Internationalisation gets deferred because it looks like a translation task and translation can be added later. Some of it can. The parts that cannot are the assumptions baked into your data model and layout - that names have two parts, that a date is unambiguous, that text flows left to right, that a currency amount has two decimal places.
01Get the storage decisions right first
Store timestamps in UTC with the original timezone recorded separately where the local time matters. Store currency as an integer in the smallest unit with the currency code alongside - never a float, and never an amount without its currency. Store text as Unicode throughout, with database collation set deliberately rather than defaulted.
These are the expensive ones to change later because they require migrating data, and getting them wrong produces bugs that are subtle rather than obvious - a meeting that appears an hour off twice a year, a total that is out by a rounding error, a name that sorts strangely.
| Area | Retrofit cost | Why |
|---|---|---|
| UI strings | Low | Mechanical extraction |
| Date and time handling | High | Data migration, logic everywhere |
| Currency storage | High | Financial data migration |
| Name and address fields | High | Schema and every form |
| Text direction | Very high | Every layout decision |
| Sorting and collation | Moderate | Query and index changes |
02Names and addresses are not structured the way you assume
First name and last name is a Western convention that fails for a large share of the world. Some people have one name. Some have several family names. In many cultures the family name comes first, and mononyms are entirely normal.
A single full name field plus an optional display name handles nearly everyone. Addresses are the same problem: a form demanding a state and a five-digit postcode is unusable in most countries. Store a free-form address block with a country code, and format for display rather than for storage.
03Layout has to survive text expansion
German runs thirty to forty percent longer than English. Finnish can be worse. A button sized precisely to its English label breaks in translation, and a fixed-height card overflows.
Design for variable length from the start: flexible containers, no fixed widths on text elements, and a pseudo-localisation mode that inflates every string during development. That catches expansion problems while you are building rather than after a translator delivers.
| Pattern | Problem | Instead |
|---|---|---|
| Concatenating sentence fragments | Word order differs by language | Full sentences with placeholders |
| Fixed-width buttons | Longer translations overflow | Flexible sizing |
| if (count === 1) singular | Some languages have several plural forms | Plural rules from the platform |
| Text baked into images | Not translatable at all | Real text over the image |
| Hardcoded date formats | Ambiguous or wrong | Locale formatting APIs |
04Right-to-left is a layout decision, not a stylesheet
Arabic, Hebrew, Farsi and Urdu flow right to left, and supporting them means the entire layout mirrors: navigation, icons that indicate direction, progress indicators, alignment. Retrofitting this into a codebase full of left-specific styling is genuinely expensive.
Using logical properties - start and end rather than left and right - costs nothing while building and makes mirroring largely automatic. Even if RTL is not on the roadmap, it is cheap insurance against a market you might enter.
05Decide the scope honestly
Full localisation - translated content, local payment methods, local support hours, region-appropriate legal terms - is a company-wide commitment, not a frontend task. Translating the interface while support only operates in one timezone and billing only accepts one currency produces a product that looks localised and is not.
The pragmatic position for most companies is to get the storage and layout decisions right early, because those are the expensive retrofits, and defer translation until there is a market to justify it. That keeps the door open without paying for a capability nobody is asking for yet.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer