The MLC PROJECT

The Multi Lingual Compatibility project promotes the use of various languages in MI applications. It offers ways to prepare applications for translation and to integrate them into the application.

It provides practical solutions and support in the form of documentation, basic subroutine/function libraries, examples et demos.

MLC acts as a 'leader' in this area rather than trying to impose a unique and constraining avenue. It will gain from experiences of willing contributors and may present alternative solutions, the final choice being left to the developer.

The basic motivation behind this project is to widen as much as possible the range of potential users of MB applications. One of the perceived reasons of possibly limited use of some applications is the language barrier that may exist in some places. MLC is a way to help bringing down such barriers.

MLC is directed to all developers. It is essentially a 'free' contribution to the MB world, but anyone can develop his application (freeware, shareware or commercial) while respecting the spirit of MLC and using the resources it offers.

POSSIBLE AVENUES

There are three global solutions to introduce multi lingual compatibility in MBX applications. One adopts an internal structure with all the language strings hard coded in the MBX, the other two rely on an external file for the language strings, one solution with hard coded strings in the form of a DLL, the other in a simple texte file.

IHCS(internally hard coded strings) as well as EXLS (external language strings) can be in essence unilingual or multilingual. Unilingual IHCS applications have a different MBX for each language, while all languages of a multilingual IHCS will be all contained in one executable. An EXLS application will always need 2 files, the executable and the strings file; in a unilingual application, the external string file deals only with one language and there are as many external files as languages, while all languages are listed in a single file of a multilingual program.

The distinction between external text or DLL files is mainly centered on the ease with which such files are modified: handling DLLs requires special software that not everyone may have, when there is always some text editor available nearby.

The advantages and drawbacks of each situation can best be presented as small 3x2 tables. The DLL multi-language situation is described for reason of symmetry even though all applications I have seen have been sinple language DLLs.

CODE PROTECTION
If the author is not able to translate himself in the desired languages, he must rely on others to do the work. There are certainly ways to offer to would be translators excerpts with all the necessary statements to be translated to protect the main code but that requires more work from the author that must prepare the excerpts and reinsert the translations in the main code. Short of that, the author may loose control of his code.

one language

several languages

Internally hard coded	Code protected only by offering an excerpt of strings to be translated
External DLL file	Main code fully protected no extra work required. Language strings protected from accidental changes.
External strings file	Main code fully protected no extra work required

CODE UPKEEP
This relates to the maintenance of the code itself, without consideration for the 'language' implications of those code changes.

	one language	several languages
Internally hard coded	Upkeep must be replicated on every language mb/mbx	One upkeep
External DLL file	One upkeep	One upkeep
External strings file	One upkeep	One upkeep

LANGUAGE UPKEEP
Simple corrections to language strings, due to code changes or to incorrect translations

	one language	several languages
Internally hard coded	New compilation(s) of corrected code for the concerned executable(s)	New compilation of corrected code of the unique executable
External DLL file	Corrections (DLL compiler) in the concerned language file(s)	Corrections (DLL compiler) in the language file
External strings file	Corrections (text editor) in the concerned language file(s)	Corrections (text editor) in the language file

ADDITION OF A LANGUAGE
The mechanisms for adding a language are entirely different if the code of an IHCS is not freely distributed.

	one language	several languages
Internally hard coded	If the author wants to control his code, he must create a new executable for the language.	id... , he must create a new version of the executable including the new language.
External DLL file	Addition by end user himself. New language file may be offered for general distribution without returning to the author.	Addition by end user himself. If translation is sent to author, he can consolidate the language file for general distribution.
External strings file	Addition by end user himself. New language file may be offered for general distribution without returning to the author.	Addition by end user himself. If translation is sent to author, he can consolidate the language file for general distribution.

SIZE OF FILES
One must consider the size of the MBX executable and if it applies, of the external files. The importance of that dimension may be different for the author and the end user. The author must keep all the language files, the end user can be satisfied with those related to one, to a few at the most.

	one language	several languages
Internally hard coded	Reference size for executable: code + strings for one language.	Maximum for executable: code + strings for all languages
External DLL file	Minimum for executable + as many single language DLLs as there are languages.	Near minimum executable (mini + language switching code) + as many single language DLLs as desired.
External strings file	Minimum for executable + as many single language text files as there are languages.	Near minimum executable (mini + language switching code) + one string external (~ single language file * ALL available languages)

SPEED OF TREATMENT
That measure of performance will simply be estimated from the difference in code structure. As using strings that are in the program memory is faster that having to read them as needed, the external solution may have different performances if the application reads in all the strings or only as required.

	one language	several languages
Internally hard coded	Fastest solution	Near to next fastest, requires selecting language for each string handling
External DLL file	No change in speed will most probably perceived.	Could be slightly slower because reading a bigger DLL, but no impact is expected
External strings file	Slower if strings are read as required only	Slowest if strings are read as required only because the added choice of language

LANGUAGE SWITCHING
The ease of language switching is important mainly for those who 'overlaps' cultures and who handle regularly several languages. Those users who are essentially unilingual would be less interested in that criterion.

	one language	several languages
Internally hard coded	close application and change executable	on the fly within the loaded application
External DLL file	a/ if one external only recognized by application, close application and physically switch external. b/if several external files recognized by application, on the fly within the loaded application	on the fly within the loaded application
External strings file	a/ if one external only recognized by application, close application and physically switch external. b/if several external files recognized by application, on the fly within the loaded application	on the fly within the loaded application