In summary: Implementing a proper localisation workflow takes time and a lot of care. There are definitely many things to consider and keep in mind. In this article, we will discuss some of the most common localisation issues faced by developers and how to solve them with the help of solid localisation software. By the end of this article, you will learn that a developer should only be involved in setting this process once, and can forget about ongoing content updates later on.
One of the biggest pains for companies, and especially for product managers who own the localisation process, is a lack of developer time. Freeing up dev hours usually involved in product releases to help out with localisation is not easy, especially when developers are typically known to hate everything localisation related. As a result, when it comes to multilingual content, release times are postponed.
Manual processes
The number one pain for any developer is performing routine manual tasks. If you are still using Excel, Word, and the like, for translation purposes and asking developers to copy/paste these translations into the code, don’t be surprised to see them getting frustrated.
An alternative scenario we have seen is when a developer is asked to send a source file to translators. In turn, the linguists make edits directly in this file and send it back. This, however, leads to all kinds of problems, such as:
- It is hard to resolve conflicts and make sure that the same file was not edited by multiple people
- Certain file formats can be quite complex and you cannot expect translators to understand each of them
- It is quite easy to break the file even by adding an extra space or a quotation mark
- If the file is broken, developers will need to spend additional time on finding the problem
- There’s no easy way to make sure that all messages are translated into all languages
Imagine you have five files (one per language), and each file contains five hundred entries. How would you match them and see which keys are missing? In a manual process, this involves many different individuals, thus it’s hard to keep track of the process.
Synchronising translations between TMS and code repository
If you are already using a translation management system, congratulations. You are one step ahead, even though there are still issues that have to be considered. The most common one is making sure that translation files are synchronised properly between the TMS and the code repository hosted on platforms like GitHub or Bitbucket.
How do developers achieve this? Do they export the translations from the code repo to the TMS manually? Do they create pull requests each time translators perform updates? Carrying out these tasks manually is quite a tedious and error-prone process.
Our advice to you is to automate as much as you can. Look for localisation software that provides integrations with popular code hosting services such as GitHub, Bitbucket and GitLab. By employing them, developers can easily import and export translations with just a couple of clicks. This way, tiring back-and-forths are eliminated, as is idle waiting time.
API and webhooks
The next localisation issue developers often experience is the need to download translation files to your software on a regular basis. While this task can be performed manually, it is quite tedious. Apart from that, some developers may need to monitor changes made by translators in the source files: for example, to check which translations were added or updated.
To optimise your localisation process, look for localisation software that allows you to easily download your project strings, either to a single file or by using previously assigned file names. API and webhooks enable you to do so.
API means “application programming interface”. It allows third-party applications to communicate with the given service and manage it by sending properly formed requests. When considering different localisation software options, you should pay attention to how powerful the API is.
For example, Lokalise has a feature-rich API that enables developers to perform all major tasks, including file import and export, translation updates, contributor management, project creation and much more. It’s also possible to create a script for downloading new translations on a regular basis.
As for a webhook, this is a mechanism that sends a request to the specified application once a certain action has taken place. Think about the notifications you’d need to ensure great workflows and a healthy pace of progress. Having custom webhook integration available in your localisation software can be of great use here.
Having proper translation file formats
Translation file formats vary widely depending on the platform and technology. There are formats like JSON, XLIFF, YAML and many others. Developers need an easy way to download translations in different formats for different platforms (say, websites or mobile apps).
Localisation software normally provides a solution to this issue. For example, Lokalise was built with developers in mind and it allows you to assign translation keys to one or more platforms (Web, Android, iOS, and others). This way, devs can control which keys to download for specific formats. For example, if a key is assigned to Web and iOS platforms, it will be exported when choosing JSON and Apple XLIFF formats. However, it won’t become a part of the bundle when choosing Android XML.
To maximize productivity and prevent mix-ups, your chosen localisation software should enable you to assign translation keys to separate files. Moreover, if the key belongs to multiple platforms, you should be able to customise files separately and control which key goes into which file during export.
Think about the export options, too. You need to be able to choose what languages to include in the downloaded bundle, what format to utilise, which keys to include and which ones to skip, what to do with empty translations and more.
Finding duplicate translations
When a team of developers works on the same project, they may end up producing duplicated translations. For example, someone may create a new webpage with a license agreement and add an “OK” button there. To provide translation, one of the developers will also add a key named “license_ok” with an “OK” value. However, another person may also introduce a different translation key, “accept”, with the same “OK” value.
This means that this value has to be translated twice which is not ideal. Moreover, there can be multiple translation files for different platforms that have the same translation values but different key names. This may result in a total mess really quickly.
The solution to this? A duplicate finder feature in your chosen localisation software. Using this finder, developers should be able to detect all the duplicated translations and decide what to do about them:
- Delete completely
- Hide for all non-admins (perhaps, to decide later)
- Merge all duplicate translations into a single key
- Create a so-called “parent” translation key and link all duplicates to it (when the parent translation is updated, all the linked keys are updated as well)
This useful feature helps you avoid translating duplicate strings over and over.
Version control
Developers love version control systems like Git. The open-source version control system has a host of features and, most importantly, it allows developers to work on specific parts of a project in parallel without affecting the base version or interfering with each other.
When a feature is finalised, the branch can be merged with the base project version (called master or main). After merging, the master version contains both previous changes and the changes taken from the other branch. Any conflicts found during the merging process can be easily tracked and resolved. For example, if the same line was modified in both branches, the dev will be able to decide what changes to keep.
When choosing your localisation software, make sure to assess how it supports version control. Ideally, it should be possible to create as many branches inside the project as required and switch between them in just two clicks. By using this feature, different translators can work on different areas of projects with ease.
Placeholders and plural keys
Another common localisation issue is the proper use of placeholders. Placeholders allow devs to insert dynamic values right into the translations (for instance, to greet a currently logged in user). The thing is, different formats require different placeholders. If the same translations are utilized for multiple platforms, that may become an issue as developers will have to somehow adapt placeholders manually for each case.
This problem can be solved if the localisation software provides an option to use universal placeholders.
So, how do universal placeholders work? With this feature enabled, all platform-specific placeholders get replaced with universal ones during the translation file upload. The real magic happens when translations are downloaded for the specific platform. During export, the universal placeholders get automatically replaced with the platform-specific ones! This means that the same translations can be utilised on multiple platforms without worrying about the placeholders.
Another problem with placeholders is that some translators tend to edit them, thinking that they have to be translated. This is actually not the case: they need to be left intact. Editing their placeholders can make devs pretty furious.
Here’s how Lokalise provides a simple fix for this issue. Placeholders are displayed as blocks in the graphical editor, enabling translators to visually differentiate regular text and “system” elements which have to be left as is.
Placeholders are not the only thing that is platform-specific: unfortunately, plural keys have very different formatting rules as well. Moreover, different languages have different plural forms. For example, in English, there are two plural forms, whereas in Russian there are four. No one can possibly know all these specifics for every language on Earth. This is why you need software to help out.
It should allow you to automatically export plural keys in the proper formats and have built-in support for virtually all existing languages, including their plural forms.
Previewing translations at the design stage
This localisation issue affects both developers and designers. Both groups need to work together to ensure that translations for different languages fit properly within the design. This is very important because certain phrases in some languages may become significantly longer or shorter, thus breaking the layout.
To overcome this problem, make sure to check if the localisation software you’re considering has vital integrations such as Adobe XD and Figma. These integrations streamline the translation process and start localisation at the design stage. Here’s a simplified overview of the process:
- Developer or designer opens the project in Figma and chooses text elements to upload to the localisation software
- Translators take care of the uploaded texts as usual
- Once the design language is switched, the corresponding translations are downloaded automatically
As you can see, design integrations enable you to exchange design content, translations and screenshots. You can speed up your workflow and preview results almost immediately.
Providing context
The last localisation issue is providing context to translators, who need it in order to deliver quality results. They need to understand the specifics of the app, where and how the given texts are utilized, what their purposes and functions are and so on. Your localisation software should enable this, so make sure that developers have the option to add information about the translation keys.
Here’s how we at Lokalise approached this. Key comments and a built-in chat function are the features that enable users to understand context and stay in the loop. Adding key comments is simple and requires just a couple of clicks. Translators can then read them and ask additional questions in the project chat.
In addition, devs and designers can upload screenshots and link them to translation keys, and offer additional convenient features such as automatic key detection. This feature tries to recognise the text on an uploaded image and link these portions of text to existing keys. As the old saying goes: a picture is worth a thousand words. Therefore, showing how and where exactly the text is to be displayed comes in handy.
To provide additional context, developers should be able to set up a web in-context editor. With this editor, translators can manage texts directly on the webpage; far better than squinting their eyes at spreadsheets.
Check all relevant boxes for your localisation software
As you can see from what has been discussed above, the list of localisation pains for developers is quite lengthy. Solving these issues will not only enable developers to get back to their main tasks, but it will also positively impact the speed of release cycles. When you enable developers to set up a process once and just forget about it, it leads to better productivity across different teams, faster time to market, and cost optimisation.
This is exactly the kind of environment we created in Lokalise.
Lokalise is localisation software that aims to eliminate the hassle of localisation by providing tools to automate, integrate and better manage your translations. Moreover, this software was created by developers, for developers. If you’re curious to find out more about how it can help your localisation process, try it for free. See it in action, no credit card required.
