Stages of streamlining software localisation

More often than not, software start-ups either want their app to reach as many customers as possible from the get-go or decide to expand and grow in other countries once the product has won popularity in one market. Irrespective of the scenario, however, one thing is certain – at some point, their app will need to be localised.

One of the most common methods employed at the beginning of the venture is converting content files or copying software strings to spreadsheets. In all likelihood, this is done due to the fact that spreadsheets provide an easy environment for editing pieces of content in multiple languages (usually with the use of columns). The process is sometimes handled by internal employees who are native speakers of a given target language and can provide all the necessary translations as an additional task – this, however, is never a good practice, as top-notch localisation demands so much more than just mastery of language (you can read more about this common yet unrecommended procedure here). On top of that, spreadsheets require extremely precise instructions, especially due to the issues with placeholders. On the other hand, you can use spreadsheets to paste screenshots or links to reference materials, which definitely makes linguists’ lives much easier. That being said, it needs to be noted that spreadsheets are only intermediary files and should not be treated as a content management system. Additionally, using spreadsheets for translation often poses a very serious problem. Whether it’s a Microsoft or a Google format, it will never be the native format that the app can use. Conversion or copying is always necessary – and usually time-consuming. To avoid this, we can work directly in the localisation files with software strings, be it JSON, YAML, XML or PHP. These files require employing certain structure, so they are rarely edited by someone unfamiliar with coding.

So what can we do instead? Sending localisation files to a language service provider may be already a significant improvement. A specialised company (usually an experienced and reliable translation agency such as locatheart) is likely to employ a translation management system or computer aided translation tools that allow for filtering out structure elements (string IDs and placeholders) as an inbuilt feature or with the use of regular expressions. Moreover, the LSP, apart from providing a complete translated file in its native format, can offer translation memory management services, thanks to which you don’t necessarily need to extract and submit only the newly added strings. You can simply deliver the entire source file to the LSP whenever it is updated. The LSP will pre-translate the previously completed strings using the translation memory and quote only the new content. The LSP can also, based on its completed work, prepare a glossary of key terms and ensure consistency of future translations, which is next to impossible in the case of spreadsheets.

Now, how to prepare for outsourcing localisation to an external partner? As one can imagine, such a step leaves little control to the product or development teams. Developers will certainly be able to spot the difference whenever a string translation is modified, but there will be no in-house employee to manage the process or assure and assess quality. Companies that have fixed localisation requirements and regular volumes of new content often choose to make localisation management an internal process, having a single, dedicated person or a team (as opposed to the product manager, developer, or anyone who requires translated content) to centralise the localisation needs of the entire company, which can bring additional synergy and savings to the organisation. This person (or a team) will likely need a tool to manage the multilingual content and localisation projects, and to efficiently communicate with the language service provider. You can read more about becoming an internal translation manager here.

When it comes to translation management systems, we can differentiate two types. The first type (which covers such tools as Lokalise, Phrase Strings and Crowdin) is intended purely for software localisation. It includes tools that are usually cost-effective and allow for the management of app content through direct integration with code repositories (sometimes also with design tools). Amongst their drawbacks, however, are few supported file formats (they are usually focused only on formats containing software strings) and the limited choice of vendors. Nevertheless, these tools are continuously evolving, and their limitations may be addressed in time. If a given tool meets the company’s needs (mainly product localisation), it will certainly bring benefits.

The other type of TMS tools (like memoQ, Phrase TMS or XTM Cloud) is more extensive. Since they are not focused just on software localisation, they allow for addressing the needs of multiple departments – and since they are fully vendor-agnostic, they let you select any translation agency or freelancer. To top it off, they also offer much more configuration options when it comes to translation workflows and file filters. Given their merits, it’s definitely worth tracking their development and making use of the newest updates. An independent consulting company, Nimdzi, carries out a yearly market research of such tools, which you can find here.

What about the price? Using a well configured TMS with all necessary integrations or CAT tools can easily result in 30% lower cost of translation in comparison to regular rates per word. We can achieve such savings thanks to pre-translating our content with the use of a machine translation engine (AI or neural) and leveraging previous translations from the translation memory. Moreover, the localisation manager (or the localisation team in the case of higher volumes) ensures adherence to company guidelines (by preparing style guides) and terminological consistency (by maintaining term bases available to linguists in the TMS).

Last but not least, we need to mention various options of providing linguists with references or context. The easiest one is giving them access to screenshots or links to designs within the tool. Alternatively, we can add design or screenshot links as metadata in the files with software strings. The most advanced method is to integrate design with development and make sure that the content is properly formatted as software strings in the design tools.

As presented above, there are multiple ways of localising software. The chosen option, however, should not only be adjusted to the company’s current needs, but also take into account future growth. Implementing temporary or impromptu solutions might be risky and result in significant technical debt or low quality. Professional localisation consultants, such as an internal localisation manager, a solutions architect representing TMS developer and an experienced translation agency, are bound to ensure efficient localisation processes in the long term.

Localisation Manager with over 11 years of experience on both vendor and buyer sides. Skilfully manoeuvres between the areas of business and technology. Has devised and managed localisation processes at such companies as BSH (Bosch Group) or AirHelp. His primary goal has always been helping companies expand internationally to reach new markets and customers.