Nowadays, software localisation seems to be the rule rather than the exception – or at least preparing for it should be. There aren’t many software developers who can say with any degree of certainty at the start of development that all of their future users will be from the same place and speak the same language. I’m not talking about every little piece of code written for internal use, you understand, even though they can also occasionally turn into something entirely unexpected. So, getting ready for software localisation can be a smart move even if there is no pressing need for it right now.
I noticed first hand an awareness of localisation and a willingness to do it when I attended Slush several times in a row a few years back. I attended Slush for the first time in 2011. At that time, the event was something quite different from its current incarnation. During those first visits, start-up founders and developers were talking about localisation as something that might become topical someday in the future. Fast forward a couple of years and localisation was something that had been frequently considered. A few more years further down the line and clear localisation plans were starting to emerge. Many companies had even set out on that path right at the start of their journey. For me, this is a direct result of a large number of companies targeting rapid growth by training their sights on international markets from the outset, otherwise they quickly discover the limits of their capacity for growth. It goes without saying that the same applies to established operators and the development departments of large corporations.
Here, I’m not going to offer detailed internationalisation instructions. For example Microsoft and Apple have more technical and detailed guides on that. Instead, I’m going to highlight a few issues you should pay attention to in your application’s coding or texts as these issues are something I have often encountered during the localisation stage. Good preparation equals less time and money spent on software localisation – and it makes the work much less stressful for developers and translators.
1. Don’t truncate text
Truncated text commonly occurs when there is a placeholder in the middle of text which will be replaced by, for example, text or a number when the software is run. The start of the sentence can then appear as a separate entity from the end of the sentence, and the placeholder may not even be visible to the translator. This usually leads to poor translations because the translator may not see which parts of the sentence belong together or know the value of the placeholder.
It’s better to write UI text in such a way that the placeholder is located in the middle of the text to make it easier for the translator to understand the context and modify the sentence structure according to their native language.
For example, it’s better to keep the sentence “Please click %2 and then continue to selection” as it is, without dividing it into three sections (“Please click”, %2 and “and then continue to selection”).
Take it from me, translation quality will be better and you won’t have to reply to unnecessary questions from translators.
2. Use consistent terminology
UI texts are meant to make life as easy as possible for users. One way to achieve this is to always use the same terminology. This means the user doesn’t need to guess what you’re talking about. It also improves the quality and consistency of translations, making the UX better for all different language users.
3. Recirculate the same texts and structures whenever possible
Similar structures improve the user experience. By always using consistent structures and the same text when referring to a functionality, you don’t, so to speak, muddy the waters for users. As an added bonus, translations will cost less because the previous translations are available for reference.
4. Be concise
The benefits of writing concisely should be fairly self-evident. Usually, there’s not enough screen space for unnecessary babble and you want to avoid wasting users’ time. A concise source text is also good for translations as they may be longer than the original simply due to grammatical differences between languages. As an example, a good rule of thumb is that texts translated from, say, English to German become roughly 30% longer. Also, you shouldn’t forget about the cost effect here either: concise text means less text to localise, which equals lower costs.
5. Have a native speaker review the text
The majority of UI text is written in English, a language most of us can speak and write relatively well. That said, there is quite a significant difference between being fluent in a foreign language and speaking it as your native tongue. A foreign language-speaker may adopt structures from their own language, use limited vocabulary, etc.
What’s more, it’s always a good idea to let someone review your text even if you’re writing in your native language. Even small mistakes can snowball into big issues at the translation stage with the mistake being subsequently repeated in several different languages.
6. Don’t hard code
This point is probably already well understood, but since it’s so important, it’s worth repeating once more for effect: don’t hard code text – ever (if you know of a scenario where hard coding pays off, please let me know and I’ll make a note of it). It is very rare you encounter this issue in localisation anymore.
7. Separate text from images
Whenever possible, captions should be in text format. It makes them easier to translate and place back in the image. Of course, you can’t always help it. Images can sometimes include text in image format, which also needs to be translated, but the least you can do is keep these occurrences as few as possible. Translating text embedded in an image is more expensive than translating separate text.
8. Pay attention to time, date and address formats
Although not usually a problem in translation, this may annoy and confuse users. If feasible, provide the user with the option to enter their address in the local format and select the time and date format. If you don’t know how addresses are formatted in a particular place, let us help you.
9. Provide context
Often, translators view the text they’re translating in a table and not an app or website. (Naturally, this depends on the process.) For this reason, it’s important to provide them with as much information as possible about where the text will be displayed, what it does and what surrounds it. For a translator, screenshots and descriptions are worth their weight in gold because they will save them a lot of confusion. It will also save you a lot of time responding to questions!
+1 bonus tip
Don’t worry about exporting your translation materials into Excel sheets or Word documents – at least, not for our sake. We can handle all of your resource files.
All of these tips will make software localisation smoother and increase the chances of accurate and flowing translations.
We also have software localisation support services, such as proofreading, and we can also analyse in advance how easily your text materials can be localised. We can provide you with translations in all the languages you require. Working together, we can also choose the process most suitable for your update and translation cycle, including large-scale automation for your continuous localisation needs or a lighter and more traditional option if your software is not updated on a regular basis.
