Month: March 2006

Developers often think that using the executable file (EXE) as the source file for the translations is not a good idea. They would rather have their source file translated: The resource script (in other words the .rc files). That’s what we first thought, too. But even though it’s counter-intuitive, IT IS WRONG !

This article points out a few of reasons why using the EXE as the source file makes developers’ life much easier. It also covers several major misconceptions about EXE-based translations.

With EXE-based translations, I can’t modify my code anymore…

WRONG!!! appTranslator will happily and instantly build updated translations of your program whenever you modify your code. It needs not touch your code. It simply makes a copy of your new exe, extract its resources and replace them by their translated version. There is really no difference in this regard between using a .exe file or a .rc file. Oh yes… there is one: It’s much easier and faster to build a translated exe by updating its resources than to link the program again, using an alternate, translated rc file.

What if I modify the resources of my application ?

No problem ! Again, there is really no difference in this regard between using a .exe file or a .rc file. appTranslator compares its version of your resources and the resources in the .exe. Using advanced algorithms, it finds the new and modified item (even in dialog layouts!) and updates the translations accordingly. And you can fine-tune some advanced aspects (such as dialog controls layout) as easily

EXE-based translations help isolate development and translation

Translating the .rc files means the developers must handle the compilation of the translated .rc files. Therefore, there must be one project file for each translation of each translated module. Do you want developers to spend time managing translation-related projects ? Or be bothered by bloated projects list ?

EXE-based translations do not require any intrusion in the regular development process: Translated EXEs are built directly from appTranslator. No more intrusions in the developer’s work !

By using the .exe file as the source for translations, we basically use the endpoint of the developer’s work (the exe file is the developer’s output, right?) as our starting point for the translation work. In other words, we add a new link to the development process rather than hook unrelated work items in the middle of the developer’s work.

Allow translators to test their work

Very often, translations are performed by support staff of your foreign distributors. These people may not be the best translators but they know your app and they know your business, hence they probably have a better grasp about the terminology used in your apps than most professional translators.
Let them test their translations. If they are translating .exe files, the localization tool can generate translated exe on-demand.
On the other hand, if they are translating .rc files, they can’t compile the EXEs in order to test them. The developer must be involved and do the job for them, which means that developers must spend time doing a job that could otherwise be done by a computer. Not very cost-effective !

Make sure everything is translated

There can be lots of rc files buried in toolkits and libraries, including one another. Keeping track of all of them is often painful. By using the exe file instead of the rc files as a source, you ensure that all the resources are available to the translators.

One might argue that on the other hand, the resources from a library used in different executables are duplicated and need to be translated several times. There is an easy workaround: Create a dummy exe whose sole resources are the toolkit or library’s resources and import. Use this dummy EXE to maintain translations of the toolkit’s resources. Import these translations into each real exe that uses the toolkit.

I don’t want to be locked into appTranslator

Developers think that having a translated version of their .rc file is important to help them keep in control: If they have translated .rc files, they can start using another localization tool at any time.
Having translated EXEs give them the exact same …