SUBJECT: Multi Lingual implementation using the TMultLang 1.131 package

* * * *
I assume you have at least gone through the Quick Step-By-Step tour in the helpfile to better understand what I will describe here on. I do not dive into any detail discussion of how Objects are actually translated or how to add languages since that should be described in the Helpfile as part of the Step-By-Step tours.

There are two major differences in having multi lingual support in Delphi and the use of the TMultLang component package.
The First, a static method by just having a few languages edited at design-time and be compiled together with your EXE when finished.
The other, a dynamic method to make the translations (edit, add or remove) anytime, even during run-time. This requires an external file to hold the Translation data since the EXE or DLL file cannot be edited after a compilation because of security reasons.

The three options below briefly describes suggested implementations of the two above methods (All supports switching languages at run-time as well as just one installation time language for the application):

* * * *
1. An application that only supports the languages designed before the Compilation of the executable files (Static, no external files needed):

 Drop the TMultLang component on all the forms you want to be translated in your application. Since this component defaults to use the form as storage of the language data we don't need to do anything except to add the languages in the Language editor.
Because Delphi uses different form files (*.DFM) for each Form we cannot share the language data between the forms with this functionality, therefor we have to add each language with the translations on all forms. It is important to use the exact name of your languages on every form, otherwise the component will later not be able to find a requested language because the name may be different on one form.
In your main form of your application, set the DefaultLanguage property of the TMultLang component to the language you always want when you start the application (in the OnCreate event of the main form). This name can for example be retrieved from an INI file which has been configured at installation time of the end-user.
If you make the TMultLang component visible or by setting the AdoptOn property to another control like the Menu, you will also be able to switch the language at run-time (That effects the whole application). You can also use the Translate method to programatically switch language when needed.

* * * *
2. An application that supports dynamic editing of languages at both Design- and Run-Time (without the need of source code; one external file *.lan will be needed):

This is the same procedure as with the first option, but instead you will need to set the ExternalFile property to the same binary data file (yourfile.lan) on all forms. This makes the languages sharable between all forms and you will be able to pick previous translations from other forms from the drop down box in the Language Editor.
By calling the Edit method of the TMultLang component at run-time you will be able to Edit, Add or Remove languages at any time for the current form.
It is very important to know that if you choose another extension than *.LAN of the binary data file it will be saved as an casual textfile (INI format) but CAN THEN NOT BE SHARABLE between other forms, if you do share a textfile the result will probably not be what you expect unless you exactly know what you are doing.

* * * *
3. An application that supports both static and dynamic editing of languages at both Design- and Run-Time (without the need of source code; one external file *.lan can be added at run-time):

This is the same procedure as with the first option. Make all the basic languages you want to support according to option 1. When you want additional languages in your application, just set the ExternalFile property of all forms to the external binary data file (yourfile.lan) which holds more languages or does not exist yet if it is the first time (will automatically be created). That can be implemented as follows:
 In the OnCreate event of all forms check a conditional statements that can be retrieved from an INI file, if you should use the external file. If it should, just set the ExternalFile property to the binary data file and it will load all additional languages when needed. Whenever you later want to edit, add or remove langauges call the Edit method.


* * * *
This also comes to the conclusion about the CTRL-ALT-E option available at design- and run-time in the TMultLang component package; the component it self is just an application like the ones you do. The dialogs of this component package like the Language Editor is just another Form which have support for different languages by having the TMultLang component included in it self.
Those forms are using option 3 described above with an implementation that invokes the Edit method by pressing the CTRL-ALT-E combination. Of course, first we have to set the MULTLANG.INI file to the binary data file before we make any translations for additional languages (as described in the Helpfile topic 'Let the agents do the translation for you').

Well, why do you need to use the CTRL-ALT-E button combination to translate the TMultLang package dialogs (NOT FOR YOUR OWN FORMS)?
It is a simple reason besides that many people (you or an agent) like to work with their own language even though they can read English. For example, as a Japanese translator you will not be able to translate messages very well unless the edit boxes uses the apropriate fonts (if not running on a Japanese version of Windows like JWin). Therefor you will need to translate the edit boxes to use the apropriate fonts in the Language Editor with this elegant dynamic solution.


The  CTRL-ALT-E key combination is only used internally by the component package dialogs and does not effect any form you drop the TMultLang component on. If you want to make an option in the Menu instead of having a keyboard combination to invoke the Edit method it is entirely up to you and the implementation used in the TMultLang package should only be seen as an example implementation method for your own application.

This is a technical paper distributed by the Author of the TMultLang package. If you have any questions please contact him via the address:
Patrik Wang
E-Mail: PWang@msn.com
Fax: +61 2 3269032
* * * *