06/05/2022

Software localisation

The localisation of software products is a complex process with individual specific characteristics and requirements. It requires highly specialised knowledge and corresponding processes. Localisation tools can provide substation support for this by facilitating workflows, reducing effort and increasing precision. We show the possibilities and tool variants.

In full: software localisation refers to the transfer and adaptation of software products to the local linguistic and cultural conditions in a specific sales or usage area. Translation is a sub-activity in this context. Localisation projects also include tasks such as project management, software engineering, testing and desktop publishing. Putting this into practice requires highly specialised knowledge and corresponding processes.

When translating and localising software products, protecting the underlying code is crucial to create a functional product. Since essential components are repeated or retained in further development and do not need to be re-translated, it is therefore wise to use technical tools that support this and contribute to maximum precision.

However, while a large number of file formats can be translated optimally with the help of common translation memory systems, there are limits when it comes to translating and localising software products.
There are special localisation tools for these particular use cases: programmes that support the user in software localisation. The basic steps required include the extraction of the texts from the software (source file), editing of the texts by the translator and the creation of a localised version (target file). When a new version of the source file has been developed, the localisation tool recognises the newly added texts so that only these need to be translated.

Examples of tools are Passolo from RWS, Alchemy Catalyst plus online platforms such as Phrase or Lokalise.

The localisation tools listed generally offer similar functions to normal translation memory systems, but go a step further. One of the most important enhancements is the WYSIWYG editor with the option for real-time preview and editing of the software interfaces. Translators are thus able to see their translations directly in context – “WYSIWYG” stands for “what you see is what you get” – and to amend them if a string is too long or another translation would be more suitable in the context.

Often, existing translation memory systems and terminology databases can also be integrated so that the translators can access data that has already been stored. Likewise, machine translation can also be integrated.

There are also some differences when it comes to quality control, because more emphasis is placed on checking software-specific issues like length checks, tags/placeholders or overlaps. Depending on the tool, however, other test criteria such as terminology, spelling, punctuation etc. fall by the wayside.

Furthermore, there are other advantages that are also weighted differently or differ from one another depending on the tool. For example, some tools allow translators to make visible comments from within the software. (Example of use: if the term “user” is highlighted and the comment “singular” is added, the translator knows that user must be translated in the singular) Other tools, on the other hand, allow for easy management of localisation projects, also with regard to agile development and short update cycles. In varying degrees, all localisation tools also offer a variety of supported file formats and interfaces or integrations.

The variability shows that there is no one right or best localisation tool – and not every tool is suitable for every specific need.

In many cases, hybrids also lend themselves to meeting a specific combination of requirements and, above all, ensuring the optimum quality of the translations.
For example, managing projects on the client side can be beneficial because it allows for easy synchronisation with updates and translatable exports, where normal workflows and TMS would tend to freeze development.
The client may already have such a localisation tool that can be used and integrated into the individual workflow.

In other configurations, depending on the tool, translation in a “normal” translation memory system is also a good option, because this allows easy access to existing resources (translation memory, terminology) and translation checking works better.

Another possibility would be to simply transfer the checks to an external tool such as Xbench or Verifika, although there are also localisation tools that allow the connection or integration of such external tools.

Ultimately, it comes down to knowing individual priorities and specific requirements and then aligning everything optimally with them. For this reason, it is advisable to check the prerequisites before starting a localisation project and integrating the corresponding tools, and to set up a customised workflow with the language service provider you trust, who has proven itself in practice, and to test it thoroughly in advance.

Do you develop and distribute multilingual software products? Then talk to us. Our localisation experts will be happy to advise you on measures, options and optimal workflows, including the use of localisation tools.