Localising a software product is a painful, time-consuming process. After much thought, I think there is just no simple way. If you ever plan to tackle the process, be prepared to sink a lot of time and effort into it. Then when you’re coming up to the next release, be prepared to go through it all again.
Planning
You can easily plan for localisation. Maybe you have a list of rules or guidelines something like this:
- Externalise all text and images that are visible to the user
- Don’t depend on word order or grammar
- Leave 30% to 50% of the space empty to allow text to grow
- Never perform lossy text encoding conversions
The trouble is, people won’t follow them, and you won’t find out until it’s too late, and the release is slipping. The dialog with barely enough space for the English text, the place where “…file i of n…” is composed by concatenation, the conversion to some ANSI code page for processing, the attempt to pluralise something by adding an “s”…
You must factor in time for dealing with this kind of thing in your release schedule. No set of rules ever works. Fixing things at the end seems to be an inevitability.
Translation
Translation is definitely tricky. Ideally the translator should be fluent in the source language, fluent in the destination languages, familiar with the relevant jargon and familiar with the product being localised. Realistically, this just won’t happen. You might get two out of four, or three out of four if you’re really lucky.
Reviewing translations is a particularly painful process. You might have two hundred translated sentences to review, and there might be less than five bad ones in there, but you still have to check more than a hundred and ninety good ones while finding the bad ones. And bad translations are by no means simple. The fall into a number of categories that are quite different:
- Garbage in, garbage out
- Sometimes you wonder how the original text got into the product at all. If you give your translators garbage to work with, as a general rule, you’ll get garbage back.
- Terminology
- Real-world example: think about the English words “computer”, “machine” and “device”. These words are often interchanged, but there are places where only one will do. The situation is similar in German with “Computer”, “Rechner” and “Geräte”, but you can’t do a one-to-one mapping with the English.
- Lack of context
- A translation may look perfectly good at face value, but actually be useless because of the situation in which the text is used. These aren’t usually the translators’ fault — they often don’t know the product well enough to get these things. Catching these is one of the most important parts of the review process.
- Literal translations
- We all know about this kind of thing. Sometimes the literal meaning is not the intended meaning. This is another thing you often can’t blame the translators for.
- Just plain bad
- Sometimes you get translations that are just obviously wrong. You try, but you can’t understand how they came up with it.
Catching any of this requires a good review process. Of course, the requirements for the reviewer are similar to the requirements for the translators, and such people are hard to find. It’s also rough because you’re usually reviewing the text in some kind of resource file, so you have to use your knowledge of the product and imagination to picture it in context. Not to mention that looking at string tables all day is boring and repetitive, which in itself can lead to slip-ups.
Testing
Once you think it’s all there, you need to test it. This should be done by a native speaker of the destination language, and preferable one who isn’t particularly familiar with the product — you don’t want them to fly on memory and not actually read what they see.
But at the same time, you need the test to provide maximal coverage. Every possible UI, error condition, generated output and log message should be tested, to ensure that they make sense in context.
Is this possible? Maybe, but it isn’t likely to happen. That doesn’t mean you shouldn’t try, though. You want to ship a product the feels “natural”, “comfortable” and “right”.
End users
What happens if you ship a product that isn’t localised perfectly? It depends on the nature of the imperfection.
Something like lossy text encoding kills you. It makes the product useless for all practical purposes. At the other end of the spectrum, a few less-than-perfect translations are probably just going to make people smile.
In the middle of the scale, there are things like text that doesn’t quite fit, and UI elements that aren’t positioned properly. These will make a product feel unprofessional or annoying.
So how long will it take? Is it worth the risk? How big is the potential market? All big questions without simple answers.
