Reference materials are essential
This is what makes software translation projects so unique—they simply cannot be translated properly without reference materials showing the context or clarifying the meaning of all ambiguous words and phrases. These can be screenshots, a user manual for the software being translated, notes from developers, and so on. If a client did not provide any materials of this kind, the translator should make it clear that without reference materials, quality will inevitably decrease.
Having reference materials is one thing, but using them is quite another. Translators must commit to finding each word or phrase in these reference materials, so that they see the context at all times. Without this commitment, reference materials are useless.
Translators should clarify all ambiguous words and phrases with their client by compiling and sending a query, ideally as early as possible before delivery. Ambiguity is an integral part of localization projects, which makes it crucial to confirm everything that is unclear with the client. Working based on assumptions is setting yourself up for failure. Guessing is bad with every type of translation, but with software localization, it is twice as bad.
This example is taken from the post about the Russian localization of Adobe Reader 9. Does it mean “To open settings” or “Settings for opening files”?
Accuracy is often more important than style
It is imperative to translate software accurately. While a literal translation is not ideal in general, it is more or less okay in software localization. Being faithful to the original is more important than style, because tampering with style can change the meaning dramatically. You might not like a phrase, because it sounds too vague or too technical to you, but that’s the way software is often designed to be. Do not omit words to make a phrase sound better. Tautology might be okay, although common sense should prevail, of course. If you can improve style without sacrificing accuracy and consistency, do so by all means.
“Control Bracketed Test Calibrator Scheduling”
“Maintenance Window Log Tab”
The original in this example is difficult to read, but “fixing” it is not necessarily a translator’s job.
Use common terminology
Since so many programs have been localized, chances are there is already a good translation of most terms in any project. Your job as a translator is to find and re-use those existing translations, as long as they are valid and/or come from an authority such as Microsoft, HP, Cisco, etc. It is quite difficult to find a better translation than a dedicated team of linguists at Microsoft did. Plus, you are making things easier for users, who will identify with familiar terms more easily than with something that you made up on the fly.
And do not forget to use the Microsoft style guide, too.
Subject matter knowledge is crucial
Do not accept a localization project, if you are not comfortable with the subject matter. Localization requires a unique skill set: understanding the subject matter and understanding software in general. There is always an added layer of complexity with software. While with regular translation, you might sometimes get away with a general translation of something that you do not understand, this is quite unlikely with software, which makes it much more challenging. For example, a client once offered us a job to localize into Russian a program for trading options and futures. Even though we have knowledge of financial markets and the terminology was generally clear to us, we did not accept that project, because we did not know the subject matter deeply enough to translate such a specialized program.
Add us to your RSS reader to make sure you don’t miss future posts with translation tips.