GET A FREE CONSULTATION OR SAMPLE TO GET YOUR PROJECT GOING.

Yes, I want my consultaion

Five Secrets of a Software Localization Pro

Photo by David Wallace, http://www.flickr.com/photos/dnwallace/8383077596 Thinking about accepting a software localization project as a translator? Tips in this post will help you make a decision and do a good job.

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.

No guesses

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.

Example:

“Open Settings”

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.

Example:

“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.

2 comments

  • Selena says:

    Hi! If you’re involved in software localization projects, you might want to check out this great, collaborative online localization tool: https://poeditor.com/
    You’ll see that it has a sum of very useful features to aid your localization workflow, like set reference language and translation memory. Cheers and good luck with your projects!

    • Hello Selena,
      Thanks for reading and commenting. As a web-based tool, PO Editor is definitely a very good choice for those localizing software. I imagine the learning curve is a lot less steeper than with offline CAT tools (although the latter undoubtedly have their own advantages).
      Best,
      Roman

Add comment


About the Author

Roman Mironov
Roman Mironov
CEO & Founder

As the founder of Velior, Roman has had the privilege of being able to turn his passion for languages into a business. He has over 15 years of experience in the translation industry. Roman has helped dozens of clients increase sales by making their products appealing for speakers of other languages.