There are three methods to localize Windows applications. The methods are:
Binary localization works on every case except with Visual Basic where Visual Basic localization should be used.
In addition of localization methods this topic contains information about the following issues:
This is the easiest and safest localization method. Binary localization works in the following way. Each Windows application or library file (.exe, .dll or .ocx) contain resource data. Sisulizer reads the resource data and adds items that need to be localized. When creating localized files Sisulizer copies the original binary file to a new locations and replaces the original resources with the localized resources. The result binary file are identical to the original files except the resources have been localized. Windows application and library files are also called PE files (portable executable). Sisulizer can localize all known of Windows resource types such as dialog, menu, bitmap and VCL's form resources. In addition Sisulizer can localize any custom resource type.
When creating a localized file the user has several other options how to create localized files. One option is to create a single multilingual file that contains each resource in many languages. Another option is to create resource only DLLs that contains no code segments but only resource data. When you deploy the original application with these resource DLLs the application will become multilingual.
Other issues considering binary localization:
The is the old way to localize Windows applications. resource file localization works in the following way. Sisulizer reads the original resource files (.rc) to create the items in the projects. When creating the localized files Sisulizer creates localized RC files that have identical structure to the original RC files but the files have been localized.
The user has to compile the localized resource files to .res files and then link them to the application to get the localized application.
Visual Basic does not use resources to store forms and strings. This is why Visual Basic projects must be localized in a different way. The idea is to create a complete set of project files (e.g. forms, modules, etc) for each language. The structure of the files is identical to the original files - only the strings and possible form layouts have been localized to the target languages.
Every time you change your original source code your should run the build process to automatically update the localized projects(s). If you have the Sisulizer Enterprise edition you can automate this even further by using the SlMake command line tool in your make file.
Some Visual Basic applications use different approach. They uses Load event to get the string values from the string resource and assing the values to the user interface elements. When localizing such an application use the binary localization method. <sl>\VB\Binary\Converter contains a sample applications using the binary localization. However binary localization is not the recommended way to localize Visual Basic applications. use it only if your Visual Basic application already uses resource strings.
The following table compares different localization methods.
|No need for recompilation||yes||-||-|
|No source codes needed||yes||yes||-|
|Works with Visual C++ applications||yes||yes||-|
|Works with Visual Basic applications||yes*||-||yes|
|Works with Delphi applications||yes||-||-|
|Works with C++Builder applications||yes||-||-|
|Works with Other Windows applications||yes||-||-|
*) Only if the Visual Basic applications has been prepared for binary localization. See Visual Basic localization.
Our recommendation is to use the binary localization except with Visual basic applications where the Visual Basic localization should be used.
Sisulizer's VCPP directory contains Visual C++ samples, VCL directory contains Delphi/C++Builder samples, FireMonkey contains Delphi FireMonkey samples, VB directory contains Visual Basic samples.