Version 1.5 (2014) is specifically adapted for Windows and uses the VCL library for full Unicode support. It has renewed support for use of Extrenal Translation (using Google Translate), supports the use of DRC files and has a significant number of bugs removed so that it works fine under more demanding circumstances.
This program for translating the resources of Delphi executables is originally created by Jens Kühner (2003) for Kylix applications running under Linux.
In the current version 1.5 for Windows full Unicode support is implemented. Extensions are implemented, so that you can use different translation memories in LinLocalize, such as .tmx files and .po files.
LinLocalize for Windows is a translation tool running on Windows for easy localization of your Delphi-applications. Linlocalize extracts all embedded Delphi-resources (resource strings and forms) of a Windows-PE-file (Portable Executable: shared-object-file/dynamic-link-library or executable) and writes the translated texts back to a shared-resource-file or standalone executable. Translate your Delphi-applications within one translation-tool and use the same glossaries for automatic translation. To localize for different languages, you may have to convert hard coded strings in your Delphi-source-code to resourcestrings.
Version 1.5 is written in Delphi XE, using the VCL. Probably, it can be compiled using Delphi 2009 or later, but not by earlier versions, because it needs Unicode.
DxGettext |
Borland's TM |
Linlocalize |
|
Interface |
Not integrated |
Integrated |
Integrated |
Documentation |
Manual |
Some pages in Delphi's help file |
None besides this. |
Available translated string lists |
For many languages, but they are often incomplete |
A few languages are part of the package / a few can be found on the web |
Can use DxGettext string lists |
Source |
Can obtain strings from the executable |
Uses the original source to obtain the source strings |
Extracts the source strings directly from the executable |
Executable translation |
Seeks translations in a string list during run time. Alternatively, there is a tool to integrate this in a dll or in the executable. |
Creates a language resource dll |
Creates either a language resource dll or adapts the original resource within the executable |
Translations maintenance |
Many different tools for maintenance |
A single, integrated tool for maintenance |
A single, integrated tool for maintenance |
Can adapt forms |
No |
Yes |
No |
Easy to use |
So so |
You wish |
Yes |
Usable without adding source code to your program |
Yes and No, depends on where you put the translations |
Yes |
Yes |
Costs |
None, Freeware |
"Free", when you buy Delphi Enterprsie |
None, Freeware |
Source code available |
Yes |
No |
Yes |
I have used Borlands Translation Manager for a few years. Borlands TM uses Delphi source files to create a separate source for the language dll. This has a main advantage that the other two don't have: you can adapt the forms itself to the language. When a translated string is too long, you can adapt the form especially for that language.
However, I found my self too often in difficulties, without an easy solution. It is a quirky tool indeed. For instance, it is difficult to change the source language. As a default, it is set to locale language used by Windows, in my case Dutch. As all executables are written in English, the native language of Delphi, you have to change this setting for every project to English. It is possible, but difficult to find and you have to rebuild all source files that ITM uses. Furthermore, when using complex components it is not easy to determine which resources are really needed. I ended up adding all forms that were used in the source code of the components. By the way, it cost me considerable time to discover how to add these forms, and yes, you can only do this by rebuilding the project form the bottom. It uses string lists in a Repository, comparable to Linlocalize Glossaries. You can add strings form your project to the Repository, but it doesn't ask which strings you want to export. In most cases, it exports nothing without telling you this, until you discover that you have to select the strings that you want to export. This seems logical, but as I use this tool on a very irregular basis, I tend to forget this procedure. In short, it is a tool I have learned to hate.
DxGettext exist for al long time and is a usable alternative. However, the many unintegrated tools make it difficult to use, especially on an irregular basis. Furthermore, the command line tools can give unexpected results. For instance, I have not yet discovered how to use the tool msgmerge to merge two PO files, without ending up with a file that is shorter than each of the original files.
It was a pleasant surprise to discover Linlocalize, and its description made me interested enough to try a conversion to Windows. Even though there is only a very small part that was not compatible, it cost me considerable effort to solve this problem. Most difficulties were caused by the routine that calls wensresbind.exe, which started a new process using pipes for the input and output. Probably this is much more common in Linux than it is in Windows. However, it works reasonably well. I can't get it to return with a decent error message when there is something gone wrong. After its return it says Ok, while in fact it is not ok, which is only clear from a previous message.
If you really have to localize for many different languages, it is probably best to use a professional program. When you use ITM, you'll have to accept the frustrations it can cause (BTW, do not think that I am the only one with this experience; you can find many similar complaints on the web). Furthermore, when you are an American, you will find the settings that are so uncomfortable for others just right. When you have just have to translate the strings from English to your own native language, so that your users are not confronted with English error messages, LinLocalize is much easier to use, even without a help file.
2011, Hans Landsheer