project manager facing a wall with documents pinned on it
project manager facing a wall with documents pinned on it

You want to bring your software to other markets and you know you will be localizing it. You have researched localization online and found many useful tips that you intend to implement in your localization process. In addition, you are aware of internationalization concepts such as Unicode, text expansion, and separating strings from source code. So you should now possess the knowledge to tackle localizing your software with the resources you have at your disposal, right? Besides the many localization best practices that you may already know, you should also keep in mind the following mistakes or DON’Ts when starting to localize your software in order to avoid problems and dead-end situations later.

Don’t improvise as you go along.

The more things you standardize or agree upon before starting, the smoother the localization process will be. A big issue here is terminology. Try your best to standardize the way you call things in your program. This is not only for the benefit of users in the original language of your software, but it will also make translation easier. It is also advantageous to agree on the terminology in other languages, i.e. create glossaries. This may seem like a big up-front investment, but it will save you a lot of time down the road, as there will be fewer interventions during the localization process about undefined terminology, which will also improve the overall consistency of the translation.

Also, try to standardize the formats in which you have translatable documents and try to keep their number down. You may have some strings in XML, some in a database, and some in your own internal format. Standard formats have the benefit that they can be read and edited with a variety of tools. Even transitioning from one standard format to another sometime in the future might not be as difficult, because converters will likely exist. Try to replace at least the internal format with a standard one. Whoever will be processing those strings will thank you.

Don’t make your own tools.

You might be tempted to develop your own tools that can handle the formats you use, including the internal format. As Henk Boxma writes in his article about software translation costs, making your own localization tools might end up costing you more than a dedicated localization tool. It may also prevent you from reaping the full benefit of computer-assisted translation (CAT) tools and make any outsourcing of translation more difficult.

CAT tools are dedicated tools that have been developed over the years. They are designed to handle a large variety of formats and contain features which facilitate a more streamlined translation process that can also deliver higher quality with built-in quality assurance tools.

lines of XML code that will be localized with a CAT tool software

Unless you are willing and able to dedicate development resources to your in-house tools in the long-term, those tools probably won’t have features comparable to CAT tools. Instead of creating a tool that allows you to translate any internal formats, spend those resources on developing a conversion utility that converts internal formats to standard formats, such as XML.

Don’t do everything on your own.

You might have a person available in the company who is a native speaker of the language into which you are going to translate your product. It may seem like a good idea to use that person’s knowledge of the product, despite them having no background in translation. Doing the localization in-house could also keep the costs down.

But will that person have enough time to do their own work and localization? Even if localizing your product seems like a one-off project, also keep in mind that somebody will have to maintain other languages once you update your product and correct any mistakes that might slip through the first time.

A localization professional will be able to help you avoid many potential pitfalls that you might run into months or even years down the line if you do it all with existing, non-specialist resources. In the end, fixing such issues could cost you more time and money than getting expert help.

Do you agree with this choice of DON’Ts? Can you think of any other bad practices we have missed? Don’t hesitate to share your thoughts in the comment section below.


Submit a Comment

Your email address will not be published. Required fields are marked *