DÉTECTION DE LA LANGUE Parler de langue invoque au moins trois contextes différents:
la langue utilisée et reconnue par Windows: son choix résulte de la sélection de certaines pages de code et de la définition de la langue même. Il est complètement extérieur à MI et doit être ajusté pour supporter la version de MI à installer.
la langue utilisée par MapInfo: MI requière différents ensembles de fichiers spécifiques à chaque langue, un seul ensemble étant présent en même temps. La seule contrainte est la compatibilité avec la langue de Windows.
la langue d'application: utilisée par un programme mbx pour afficher ses propres menus, ses dialogues, ses messages
La "langue à détectert" est celle utilisée par MapInfo et le but de ce chapitre est de trouver la meilleure façon de l'identifier à partir de l'environnement MapBasic. On peut trouver un exemple de l'utilité de la détection de la langue dans l'ajustement automatique de la langue d'application à celle de Mapinfo. Mais les exemples d'application en sont rares encore et un des challenges de cette opératioon sera d'en trouver d'autres.
On peut noter immédiatement que l'ensemble des langues possibles est relativement ouvert; il a naturellement une limite supérieure mais à un moment donné il peut être défini par le nombre de langues dans lesquelles MapInfo a été traduit. De plus, MI est en évolution constante et les traductions ne suivent pas toujours la cadence; toutes les langues ne sont pas disponibles pour chaque version de MI.

Ceci exige de conserver à jour une bibliothèque de tous les fichiers de "langue" pour les différentes versions pour pouvoir toujours accéder aux données pertinentes et s'assurer qu'elles occupent la même position dans les fichiers.
  FICHIERS DE LANGUE DE MI Deux fichiers contiennent les chaînes de caractères qui semblent nécessaires pour supporter une langue. L'un est un fichier en texte ASCII accessible avec un simple éditeur de textes : dans MAPINFOW.MNU se trouvent toutes les définitions des menus, menus en contexte, barres d'outils. Pour explorer et éventuellement modifier l'autre, il faut un outil beaucoup plus sophistiqué; MIRESnnn.DLL, avec nnn représentant un numéro de version tel que 450 or 600, contient toutes les phrases "opérationelles " des dialogues, messages, en particulier les messages d'erreurs, etc. Il y a d'autres fichiers avec des phrases de "langues", mais d'une envergure bien moindre que MIRESnnn.dll. Sur mon installation MI5.5, j'ai identifié les suivants (certainement pas une liste limitative)
Demo32.exe et Ds32.dll utilisés par Demo Shield Designer
IDW_res.dll appelé par l'interpolateur IDW (ajouté dans la version 5.00)
Midigit.dll conserve les réglages d'une table numérisante
MiResnnn.dll serait spécialisé dans le support de serveur
Mitdgrc.dll impliqué probablement avec la production de graphiques "avancés"
Midgdgl.dll pour la gestion des raccourcis et autres dialogues
Roboex32.dll supporte WinHelp 2000
Il est bien évident que certains fichiers n'ont pas l'universalité requise (les dlls spéciales pour la version 32 de Windows, IDW ajouté en 5.0, connectivté du serveur en 4.5). Il aurait peut être été intéressant d'explorer les potentiels des 2 restant mais les possibilités offertes par MIRES and .MNU en faisaient de très bons candidats. L'expérience avec .MNU En 1998, j'ai commencé à explorer les possibilités offertes par MAPINFOW.MNU comme source d'information sur la langue de MI. J'ai écrit un petit MBX pour lire ce fichier ASCII jusqu'à trouver la chaîne correspondant au premier item du menu Fichier et l'enregistrant sous la forme d'une variable de 20 charactères. En comparant cette chaîne à celles de langues déjà reconnues, l'identification devenait possible; si la chaîne n'était pas trouvée, elle était enregistrée comme nouvelle langue. Cette technique a deux problèmes majeurs. Le premier est la fiabilité de l'information; le fichier est trop facilement et trop fréquemment modifié par les utilisateurs au point que son utilisation de façon généralisée peut être mise en doute. Le second est plus technique et apparait quand on change de plateforme de langue. Dans notre expérience, les chaînes d'identification de langues étaient compilées dans le MBX, ayant pour résultat que les phrases "d'europe de l'est" compilées sur une installation "USA, europe de l'ouest" ne pouvaient plus être reconnues sur la plateforme précédente. De toutes façons, il serait resté une question en suspens car cette approche est basée sur la croyance que la langue du menu est la langue de MI. Or il est très facile de changer de fichier MNU sur n'importe quelle installation (une façon de "...iser" partiellement une installation quand MI n'est pas disponible dans la langue en question); la langue du menu ne serait qu'une indication de l'intention de l'utilisateur et non un fait concret. Cette difficulté technique n'a pas été en soi la condamnation de la technique .MNU . Comme nous le verrons, il y a au moins une autre solution programmatique qui l'évite. Ce fut plutôt le manque de fiabilité de ce type de fichier comme source de l'information qui fut la cause de son abandon. L' expérience MIRES Anssi Joutsemieni a lancé son expérience plus récemment (printemps 2000) avec une exploration systématique du fichier MIRESnnn.DLL. Il a offert un MBX (ErrorSim.MBX) qui extrait toutes les chaînes (messages d'erreurs et bien d'autres chose) pour les placer dans un fichier texte. L'analyse de ce fichier résultat ("mapinfo.err") devrait permettre d'identifier un composant stable quelle que soit la version ou la langue (un composant est essentiellemnt un numéro de "message" ayant la même signification dans toutes les langues). Si un tel composant existait ce ne serait quand même pas une garantie pour le futur car MI ou un de ses distributeurs licenciés se chargeant de la traduction pourrait à n'importe quel moment modifier l'utilisation faite de ce numéro de "message". Avec cette réserve à l'esprit, nous espérons qu'un tel composant pourra être identifié et devenir la clé de l'identification de langue. Je me suis joint à Anssi dans sa recherche et j'ai contribué en écrivant un MBX qui lit dans MIRES un certain message and l'emmagasine dans un fichier INI s'il n'existe pas déjà. Cette approche apparait très prometteuse et des détails en sont fournis au paragraphe suivant. Depuis lors Anssi joutsiniemi a développé son programme et le dernier né ErrCodex.mbx vient avec un ensemble de tables MapInfo (une table par version) où sont stockées toutes les chaînes en format hexadecimal pour chaque langue qu'il a pu rencontrer. Il est maintenant possible de comparer versions et langues, et de vérifier la stabilité de tout élément.   Le projet PICKLANG Le projet PICKLANG est un essai de fournir aux développeurs des outils pour identifier la langue utilisée par MI et pour ajouter à la bibliothèque des langues déjà identifiées. Il est basé sur le principe qu'un certain message d'erreur est toujours localisé dans la même position dans le fichier MIRESnnn.DLL, et que de lire cette position du fichier serait suffisant pour identifier la langue. Nous avons choisi l'erreur 1; pour en voir le contenu sur votre machine, entrez et soumettez "error(1)" dans la fenêtre MapBasic. En anglais, son libellé est "User-defined error: 1". En français, c'est à s'en arracher les cheveux "Erreur user-define: 1" (bravo, ADDE). Nous avons retenu ce libellé tronqué après le : Pour éviter les problèmes dûs à la compilation sur une autre plateforme de charactères codés provenant d'une page de code différente de celle utilisée sur la plateforme, la chaîne de caractères est convertie en une série d'appels à la fonction CHR$() avec les codes numériques de chaque caractère. Comme ces codes ont été générés sur une plateforme identique à celle utilisée pour la reconnaissance de la langue le problème de distorsion des codes est compètement évité. Le second choix dans ce projet fut d'exposer les phrases codées dans un fichier INI. Pouvoir accéder directement à cette banque de données en facilitera la gestion; en particulier, les additions peuvent être faites avec un simple traitement de texte, ce qui est important pour ajouter l'identificateur d'une plateforme pas directement accessible. Le fichier INI peut aussi devenir la donnée de base que les programmeurs pourraient intégrer dans leurs applications avecune procédure de détection automatique de la langue. PICKLANG.ZIP est un kit contenant l'application PICKLANG.MBX et son fichier PICKLANG.INI de phrases de "langue" (oui, il se conforme aux standards MLC_INI), et le fichier LANGUAGE.INI où sont stockés les codes d'identication des langues. Toute l'information nécessaire sur comment utiliser l'application et contribuer au projet est dans PICKLANG_FR.RTF que l'on peut consulter ici. La liste des langues reconnues est gardée à jour dans ce document.