Bien créer une application multi-langues ? Unicode ou non ?

**Maxime Abbey** · 17/07/2005, 20h57

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

**[Silk]** · 18/07/2005, 01h14

Salut,
c'est un véritable roman que tu nous a pondu ici

bon là pour ton probleme je ne peux pas vraiment t'aider mais en attendant les vrai connaisseurs :

* 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

au niveau des fichiers ini à mon avi c 'est une façon assez simple d'arriver à faire ce que tu veux.
Tout d'abord il te faut voir combien de textes tu va avoir à traduire, parce que si tu as une centaine de textes au niveau des variables pour un fichier ini ça peut etre long...

sinon je pense que ce que j'ai citer c'est trop de compliquer la vie mais si tu veux vraiment le faire tu peut toujours essayer de crypter les informations que tu va stocker dans ton fichier INI.
Il faut voir 2 choses au niveau de cryptage :
-Si tu veux vendre ton logiciel tu t'encours à ce qu'il soit piraté or meme s'il est crypté sa n'arretera pas un bon crackeur
-D'une autre part si ton logiciel est un freeware meme un cryptage de base peut suffire car pour un crackeur il n'y a aucun interet à cracker un freeware.

J'ai aussi pensé a une autre méthode ( à tester si elle t'interresse)
Sa serait d'assigner un tag à certain compos de meme type ici par exemple 50 labels, on récupère leur propriété caption et on la met dans une stringlist ou un truc du genre puis on récupère les valeur chaine de la langue qui change dan un fichier ini (par exemple lé variables 0001 0002 0003 0004 0005 etc) et on les assigne..je dit sa à la volée après a toi de voir

en esperant que j'ai pu un petit peu t'aider
a+
[Silk]

**Maxime Abbey** · 18/07/2005, 10h12

Salut,
c'est un véritable roman que tu nous a pondu ici

Ca c'est plus fort que moi, je ne peux pas m'en empêcher

au niveau des fichiers ini à mon avi c 'est une façon assez simple d'arriver à faire ce que tu veux.
Tout d'abord il te faut voir combien de textes tu va avoir à traduire, parce que si tu as une centaine de textes au niveau des variables pour un fichier ini ça peut etre long...

Grosso modo, je dirais une cinquantaine de lignes. Mais de toute façon, que ce soit par fichiers INI ou non, s'il y a beaucoup de lignes, ça sera forcément long, non

sinon je pense que ce que j'ai citer c'est trop de compliquer la vie mais si tu veux vraiment le faire tu peut toujours essayer de crypter les informations que tu va stocker dans ton fichier INI.
Il faut voir 2 choses au niveau de cryptage :
-Si tu veux vendre ton logiciel tu t'encours à ce qu'il soit piraté or meme s'il est crypté sa n'arretera pas un bon crackeur
-D'une autre part si ton logiciel est un freeware meme un cryptage de base peut suffire car pour un crackeur il n'y a aucun interet à cracker un freeware.

Mes logiciels sont tous freeware donc de ce côté-là je ne me fais pas de souci (je les passerai peut être même en open-source un jour si je vois que je ne peux plus m'en occuper), il suffirait simplement de m'assurer que les chaînes traduites dans le fichier sont bien des chaînes que l'on peut traduire, car le problème du cryptage, c'est que si je crypte les fichiers de traduction, l'utilisateur ne pourrait pas réaliser un nouveau fichier de langue, puisqu'il ne pourrait pas s'appuyer sur ceux qui existent car ils seraient illisibles pour lui

Ou alors, il faudrait que je ne crypte que les clés pour ne laisser que les valeurs à traduire en clair, mais là, c'est peut-être un peu complexe pour un simple fichier de traduction

J'ai aussi pensé a une autre méthode ( à tester si elle t'interresse)
Sa serait d'assigner un tag à certain compos de meme type ici par exemple 50 labels, on récupère leur propriété caption et on la met dans une stringlist ou un truc du genre puis on récupère les valeur chaine de la langue qui change dan un fichier ini (par exemple lé variables 0001 0002 0003 0004 0005 etc) et on les assigne..je dit sa à la volée après a toi de voir

J'avais pensé à un truc de ce genre effectivement, ou même à me servir de la propriété Tag des composants pour leur assigner un numéro qui leur correspondrait dans le fichier INI, mais je ne crois pas que je vais m'orienter vers un système de clés numérotées dans le fichier INI, parce que, moi-même, je n'aimais pas traduire des logiciels utilisant ce système car on ne savait pas où se trouvait chaque chaîne dans le logiciel...

en esperant que j'ai pu un petit peu t'aider
a+
[Silk]

C'est le cas, merci

Mais j'attends d'autres avis plus éclairés avant de me lancer dans la création de mon propre système de fichiers de langue...

**[Silk]** · 18/07/2005, 11h08

C'est le cas, merci

avec plaisir

meme si je ne t'ai pas beaucoups aidé

Mais j'attends d'autres avis plus éclairés avant de me lancer dans la création de mon propre système de fichiers de langue...

bien sur

je pensais par contre à autre chose sa te serais pas plus simple de créer un éditeur pour tes fichiers de traduction, parce qu'il faut voir aussi qu'un utilisateur experimenté (toi ou moi) arrivera à créer le fichier de traduction avec le bloc note mais un utilisateur qui s'y connai beaucoup moins va-t-il y arriver sans editeur ?
une fois encore à toi de voir...

a+

**phplive** · 18/07/2005, 14h42

Bjr

Si la langue dans laquelle tu souhaites traduire comporte plus de 256
symboles différents alors oui tu dois passer par l'Unicode et biensûr en tenir compte dans ton code.

Lu sur le net :

Les fontes chinoises utilisées sur les ordinateurs pour les traitements de texte comptent environ 6500 caractères pour la forme simplifiée et 13500 pour la forme traditionnelle.

On est loin de notre alphabet à 26 lettres ...

Visiblement tu ne désires pas stocker les traductions dans une base de données ...

Alors le mieux serait d'utiliser un fichier XML avec :
* un code langue
* un identifiant de traduction
* le texte traduit dans la langue

Ensuite je verrais bien classe spécialisée qui gérent les traductions :
langue en cours d'utilisation
chargement du fichier XML en fct de la langue choisie
méthode pour traduire à partir d'un ID, d'un libellé (en francais par ex), d'un nom de composant
méthode pour "scanner" une fiche, retrouver tous ses composants et donc la traduire

Concernant le pb de la liaison entre le composant et sa traduction :

tu peux utiliser la propriété TAG comme déjà évoqué :
trivial avec un TEdit, complexe avec un TActionMenuBar ...

tu peux aussi utiliser directement la propriété Caption ou Text lorsqu'elle existe, ce qui n'est pas toujours le cas

Enfin tu peux également rédéfinir chacun des composants et leur ajouter la prise en charge de la traduction : du sur mesure en somme.
Avec les composants de la VCL ca peut se faire, avec les composants commerciaux faut voir ...

@+
Php

**Raylemon** · 18/07/2005, 15h28

Si tu veux faire des applications multilingues facilement, je te conseille le composant DKLang (ça se trouve facilement sur Google).

Très simple d'emploi, il permet de générer des fichier lng, semblable à des fichiers ini.

Il comporte 2/3 bugs, mais rien d'insurmontable.

**Maxime Abbey** · 18/07/2005, 18h44

Envoyé par [Silk

]je pensais par contre à autre chose sa te serais pas plus simple de créer un éditeur pour tes fichiers de traduction, parce qu'il faut voir aussi qu'un utilisateur experimenté (toi ou moi) arrivera à créer le fichier de traduction avec le bloc note mais un utilisateur qui s'y connai beaucoup moins va-t-il y arriver sans editeur ?

Non, je pense honnêtement que la traduction via le bloc-notes est accessible à la grande majorité des utilisateurs... surtout que la plupart d'entre ceux qui souhaitent s'atteler à la traduction d'un logiciel doivent, à mon avis, s'y connaître un tant soit peu, et d'ailleurs, j'ai très peu vu de logiciels qui devaient être traduits via un logiciel concu par l'auteur.

Si ma mémoire est bonne, à ce jour, seul l'auteur de SnIco Edit m'a demandé d'utiliser un éditeur de sa conception pour traduire son programme en français ; et encore, grosso modo, si je me souviens bien, il ne se contentait que de proposer une liste de chaînes à l'utilisateur, avec des boutons Ajouter et Supprimer, et l'utilisateur, en cliquant sur Ajouter, devait inscrire l'identifiant de la chaîne manuellement, puis sa traduction... bref, il ne faisait rien de plus que de recueillir un identifiant, une valeur par chaîne, puis de les stocker dans un fichier LNG...

Visiblement tu ne désires pas stocker les traductions dans une base de données ...

Alors le mieux serait d'utiliser un fichier XML

Hmmm... moi, personnellement, je ne suis pas très à l'aise avec les fichiers XML, donc je ne sais pas si ça ne serait pas encore plus compliqué pour le traducteur... et, de plus, je ne vois pas ce que ce format pourrait m'apporter de plus qu'un fichier INI. Plus facile à traiter par programmation, peut-être ? Si tu pouvais me donner un exemple concret qui montre un avantage du XML par rapport à un fichier INI pour une traduction de logiciel... j'ai jeté un coup d'oeil à un projet sur SourceForge permettant la traduction de logiciels via des fichiers XML (xml10n il me semble) mais, en voyant leurs fichiers de traduction, je n'ai pas vu ce qu'il y avait de spécial qu'on ne pourrait pas réaliser avec un fichier XML...

A moins que tu ne conseilles le XML pour le support Unicode, car les pages Web peuvent supporter ce format contrairement aux fichiers INI ? Ce qui fait que je pourrais tout à fait voir des caractères asiatiques, par exemple, directement dans le navigateur XML, alors que je ne pourrais pas les voir avec un fichier texte ? Dans ce cas, en effet, je vois tout l'intérêt du XML... mais comme précisé dans mon premier post, quel bénéfice pourrais-je tirer à passer par l'Unicode ? Je veux dire, pour reprendre mon exemple des logiciels d'Antoine Potten, si tu regardes les fichiers de traduction asiatiques pour ses logiciels, tu ne vois pas les caractères asiatiques car tu n'utilises pas la même page de codes... mais si quelqu'un a pris la peine de faire une traduction dans un langage asiatique, c'est bien que le logiciel peut les afficher même s'il n'est pas Unicode... à part le fait qu'un utilisateur puisse afficher correctement tel ou tel langage quelle que soit sa localisation, que pourrait apporter l'Unicode à un logiciel ?

Enfin tu peux également rédéfinir chacun des composants et leur ajouter la prise en charge de la traduction : du sur mesure en somme.
Avec les composants de la VCL ca peut se faire, avec les composants commerciaux faut voir ...

Oui ça je crois que je vais éviter, sinon, bonjour la masse de boulot en plus...

Si tu veux faire des applications multilingues facilement, je te conseille le composant DKLang (ça se trouve facilement sur Google).

Très simple d'emploi, il permet de générer des fichier lng, semblable à des fichiers ini.

Il comporte 2/3 bugs, mais rien d'insurmontable.

En fait je l'avais déjà essayé (apparemment c'est le seul survivant en matière de composants VCL gratuits permettant de créer des applications multilingues...

) J'y avais jeté un coup d'oeil rapide, trop rapide à mon avis, car je n'avais pas trouvé comment l'utiliser... mais en relisant le fichier ReadMe je viens de m'apercevoir que c'était expliqué dans ce fichier... je ne l'avais pas vu la dernière fois, mais je cherchais plutôt une section nommée "Usage", je pensais pas trouver les instructions d'utilisation dans une section "TECHNOLOGY AND BACKGROUND"

Je vais de ce pas jeter un coup d'oeil plus sérieux à ce composant, savoir si j'aurai vraiment besoin de créer le mien ou pas ;-) Et si les bugs que tu mentionnes sont ceux décrits dans la section ISSUES/DRAWBACKS, effectivement ce n'est pas grand chose

**Raylemon** · 18/07/2005, 18h51

Bah, c'est vrai qu'il faut chipoter un peu pour savoir comment ça marche.
En fait, tu dois placer un compo DKLangManager sur chaque fiche à traduire.

Regarde aussi les démos fournies, c'est avec ça que j'ai trouvé le truc

Au niveau des bugs, c'est rien de grave. Le premier que j'ai trouvé, c'est qu'il ne reconnait pas le langage de l'application, donc pour lui la langue par défaut c'est Anglais (états-unis). Mais tu corriges ça facilement en lui passant le code de la langue que tu veux dans un OnCreate

Le second, c'est la gestion des "constantes".Si tu fais Edit Constants, dans le menu Projet, tu ne sais pas en ajouter ! Ce que je fais, c'est que j'ajoutes les constantes dans un fichier texte, et je charge ce fichier dans la boîte de dialogue.

A part ces deux-là, le reste est très simple à utiliser

**phplive** · 18/07/2005, 20h18

Décidemment le bloc note c'est une idée fixe !

Sache que seuls les blocs notes de W2000 et XP supportent l'UNICODE

D'autre part l'utilisateur qui accepte déjà de saisir les traductions se fait rare; celui qui accepte d'utiliser le bloc note encore plus rare !

A mon avis rien ne vaut une bonne vieille feuille Excel ou équivalent qu'on exporte ensuite au format CSV par ex.

Le XML effectivement sans un éditeur idoine c'est pas top.

Par contre c'est simple d'utilisation sous Delphi et bien structuré.

Autrement indépendemment de la traduction pense que tu dois être en mesure pour une fiche donnée de retrouver tous les composants et ses libellés associés succeptibles d'être traduit, aussi bien les composants statiques que ceux créés dynamiquement (ca peut arriver, c'est rare mais ca peut arriver)
... sans compter les objets COM et autres ActiveX (si tel est ton cas)

Naturellement si tu veux pouvoir changer dynamiquement de langue, le changement doit s'appliquer à l'ensemble des fenêtres de l'application et pas seulement à la fenêtre en cours. Ainsi qu'à l'aide intégrée cela va s'en dire ...

Bon courage car c'est pas simple

@+
Php

**Maxime Abbey** · 18/07/2005, 20h57

Envoyé par phplive

Décidemment le bloc note c'est une idée fixe !

Sache que seuls les blocs notes de W2000 et XP supportent l'UNICODE

Quand je dis bloc-notes, je pense plutôt à "éditeur de textes" en fait...
Pas forcément celui de Microsoft donc, mais des alternatives comme Notetab Light par exemple.
Mais je vais d'abord tester DKLang, proposé par Big, avant de songer au XML

**lil_jam63** · 19/07/2005, 00h19

Bonjour, toput d'abord la solution des fichiers ini (ou renommé en lng, etc...) est celle qui correspond le mieux à tes besoins, je te propose deux composants qui te seront utiles, le premiers fait partit de la JVCL 3.0:
- TJvgLanguageLoader
qui n'est pas très agréable et un deuxième qui est un utilitaire + composant que j'ai utilisé et qui m'a convaincu:
- GenLang
son utilisation est très simple et efficace avec par contre quelques contraintes puisqu'il utilise la propriété tag des composants

**Maxime Abbey** · 20/07/2005, 21h28

Je connaissais pas du tout GenLang... son auteur devrait le référencer sur Torry.net, où je vais souvent faire mon marché pour trouver mes composants Delphi

Elle est pas mal du tout cette suite de composants, mais c'est vrai que d'utiliser systématiquement la propriété Tag est un peu contraignant si on veut l'utiliser pour autre chose

J'ai également trouvé la suite Polycon Translator qui a l'air pas mal (je ne l'ai pas testée car je n'arrive pas à la compiler sous D2005 PE), mais sa licence est très restrictive : le composant est en GPL, on ne peut l'utiliser gratuitement que si on publie ses logiciels sous licence GPL. Pour toute autre utilisation (même non-commerciale, donc dans un logiciel freeware sans sources), il faut acquérir une licence qui est assez chère si je me souviens bien.

Puis j'ai redécouvert la solution GNU gettext for Delphi que j'avais déjà téléchargée mais jamais utilisée. Mais en fait, elle a l'air vraiment pas mal : open-source, utilisée dans de très nombreuses applications surtout dans le monde Linux (The GIMP fait partie des applications qui l'utilise, si je ne me trompe pas) et elle a l'air tout à fait adaptée à l'Unicode, puisqu'elle semble tout gérer en WideString ; couplée aux TNT Unicode Controls, elle doit permettre de faire de vraies applications multilingues et Unicode, pour peu que les fichiers de traduction soient eux aussi en Unicode. En tout cas, l'application de démo présentée sur le site affiche aussi bien les langages européens que le russe chez moi par exemple.

Le seul truc qui semble un peu moins bien avec gettext, c'est le format de fichiers langue, les "mo" et "po", qui semble un peu complexe surtout pour quelqu'un n'ayant jamais fait de programmation (le traducteur ?), et le fait qu'on doive stocker les fichiers sous une arborescence spéciale, mais je pense et j'espère que ça peut être modifié. Je jette un coup d'oeil plus approfondi à celle-ci en tout cas, même si DKLang et GenLang sont des alternatives tout aussi convenables !

**Lusso** · 17/03/2007, 00h04

Envoyé par lil_jam63

- GenLang
son utilisation est très simple et efficace avec par contre quelques contraintes puisqu'il utilise la propriété tag des composants

Et est-ce qu'il est possible de traduire des chaines avec cet outil ?

**Raylemon** · 17/03/2007, 01h40

Pour revenir à ce que disais Maxime Abbey à propos de dxgettext, je l'ai découvert il y a quelques temps, et je n'utilise plus que ça. Il gère entièrement la traduction. On peut soit utiliser des resourcestring (ce que je fais le plus souvent), soit utiliser la fonction _() (pratique quand on veut traduire une application existante).

Il est vrai que la gestion des fichers .mo et .po est un peu fastidieuse, mais il suffit d'utiliser poEdit, un programme gratuit, qui permet d'extraire, traduire et compiler les fichiers de langues.
DxGettext permet aussi des traductions "a chaud", sans devoir redémarrer le programme.

D'ailleurs, la JVCL possède aussi le dxgettext (jvgnugettext, je crois).

**defluc** · 17/03/2007, 11h59

Bonjour

Dilemme :

Si

on doit pouvoir changer de langue à la volée (en gros, pas question de redémarrer le logiciel pour changer de langue)

, selon le nombre de chaines à traduire, la traduction rique d'être très longue s'il faut lire un fichier de langue et affecter les variables à chaque demande de traduction.

Si chaque fichier de langue est lu au démarrage de l'application et affecté à une StringList par fiche, la traduction sera très rapide mais, dans la source, il faudra bien repérer à quel indice de la liste correspond la chaine à traduire, ce qui est plus fastidieux. De plus, les ressources utilisées par les listes peuvent être conséquentes.

**Okaryn** · 17/03/2007, 12h32

Hello,

Si tu veux, j'ai réalisé un petit composant qui permet de lire des données à partir d'un fichier ini pour traduire les caption et hint d'une application ou d'une form en 1 fois.

Il y a également une section libre pour retrouver des messages à afficher.

Si le nom d'un composant commence par un "_", le caption n'est pas traduisible.

http://trafalga.free.fr/multilangage.zip (sources + exemple)

A++

**defluc** · 17/03/2007, 12h40

Ok pour les Caption, les Text, les Hint, les Tstrings des Memos.

Mias pour les messages envoyés par l'application ....

**Okaryn** · 17/03/2007, 13h20

Au lieu de faire un message avec le texte en dur, il suffit de lire dans le fichier de traduction la ligne correspondante, repérée par un identifiant simple.

**defluc** · 17/03/2007, 14h55

Ca, je le savais, mais c'est parce que tu ne parles pas des messages mais seulement des caption et des hint pour ce qui est de ton composant. Alors, je me demandais s'il traitait aussi mes messages.