Le projet MLC

Le projet de Compatibilté Multi Lingue encourage l'usage de différentes langues dans les applications MapInfo. Il offre des moyens de préparer les applications pour leur traduction et d'intégrer les diverses traductions dans les applications.

Il offre des solutions pratiques et des aides sous la forme de documentation, de bibliothèques de sous-routines /fonctions, des exemples et démonstrations.

MLC agit comme un 'leader' dans ce domaine plutôt que d'imposer une approche unique et contraignante. Il s'enrichira de l'expérience de contributeurs volontaires et pourra présenter des solutions alternatives, le choix final appartenant au programmeur.

L'intention principale de ce projet est d'étendre le plus possible la gamme des utilisateurs potentiels des applications MI. Un des freins à la dissémination de ces applications est sans aucun doute la barrière de la langue qui peut exister dans bien des pays. MLC se veut un moyen de faire tomber cette barrière.

Mais au-delà de cette barrière, il existe d'autres contraintes provenant en grande partie des installations même de MI. De nombreuses anciennes versions de 'MI for Windows' existent encore dans le monde, et la compatibilité 'à rebours' des applications MB est assez limitée (MI5.5 ne peut pas charger une application MB6.0). La philosophie de MLC se traduit donc en partie par une requête aux programmeurs de compiler leurs applications avec la version de MB la plus ancienne qui soit compatible avec les éléments du code utilisé dans leurs programmes et à laquelle ils ont accès.

MLC s'adresse à tous les programmeurs. C'est une contribution essentiellement gratuite au monde du MB, mais n'importe qui peut développer une application (gratuite, contributive ou commerciale) tout en respectant les principes de MLC et en utilisant les ressources qu'il offre.

PISTES POSSIBLES

Il y a trois types de solution pour introduire la compatibilité multi-lingue dans des applications MBX. Une adopte un structure interne dans laquelle toutes les chaînes de langue sont codées dans le MBX alors que les deux autres dépendent de fichiers externes pour les langues; pour une de celles-ci, les phrases sont codées dans un DLL alors que dans l'autre, elles sont dans un simple fichier texte.

Le codage des phrases dans le MBX autant que le recours à des fichiers externes peut être uni-lingue ou multi-lingue. Pour les applications "internes" uni-lingues, il faut avoir un MBX pour chaque langue alors qu'une multi-lingue aura les phrases de toutes les langues codées de façon interne. La solution avec fichier externe requière toujours deux fichiers, le MBX et le fichier texte. Encore ici, un fichier externe peut correspondre à un seul language, ou tous les languages peuvent être dans le même fichier.

La distinction entre un fichier externe texte et un DLL tient surtout à la facilité avec laquelle ils sont créés et modifiés: travailler sur des DLLs exige un logiciel sécialisé que tout le monde n'a pas nécessairement alors qu'un simple traitement de texte est suffisant dans l'autre cas.

Les avantages et inconvénients de chaque solution peuvent être mieux présentés sous la forme de petits tableaux. Les DLL multi-lingues sont inclus bien que je n'ai trouvé à ce jour que des applications DLL uni-lingues.

PROTECTION DU CODE
Si l'auteur n'est pas capbale de traduire lui-même dans les langues voulues, il dépend du travail des autres. Il peut certainement trouver des moyens d'offrir aux traducteurs éventuels des extraits de tous les énoncés à traduire pour protéger son code mais ceci requière plus de travail de l'auteur qui doit préparer les extraits et réinsérer les traductions par la suite. Sinon, l'auteur perdrait le contrôle de son code.

une langue

plusieurs langues

Codage interne	Code protégé seulement en offrant en "extrait" les phrases à traduire
DLL externe	Code complètement protégé; aucun travail supplémentaire requis. Les phrases sont aussi protégées contre un changement accidentel.
Fichier texte externe	Code complètement protégé; aucun travail supplémentaire requis.

MISE À JOUR DU CODE
Ceci concerne la mise à jour du code lui-même, sans prendre en considération les conséquences sur les "phrases".

	une langue	plusieurs langues
Codage interne	La mise à jour doit être répétée sur chaque MB/MBX	Une mise à jour
DLL externe	Une mise à jour	Une mise à jour
Fichier texte externe	Une mise à jour	Une mise à jour

MISE À JOUR DES LANGUES
Mise à jour des phrases, suite à un changement de codes ou de mauvaises traductions

	une langue	plusieurs langues
Codage interne	Nouvelle(s) compilation(s) de code corrigé pour l(es) exécutable(s) concerné(s)	Nouvelle compilation de code corrigé pour l'unique exécutable
DLL externe	Corrections (avec compilateur de DLL) du(es) fichier(s) de langue impliqué(s)	Corrections (avec compilateur de DLL) du fichier de langue unique
Fichier texte externe	Corrections (éditeur de texte) du(es) fichier(s) de langue impliqué(s)	Corrections (éditeur de texte) du fichier de langue unique

ADDITION D'UNE LANGUE
Les mécanismes d'ajout d'une langue sont entièrement différents si le code d'une application avec codage interne n'est pas librement distribué.

	une langue	plusieurs langues
Codage interne	Si l'auteur veut garder le contrôle de son code, il doit créer un exécutable pour la nouvelle langue.	id... , il doit créer une nouvelle version de l'exécutable incluant la nouvelle langue.
DLL externe	Addition par l'utilisateur même. Le nouveau fichier de langue peut être mis en distribution sans être retourné à l'auteur.	Addition par l'utilisateur même. Si la traduction est envoyé à l'auteur, il peut consolider le fichier de langues pour distribution générale.
Fichier texte externe	Addition par l'utilisateur même. Le nouveau fichier de langue peut être mis en distribution sans être retourné à l'auteur.	Addition par l'utilisateur même. Si la traduction est envoyé à l'auteur, il peut consolider le fichier de langues pour distribution générale.

TAILLE DES FICHIERS
On doit prendre en compte la taile du MBX et s'il y en a des fichiers externes. L'importance de cette dimension peut être différente pour l'auteur et l'utilisateur. Si l'auteur se doit de conserver tous les fichiers externes, l'utilisateur peut ne garder que celui ou ceux dont il a besoin.

	une langue	plusieurs langues
Codage interne	Taille de référence pour l'exécutable: code + phrases pour une langue.	Maximum pour exécutable: code + phrases pour toutes les langues
DLL externe	Minimum pour exécutable + autant de DLL que de langues.	Près du minimum exécutable (mini + code pour changer de langue) + autant de DLL que de langues désirées
Fichier texte externe	Minimum pour exécutable + autant de fichiers textes que de langues.	Près du minimum executable (mini + code pour changer de langue) + un fichier externe (=~ un fichier texte de langue unique * nombre de langues)

VITESSE DE TRAITEMENT
Nous estimerons cette mesure de performance à partir de la strucutre du code. Comme d'utiliser des phrases en mémoire (déjà codées) est plus rapide que de les lire au fur et à mesure des besoins, la solution externe pourraient avoir une performance différente si toutes les phrases étaient lues en une seule fois.

	une langue	plusieurs langues
Codage interne	Solution la plus rapide	Presque la plus rapide, requière une sélection de langue pour chaque traitement de phrases
DLL externe	Perte de vitesse probablement imperceptible.	Pourrait être plus lente à cause de la taille du DLL, mais probablement pas perceptible
Fichier texte externe	Plus lente si les phrases sont lues au besoin	La plus lente si les phrases sont lues au besoin à cause de la taille du fichier externe.

CHANGEMENT DE LANGUE
La facilité de changer de langue est importante surtout pour ceux qui vivent entre deux cultures et qui utilisent deux ou plusieurs langues régulièrement. Les utilisateurs uni-lingues seront moins intéressés sur ce point.

	une langue	plusieurs langues
Codage interne	Fermer l'application et changer l'exécutable	Sans interruption lorsque l'application est chargée
DLL externe	a/ si l'exécutable ne reconnait qu'un seul DLL, fermer l'application et intervertir les DLL . b/ si l'exécutable peut choisir entre plusieurs DLL, sans interruption lorsque l'application est chargée	Sans interruption lorsque l'application est chargée
Fichier texte externe	a/ si l'exécutable ne reconnait qu'un seul DLL, fermer l'application et intervertir les DLL . b/ si l'exécutable peut choisir entre plusieurs DLL, sans interruption lorsque l'application est chargée	Sans interruption lorsque l'application est chargée