Share on twitter
Share on linkedin
Share on facebook

Software Localisation – Why It’s Important For Your Business

Software is a living entity – it keeps on growing and improving with time. We know this better today in the age of smartphone applications which are updated almost on a daily basis. Software often competes with each other by offering better interface design, features, and performance – parameters that always have a scope for improvement. One of these defining parameters is the software’s suitability for a particular locale. Developers usually address this as Software Localisation.

Here’s the definition by the W3C community:

Localisation refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale).

As every business today has varying levels of dependability on the Internet and computer software, it has become increasingly critical to address localisation needs.

It is a challenging task, but it must be done. Take the example of China; according to Gartner, foreign enterprises are often not able to perform well in China because of their inability to localise well:

By 2019, two-thirds of data centre IT infrastructure spending in China will be obtained by local Chinese vendors, according to Gartner, Inc.

One of the reasons, as quoted by the Gartner analyst, is

Chinese enterprises often require more localisation and customisation than global vendors can usually offer.

The Localisation challenge in China is a steep one. The language is written vertically and has most words with only one or two characters. This means that the language is more verbose than English or any other western language. That is why Chinese people are able to cram in five times more information using a 140 characters post on Weibo (Twitter’s Chinese equivalent) than people can with a 140 character tweet in English.

Software localisation gets increasingly complex with scale. For content authors and owners handling enterprise content management processes, meeting market expansion needs and cultural sensitivities is a huge undertaking. In addition to language translation, it can involve the conversion of measures (weight, temperature, etc.), date formats (MMDDYYYY, DDMMYYYY), and currencies to suit a region better.

Internationalisation – First Step to Localisation


Internationalisation is the design and development of a product, application or document content that enables easy localisation for target audiences that vary in culture, region, or language… Internationalisation is often written i18n, where 18 is the number of letters between i and n in the English word.


This means developers should write the code following certain processes, making it easily possible for the software to be adapted to various languages and regions. In theory, it’s a one-time process; however, in the real world, where incremental changes are often made by different vendors at different points of time, internationalisation has to be done in different stages.

It is important to understand that for developers it’s not always easy to foresee changes in the future.

For example, a button in an application labelled as “Copy” has to be labelled as “Kopieren” in German. Similarly, “Restore” becomes “Wiederherstellen”. This can affect readability at times.

This means developers need to plan for text in other languages making an interface that allows room for expansion and compression when the translation occurs. Programming dynamic UI expansion into the software is recommended for this purpose. Both Android and iOS application frameworks offer features for dynamic UI expansion. Furthermore, in languages such as Urdu, the text is read from right-to-left (RTL). This means that the software design needs to support RTL scripts.

Internationalisation also requires:

  1. Enabling the use of Unicode – Unicode/UTF-8 is recommended practice unless dealing with Asian languages that require UTF-16.
  2. Avoiding Concatenation of Strings – Developers sometimes concatenate two or more strings to save space. This can easily result in translation errors in the localisation process.
  3. Avoiding hard-coded strings – All user-visible strings must be externalised appropriately.
  4. Support for features that aren’t used until localisation – Developers might have to add markup in their DTD to support bidirectional text or provide CSS support for vertical text.
  5. Support for local, regional, language, or cultural preferences – Examples – Local calendars, date and time formats, measures, etc. Typically this can be achieved by attaching predefined localisation data from existing libraries or user preferences.
  6. Separation of source code/content from localisable elements

Important Considerations in Software Localisation

  1. Localisation of UI elements (messages, menus, tooltips, etc.)
  2. Information Architecture & Workflows

There are broadly two major areas of focus in Localisation:

The entire process usually includes the translation of products (software, manuals), and to the programmer and translator environments (tools, community, etc.)

Creating an Infrastructure and Building a Collaborative Team

Building a Collaborative Team

In large-scale projects, the responsibility for translation can be shared among the team members and volunteers. Usually, Localisation in large-scale projects is managed by Project Managers, followed by dedicated generic Translators, Localisation Translation Specialists, Terminologists, Internationalisation Engineers, Editors/Proofreaders, QA and testing team and Multilingual Desktop Publishing Specialists.

Naturally, for efficient management of such collaborative localisation efforts dedicated tools and infrastructure is required.

Using computer-assisted Translation Software can speed up the process, though it should be noted that such systems are not full proof. However, certain features for spell checks, grammar checks, terminology management, and translation memory management are very useful for translators.

Planning for Localisation

As discussed, internationalisation and localisation cannot be an afterthought, and they need advance planning from the very beginning. This planning should cover:

Planning for Localization

After identifying the scope for localisation, the next step is to identify the Localisation source. This is the actual text the translators will work upon. Usually, translators are given special translation files that are merged back into the code with an online translation system that relies on a database. In certain cases, translators may have to edit the computer code.

These days single-source publishing is in the trend where both authors and translators work on one kind of text, which could be a shared word document, a wiki page or XML-based document. Commonly used Google translator toolkit provides an alternate approach where original portions of the source and target text are shown simultaneously in two separate windows.

Coming down to the best practices for translation, often it’s recommended to aim for  “good enough” translations rather than 100% translation. It might be okay to let users deal with untranslated English than cope with arcane translations that create ambiguity and confusion. Hence, translators need to prioritise their work with the translation of the most critical and often used messages. Further, several rounds of quality checks might be required to ensure that the software translation is good to go.

Terminology Management

There are certain critical terms in software that need to be defined precisely the same way in every language. No ambiguity should arise when the localisation occurs. Terminology management addresses this need with a glossary of terms. Special tools such as terminology management systems store terms and their translations, so translators can refer to them and ensure consistency.

Localisation Review

The aim of the review should be to ensure that the translation provides intended results while preserving the context. This can ideally be achieved by simply testing the software and all its features. If not possible, certain test cases could be run for random quality checks. For incremental improvements in large projects, user feedback is often most useful. An example is Microsoft Help documentation, where every article ends with questions seeking user’s feedback on the quality of the article.

Nonetheless, setting up these procedures, with the right tools is often a huge undertaking for enterprises, and they prefer hiring a professional translation services provider. In the second part of this article, we will understand how businesses can benefit from translation services.

comment-text Leave a Comment

Similar Articles