Software Localization

A beginner’s guide to Windows software localization

Business colleagues often ask me if localizing software into foreign languages really means more sales and better revenues. If you complete the localization process in the right way, the answer is “absolutely, you can achieve higher profits”. Moreover, would successful software companies like Microsoft have been localizing software for years without a proven business case for the process?

Economies like USA, Germany and Japan are incubators for large sales profits with professional localized software. And, smaller foreign software markets are extremely profitable if you sell the first localized product in your category in those countries. However, if your software does not sell well in your own language, then localizing will not make the situation better. But if you have a product with huge sales in your home market, you can build on your success with localized software. If you see more and more customers from other countries buying your software, even though it is not localized, you should jump on this business opportunity—and localize your software. If you are not sure how to start the localization process, then this article is your starting point.

1. Do I need a software localization tool?

Absolutely. The main reason is that your translator is not a developer. You want to localize the professional way? In most cases, you want to hire a professional translation expert who is a native speaker of the target country to translate your strings. To keep your costs down, you want to provide a single source file with all the strings to be translated, along with an easy-to-use editor. This approach gives you several advantages:

  • Most translators dislike learning new formats that different software compilers require. The professional translator will charge you more for the learning curve.
  • Professional translation experts prefer to get all strings in one single source. This also keeps your costs down, as the translation professional might charge you more for each document that you send.
  • And your translator can work faster and concentrate on his/her job if you provide an easy-to-use, intuitive editor. A good software localization tool offers an effective text editor that is easy to learn.
  • Your translators will give you a better word price if they can re-use what they have already translated in other projects. As a developer, you have a large collection of useful functions you can reuse frequently. Professional translators have something similar with their translation memory. Your software localization tool should support the access to standard translation memory, like Trados.

You, as a developer or owner of a software company, get higher localization quality with an effective tool because of the WYSIWYG (What-You-See-Is-What-You-Get) display. An effective software localization tool provides this feature for all visible elements. The translator sees the context of the string while translating—this means you spend less time answering the translator’s questions. If a string is too long for a dialog box, he/she can recognize that and implement a shorter translation. Or, the translation professional can even change the size of the screen element to make the text fit.

And what happens if you choose not to use a localization tool? The major pitfall with software localization completed without a tool appears when you are ready to update or upgrade your software. Each time you issue a new version of your software; the development process creates new strings or changes many existing strings. A professional translation tool quickly scans your application for these changes. And, your translator does not have to start from scratch—he/she charges you only for the changed or new strings. So the translation tool pays for itself and saves you time and money.

2. Which software localization tool is the right one for me?

You can find many, many software localization helpers on the internet. But the range of really effective, professional tools is very small. So what separates the wheat from the chaff? The following information can help you choose the right tool for your software.

Source code localization is an outdated approach to software localization. The newest generation of localization tools supports binary localization. You should not expect less in the tool that you choose. Source code localization works on your source code, which you should not share with a third party. Personally, I would never allow an application to change my holy source code and perhaps make a mess of it. Binary localization solves this problem smoothly. The process works only on the resources of your compiled Windows application. You don’t need to recompile your application to add a new language. Using resources reflects Microsoft’s recommended method for localizing software. If your development platform supports this process, you should be using it.

A software localization tool must be as easy to use as possible. The reason is simple. Your translator has to learn the tool in minutes, not days. Some vendors offer training. However, few software developers, owners, and translators have the time to invest in this type of training.

The software localization tool should come with a free translator license for all of your translators. And this license should run without the need for the translator to install the run-time version of the software. Provide the right translation tools so that your translator can be up and running within minutes.

Far Eastern languages need special features in an effective localization tool. You might not plan to localize for these languages for now. Japan and China are very good future markets, especially if you are the first mover in your product category. You might possibly bundle your software with computers or other software; and chances are high that these products might sell in countries like China. However, Chinese and Japanese markets require a lot of prior planning. You should not switch the localization tool under time pressure to climb the highest translation mountain—double-byte languages. Choose a software localization tool that is already prepared for these challenging languages. The right tool ensures that, if your boss drops into your office and ask you to prepare for Chinese localization, then you are well prepared for the challenge. Choose the tool wisely and check to ensure that the vendor has experience with exotic character sets. Check if the vendor has developers in Japan or China. Developers with these skills have practical day-to-day experience with double-byte character sets and do not read about them from a book. Do you expect that a developer not used to entering text with an IME would know about that? Your Japanese or Chinese translator needs an IME because keyboards cannot provide the hundreds or thousands of characters used in their language.

Another issue is the support for multiple platforms. The tool that you choose should support as many platforms as possible. This gives you the chance to import strings from different sources into one localization project. This way you can reuse translations made for languages such as Delphi in your XML files. The tool should support database localization in case you have tables to translate. And the right tool can give you the best support when you must switch platforms, such as going from classic Visual Basic to Visual Basic .Net. A state-of-the-art software localization tool has full WYSIWYG support. This means that you see all dialog boxes, menus, and components as they are shown at run-time in your program while translating. Your translators see the context of the text they are reading. If you localize from and to certain languages, such as English to German, you soon recognize that German strings are longer than the English originals. A good WYSIWYG display shows these occurrences so that you can enlarge the labels. Moreover, if you have created your own visual components, you should be able to edit them inside the parent forms. And the GUI of your localization tool should support UNICODE to allow editing of all the possible character sets without restarting the software. Moreover, the localization tool should support UNICODE for filenames and everything the tool uses for input. All these things should be supported for foreign character sets.

3. What do I do after choosing the right tool?

If you have already separated the code from the strings using resource files in your project, you only need to scan your .EXE, .OCX, or .DLL with your localization tool. The tool can collect all strings and display them in an editor for translation. You can then create a translation package and send it to your translators. After they send back the results of their work, you can build the localized version. The process is really this easy. A good localization tool takes care of character sets and all of the nasty details. But there are two pitfalls you have to take care of.

The first problem occurs if you have not maintained resource files. But you are in luck. Probably your development system took care of that for you. All strings for menus and dialog boxes are stored in resource files by default. If you use Delphi, C++ or the .NET platform, you only take care of the strings you hard-coded in your source files. If you think that you might have been better off separating those strings into resource files from the beginning, you are right. But it’s not too late to do it. Moving all strings into string resources is not a hard job. Instead of writing the following code example:

“ShowMessage(“Hello World”);”

In C++ Builder with VCL, you can write this code:


You can then create a string resource table entry named SMyString with the content “Hello World”.

For combined messages, you should use placeholders like %s in your strings to avoid problems with different grammar. While in English, you write “Insert disk in drive a:”, in German, the text is “Legen Sie eine Diskette in Laufwerk a: ein”. If you use a placeholder, such as “Insert disk in drive %s”, your translator can easily follow the German grammar in writing “Legen Sie eine Diskette in Laufwerk %s ein”. You just need to replace the placeholders with the current value after reading it from the resource.

The second problem is related to how common development systems for Windows organize the GUI. Except the new .NET platform and for UNICODE compiled C++, the development systems use ANSI GUI API calls. While you can easily create UNICODE strings (16-bit characters) inside your application, everything displayed in forms and windows is converted into ANSI (8-bit chars). This means that you must test a program localized into Japanese with a system configured to start non-UNICODE applications with a Japanese character set. You cannot change that character set inside your application. The decision is made before any lines of code are executed. You can read a description of how to set the right code page at the following link:

Working with Code Pages in Windows

Do not panic if your localized application shows only garbled characters. Your test system is not configured correctly. Your customers will automatically see everything correctly because their Windows system starts non-UNICODE applications with the correct character set. Everyone who is technically interested might search the web for the term LCID. Other people just trust their localization tool which does it correctly for you. A very elegant solution to solve this problem is to use third-party controls to make your GUI UNICODE-enabled. Borland VCL developers can find very good offers.

Have I mentioned that the software localization tool of your choice should be UNICODE-enabled in its own GUI? Sure, but it is important enough to repeat that.

4. How to find the right translator

If you choose the right tool, you have many options in choosing your translator. Whether you work for a large enterprise with other divisions that complete the translation internally or if you hire an external translator, the steps are always the same. You send a single file including everything your translator needs. He/she installs the files and can start right away. If you choose wisely, your translator does not have to download huge run-time tools like .NET—and he/she avoids the usual hassles if the tools do not easily install. While with a good localization tool, you can develop and localize the product at the same time, most companies start localization at the end of the project when schedules are tight. Every delay in this phase is critical—costing time and money.

Whoever does the translation—there is one rule you should never break. Always use a native speaker for the job. These translators might be more expensive, but they are worth every cent. If you fear the cost, go back to the beginning of this article. The starting point is that, if your product sells well in your home market, the price for the software localization tool and the translator is well worth the investment—and does not decrease your profits. If the cost is beyond what you are currently making, you should rethink whether the localization adventure is a good investment at this time. If the cost does not hurt your profits, then you should not compromise. Don’t send the message to potential customers in your new markets that they are second-class by presenting a product that shows odd, quirky translations. Choose an experienced translator or translation company with knowledge of software localization. The result will be quality sales and new revenue streams.

Software Localization – you can do it – but do it right!

Software localization for all major Windows development systems like products from Microsoft and Borland is an easy task if you follow some simple rules. I would say that the majority of developers can localize their product without a learning curve if they use the right tool. All trustworthy, reliable vendors of software localization tools give you a free test ride. Take advantage of these offers. Beyond the facts mentioned in this article, you must choose which tool you personally like most. Do not forget to look at the costs of the tool. Check any extra costs, like updates and support.

A last hint: a good vendor will support you and your problems 100% even while you are in your evaluation phase. Use this opportunity to check their service before you purchase their product!

— Markus Kreisel

3 replies on “A beginner’s guide to Windows software localization”

I found your blog via google by accident and have to admit that youve a really interesting blog 🙂
Just saved your feed in my reader, have a nice day 🙂

Hi Florian,

Google just started to list us better and things become under steam now. First comments are rolling in (including spam 🙂 ) . So now the time is right for more articles. Please stay tuned – we have more to post soon.

Hello! I am a translator looking to branch into localization. Thank you for this overview of localization.

Any suggestions on how to start getting my feet wet?

I will definitively follow this blog.

Leave a Reply