8 software localization issues that could hurt your business, and how to avoid them

What is software localization?

Before diving into the main challenges you will face when localizing your software, let’s understand what it entails exactly.

Software localization is the process of adapting your software to meet the standards of other regions and markets. Beyond simply translating text documents, localizing your software gives you the opportunity to get more precise and cover content that is not limited to plain text. For example, you need to adapt visuals, formats (date, time) and URLs, amongst other factors.

Moreover, your localization team will most likely work hand-in-hand with your development team to understand the limits and requirements of your software.

In a nutshell, software localization is more than speaking your audience’s languages; it’s also making your product relatable and familiar to them on a cultural level.

Software localization issues, consequences, and solutions

Here you are, deep into the localization process of your software. As intimidating as it looks, you will quickly realize that issues that seem unconquerable can often be fixed with small changes. However, not taking care of them can lead to painful consequences for your product globally.

Translating, not localizing

One of the most common pitfalls in software localization is not being able to spot the real difference between translation and localization.

The main consequence of this issue is having content available in multiple languages that falls flat with different audiences. Your potential customers do not necessarily understand the essence of your offer, and are therefore less likely to trust your business. All in all, bad localization can sabotage your image and your brand tone of voice.

When expanding your product, do not think of languages first. Think markets, regions of the world, cultures. That way, you can collaborate with vendors who understand their tasks and what they need to take into consideration when localizing your software. For example, if you get your software localized into Spanish for Spain, and for Mexico, you need two different locales, even though those two countries share the same language; their cultures are not identical.

Embedding text in your code

Professional translators are often not outstanding developers. When creating the code of your software, there is a risk that your development team will “lock” text into the code, and it cannot be extracted later for localization.

The consequences are straightforward: your localization team will take more time to analyze the translatable strings, and they could forget some. The localization process will be less efficient, the delivery dates will be pushed back, the quality might suffer, and you will lose money down the line.

Thankfully, the solution to this problem is quite simple. Ensure that your development team keeps all the text in external files that are later integrated into the code in different languages.

Splitting strings

One of the complexities in localization is that grammar is different for every language. Therefore, when your developers split strings into several keys, forcing a specific sentence structure, it creates inconsistencies across languages.

Because of this practice, your localization team needs to find loopholes to make the sentences work in their language. The issue is that they might make awkward linguistic choices, because they do not have any other choice, since the strings limit how they can handle linguistic challenges.

One simple solution: do not split sentences! Create a string per sentence, and do not assume that all the languages will adapt to the source structure of your product.

Not considering language lengths

When expressing an idea, two languages are not equal. While English can have a verb that describes a very specific action, French might need four or five words to express the same idea. This is called text expansion and contraction.

The problem with this phenomenon is that if your software is designed to fit a specific word count, localization in other languages could break your website or app layout.

 To counter this issue, design your software with expansion and contraction in mind. While French or Italian can typically be 25% longer than English, Chinese and Japanese will usually be shorter. Leave extra space for longer strings to fit, align your labels, or store the dimensions for a label in the files translators will use to localize. You can also set a character restriction for them to respect.

Not considering vertical and horizontal languages

Another key linguistic factor is language direction. Not all languages are read left-to-right. Some are right-to-left. And there are also languages that read vertically. This has a big impact on how the localized content displays on your software.

For example, the same way longer strings might not fit in their sections, a language that is vertical is not going to display correctly on software designed for a horizontal language. This results in content that is impossible to read by your audience because it does not show the correct way. A platform that is hard to understand will drive your potential customers away.

To correct this issue, create specialized versions that adapt to vertical languages and languages that read right-to-left. You can set a language direction in your code. Finally, make sure that the different languages display properly by testing them before the end of the localization process.

Using images with text

Most likely, you need to illustrate your words with images, to make your point clearer and easier to understand. Good idea! However, there is a problem when there is text embedded in your images, because that text is not going to be localized with the rest of your content.

Two scenarios can result from this issue: your localized software has fewer images than the source one, or you show your global audiences images with text they do not understand. Either way, it has a negative impact on your product and how your content is interpreted by your potential customers.

You also have two solutions to that concern: remove the text from images that can still make perfect sense without it. Or you can separate the text from the visual, so you can send it separately to localization, and implement the different languages into the visuals afterward.

Starting localization when everything else is done

Your software is 100% complete, and you want to expand your product to new markets as soon as possible. You decide to start localization only now, as you were working on your original content before.

The problem is that you face all the issues stated above, and more, which pushes back the date when your different locales are ready. It causes stress and could make you compromise on quality to release your software in different languages sooner.

Consider localization before everything else is done. In fact, you will face different challenges that will need adjustments along the way. Tackling the localization process as early as possible helps you anticipate those challenges and prioritize the highest quality.

Not allowing communication between teams

Software localization includes several parties: a project manager, vendors (or an in-house team), graphic designers, and a development team. During the localization process, some parties might have feedback for others. Not permitting them to communicate with each other can cause more harm than good.

On one hand, the vendors might request more context from your other teams to produce the best localization. On the other hand, your other teams would need the professional translators to make some adjustments to improve how the different locales look on your software. If communication is not part of your workflow, you will end up with different languages that lack consistency and quality. Therefore, your target audiences cannot relate to what you offer them.

To fix this, you can ask your project manager to be the person responsible for communicating questions and remarks between teams. You can also ask them to create query sheets, so the different parties can write down their requests and have a history of them. Plus, you can always put the different teams directly in touch via a messaging platform.