Internationalization (i18n): designing for multiple languages from the start
Internationalization (i18n) prepares a product for several languages, formats, and text directions before translation. Learn what it covers and what to avoid.
What is internationalization?
The W3C describes it in practice as designing and developing a product so that localization is easy. Localization, by contrast, is adapting the product to the language, culture, and requirements of a specific market. If internationalization is skipped, every new market becomes a rebuilding project.
Apple describes it in similar terms: separating code from interface and text, so translations do not require changing the app’s logic.
Why does it matter to a designer?
Because most internationalization problems are visual and show up in the design. A button sized for “Save” can break with a longer equivalent. A layout aligned to the left looks wrong in Arabic or Hebrew. A date written as “03/04” means different things depending on the country.
Internationalization also requires layout logic that does not depend on the source language. That is good practice for any designer, even if the app never leaves one country.
What does it cover?
Internationalization is usually grouped into five areas:
| Area | What it means | Example |
|---|---|---|
| Text | Separate strings from code and use Unicode encoding (UTF-8 unless there is a strong reason not to) | One translation file per language |
| Formats | Show dates, times, numbers, and currencies by the language’s conventions | “1.234,56” versus “1,234.56” |
| Direction | Support right-to-left languages and declare language and direction | A menu that mirrors in Arabic |
| Expansion | Leave room for longer text | A button that grows when translated |
| Culture | Review icons, colors, symbols, and references | A gesture or image with a different meaning |
The W3C’s review checklist includes locale-relevant sorting, text normalization, and capturing language and direction in input. These points often go unnoticed until a real problem appears.
How do you design for text direction?
One of the most useful decisions is to use logical properties instead of fixed ones. MDN explains that logical properties use the block and inline axes instead of left and right. A margin defined as the inline start adjusts on its own when text runs right to left.
MDN adds that this way content translated into languages with different writing modes renders as intended.
For designers, the idea translates into thinking in terms of “start” and “end” instead of “left” and “right”. A forward-pointing arrow should be mirrored in a right-to-left language, but a clock hand or a play icon usually should not be. That distinction should be documented.
What should you agree on with engineering?
Before designing screens, agree on four points:
- Where the text lives. Apple describes separating user-visible text from executable code, so that exporting translations does not require changing the source code.
- Who formats dates, numbers, and currencies. Apple asks for dates, lengths, weights, prices, and currency symbols to be expressed correctly per locale; use the platform’s utilities instead of formatting by hand.
- How language and direction are declared. The W3C checklist asks for metadata about and support for both.
- How it is tested. Apple recommends test plans that flag clipping, truncation, overlapping, and issues in right-to-left languages.
When should you start?
From the design phase. The W3C states that internationalization should be a fundamental step from the start, and that adapting it later is usually much harder and slower. If your product already exists, start with what hurts most: fixed text inside images, date formats written by hand, and layouts with fixed heights.
When is it not necessary?
If the product is an internal tool for one country and one language, a complex i18n system is not worth building. The sensible approach is to keep the basic separation of text and formats, which costs little, and leave the rest until a real market exists.
Example
Illustrative example: an order app shows the total with a currency symbol and a format typed by hand on each screen: “$ 1234.5”. When the team launches in Colombia, they find the format ignores the local decimal and grouping conventions. The fix is not to translate each screen; it is to centralize number and currency formatting in one function that follows the language’s conventions. From then on, every new screen inherits the correct format.
Common mistakes
- Writing text inside components, which forces code changes for every language.
- Designing with fixed heights and widths that cannot tolerate longer text.
- Concatenating sentences from fragments, because word order changes between languages.
- Typing dates and currencies by hand instead of using the language’s formatting.
- Using arrows and fixed positions without considering text direction.
- Leaving internationalization for “later”, when the design is already locked.
If you want the full path, the product localization strategy page shows what to decide before translating, and RTL and UI localization goes deeper into right-to-left languages. For the system that holds these decisions together, the design system is where they are best documented.