Localisation

Software & App Localisation: A Guide for Tech Companies

Jun 22, 20267 min read
Software & App Localisation: A Guide for Tech Companies

Localising a software product is not the same as translating its content. Tech companies entering new markets learn this quickly: an interface translated word for word can be linguistically correct and still feel foreign, rigid, or confusing to the end user. This guide covers what software localisation involves in practice, the most common mistakes, and how to structure the process so the product functions natively in any market.

What separates localisation from translation in software

Translation is the linguistic transfer of content from one language to another. Localisation goes further: it adapts the product to the cultural, technical, and regulatory context of the target market. In a software context, that includes date and time formats, decimal and thousand separators, currencies, text direction (left-to-right or right-to-left), plural forms and forms of address, and the expansion or contraction of text within interface elements.

English is notoriously compact. A 40-character phrase in English can easily become 60 characters in European Portuguese or 70 in German. If interface elements were not designed with this variation in mind, the result is truncated buttons, clipped labels, and unreadable menus.

For SaaS platforms and multi-language applications, this technical dimension is as important as linguistic quality. Localisation starts at the design stage, not at delivery.

Types of content that require localisation in software

In an application or digital platform, the content to localise rarely stops at interface strings. A complete inventory typically includes:

  • UI strings: labels, buttons, error messages, tooltips, notifications
  • Onboarding and tutorials: activation flows, in-app walkthroughs, coach marks
  • Documentation and help content: FAQs, support articles, user guides
  • Integrated marketing content: banners, pop-ups, upsell copy
  • Transactional emails: confirmations, alerts, account recovery
  • Terms and conditions and privacy policy: with direct legal implications in the target market
  • Store metadata: titles, descriptions, and screenshots for the App Store and Google Play

Each content type carries distinct linguistic and technical requirements. Terms and conditions, for instance, require legal review in the target market, not just translation. Store metadata has strict character limits and its own ranking criteria.

File formats and technical workflows

Software localisation works with specific file formats: `.strings` (iOS), `.xml` (Android), `.json`, `.po`/`.pot`, `.xliff`, `.resx` (.NET applications), and others. The extraction, translation, and reintegration of these strings is managed through translation memory (TM) and CAT tools that maintain terminological consistency across product versions.

Companies managing frequent product updates benefit from direct integration between the translation management platform and the code repository, via API or connectors for tools such as Lokalise, Phrase, or Crowdin. This continuous model, known as localisation-in-the-loop, allows new strings to be sent for translation automatically on commit, without interrupting the development cycle.

M21Global's technology and software localisation service supports these native file formats and continuous integration workflows, maintaining terminological consistency across versions and languages.

Terminology management and consistency across versions

One of the biggest sources of friction in localised software is terminological inconsistency. The same concept appears translated three different ways depending on the product version or module. For the user, that creates confusion. For the support team, it creates volume.

The solution is to establish a product glossary before any translation begins. The glossary defines the product's key terms, their equivalents in each language, and usage rules. It should include terms to avoid, regional variants, and decisions about which terms remain untranslated (feature names, brand terms, technical commands).

Localisation projects that do not include translation memory and glossary management as part of the service accumulate terminological debt. Each new product version costs more to localise because there is no reuse of previously approved content.

For applications expanding into Portuguese-speaking African markets such as Angola and Mozambique, adaptation goes beyond terminology: it involves register variation, cultural references, and sometimes local regulatory requirements. The article on mobile app localisation for Angola and Mozambique covers those specifics in detail.

Quality standards and certification in the localisation process

The appropriate quality level depends on the content type and the associated risk. Internal UI strings or large-volume reference content can be handled with faster workflows. Onboarding content, product documentation, and legal texts require an independent review step.

The highest quality level involves three independent linguists: a translator, a reviewer, and a quality assurance reviewer, with dedicated project management. This is the process audited under ISO 17100, which guarantees independence between the person translating and the person reviewing. For SaaS products with extensive technical documentation or a presence in regulated markets, this level is the most appropriate. The article on ISO 17100 localisation for SaaS platforms explains when and how this standard applies to digital products.

How M21Global supports tech companies with localisation

M21Global has worked with technology companies on the localisation of software, mobile applications, and digital platforms for over 20 years. The process includes support for development-native file formats, glossary and translation memory management, and workflows adapted to product release cadences. With ISO 17100:2015 certification from Bureau Veritas and over 300 million words translated, the team has direct experience with products operating across multiple European and Portuguese-speaking African markets. To start localising the product for a new market, request a quote through the M21Global website.

Request a free software localisation quote

Frequently Asked Questions

What is the difference between software translation and localisation?

Translation converts text from one language to another. Localisation adapts the entire product to the target market: date formats, currency, plural forms, text direction, cultural register, and local legal requirements. In software, both are part of the same process.

Which file formats are used in software localisation?

The most common formats are .strings (iOS), .xml (Android), .json, .po/.pot, .xliff, and .resx (.NET). The correct format depends on the platform and development framework in use.

Is ISO 17100 certification required for software localisation?

It is not mandatory in every case, but it is recommended for high-impact content: product documentation, legal texts embedded in the platform, and user onboarding content. For internal UI strings or reference material, lighter workflows are appropriate.

How is terminological consistency maintained across product versions?

Through product glossaries and translation memories managed over time. A glossary defines approved terms in each language and their usage rules. Translation memory reuses previously approved segments from earlier versions, reducing the cost and time of each update.

Does software localisation cover app store metadata?

Yes. App Store and Google Play metadata, including the title, short description, long description, and keywords, should be localised with attention to character limits and the ranking practices specific to each store in the target market.

Need Professional Translation?

Request a free, no-obligation quote for your translation project.

Request Quote