When a software company decides to enter new markets, three terms appear repeatedly in the same conversations: internationalisation, localisation and translation. They are related, but they describe different activities with different owners, different timelines and different cost structures. Treating them as interchangeable leads to missed deadlines, rework, and products that feel foreign even after significant investment.
What software internationalisation means
Internationalisation, abbreviated as i18n (18 letters between the «i» and the «n»), is an engineering decision. It happens before any translator is involved. The goal is to build the application in a way that allows it to support multiple languages and regional conventions without requiring structural changes to the codebase for each new market.
In practice, this means externalising all user-facing text into resource files, such as `.json`, `.po` or `.resx`, rather than hard-coding strings into the source code. It also means ensuring the application handles Unicode encoding correctly, that text containers have enough room for languages that expand in length (German text is typically 20 to 30 per cent longer than its English equivalent), and that dates, currencies, number formats and units of measurement are treated as configurable variables.
An application that has not been internationalised can still be translated, but the result will be fragile. Every product update will require repeating the text extraction and reintegration work, multiplying costs over time and creating ongoing dependency on manual workarounds.
What software localisation involves
Localisation, abbreviated as l10n, is the process of adapting a product for a specific market or cultural context. Translation is a central part of that process, but it is not the whole of it.
A thorough localisation effort covers:
- Interface text: translation of all strings, including error messages, button labels, tooltips and help content.
- Regional formats: date formats (DD/MM/YYYY vs. MM/DD/YYYY), decimal separators, currency symbols, and time zones.
- Visual elements: images or icons that may carry different connotations in the target culture.
- Text directionality: languages such as Arabic or Hebrew require right-to-left (RTL) interface layouts.
- Legal and regulatory requirements: mandatory fields, privacy notices and terms of service that vary by jurisdiction.
- Tone and register: a B2C product for the Brazilian market communicates differently from the same product for a German audience, even when both versions are linguistically accurate.
Localisation assumes that internationalisation has already been completed. Without that technical foundation, localisation becomes a manual, error-prone process that scales poorly.
For companies expanding into Portuguese-speaking markets in Africa, localisation involves additional layers: local terminology, regional format preferences and regulatory requirements that differ substantially from European Portuguese conventions. The practical implications are explored in detail in the article on mobile app localisation for Angola and Mozambique.
What software translation specifically requires
Translation is the linguistic component of localisation. It involves converting text from a source language into a target language while preserving meaning, tone and function.
Software translation has characteristics that distinguish it from document translation:
- Strings often have strict character limits determined by the interface layout.
- Text appears without immediate context: the word «open» may be a verb («abrir») or an adjective («aberto») depending on which screen it appears on.
- Variables and placeholders such as `{username}` or `%s` must not be translated but must be preserved in the correct position.
- Terminological consistency is critical: if «account» is rendered as one term on one screen and a different term on another, users notice, and it erodes trust in the product.
Software translation without adequate contextualisation produces inconsistencies that degrade the user experience. For this reason, professional software translation projects should include localisation kits with screenshots, controlled glossaries and style guides aligned to the product's voice.
How the three processes fit together in practice
The correct sequence is always: internationalisation first, localisation next, with translation as a component of localisation. Inverting this order or treating the three as independent activities generates inefficiencies that compound over the product lifecycle.
A practical way to frame the relationship:
- Internationalisation is what the development team does to make the product adaptable.
- Localisation is the cross-functional process of adapting it for a specific market, coordinating engineering, design and linguistics.
- Translation is the linguistic work carried out within that process.
For SaaS products, this articulation has direct implications for how translation suppliers need to work: with access to staging environments, correctly structured resource files, and quality assurance processes that include in-context review. The article on ISO 17100 localisation for SaaS platforms sets out what these requirements mean in concrete terms when selecting and briefing a translation supplier.
How M21Global approaches software and technology localisation
M21Global works with product and engineering teams on software and application localisation, with a focus on terminological consistency, translation memory management and integration with the most common resource file formats. For products where interface quality is central to brand perception, the Estratégica service tier delivers a three-linguist workflow with independent review and quality control audited to ISO 17100:2015. For high-volume content where impact is lower, the IAH+ service combines machine translation with selective human review to meet faster turnaround requirements.
If the product roadmap includes a new market launch or a structured localisation programme, contact M21Global through the technology and software localisation service page to discuss project requirements and receive a proposal matched to the scope and timeline.
Related Services
Request a free software localisation quote
- Request a free software localisation quote
- Mobile App Localisation Angola Mozambique
- Iso 17100 Localization For Saas Platforms
- A Surprising Amount Of Content Available Online Is Generated By Artificial Intelligence
Frequently Asked Questions
What is the difference between software localisation and translation?
Translation is the linguistic conversion of text from one language to another. Localisation is a broader process that includes translation but also covers regional formats, visual elements, legal requirements and communication tone for a specific market.
What does software internationalisation (i18n) mean?
Internationalisation is the process of engineering an application so it can support multiple languages and regional conventions without structural code changes. It includes externalising text into resource files, supporting Unicode, and treating dates, currencies and formats as configurable variables.
Does software need to be internationalised before it can be localised?
Yes. Without prior internationalisation, localisation becomes a manual and unstable process. Every product update will require repeating the text extraction and integration work, increasing costs and the risk of errors over time.
What file formats are commonly used in software localisation?
The most common formats include .po (gettext), .json, .resx (.NET applications), .strings (iOS) and .xml (Android). The appropriate format depends on the platform and development framework used.
Is ISO 17100 certification relevant for software translation projects?
ISO 17100:2015 defines quality requirements for professional translation processes, including independent review and quality control. For software products where interface accuracy directly affects the user experience or operates in regulated contexts, working with an ISO 17100-certified provider offers a structured quality assurance framework.

