This is a real-life example of translating a small Windows application called Multilizer Translator Gadget, which is a Windows Sidebar Gadget. Although every software localization project is unique, there is a universal path that is followed by the majority of localization cases. Let’s go through this path with this case.

Pre-Localization Phase

Before any localization project can be started, one needs to define the goals for the project. Localization is not a simple term and to avoid any misunderstandings it is important to clarify what it means in this specific case. In our case, the localization was reduced to translating the user interface into multiple languages.

#1 Set up the goals for the project.

After one knows what is the desired outcome of the project, it is recommendable to take a look at the software. There are many things software developers can do to ease the actual localization process. (Due to the technical aspect of this stage, the following few paragraphs contain some technical jargon. If it’s too complicated, just jump straight to the “Localization Phase” or ask a nerd for some assistance.)

In our case, we found out that gadgets typically consist of HTML, CSS, and JavaScript. And the texts to translate can be in HTML files, or sometimes also in JavaScript. This applied also to the gadget that we developed.

The sources were organized in a typical way in the following folders:


The root contains the HTML and the gadget manifest. CSS contains the style sheets. Images contain the images used by the gadget. And js contains the JavaScript that adds the desired functionality in the gadget.

#2 Check the software architecture.

The Gadget takes use of the Microsoft MUI architecture; there can be folders named by the ISO locale, such as ‘es-ES’. On a Spanish system, the Sidebar would first look for files under the ‘es-ES’ directory. If not found, then ‘neutral’ files would be loaded. Based on this architecture, the translation would involve all the files would be copied under a new directory named by the ISO locale. After that, the files with texts in English would be translated to another language. This approach, however, is not so elegant. A lot of files were duplicated as such.

To overcome this, we decided to internationalize the code. This means that we removed all English texts and placed them in one common resource file named ‘resourcestrings.js’. And the user interface is now populated at start-up by calling a getResourceString() function.
With this approach, the translation of the gadget is simply reduced to the translation of ‘resourcestrings.js’.

We also added two extra functions to make the programming part even more convenient:

  • setElementText(elementid,resourcekey)
  • setAttributeText(elementid,attributename,resourcekey)

#3 Internationalize the code (if possible)

These relatively small changes in code ease and simplify the next phase of the localization project significantly.

Localization Phase

When all the preparative work is done, the actual localization can begin. One can do the localization phase manually or semi-automatically with a special localization tool. Manual work requires a lot more technical knowledge about software development than working with a localization tool. The most significant differences between these two methods are time and security. A localization tool speeds up the process by automating certain tasks and secures the software by eliminating the possibility to make fatal changes to the code during a localization process.

We did our project with our own, advanced localization tool called Multilizer Enterprise. It is a versatile tool for both small and big projects. We first created a new Multilizer project and scanned our software with the tool. Our localization tool recognizes which part of the code should be translated and shows only these strings. After that, we exported the translatable material automatically to Google Translator Toolkit with MOTO.

#4 Prepare the project for translation.

At this point in the project, it’s time to translate. Depending on the goals of the localization project, one should decide how the translation is made. The best output is likely to be made by a professional translator who is specialized in the topic and software localization. However, there are also situations when e.g. crowdsourcing translation is the best solution. Again the goals and targets of the project should be taken into account. In our project, we used an online employment platform called Elance to find translators.

The translators worked on our project with Google Translator Toolkit. This kind of online outsourcing is simple for the translators because they can work online where and when they want to without any need for downloading or installing programs on their own computers. To ensure the quality, there should be a good communication channel between the participants.

#5 Recruit translator(s) and communicate with them.

When the translations are finished, they can be integrated into the code. In our project, this was made by importing the translations automatically back from Google Translator Toolkit to Multilizer Enterprise.

#6 Integrate the translations to your project.

When all this has been made, one can finish the project and build the localized software. In this stage, there is a temptation to mark the project as finished and move to the next one. However, there’s still one important thing to do.

After-Localization Phase

After the software is localized, one should test it properly. It’s a good idea to let the translator(s) see the outcome as well. All the possible mistakes or typos are relatively easy to fix now before any further marketing actions.

This is how our localization project proceeded. Would you do something differently?