By Ryan Smyth
(Winner 2006 Silver Faucet Award
Guitar and Drum Trainer – SIA Best Application Using .NET 2005 and 2006)
Everyone has their own take on who, what, when, where, why and how to localize and translate software. The marketing guys want everything and have no clue what it is beyond, “a new Japanese version”. The programmers will sometimes ask for an Excel file with all the strings in Japanese. The translator that got hired by the intern is about to finish high-school and will do whatever he’s told. The translation company that got hired after the kid got fired would prefer things done their way, but since you’re paying they’ll do whatever you ask. It can be a real mess trying to get things done.Since I’ve pretty much done everything from end to end at least a few times or more, I think I’ve got a fairly well balanced opinion on how to get things done right. I’ve worked on pretty much everything from professional journal articles and ad copy to small applications and documentation to large projects that incorporate client applications and server daemons with integrated websites. In each area different approaches and processes can work better and while there’s no “one right way” to get things done, there are some general principles and things that can help to keep the flow tight and produce good results. If you’re considering having your software translated, then hopefully this article will serve as a decent basic primer on software localization and translation issues for you, and point out some trouble spots and things that you will need to consider.
This time around I’m working on another few relatively small end-user applications, and sitting on the opposite side of the fence for one of them. For the sake of ease I’ll call them “App A” and “App B”. I’ll refer to them as examples from time-to-time.

Interpretation – Not Translation

I’ve already ‘translated’ App A before, end-to-end from the GUI and documentation to web content. I say ‘translated’ because while people understand that, that’s not really what I do. I don’t believe in ‘translation’ per se for software and web content (or much of anything else for that matter). It’s just a bad idea. You invariably end up with weirdness. Instead, some kind of ‘interpretation’ works better to get things right in the target language. Sometimes that means cutting things out and re-writing large sections. This is more important the further away you get from the original language group. e.g. While it’s pretty straight-forward to go from English to Spanish and vice-versa, you’ll have a tougher time going from English to Japanese and vice-versa. At all times you’ve got to keep your eye on the most important aspect of the ‘translation’ – your users.

Doing Things Right the First Time Around

Back to App A… While it’s already been translated, the original translation was pretty much unusable beyond itself. It was done directly in the EXE file and since then has undergone some serious upgrades with new resources and deleted resources, which I was expecting. So a good amount of work is getting redone and the work that has already been done is relegated to wasting time with copy & paste.
However, this time around it’s getting done right. The translations are now being pulled out into resource DLLs (the software is done in C++) that can be easily translated later on. That doesn’t help at the moment, but it’s certainly a step in the right direction.
If you’ve never pulled resources out into resource files, it’s a very good idea to start programming like that now. If you ever do localize and translate your software, you’ll be ready to do it very quickly, and it will make the actual programming more manageable for you.

The Right Tools

I’ve seen software translations done in Word, PowerPoint, and Excel. They’re almost always the wrong tools to use. PowerPoint and Excel have no place at all in any software translation. Word on the other hand does have some good uses, and they’re always called “Track Changes”.
Tracking changes in Word is most useful for larger projects where you need to keep track of the quality of a translation. Once the original translation is done, you’ll need to have it copy edited and then proof-read if the copy editing shows that the original translation had too many errors. Judging what constitutes “too many errors” is shouldn’t necessarily be numerical though; the type of error is more important, e.g. style considerations are often more important than simple tense, particle or article errors.
That isn’t the ideal way to get a translation done as you introduce extra steps where human error can occur, but it does give you some more control over the quality of the translation if you can’t do it yourself. For a typical small mISV I wouldn’t recommend going that route as the number of steps becomes much larger and the costs of doing it that way increase greatly.
Regarding human error, one problem that I’ve seen far too often is ‘copy and paste’ not being done right. The low-paid person handling the final document invariably ends up missing some characters when copying. Then again, I’ve seen people start re-typing things, which is an even worse idea.
While Word and tracking changes is good for quality control, it’s almost always better for the translator and editor/proof-reader to make changes directly in the resource that will be used. This eliminates any possibility of human error being introduced through copy and paste or retyping. If you’re using the ‘copy and paste’ method, you should probably get your proof-reader to go over things once more, which is an unnecessary step.
There are some very good translation tools available for a variety of uses. I use appTranslator ( and am very happy with it. It’s easy to use for translators and keeps things simple. While it may be missing some features that some more expensive solutions offer, it more than makes up for this in usability. i.e. You can either pay your translator to learn some new complex translation software, that you’ll have to pay for, or you can give them a free appTranslator Translator Edition that is highly-intuitive and simple to use. I’ve never missed anything or needed anything that I don’t already have in appTranslator.
If you want to keep costs low, then appTranslator is ideal. The professional version is reasonably priced and you can distribute a free ‘translator edition’ to your translators. Many other solutions require you to pay for the software licenses for each translator. This can really bring your costs up very rapidly, especially if you’re planning more than one translation. Also, with the easy to use interface in appTranslator, your translators won’t be fussing around with low-level or difficult interfaces that increase the risk of them making errors, either technical or grammatical. Those costs are invisible, but can end up costing much more when you end up redoing work that should have been ok in the first place.
There are several key benefits to working with resource files and a tool like appTranslator:

  1. Translation is done at a low-level which eliminates intermediary steps where human-error can be introduced.
  2. The work process is simplified greatly, which allows your translator/copy-editor/proof-reader to focus on their tasks, and not technical issues.
  3. You protect yourself against future upgrade issues with the ability to import translations from previous versions of your software.

On a side-note, I don’t believe that the cost of software should always be determined by a feature set; service and support takes time from real people and quite often that quick response to a support email can save your bacon. I’ve found that Serge, the appTranslator developer, is quick with support emails and very responsive. For me this adds significant value to the application as I’ve got someone to get answers from if I need. For many mISVs this probably strikes home as a real advantage that we as small developers have over larger companies with complex, slow, and often frustrating support procedures.

The Right Process with the Right People

Using the right tools is often enough to basically force you into a process that will produce a high-quality translation for you. However, even the best of tools will give you enough rope to hang yourself. These dangers are often avoided by using the right people to get the job done.
App B has already had its interface translated into Japanese, so only the documentation and web pages remain. The application will still need to be proof-read though. Since it’s a utility with some technical language in it, using an excellent translator that does fashion and tourism translations probably isn’t a good idea, so we’ve enlisted a Japanese proof-reader that works in IT.
While this should be a no-brainer, I’ve seen more than one translation done by someone who didn’t understand the subject matter, and the results were very poor. Don’t think that you can get just any-old “native speaker” to work on the project. It won’t work. Just for example, take something like the short paragraph below and ask your grandmother to explain it to you:
“Editing compressed audio will degrade the quality of the final product unless the compression is lossless such as with FLAC. Another consideration for achieving better quality results is to use a higher bit-depth and sample rate. However, if you’re recording at something like 48,000Hz, then you’ll want to make sure that you have a high-quality sample rate converter if you’re publishing at 44,100Hz.”
Nothing too difficult there, but if your translator doesn’t understand what FLAC, bit-depth and sample rate are, you’re bound to end up with some pretty bizarre stuff at the end of the day.
For another perhaps more poignant example:
“Instead of using where, try using an inner join.”
In that example your translator doesn’t have any choice but to leave “where” as “where” and “inner join” as “inner join”. The terms are opaque and not subject to translation as they are a part of a computer language and not a human language. For cases such as those, it’s important not only that your translator understand what a “where” clause and an “inner join” are, but also that you properly format them with italics, bold, a different color, or some other way to denote that they are opaque. Special formatting may not be possible in some dialogs or message boxes, which only goes to reinforce that your translator should be competent in your subject matter.

Consistency in the Original

If you start with dog-poo, the best translation you can expect is shiny dog-poo. And they both stink. Make sure that your original application and documentation are good quality.
A large part of that quality is being correct and consistent in your writing style and choice of words. E.g. “click”, “press” and “select” all have different meanings and should be used consistently in the correct places. You click a button with your mouse. You press a key with your finger. You select an item from a list with your mouse by clicking on it. E.g. “Press F4 to display the Preferences then click the ‘Advanced’ button to display the ‘Advanced Preferences’. Under the ‘Languages’ heading select your language from the drop down menu.” You wouldn’t click the F4 key and you wouldn’t press the ‘Advanced’ button.
Also make sure to be specific in what you mean and avoid ambiguous terms. “Upload”, “download” and “transfer” all have different meaning. “Transfer” includes both “upload” and “download”, and shouldn’t be used unless you want to include both cases.
When you have an item or function that has several synonyms, choose one and stick with it. While in general prose it’s nice to mix up the language for style, for software it will only create confusion, and for your translator, this can be disastrous. Are you talking about two different things or the same thing?
For some things synonyms should be divided to mean different things. E.g. “Options” and “Preferences”. “Options” is typically better for a main menu item while “Preferences” is typically better for sub-menu item. This is moot if you only use one of those words, but there are other situations where the general principle will hold, e.g. “folder” and “directory”.
If you need to, create a glossary of terms while you’re writing your interface and documentation. This will help you keep things consistent for you, your users, and your translator. Remember that things can take on radically different meanings in another language, and clarity in your original not only produces a better product in the original language, but also in any translations that you create.

A Small Technical Note

Formatted strings are wonderful and beautiful and make life grand, but don’t put more than one variable in them if you can avoid it. It’s better to break them into smaller manageable chunks with one variable per formatted string. For example:
("%d results returned for %s", count, term)Could also be written as:
("Search for %s returned %d results", term, count)What happens when your translator creates a wonderful, elegant translation for the second of those two and it reads something like:
("%d results returned for %s", term, count)Ooops. Your program just threw an error because you ended up with mismatched types.
Instead, try something like this:
("Search Term: %s", term) ("Total Results: %d", count)The problem becomes worse when the types are the same because you won’t even catch an error and the output, while technically correct, turns out to be gobbledy-gook when someone reads it.

Another Technical Note

App A and App B are done in different languages, C++ and Delphi respectively, and have different translation methods. While the resources are all neatly contained in language resource DLLs for App A, App B is using INI files instead. Both have certain advantages and disadvantages.
INI files are most certainly much easier to translate with a simple text editor like Notepad or EditPlus, while DLLs require special software that can cost you a few dollars. If forced to choose between them, I’d side with DLLs in a heartbeat. The pain of having to use/buy a special tool is small compared to the advantages of being able to easily manage those language resources and update them.
While examining the INI resources for the Japanese translation of App B, each and every variable in the INI file needs to be manually checked between versions. This is time consuming and costly. For App A, it’s just a matter of importing an existing translation into appTranslator, which takes all of 5 seconds.
The point here isn’t so much that it’s faster, but rather that maintaining the application is both more accurate and easier.
For my flagship product (Guitar & Drum Trainer, or simply GDT), I program in C#, and while I never did release the previous translations of the previous version (due to lack of time), I will be localizing and translating the current version again into Korean since it’s a complete rewrite. For me those maintenance issues are less important as I speak English and Korean and can very easily fire-up Visual Studio and make any changes to the program that I need. If you don’t speak the language that you’re translating into, then you don’t have that luxury and maintenance becomes a greater worry.
If you’re programming in .NET, then there are some convenient tools available to you and your translator. For Visual Studio 2005, look for “WinRes.exe” in “C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin”. You can find more information about it at

The Help File from 3 Perspectives

I write the documentation in English for GDT and for App B. I’ve already mentioned some of the important considerations for writing above, and they all basically boil down to clarity and consistency. From this perspective, things are fairly easy to deal with.
However, App B has Japanese documentation. Yikes. I don’t speak Japanese and won’t be able to personally ensure the quality. For a case like this, the process needs to be more robust to take care of quality issues.
GDT will have Korean documentation, but since Korean isn’t my native language, I know that there’s no way I’m going to touch that. I’m fine with translating the actual application into Korean as I’ve translated a few audio and multimedia applications from Korean into English and have an excellent grasp on the language in that area, so I have a proof-reader for that. Prose is a different story entirely and recognizing my limitations there is important. For that I’ve got a translator working on it.
The help file for App B is quite long and maintaining it could be problematic. The documentation for GDT is fairly short and is unlikely to expand to a level where maintenance becomes a real issue. For this my translator simply opens up the HTML and starts typing. Nothing difficult or complicated there.
Back to App B… As maintenance plays a very real part in the product life-cycle, it’s important to manage those help file resources as easily as possible while still maintaining a high level of quality. As the Japanese are well-known for perfectionism, quality is especially important.
The process I’ve chosen for this project is slower and more complicated, but is designed to keep quality high and keep the help project maintainable. I’ve chosen two tools for that:

  1. Help and Manual XML Edition
  2. Microsoft Word

The approach here is more like the old-fashioned edit-on-paper method. The basic translation is done in Help and Manual, exported to a Microsoft Word format for editing with the Track Changes option in Word. If the original translation turns out to have met its quality standards, then the changes are entered into the Help and Manual project. If not, the Word file is sent to another proof-reader for a basic “cleaning” from a fresh pair of eyes, then those changes are entered into the Help and Manual project where they can be exported to a CHM help file, a PDF, and set of files for online help.
This process introduces the possibility of human-error with copy & paste mistakes, but given the scale of the project, a more robust solution isn’t really justified.
Later on updates are more manageable with a single help source file and the process can continue with little redundant effort.
The process is basically dictated by the scale of the project. In other words, of all the resources allocated to the project, how much needs to be allocated to managing it versus doing it.
For the original English translations, I can quite easily create and maintain the help files. There’s nothing difficult about this. Here I’m the author. (As I mentioned above, instead of just ‘translation’, I ‘interpret’ parts, rewrite parts, and add new content where I find portions to be thin.)
For the GDT help translation, it’s quite small and easily manageable. An HTML editor or text editor is sufficient for the translation, and things are very straight-forward. If your application is small and the help is simple, you may find that this approach works for you.
App B has a large help file and there are quality issues to deal with. A simple process like for GDT won’t be sufficient. In this case, my role is managerial and my task is to ensure that the end product meets quality standards. If you have a larger application with more complex documentation, then a more robust process like this may work well for you.

Some Process Mistakes to Avoid

No matter how you decide to go about your translation project, there are some pitfalls to avoid. While these may seem trivial to some, I lost track long ago on how many times I’ve seen things like these happen.
Don’t try to translate an application and help before it’s done. If you make any changes to the application or the help, you’ll end up having to have things translated again. While you don’t necessarily need to have a final release ready, your interface should at least be finished with no additional controls or strings to be added. However, if the translation is being done in-house, then this approach can work, but will still involve some redundant work.
Don’t try to do it “one piece at a time”. If you try to get small parts of the application or help translated in small pieces, you may end up needing to use different translators. This can result in inconsistencies in style and word use, which reduces quality. Even if you use the same translator, if you spread out the translation over a long time, your translator may not have the previous translations anymore and if you haven’t made sure to keep your original consistent, it’s unlikely that your translator will be able to keep the new work consistent with the previous work.
Prepare the software before translating it. This includes taking care of any code page issues, extracting resources into DLLs, and making sure that formatting issues for dates, times, currencies, numbers and the like are taken care of. If you start with a mess, you’ll end up with a mess.

In Closing

There are many things that I haven’t covered above, such as support issues, or that I’ve glossed over very quickly, such as choosing a translator. However this article is by no means meant to be exhaustive or complete, and there are plenty more resources on software localization and translation available on the Internet to help fill in the gaps.
Hopefully this will help out a few people that have been thinking about providing their software to a broader market or highlighted some things to think about for those that are struggling with some common problems.

About the Author

As the “Renegade” behind Renegade Minds, Ryan writes and markets Guitar & Drum Trainer, a specialized audio player for musicians to more easily transcribe, practice and learn new songs by ear. He also offers several other programs and utilities at Renegade Minds. During the day, he’s the ALTools Evangelist for ESTsoft. Originally from Ontario, Canada, Ryan has called South Korea “home” since 1996. In addition to his many interests in software and software marketing, Ryan also enjoys playing various sports, studying to improve his Korean language skills and plotting world domination… errr… ‘liberation’ that is. 🙂
[tags]software localization, software internationalization, micro-ISV, micro-ISV best practices[/tags]

Write A Comment