Software Localization Requires Getting the Words Right
This is the second installment of our in-depth series about the software localization process. Last week we looked at some steps of the initial steps in the process, such as identifying your target languages and project specs, how to plan for updates, and why translating your software is important. In the middle of a large project, one of my colleagues once had a client ask her, “Why is this taking so long? You already have the text in English, don’t you just convert it to Chinese real quick?” A lot of people have this kind of Google-Translate mindset where they assume every word in English has a single equivalent word in other languages, with the exact same meaning and nuance.
You plug the source word into the linguist machine and it spits out the target word. What could possibly go wrong? The problem is that source-in, target-out translation is like buying a plug converter at the airport, plugging your hairdryer into the higher-voltage outlet in your Italian hotel, and nearly catching your hair on fire. Just think how many synonyms there are for each word, each with slightly different shades of meaning. When it comes to translation, these tiny differences can make or break your localized software products. Fortunately, there are several ways of ensuring you’re saying exactly what you mean in your target languages, so your software is user-friendly in every market.
Terminology in Software Localization
If your software is highly specialized, it might have obscure twelve-letter words that have really specific definitions. Or, if you’ve previously released the English version of your software to foreign markets, there might be some existing terminology that your team or your customers have already been using to talk about your product. Because there are so many (correct) ways to translate any given term, it’s important that any existing terminology resources be made available to your translation team. This helps avoid misunderstandings and inconsistencies, and preserves any preferences that your clients or customers might have.
When we start a new software translation project, we encourage clients with specialized products to help us create a termbase. This process involves selecting key terms, translating those terms, and then having them approved by the client team. Once the termbase is complete, our linguists use the preferred terminology in future translations and update the glossary along the way. Establishing the termbase up front shows the linguists which terms are important to your product, and helps save time later on in the process by avoiding last-minute terminology changes.
Consistency Throughout the Software Localization Process
The terminology management process helps ensure that the same terminology is used consistently throughout your translations. But what about consistency across all other materials? Most languages have standard UI translations for a lot of the basics—setup, home, file, etc.—which good software localization linguists reference frequently. Any marketing material, translated documentation, or other translated applications you might have are also important reference materials for translators. Whether we use existing materials to add to the term base or translation memory, or simply reference them for style, these resources always improve the overall quality of your translations.
Do You Mean View or View? Context in Software Localization
One of the biggest challenges of translating software strings is that they’re often . . . stringy. As opposed to documentation, which usually uses full sentences with context clues and clear grammar, software strings can be a bit cryptic and lacking in context. Consider the string “View”. Without any context, this could either be the button you press to change display options in your software, or it could be the button you press to display a new message. These two situations would require a different translation in most languages, because it’s the difference between a noun and a verb.
English is fun because we have a lot of words that could mean more than one thing, whether as different parts of speech or different tenses: read/read, change/change, insert/insert. To make sure everything is translated for the right context, it’s helpful to translators if they have reference materials. This might be access to the English application, screenshots, or a demo/overview of the software. It’s also possible to include context information in string labels as part of your file format.
Keep Your End Goal in Mind
The goal of localizing your software is to make it accessible to your target market. Inconsistencies, unfamiliar or imprecise terminology, or faulty translations for the context can all cause issues in the understandability and usability of your software. These are all aspects you can consider before translation, but even if you cover all your bases during translation, you’ll still have to take one more catch-all, fix-all step before your software is perfect and ready to take on the world. Next week I’ll talk about software validation and testing. In our Intro to the series, we give a general overview of the series. In Part 1 we discussed target markets, project specs, and update models.