Software internationalisation (i18n) is the process of building software so it can work in any language or region without code changes. It's not a translation task. It's an architecture decision.
Done early, it makes localisation fast and scalable. Done late, it creates engineering debt that slows every release.
This guide covers what good internationalisation looks like, the cost of getting it wrong, and a practical checklist for implementation.
Software internationalisation means designing your software to support multiple languages, regions, and cultural conventions without rewriting code for each new locale.
The abbreviation "i18n" comes from the 18 letters between the "i" and the "n" in "internationalisation."
The core principle: separate content from code, and design for variability.
What i18n covers:
What i18n is not: it's not translation. It's not localisation. It's the foundation that makes both possible.
Internationalisation (i18n) makes software capable of supporting multiple locales. Localisation (l10n) adapts software for a specific locale. The relationship is sequential: i18n is the architecture, l10n is the execution.
A useful analogy. Internationalisation is building a house with modular rooms that can be furnished differently. Localisation is furnishing each room for a specific occupant. You can't furnish a room well if it wasn't built to be modular in the first place.
|
Internationalisation (i18n) |
Localisation (l10n) |
|
|
What |
Architecture and design decisions |
Adapting content and experience |
|
When |
Once, at the start (ideally) |
For every target market |
|
Who |
Engineering team |
Localisation team, translators, reviewers |
|
Output |
A codebase ready for any locale |
A product adapted for a specific market |
|
Example |
String externalisation, flexible layouts |
Translating UI, adapting date formats |
Teams that skip i18n and jump straight to l10n end up retrofitting architecture mid-project. That means going back into code to pull out hard-coded strings, refactor fixed-width layouts, and add locale-aware formatting. It's slower, more expensive, and introduces regression risk.
Teams that invest in i18n upfront add new languages by adding translators and reviewers. Teams that skip it need engineering effort for every new language.
If internationalisation isn't built in from the start, every localisation effort needs engineering workarounds.
The patterns are predictable:
The compounding effect. Each of these issues costs time to fix. But the real cost is multiplication. Every new language and every new market amplifies the debt. What costs a day to fix for one language costs a week when you support 20.
Teams report spending 2-5x more engineering time on retrofitting i18n than it would have cost to build it in from the start. Retrofitting also introduces regression risk that slows the entire release cycle.
Well-built i18n means new strings flow to the TMS automatically. The UI adapts to any language without code changes. Localisation runs alongside development through continuous integration.
Poor i18n means manual string extraction every sprint, layout hotfixes for every new language, and engineers pulled back into localisation support to answer context questions and fix rendering issues.
The velocity gap is real. Teams with solid i18n ship localised versions in the same release window as the source language. Teams without it add days or weeks of engineering work to every release that touches localised content.
AI-assisted translation, automated QA, continuous localisation pipelines, and visual context tools all work better when i18n foundations are solid.
LLM-based translation tools need clean, context-rich strings to produce quality output. Hard-coded strings buried in code with no context produce poor translations, no matter how good the AI model is.
Automated QA catches formatting errors, length violations, and terminology gaps at scale. But only if strings are properly externalised and resource files follow consistent formats.
Visual context tools like Rigi give translators and reviewers real UI previews. But they depend on strings being properly externalised and the UI being built with locale-aware rendering.
The better your i18n, the more value you get from every tool in your localisation stack.
All user-facing text lives in resource files, never hard-coded.
Standard formats include JSON, XLIFF, .properties, .strings (iOS), and XML (Android). The OASIS XLIFF standard provides a widely-supported interchange format for translation data.
Meaningful key names provide context. screen.login.button.submit tells a translator far more than string_42. Good key naming cuts context queries and translation errors.
Pluralisation needs proper handling. English has two forms (singular, plural). Arabic has six. Russian has three. Polish has four. Use ICU MessageFormat or platform-native pluralisation (like .stringsdict on iOS) to handle this correctly.
Never concatenate strings. Building sentences by joining fragments ("You have " + count + " items in your " + location) breaks in languages where word order, gender agreement, and case markings change.
Format dates, times, currencies, and numbers using locale libraries, not hard-coded patterns.
Use established locale libraries: the Intl API in JavaScript, ICU libraries for C/C++/Java, or the Unicode CLDR data that underpins most of them.
Never assume format patterns. MM/DD/YYYY is US-only. Even "obvious" formats like comma-separated thousands vary across markets.
UTF-8 is the standard. Every layer of your stack needs to handle it consistently: database, API, transport layer, and frontend rendering.
What to watch for:
Consistency matters. If your database stores UTF-8 but your API returns Latin-1, or your frontend renders characters differently than your backend validates them, you'll get corruption, display errors, or data loss.
Design for text expansion. German text can run 30% longer than English. Finnish and Dutch expand similarly. Chinese and Japanese are often shorter. If your UI uses fixed-width elements sized for English, translated content will truncate or break the layout.
Use flexible containers. Auto Layout (iOS), ConstraintLayout (Android), and CSS flexbox/grid (web) all support dynamic sizing based on content length.
RTL support goes beyond flipping the CSS. Arabic, Hebrew, Persian, and Urdu need mirrored layouts. Navigation flow, icon positioning, progress indicators, and reading direction all need to flip. Bidirectional text (mixing LTR and RTL in the same string) needs explicit handling.
Keep locale-specific logic out of application code. Drive currency conversion rules, date format preferences, and number formatting through configuration, not if-else blocks.
Use feature flags for market-specific functionality. Some features may only apply in certain markets. Use configuration-driven feature management rather than hard-coded market checks.
Delegate formatting to i18n libraries. Don't write custom date formatting, currency rendering, or pluralisation logic. Use established libraries that are maintained and tested across locales.
This checklist provides a structured path from codebase audit to production-ready i18n.
Where XTM and Rigi enter the picture. Once your i18n foundation is solid, a TMS like XTM handles the translation workflow: string sync, translation memory, glossary management, and team collaboration. Rigi adds visual context so translators see strings in the real product UI without engineering involvement. Solid i18n is what makes this parallel execution possible.
Treating i18n as a "later" problem. The cost of retrofitting compounds. Every sprint that passes with hard-coded strings and fixed layouts adds debt that gets harder and riskier to fix.
Hard-coding strings or concatenating translated fragments. Both make localisation impossible without code changes. Concatenation is especially harmful because it assumes word order and grammar rules that break across languages.
Assuming English formatting patterns are universal. Dates, currencies, numbers, addresses, and name ordering all vary by locale. Formats that feel "obvious" in one market are wrong in another.
Using images with embedded text. Text baked into images can't be translated without redesigning the image. Use text overlays or dynamic text rendering instead.
Ignoring pluralisation complexity. English has singular and plural. Arabic has six plural forms (zero, one, two, few, many, other). Russian has three. If your code only handles "one" and "other," it produces grammatically incorrect output in most languages.
Testing only in English. If you haven't tested with pseudo-localisation and at least one real language, you haven't tested internationalisation at all. The bugs that matter (truncation, encoding, layout breaks) only show up with non-English content.
Over-engineering custom i18n frameworks. Established libraries (Intl API, ICU, CLDR) are maintained, tested, and documented. Building custom i18n logic creates maintenance burden and bugs that standard libraries have already solved.
Software internationalisation is not a feature. It's a foundation. The teams that build it in early ship faster, localise cheaper, and scale without engineering bottlenecks. The teams that delay it pay more every sprint, for every language, in every release.
The good news: i18n is a solved problem. The standards exist. The libraries are mature. The checklist is clear. The only variable is when you start.
If you're building something new, build i18n in from day one. If you're retrofitting, start with the audit and work through the checklist methodically. Either way, the investment pays back every time you add a language, enter a market, or ship a release.
Ready to see what becomes possible when your i18n foundation is solid? Explore the Rigi product tour to see how dynamic visual context and structured review make parallel localisation work.
Internationalisation in software is the practice of designing and building applications so they can support any language, region, or cultural convention without code changes. It covers string externalisation, locale-aware formatting, Unicode support, flexible UI layouts, and RTL text direction. The goal is to create a codebase that's ready for localisation from day one, so adding a new language is a content task, not an engineering project.
Before. Always before. i18n is the architecture that makes l10n possible. Trying to localise software without proper i18n means rewriting code for every new language. The best approach: build i18n into the architecture from the start, then localise each market on top of that foundation.
The cost depends on your starting point. For new projects, building i18n from the start adds 5-15% to initial development time. Retrofitting an existing codebase costs far more: teams report 2-5x the effort of building it in originally, plus regression risk and release delays. The longer you wait, the more it costs.
Pseudo-localisation replaces source strings with modified versions that simulate translated text: expanded length, accented characters, and special symbols. It catches layout truncation, encoding errors, and hard-coded strings automatically, without waiting for real translations. Running pseudo-localisation in CI catches i18n issues every build. It's one of the most cost-effective quality gates in the localisation process.
Globalisation (g11n) is the business strategy of making products available worldwide. Internationalisation (i18n) is the technical architecture that enables software to support multiple locales. Localisation (l10n) is the process of adapting a product for a specific market. In practice: globalisation sets the business intent, i18n builds the technical foundation, and l10n delivers the market-specific experience.