Localisation d'une application (Delphi 2009)

J'ai une grosse application (50 formes) que je voudrais "traduire" en anglais.
Je me suis déjà arrangé pour que tous les messages internes soient rassemblés dans une seule unité donc, de ce côté-là, pas de problème.
J'ai "ajouté" l'anglais UK (ENG) comme langue et je l'ai activée (pour mes tests).
Delphi a créé le répertoire ENG et y a copié tous les DFM et créés des DFN.
J'ai commencé à utiliser l'éditeur de traductions pour les formes.
Après avoir traduit les infos texte françaises en anglais, j'ai tout sauvé et compilé.
Delphi m'a créé la DLL ENG correspondante, mais quand j'exécute l'application, c'est toujours en français !
J'ai jeté un coup d'oeil dans la DLL : les textes sont en français.
Je suis "remonté" vers les DFM du répertoire ENG, ils sont en français et inchangés !
Les DFN sont corrects : quand je redémarre le traducteur sur un DFM traduit, c'est correct et si je demande de me montrer la forme traduite, elle l'est bien.
Le problème est donc que Delphi n'a pas fait suivre les modifications de traduction depui (je présume) les DFN vers les DFM
Que faire ?

Je ne connais pas le système de traduction de Delphi, j'ai toujours trouvé pénible qu'il y ait plusieurs versions de DFM !

Je t'explique un mécanisme de traduction que j'ai vu utilisé en D5 à D7 ainsi qu'en BCB5 et BCB2007 mais pour VisualC++6
Ce n'est pas mon idée, mais au moins 4 personnes dans 4 sociétés différentes, 2 françaises et la 3eme belge et la 4eme Coréenne ont eu la même idée, à des degrés d'intégration et d'élégance différente du code !
Là où je travaille actuellement, libellé, message, sql tout est dans des fichiers ini avec ce mécanisme

Si tu as le courage, ce n'est pas très dur !
Cela peut se faire par RTTI (juste IsPublishedProp et SetPropStr\GetStrProp) et un fichier Ini
Si tu ne veux pas faire de RTTI, une gestion par transtypage et un code plus spécifique à chaque est envisageable même si moins élégant !
Tu fais des rubriques avec le nom de la classe de la DFM, les clés de la forme ObjPublié.PropriétéPubliée, ainsi tu peux gérer le Caption, Text, Hint ...


Lors du constructeur de la classe fenêtre (tu peux faire un ancêtre qui remplace le TForm)
Tu lance la fonction de Traduction, elle va parcourir les Components de la Form
si présent dans le Ini, cela prend la traduction du fichier
si absent, cela ajoute la valeur par défaut dans le Ini

Ensuite, tu n'as qu'à modifier les Ini avec NotePad, ajouter une langue se fait sans douleur nouveau Ini (un petit menu dans l'appli pour ajouter une langue avec son ini), pas besoin de recompiler !

Petit défaut, la gestion des libellés de différentes tailles, c'est l'avantage d'avoir plusieurs DFM, on peut adapter l'écran en fonction de la langue
Mieux vaut écrire les textes en français et prévoir une marge (le portugais peut être plus long, l'anglais est souvent plus court)

Autre défaut, Cela oblige d'ouvrir chaque fenêtre en RunTime
On peut aussi le faire en DesignTime via un RegisterComponentEditor de la fenêtre ancêtre qui permet de gérer la création de l'Ini via l'IDE

Autre défaut, Après faut penser à l'Unicode est au alphabet non latin !
Je n'ai jamais expérimenté de l'Ini Unicode en Delphi, mais je l'ai vu en VSC++6 dans un programme de démo d'un fabricant de DVR

Gros Avantage, outil simple, facile à mettre en place, pas de recompilation, maitrise de l'outil, pas de risque de voir l'outil de traduction changé à chaque version de l'IDE ou ayant des problèmes de rétro-compatibilité, pas besoin d'une version Entr ou Archi !

J'ai aussi utilisé, Multilizer qui gérait des fichiers XML pour son projet et des fichiers LNG, idem pas besoin de recompiler des DLL, suffit de fournir le fichier LNG, et avec les fonctions Translate de Multilizer, on peut convertir d'un coup tout un écran
L'outil de Traduction ressemble à celui de Delphi, c'est à s'y tromper !
Il est tout aussi pénible ! clic ici, clic là, ça vaut pas un UltraEdit



EDIT : Perso, une fois j'ai failli être recruté pour m'occuper de l'internalisation, il me semble via les outils de Delphi, pour Régie Publicitaire d'un groupe de télévision française :mouarf:
Il fallait être super qualifié pour un poste pas très ben payé et assez pénible, et la "Chef" semblait être une ......

On en est au même point , moi avec D2010 :roll:
J'espère profiter du Codeway Tour a Nantes pour poser la question (encore une semaine a attendre)

Même façon de faire que Shail mais en utilisant une base de données, cela rajoute la possibilité d'afficher un masque de saisie provenant de la base et facilité la modificiation (on ne control pas l'utilisateur via les modifs d'un INI).

a+