We know that localization of software and mobile applications is extremely important if you want to expand to new international markets. Now let’s talk about the most common software localization mistakes.
1. Thinking You Won’t Need to Localize Your Software
The most important thing for any software developer who MAY (or may NOT) decide to localize their software is to prepare the newly developed application for internationalization from the very beginning.
This includes developing with a dedicated language resource file. That means that whatever text (or “strings”) the users see in the user interface comes not from the code but rather from the resource file. That way all of the text will be in one file or set of files whenever you decide to expand internationally.
You will be able to take this language file, easily replace it with the file for another language, and voilà! It’s translated.
If you don’t build your application with a resource file, you may need to find strings in your code and then copy and paste translations.
Whenever manual copy and paste is required for localization, the element of human error is maximized. There are bound to be mistakes.
So rather than develop for English only, follow best practices and develop with the potential of a future software localization project in mind—just in case.
Translate Structured Authoring Content Into Other Languages
Effectively localizing structured content for elearning materials or user guides in the DITA XML format can be tricky. Let a DITA XML Localization Company with decades of technical documentation translation experience guide you.
Let us translate your DITA content
And whenever (or if) you decide to go ahead and localize your software, you will be able to do that more easily because no software development changes will be needed.
Further, the chances of your code being corrupted by translators is minimized. The people who work on localization of your software, will work with only specific language files, not your code.
2. Thinking All Language Structures Are the Same
All the text in any software app is broken into strings, and these strings may include all sorts of things, such as numbers, percentages, special characters, and—obviously—text. Developers tend to break strings down into smaller entities that are easier to handle for them —but almost impossible to handle for translators.
For example, developers may take a string:
And break it into two strings like this:
That way they can replace the percentage on the fly. It may say “15%” off one day and then “20% off” another day depending on requirements.
However, imagine how many options a translator has when they see the word “off” without context? And of course this “15%” part will be in a variable which the poor translator cannot see. So is it off like “take off” or off like “percent off” or off like “knock off” or off like “turn off”?
And even if they know the meaning of this specific “off,” the problem is that in many languages the word should go BEFORE the percentage variable, i.e. in Russian it should read:
That means that after the software is translated, it will read “15% Скидка,” which is ungrammatical.
DITA content presents special grammar challenges during localization. Learn how to avoid creating grammar errors when compiling multilingual DITA content:
How to Translate DITA Projects [Step-by-Step Guide]
The same goes for adjectives and nouns. In English our grammatical order is adjective-noun whereas in Spanish it is noun-adjective. If the developers have the strings separated as “red” and “Volvo,” for example, rather than “red Volvo,” then the Spanish version will say “rojo Volvo.” That’s nonsense.
Further, many languages need different forms of nouns that accompany numbers so you may need different strings to go with the numbers 1, 2 or 3, or 4 and anything over 5. This should also be prepared in advance so that the translators don’t need to come up with unnatural universal structures—which are not always possible.
Translators are not always happy about decisions developers make to assemble sentences in the code using short strings. . . and neither are end users.
Long all-inclusive strings (like “15% off” rather than broken down strings like “15%” and “off”) are much better. They help ensure that localization will work in the future—even for Chinese or Japanese, which are obviously very different from European languages.
3. Thinking That Google Translate Is Enough
Google Translate is named Google Translate for a reason, right? It should be able to translate, right?
Well, as someone working in translation and localization for decades now, am I scared and thinking of mastering some alternative career now that Google Translate is here and will take my job?
Translation and localization still remains a viable career for years to come. Machine translation does not perform as flawlessly as many expect. This deserves a separate post so I won’t go into details here, but you can read more about machine translation elsewhere on our blog.
If you frequent Facebook groups for professional translators where people post hilarious examples of machine translation—you will quickly see why all these people are still in translation and software localization business and why you should prefer to pay these people instead of relying on free—but unreliable—Google Translate.
For some cringe-worthy examples of bad translations, some compliments of machine translation, see our article 16 Hilarious Translation Mistakes
4. Thinking Anyone Who Knows a Foreign Language Will Be Able to Localize Your Software
Your brother-in-law learned some Italian at school and is out of a job now? You think he will be able to handle localization of your mobile app to Italian since he has nothing better to do?
Chances are it will end in a disaster and you will end up destroying your relationship with not only your brother-in-law, but also your Italian-speaking users. Sometimes, in fact, no translation is better than poor translation.
People who work in localization for years tend to know numerous specifics and industry standards. They know how to handle variables and units of measure. They know what gender-neutral translation is and how your potential users expect to have various common user interface elements translated. Your friends or family probably don’t have this background—and the fact that they will cost less or nothing at all won’t make their results any better.
As we like to say, if you think good translations are expensive, just wait ‘til you see your long-term costs for getting lousy translations!
5. Hiring Freelancers to Cut Costs
When you finally make a decision to localize your software properly, you may want to cut costs slightly and hire a bunch of freelance translators to do it.
There are great freelance translators out there. Many of them. There are dedicated websites where you can easily find them all and choose the best ones to work with. But—there’s definitely a “but”—the best freelancers may not be available because they already have plenty on their hands.
It’s not impossible to find excellent freelance people, but it will take tons of time and effort. You will receive hundreds (if not thousands) of applications from all sorts of people with all sorts of per-word rates, and you will be amazed how different the rates are. You may be tempted to choose the cheapest ones but will soon realize they may not be the best ones.
Or you may even think that paying the highest rates is still better than paying a full-service translation agency—language service provider—and so you choose the expensive translators.
But you will soon realize that hiring and managing a group of freelance translators may turn into a full-time job for you. As you look at the profiles you wonder: is the profile actually legitimate? Or did he or she just copy the profile text from another translator? Now you are going to be calling up their references at agencies around the world to ask about quality of work.
Once you choose freelancers and start the project, you will find all your time goes to answering translator questions, dealing with unreadable files, and stressing out when a translator has a personal emergency that will lead to broken deadlines.
Read more: 5 Reasons You Should Work with an LSP
So stay tuned as in the next post we will discuss how to localize software and mobile apps right from the very beginning.
Software Localization Series
This is part 2 of our software localization series. See the other parts below.
- Software Localization—Don’t Make This Fatal Error
- 5 Software Localization Mistakes That You Don’t Want to Make
- Software Localization—How to Make It Work
- What Is Localization Testing and LQA in Software Localization? [Don’t Skip It]
- Tips on Localizing an iOS App for Global Success