Salut à tous,  
 
Je travaille sur une application écrite en Borland C 3.1 sous DOS et je cherche des solutions alternatives pour gérer les langues en général. Petite explication...  
 
Par gestion des langues j'entend la gestion de tous les messages qu'une application produit :  
- le titre de l'application
- les prompts (ex. Entrez votre mot de passe)
- les messages d'erreur ( ex. Mot de passe erroné!)
- etc...
 
Cette problèmatique est triviale en France car il ne faut pas supporter plusieurs langues comme en Belgique ( ce qui est le cas ici, vous l'aurez deviné :-). L'application actuelle supporte le Français, Néerlandais, l'Allemand, l'Anglais et d'autres langues pourraient suivre!
 
La solution dont j'ai hérité est ( en gros) une librairie C qui définit un tableau à deux dimensions. Le premièr index est le numéro du message ( celui-ci est définit dans une énumération), le deuxième index étant la langue. Chaque message est hardcodé dans cette librairie dans les différentes langues...
 
Solution simple il est vrai mais pas très élégante. Beaucoup d'inconvénients, par exemple la modification d'un message entraine la recompil de toutes les app qui utilisent cette librairie alors qu'elles ne sont pas forcément concernées...
 
Merci pour votre avis sur cette question!  
 
Avander
 
 
 
 

Tu peux essayer de t'inspirer de ce que propose Java avec ses fichiers de propriétés (classe ResourceBundle dans le package java.util).
 
Un fichier de propriétés est un fichier texte composé simplement de lignes "clé = valeur". Une clé est une suite de caractère alphanumériques, de points, de tirets, et d'underscores. La valeur peut contenir tout caractère et se termine à la fin de la ligne ; le backslash est un caractère d'échappement (classique) pour les séquences \n, \r, ... et pour pouvoir écrire la valeur sur plusieurs lignes.
Les commentaires sont possibles : ce sont les lignes commençant par un dièse.
 
Enfin, et ce n'est pas la moindre des fonctionnalités, le système a la notion de localisation, sous la forme "langue[_région[_variant]]", ce qui permet à un fichier de ressources "toto" d'être écrit sur plusieurs fichiers, par exemple : "toto" (toutes langues), "toto_en" (anglais générique), "toto_en_US" (anglais américain), "toto_en_GB" (anglais britaninique), "toto_fr" (français générique), "toto_fr_FR" (français de France), "toto_fr_CA" (français du Canada), "toto_fr_BE" (français de Belgique), ...
Ainsi, si la localisation courante est français du Canada ("fr_CA" ), le système va chercher ses messages, désignés par des clés uniques à chaque message, dans "toto_fr_CA". S'il y en a un qu'il ne trouve pas, il regardera automatiquement dans le fichier "français générique", donc "toto_fr" ; et s'il ne le trouve toujours pas, il cherchera dans le fichier "toutes langues", soit "toto". Et là, s'il n'a toujours rien trouvé, alors il dira que le message n'est pas connu (en Java, une exception MissingResourceException est levée).
 
Gros avantage : les fichiers qui définissent les messages des variants ne redéfinissent que les messages pour lesquels les mots sont différents. L'essentiel des messages est stocké dans le fichier de langue générique => duplication des messages limitée au maximum. Autre avantage : si tu utilises le fichier "toutes langues" comme contenant les messages dans la langue par défaut (typiquement, l'anglais), tu géreras de manière élégante les langues non connues => dans ces langues-là, les messages seront correctement affichés, mais dans la langue par défaut. Et supporter une nouvelle langue ou un nouveau variant sera extrêmement simple : il suffira de rajouter le fichier langue ou variant correspondant, sans avoir à recompiler quoi que ce soit.

Une methode qui marche pas mal:  
Tu definis en dur une table avec des noms symboliques pour tes messages d'erreurs, et le message en anglais associes.
Ce seront les valeurs par defaut de tes messages.
Tu utilises le nom symbolique dans ton code.
Tu crées des fichiers associes pour chaque langue, avec une entrée nom symbolique - message localisé.
Au lancement de ton appli, tu lis la table des messages localises, et tu crée en dynamique une table des messages d'erreur du programme initialisée soit par un message localisé, soit par la valeur par defaut s'il n'y a pas d'entrée localisée correspondante dans ton fichier.
 
[Remarque en passant:]
Ca ca marche pour tout ce qui n'est pas un element d'interface; comme tu es en DOS, tu n'as a priori pas trop de pb d'interface .
Pour l'interface, sous windows, tu réécris le code gerant ton interface en dynamique (tu ne passe pas par des ressources) et tu appliques la méthode precedente.
[fin de la remarque en passant.]
 
A+,

 
Sous windows tu peux très bien utiliser des ressources, suffit de les modifier de façon dynamique.

Merci pour vos réflexions très instructives!
 
Avander

C'est la méthode que je proposais, en plus simple (et en mieux expliquée ). Un inconvénient, cependant : quand les messages en anglais changent, il faut quand même recompiler l'application.

Pas vraiment: Tu crees un fichier externe pour l'anglais aussi. C'est toujours mieux (a mon avis) quand une methode est completement cohérente, et ne crée pas de cas exceptionnel.
A+,