LANGUAGE DETECTION When dealing with the notion of language, we are faced with at least 3 different definitions:
the language used and recognized by Windows; its choice results in the selection of various code pages and language definitions. It is completely external to MI but must be adjusted to support the MI version to install.
the language used by MapInfo; MI deals with different languages by having different sets of specific files for each language, the only constraint being the compatibility with the language choice made in Windows.
the language used in an application for displaying its own menus, requesters, dialogs or messages
The "language to detect" is the MapInfo language and the purpose of this chapter is to find the best way to identify it from within a MapBasic environment. An example of the usefulness of the detection of the language in use by MI can be found in the automatic adjustment of the application language to the MI language. One challenge of that exploration will then be to find other situations where this automatic detection could be useful.
One should note immediately that the set of possible languages is a relatively open one; it has of course an upper limit but it is defined at any given moment by the languages that have been translated at that time. Furthermore, MI is in a constant evolution and translations may not always keep pace; not every language is available for each MI version.

This requires to keep a constantly updated library of all the MI "language" files in the various versions to have a way to extract the pertinent data and make sure that it is consistently in the same identifiable position.
  MI LANGUAGE FILES Two files seem to be holding all the string definitions necessary to support a language. One is a simple ASCII file accessible to anyone with a text editor; it is the MAPINFOW.MNU that contains all the menu definitions. The other requires sophisticated tools to explore and eventually correct it; MIRESnnn.DLL, with nnn representing a version number such as 550 or 600, holds all the "operational " strings used in dialogs, requesters, messages, particularly error messages, etc. There are other files with language strings, but they do not seem to have the wide scope of the MIRESnnn.dll. On my 5.5 setup I identified the following
Demo32.exe and Ds32.dll are related to the Demo Shield Designer
IDW_res.dll is used by the IDW interpolator (added with version 5.00)
Midigit.dll holds digitizer settings
MiResnnn.dll could be specialized in server support
Mitdgrc.dll seems to work with advanced graph output
Midgdgl.dll manages shortcuts and other dialogs
Roboex32.dll is the support for WinHelp 2000
Obviously some do not have the universality required (all the '32', the IDW added in 5.0 and the server connectivity added in 4.5). It would have been worthwhile exploring the possibilities offered by the remaining three if the MIRESnnn.dll and the .MNU had not been such good candidates. The .MNU experience In 1998, I started exploring the possibilities of using MAPINFOW.MNU as the source of information on language in use. I wrote a small MB to read this ASCII file until finding the string corresponding to the first item definition of the File menu and recording a variable of some 20 characters. Comparing that string to those already assigned to a language could lead to the identification; if not the new language string was added to the existing strings bank. This technique has two major flaws. One is the reliability of the information; the file is too easily and too frequently modified by the users to the point of rendering its generalized use completely doubtful for our purpose. The other is technical and emerges when dealing with different platform languages. In our experience the identified language strings were compiled in the MB program, the results being that Eastern European strings compiled on a US Western Europe platform could not be recognized on the EE platform. In any case, we would have had some doubts because that approach assumes that the menu language is the language in use. As it is very easy to switch MNU files on any MI installation, the menu language could be an indicator of the wish of the user, but not an affirmation. This technical difficulty was not in itself the doom of the .MNU technique. As we will see, at least another programming solution could avoid this pitfall. Its abandonment was essentially due to the unreliability of the data source itself. The MIRES experience Anssi Joutsemieni iniated this experience very recently (spring 2000) with his systematic exploration of the MIRESnnn.DLL file. He has written a small MB application (ErrorSim.MBX) that extracts all the strings (error messages and much more) to a text file. The analysis of that "mapinfo.err" file could help in identifying components stable across MI versions and languages. It would be of course valid for the past and present, but there is no guarantee for the future, MI and its licenced translators can decide at anytime to play with those components judged stable in the past. With that reserve in mind, we can hope that once such a component would be identified, it could be the data source for our language detection. I joined Anssi in his quest and I contributed to it by writting a small MB that reads in the MIRES file the message identified as one, and stores it in an INI file if it does yet exist in it. It appears to be a very promising approach; its details are given in the next paragraph. Since then Anssi joutsiniemi has expanded its original program and his ErrCodex.mbx comes with an array of tables , one per version, where are stored all the error strings in hex form for the languages he could find. Comparisons between versions and languages are made possible and the stability of the choice of one element for language checking can be ascertain with that tool.   The PICKLANG project The PICKLANG project is an attempt to provide developers with tools to identify the MI language and to add to the library of identified languages. It is based on the principle that a certain message error is always located in the same position of the MIRESnnn.DLL and that reading it from a DLL should be sufficient to identify the language. We have chosen error(1) that in English reads 'User-defined error: 1', that is truncated to the ':'. To avoid the problems due to the compilation on one plateform of character codes coming from a page code different from the one in use of the platform, the message string is converted in a string made of calls to the CHR$() function with the numeric codes of each character. As these numeric codes are generated on the platform in use and will be useful for recognition only on that same type of platform, the problem will be completely avoided. The second choice that was made was to expose these coded strings in an INI file. Direct access to this data bank will make managing the bank very easy; in particular additions can be done with a simple text processor, which is valuable for adding strings generated on other platforms not directly available. The ini file can also become the necessary data that developers need if they want to integrate in their applications an automatic language detection procedure. PICKLANG.ZIP is a kit containing the PICKLANG.MBX application and its PICKLANG.INI language strings file (yes, it is MLC_INI compliant) and the LANGUAGE.INI file that holds all the language identificator codes. All the necessary information on how to run the application and contribute to the project is in PICKLANG_EN.RTF that can be displayed here. The list of recognized languages in the INI is kept up to date in that document.