Bonjour à tous,
Je souhaiterais transformer mes applications en véritables logiciels multi-langues. En gros, je souhaiterais faire un peu comme pour les logiciels d'Antoine Potten (je pense qu'il fréquente ce forum, non ), avec les caractéristiques suivantes :
- l'utilisateur doit pouvoir créer de lui-même un fichier de langue, sans avoir à me le demander ou à utiliser un outil spécial pour ça (donc, à priori, bannir les solutions à base de DLLs ou autres et privilégier le stockage des langues dans un fichier INI, éditable avec n'importe quel éditeur de texte)
- on doit pouvoir changer de langue à la volée (en gros, pas question de redémarrer le logiciel pour changer de langue)
J'ai donc essayé, avant de me lancer dans la programmation de mon propre système de gestion de langages, des composants "prêts à l'emploi", parmi lesquels Balmsoft Polyglot.
Celui-ci me convient parfaitement, mais il semble buggé car il affiche parfois des chaînes vides au lieu des chaînes traduites (je ne sais plus pour quelle raison, il faudrait que je recherche), n'est plus à jour, et le site des auteurs n'est plus accessible.
N'ayant pas trouvé de meilleure solution à l'heure actuelle que ce composant, niveau prix (gratuit pour une utilisation non commerciale), simplicité de mise en oeuvre, fonctionnalités offertes et facilité de création de nouveaux fichiers de langue pour l'utilisateur final, je pensais donc à créer mon propre système.
Mais je me pose quelques questions :
- doit-on gérer les tables de caractères qui peuvent changer d'une langue à l'autre, et si oui, comment ? Par exemple, si moi, en tant qu'européen, je regarde un fichier de traduction japonaise, je verrai des signes ne correspondant pas à la table de caractères utilisée par le langage (exemple sans signification : éèöï), mais l'utilisateur japonais verra, lui, les bons caractères ; si j'insère les caractères tels quels dans mon logiciel, sans me soucier de changer ou non la table de caractères, je verrai certainement ces signes sans signification, mais l'utilisateur japonais verrait-il les bons caractères dans mon logiciel, comme il les verrait en éditant directement le fichier de traduction ?
- dans le même ordre d'idée, est-il vraiment nécessaire qu'un logiciel multi-langues soit Unicode ? Ca me permettrait par exemple de voir des caractères japonais au sein de mon logiciel (alors que je peux peut être pas les voir en éditant le fichier de traduction), mais cela ne serait-il pas contraignant ? Je veux dire, les fichiers de traduction peuvent-ils (et doivent-ils) être Unicode également ? Y'a t-il des manipulations supplémentaires à faire pour transformer du code de manipulations de chaînes "normales" pour qu'il puisse manipuler des chaînes Unicode, à part modifier tous les types en WideString ou autre ? Dois-je utiliser une suite de composants Unicode tels que les TNT Unicode Controls, ou Delphi 2005 PE possède t-il un meilleur support de l'Unicode que D7, par exemple, en mode Win32 (et non .NET) ? Un programme Unicode reste-il compatible avec un OS non-Unicode tel que Windows 9x ?
- quelle est, selon vous, la meilleure structure à adopter pour les fichiers de traduction ? Je pense retenir les fichiers INI, mais à part ça ? J'ai déjà traduit au fil des années plusieurs programmes multi-langues, donc j'ai déjà eu à faire à plusieurs syntaxes et j'ai pu, je pense, peser le pour et le contre de chacune :
* donner des numéros aux chaînes à traduire dans le fichier INI (ex : "000000=Bienvenue", "000001=Options du logiciel", etc.) ; à mon avis, difficile à gérer niveau programmation, car il faut en quelque sorte assigner un numéro à chaque chaîne à traduire, et on ne sait pas forcément à quelle chaîne correspond quel numéro ; avantage non négligeable pour le traducteur en revanche, il saura facilement où se trouvent les nouvelles chaînes à traduire pour mettre à jour son fichier de langue lors de la sortie d'une nouvelle version du logiciel, car il a qu'à retenir le numéro de la dernière chaîne qu'il avait traduite la fois précédente pour savoir que tous les numéros qui suivent sont des chaînes non encore traduites.
* donner un identifiant unique à chaque chaîne, mais plus explicite qu'un numéro ; avantage pour le programmeur, il devient plus facile de savoir à quelle chaîne correspond un identifiant, mais il faut toujours avoir à assigner et à gérer un identifiant unique par chaîne, et contrairement à un système avec numérotation, le traducteur ne sait pas vraiment qu'une chaîne est une nouvelle chaîne à traduire...
* utiliser une syntaxe spéciale comme identifiant dans les fichiers INI, similaire à celle de Delphi par exemple ("FormMain.Label1.Caption=Label Principal") ; avantage peut-être pour le programmeur, ce doit être plus facile à gérer, plus d'identifiant unique à utiliser, il suffirait d'écrire une fonction qui lit le fichier INI, décompose chaque valeur (dans mon exemple, s'il lit "FormMain.Label1.Caption dans le fichier INI, il devra savoir qu'il devra aller modifier la propriété Caption du composant Label1 sur la fiche FormMain, avec la valeur donnée à la clé dans le fichier INI) ; inconvénient, ça dévoile aux traducteurs la structure du programme et ça permettrait à un traducteur malin et connaisseur - et si la fonction de lecture du fichier INI n'est pas protégée contre ça - de traduire des chaînes non souhaitées par l'auteur, par exemple, en créant une clé FormMain.Caption dans son fichier de traduction, de changer le titre de la fiche :s
Je pense que cette dernière syntaxe est la meilleure, mais si vous avez d'autres suggestions
En bref, je souhaiterais connaître vos expériences et opinions sur le sujet, si vous avez déjà eu à créer des applications multi-langues, quels choix avez-vous faits ? Avez-vous eu à revenir sur un de ces choix (composants tout prêts ou système programmé par vos soins ? Fichiers INI ou non ? Unicode ou non ? Gestion de la table de caractères ? Quelle structure pour vos fichiers de traduction ? etc.)
Merci à toutes les personnes qui auront eu le courage de me lire jusqu'à la fin et surtout à celles qui prendront le temps de me répondre
Partager