To prepare a product interface for several languages, do the engineering work first: internationalisation (i18n) means building the software so that language, formats and layout can change without rewriting code. Localisation (l10n) is the later step of adapting the product to a specific market. Teams that skip i18n and send hard-coded text to translators usually pay twice, once to translate and again to fix what the translation breaks.
i18n and l10n: the difference
The W3C defines localisation as adapting a product, application or document to suit a specific target market, or locale. It goes beyond translating the interface and can include date, time, number and currency formats, sorting rules, symbols, colours, culturally sensitive imagery and wording, legal requirements, and address or name formats.
Internationalisation is designing and building a product so it can be localised easily. W3C lists practices such as supporting Unicode, avoiding hard-coded interface strings, separating localisable content from source code, adding markup and styling for bidirectional or vertical text, and supporting regional preferences such as calendars and numeral systems. The same page makes the cost argument: building i18n in from the start is far cheaper than retrofitting a finished product (W3C: Localization vs. Internationalization).
For the wider non-software picture, see localisation versus translation, and for the video side see subtitles versus dubbing.
The i18n checklist
1. Externalise every string
Move all user-visible text out of code into resource files keyed by identifier. Include button labels, error messages, alt text, email templates and validation text. Never build sentences by joining fragments, because word order differs between languages. Use whole sentences with named placeholders.
2. Use Unicode throughout
Store, transmit and display text in Unicode (UTF-8 in most stacks). Check databases, APIs, file exports and fonts, not only the front end.
3. Format dates, numbers and currency by locale
Do not hand-build format strings. In JavaScript, the built-in Intl object provides language-sensitive formatting and comparison, including Intl.DateTimeFormat, Intl.NumberFormat, Intl.PluralRules, Intl.ListFormat and Intl.RelativeTimeFormat. MDN’s example shows the same date and number rendering as 5/24/2012 and 26,254.39 in en-US but 24.5.2012 and 26.254,39 in de-DE (MDN: Intl). Other languages and frameworks have equivalents.
4. Handle plurals and grammar properly
English has two plural forms, but other languages have more or fewer. Use a plural-aware mechanism such as Intl.PluralRules or your framework’s equivalent rather than “item(s)” or a simple count check.
5. Design flexible layouts
Translated text changes length, so buttons and menus need room. Avoid fixed-width containers and text embedded in images. Test with deliberately long strings. Chinese, Japanese and Korean text often needs different line-height and font choices, and Arabic and Hebrew need right-to-left layout. W3C lists bidirectional and vertical text support among its i18n practices.
6. Separate locale from language
A language (English) is not a locale (English, Australia). Store a user’s locale preference, offer a switcher, and keep currency, region and language as separate settings where they matter. A user in Brisbane might want an English interface with another country’s measurement units.
7. Sort and search with locale awareness
Intl.Collator exists because alphabetical order differs by language. Do not assume English ordering.
A workable localisation workflow
- Pseudo-localise. Replace strings with accented or lengthened dummy text to find hard-coded text and layout breakage before real translation begins.
- Prepare a glossary and context. Give translators screenshots and notes. A button labelled “Book” could be a noun or a verb.
- Translate and review. See localisation versus translation for when literal translation is not enough. Native-speaker review catches tone problems.
- Test in context. Review the translated product on screen, not just in a spreadsheet.
- Plan for updates. New features need new strings. Decide how you will track untranslated text so it never ships unflagged.
Common mistakes
- Concatenating strings to form sentences.
- Using flags to represent languages.
- Storing dates as formatted text.
- Leaving error messages and emails out of scope.
- Translating before the design can accommodate longer text.
Trade-offs to weigh
i18n adds upfront effort, and it will not make sense for every product. If you serve one market and have no plans to expand, a light version (externalised strings and Unicode) may be enough. If an overseas launch is likely, the cost argument from W3C applies. Market choice and positioning are separate questions, discussed in how Australian brands can reach international audiences.
Where Radiance Impact fits
Radiance Impact’s Global division supports localisation and adaptation, and its detail pages cover localisation and games and software launches for English-speaking audiences. For help planning the work, contact us.
Sources
- Localization vs. Internationalization, W3C
- Intl, MDN Web Docs
