“Can we add another language?”
It’s one of those questions that can mean two days of work or six months of pain depending on how the software was originally designed.
If every visible sentence is hard-coded into components, dates are formatted manually and the database assumes every customer lives in Britain, adding another language isn’t really a translation task.
It’s an architecture migration.
Internationalisation and localisation aren’t quite the same thing
The terms are often used interchangeably, but the distinction is useful.
Internationalisation, often shortened to i18n, is the work involved in making software capable of supporting different languages, regions and conventions.
Localisation, or l10n, is adapting that internationalised software for a particular audience.
Internationalisation gives the system the capability.
Localisation supplies the regional implementation.
That distinction matters because software can contain perfectly translated text and still be poorly localised.
A language isn’t necessarily a locale
Jublo’s older language material explored how vocabulary and meaning can vary between different audiences speaking what is nominally the same language.
Software has exactly the same problem.
Consider:
en-GB
en-US
Both represent English, but the differences can affect:
- spelling;
- terminology;
- date formatting;
- currency;
- addresses;
- measurements;
- user expectations.
A well-designed application should carry a locale through the relevant parts of the system rather than simply storing language = English.
Don’t concatenate translated sentences
English sentence structure isn’t universal.
Code such as:
"Welcome " + firstName + ", you have " + count + " messages"
looks harmless until translators need to rearrange the sentence, deal with plural forms or use a language where the grammatical structure is different.
UI copy should be represented as complete translatable messages with variables rather than fragments stitched together by the application.
The translation layer needs enough context to produce a natural sentence.
Pluralisation is more complicated than adding an “s”
Developers often start with:
one message
two messages
Not every language follows the same singular/plural rules.
A proper internationalisation framework should therefore handle plural categories rather than leaving this logic scattered through application components.
Across a large application, details like this are the difference between a system that can genuinely support another market and one that merely displays translated words.
Dates and time zones are data problems
A date such as:
03/04/2026
means different things depending upon who is reading it.
Applications should store dates and timestamps in an unambiguous format and then present them according to the relevant user’s locale and timezone.
The same distinction matters for scheduled jobs, reports, notifications and business rules.
“Run at midnight” is meaningless until the system knows whose midnight.
Currency isn’t just a symbol
Changing £ to $ does not localise a commerce application.
The system needs to know whether values are being converted, independently priced or simply reformatted.
Decimal separators differ.
Currency symbols appear in different positions.
Tax treatment can differ.
Payment providers and payment methods differ.
The underlying monetary value should be represented precisely and its presentation treated separately.
Your layout has to survive translation
Some translated strings are considerably longer than their English equivalents.
That wonderfully neat button designed around the word “Save” might stop being wonderfully neat.
Fixed-width controls, text baked into images and interfaces designed with no tolerance for expansion often become obvious as soon as the first additional language arrives.
And that is before considering right-to-left languages, where direction, alignment and sometimes the entire interface need to adapt.
Internationalisation therefore has consequences for design systems as well as application code.
Content isn’t always application code
Modern products often combine several sources of user-facing content:
- application strings;
- CMS content;
- API responses;
- database records;
- email;
- push notifications;
- SMS;
- generated documents.
There needs to be a clear answer to where each one is translated and where the locale comes from.
Otherwise users end up with a Spanish interface, an English transactional email and a PDF generated with British dates.
Fallbacks matter
What happens when a translation doesn’t exist?
A well-designed system should have a predictable fallback chain.
For example, a missing regional es-MX string might fall back to a more general Spanish translation before eventually falling back to the application’s base language.
The important thing is that this behaviour is deliberate.
Missing translations should also be observable. Otherwise they can remain unnoticed for months.
Localisation needs local testing
Technical correctness doesn’t guarantee natural localisation.
People familiar with the target audience will catch terminology and assumptions that automated tests won’t.
The technology should make it easy for those corrections to happen without requiring another architectural change.
Build for the second market before the second market arrives
Not every application needs to support twenty languages on day one.
But there is a significant difference between not implementing localisation yet and designing an application that actively prevents it.
A relatively small amount of architectural discipline early on can avoid a much larger rewrite later.
Because multilingual software isn’t ultimately about translation.
It’s about designing software that understands that not everybody uses it in exactly the same way.