In the early 2000s, web localization became as popular as software localization with the growth of the internet and the need for businesses to have a presence on the web for being able to compete in a global market. However, recent technological developments blurred the lines between these translation modalities, particularly with advance software functionalities, the move to the cloud in the form of Software as Service (SaaS), and the birth of apps and widgets.

Despite this ever-evolving industry, we still find some common mistakes when it comes to localising software. Establishing an adequate and professional workflow from an early stage, plus finding the right localisation partner, will help to avoid the following mistakes in future projects.

The best practice in terms of software localization would be to prepare for internationalization well before the development of that software starts.

However, the reality is often different, and some companies decide to expand to new markets after the product is fully developed. Some of the basics not to fall on these practices would be to:

• Perform an analysis of your international strategy, your locale needs and legislation, and involve a localisation team from an early stage to decide on your best Translation Management System (TMS)
• Identify a locale instead of a language and take culture into consideration: use language and region designators. It is important to remember that a locale takes into consideration the language, culture and political region, and is usually identified by a four-digit code. For example, zh-CN refers to Simplified Chinese used in mainland China, while zh-TW would be the variant of the same language used mostly in Taiwan (Traditional Chinese).
• Make sure that your user interfaces have enough space as to fit languages that are longer than the source language, languages like Russian can expand by up to 40%, and that they are culturally appropriate. For example, the images, icons and symbols that are adequate for and English US locale might not be the same as for a Japanese one
• Separate the text strings from the code, so the translators and localisation team do not change anything and cause functionality issues
• Use standard formats both for the development side of things, encoding between languages (UTF-8) and for the integration with the localisation process. If you are working in a customised environment, check with your translation partner how can you integrate it with their localisation tools

In this type of translations, if we separate the text from everything else as we mentioned before, there is the risk that translators and localisers find themselves with no context at all unless screenshots, a working environment with a preview function, or any other context are provided to them. This can cause:

• Translated segments being longer than source texts and not fitting in the space allocated for them, especially in cases such as German or Spanish
• Strings that include placeholders or/and code, and cannot be translated when the target market requires a specific treatment in terms of number, gender, declination. For example, if you want to localise a personal software into Spanish, you will have to take into consideration that there is a gender mark (masculine or feminine), so if we want to say Welcome, in Spanish you would have to decide between Bienvenido (masculine) or Bienvenida (feminine). What usually happens in the end is that localisers would try to find a way around and go for a more neutral solution to avoid this type of issues during the final QA phase, and use Hola (hello!) in Spanish instead of Welcome.
• Mistranslations
• Problems during the software QA and testing phase that will delay the process

A lack of context is incredibly common for software localization projects. If you need help devising a workflow to increase the success of your multilingual programs, then please get in touch.

The third common mistake that is shared with other localisation modalities is the inconsistencies between the software and all the related collaterals, usually because of any of the below reasons (among many others):

1. Software has not been prepared properly for internationalization and the decisions in terms of languages or translated materials have been made later after developing or launching the project
2. A proper localisation workflow has not been put in place and therefore no translation memories, style guides, glossaries and designated team of translators have been used
3. The linguists have not been provided with enough reference material

Best practice guidance on how to translate help functions can be found here.

For example, we are often provided with MS Excel files that simply list the translatable content of the strings, instead of the full resource files (.resx).

As mentioned above, this can be due to a lack of automation and internationalisation strategy and would imply manual work returning the translations to the software environment as well as in different stages of the process.

Organisations new to localisation often believe this is an efficient way to localise content, but in reality, it creates more work for them in the long run. It can also result in further errors and mistakes during translation.

In relation to my last point about not have the original resource files, not having a professional and tailored testing process can lead to a final result that contains any kind of linguistic, cosmetic and functionality issues. A well prepared QA process for software localisation should be documented in testing scripts, and must include:

• Functionality testing: Basic functionality tests will make sure that hot keys are working, hyperlinks function properly, and other specific fields are correct (such as lists or validation of fields such as postcodes)
• Cosmetic testing: This type of QA will ensure that the appearance of the final product is visually correct and that images are consistent with the text, of good quality, and the final design is the one desired.
• Linguistic QA of the final product: Being able to do a final check of the translation in context will spot untranslated segments, segments in other languages, encoding errors, incorrect syntax, incongruent text/image, and formatting/layout issues, among any others.

Here’s a helpful infographic we have created around software testing services.

We highly recommend the creation of testing scripts for all your software as this ensures consistency when launching new programs or updating systems. Test scripts created for your home market are a great place to start as they allow your localised versions to be tested in exactly the same way.

If you do not have any testing scripts, then your language service provider will be able to help you pull something which can be adapted and added to during the initial testing phase.

I hope that you have found this guide helpful in understanding the common mistakes that arise during software localization projects.

If you are embarking on your first localisation project – or want to revisit your current workflow – then get in touch with our team. We are highly experienced in software localization and have the internal and external resources to build a tailored approach to fulfil your GILT requirements.