Misconception: It’s a better idea to translate a .rc file than a .exe fileMarch 1, 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 freedom. All decent localization tool accept EXEs (and translated EXEs) as their primary data source (The other way around is not true, by the way !). Therefore, EXE-based translations don’t lock you in more than .rc-based translations.
I want source files !
We, the developers, want to be in control. We want to be sure that we are able to recompile everything at any moment and want to depend on as few tools as possible. This is probably the biggest misconception about translation of EXEs. Why do you need these source files ? You don’t create dialog templates by editing the .rc file using a text editor, do you ? You use a dialog editor of course. And these source files are not very helpful if the tools you use to edit them just can’t handle translated versions (see below) !
The EXE file contains all your resources and every decent development tool can extract resources from EXEs as easily as it can read an .rc file.
Visual Studio does not support different code pages
If your computer’s language settings are german, Visual Studio 6 can’t display your translated .rc files whose containing text in Greek, Polish, Chinese,… . You’ll have to use a smarter text editor!
In Visual Studio .NET 2003, forget about displaying dialogs in Japanese in the dialog editor if your Windows regional options are not set to Japanese!
Handling resource files containing text in different code pages is a nightmare. And Unicode encodings such as UTF-8 is not supported by all versions of Visual Studio.
By the way, standard resources are always stored in .exe files using Unicode (even for Win9x apps), which eliminates the encoding problems that are encountered using text files (.rc files).
I want to be able to renumber my resource items
Isn’t it rather that you want to be able to fix symbolic identifiers ? Who cares about numbers ?
I want to be able to modify resource identifiers
Here is one more good reason to rely on .exe files to make translations: They do not contain symbolic items anymore. You can then safely modify symbolic identifiers since it does not affect underlying numerical values.
Do I keep symbolic identifiers when using exe ?
No. And this is probably the only slightly valid reason to prefer .rc files over .exe files.
But it’s really not as important as one might think:
Are you going to have a distinct identifier for every string among the 1000+ in your string table ? With so many identifiers, you’ll need very long (hence difficult to manipulate) identifiers. They will not be very self-speaking anyway. Using a short number will be way more efficient (This is admittedly, to the best of my knowledge, the only occasion in the whole programming industry where identifiers are counter-productive and should be avoided). Most string literals are used only once in the source code anyway, so identifiers don’t help avoid spreading the same number all around. Strings that are used several times should have an identifier. But it’s only a few ones !
When exchanging e-mail about the meaning of a menu item, the translator will most likely write File/Save rather than ID_FILE_SAVE. Menu item names are more straightforward than their id, which usually consists in turning their text into an id anyway.
As far as translation is concerned, dialog control ids are often not helpful: Most texts are either text labels (static controls) or button texts. Static controls usually all have the same id (IDC_STATIC), making it useless to distinguish texts. And buttons will most likely be referred to by translators using their (short) text rather than their identifier. We fall here in the same case as menu items.