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 which is followed by majority of localization cases. Let’s go through this path with this case.
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 straightly to the “Localization Phase” or ask a nerd for some assistance.)
The sources were organized in a typical way in the following folders:
root +css +images +js
#2 Check the software architecture.
The Gadget takes a 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 ‘es-ES’ directory. If not found, then ‘neutral’ files would be loaded. Based on this architecture, translation would involve that 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 translation of ‘resourcestrings.js’.
We also added two extra functions to make the programming part even more convenient:
#3 Internationalize the code (if possible)
These relatively small changes in code ease and simplify the next phase of the localization project significantly.
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 recognises 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 of 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 on the topic and on 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 to 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 to 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 you project.
When all this have 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 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?