Discussion :

[Lung]

On m'a demandé de traduire une de mes applications en anglais.
J'ai extrait tous les messages de mon code que j'ai placé dans une ressourcestring. Pour ça, pas de problème.

J'ai duppliqué le projet en deux projets, pour traduire les DFM.
C'est trop lourd, car si le code est identique, les interfaces sont différentes. A chaque fois, je dois prendre chaque fenêtres pour les traduire.

Comment faire pour gérer ça de manière SIMPLE ?

Dans mes recherches, j'ai vu que beaucoup avaient le même problème, mais je n'ai pas vu de solution intéressante. Quand au tutoriel sur l'internationnalisation, a part donner le mode d'emploi d'un outil tiers, il n'explique pas ce qu'il faut faire concrètement.

Je précise que l'exe doit rester autonome. Il ne faut pas de fichiers annexes (DLL ou autre) contenant des traductions. Tout doit être dans l'exe.

Quelqu'un saurait-il comment faire ça ?

[WolffN]

bonjour

désolé mais je n'ai pas de solution simple

il y a l'outil de traduction de delphi

tu garde un seul .pas et les dfm peuvent être traduits en plusieurs langue

mais ton exe sera tres fortement lié une "dll de traduction" .eng -> la moindre modif dans ton exe -> reconstruction+maj dll ressources sous peine de crash adresse aléatoire + traductions idiotes

une autre solution

consiste à tout faire soi même
faire une fonction de type GetTexteTraduit(cstidentifiantTxt,noLangue):string
maintenir en // un fichier csv de traduction
et a revoir toutes les fenêtres ...

[Lung]

il y a l'outil de traduction de delphi

Je n'ai jamais compris comment ca fonctionnait. Ca m'a l'air d'être une usine à gaz.

tu garde un seul .pas et les dfm peuvent être traduits en plusieurs langue
mais ton exe sera tres fortement lié une "dll de traduction" .eng -> la moindre modif dans ton exe -> reconstruction+maj dll ressources sous peine de crash adresse aléatoire + traductions idiotes

Pas assez fiable, donc.

une autre solution
consiste à tout faire soi même
faire une fonction de type GetTexteTraduit(cstidentifiantTxt,noLangue):string
maintenir en // un fichier csv de traduction
et a revoir toutes les fenêtres ...

Cette solution me plait beaucoup plus.


Je cherchais déjà dans cette direction, sans rien trouver de concret.
Comment fonctionnerait cette fonction ?
Je ne vois pas comment m'y prendre.

[TicTacToe]

Je n'ai pas de solution simple non plus.
Pour ma part, j'ai établi un système, qui permet de ventiler toute mes fenêtres, d'identifier les différents composants dedans, et de laisser l'utilisateur pouvoir modifier les libellés etc des compos visuels.

Les traductions sont stockées en DB.

-> au create de chaque fenêtre, tous les compos sont ventilés, et s'il y a une traduction à mettre, il change le caption (ou autre) des compos.

-> contrainte, mes ressources de chaine utilisé en interne par prog, sont stockées sous forme d'un compo visuel invisible, afin que ces chaines soient accessibles au module.

Gros avantage, tout est fait au vol, pas besoin de recompiler ni même de redemarrer l'appli, également, dans le dev. on ne se préoccupe plus du tout des traductions.
Inconvénient, attention aux changement de Nom des compos -> le module de traduction ne retrouve plus ses petits...
Autre inconvénients, s'il y a enormément de compos, le temps de ventilation peut ralentir l'ouverture d'une fenêtre (mais avant d'en arriver a un ralentissement significatif, faut remplir ! )

[Rayek]

J'ai fait un peu pareil que TicTacToe mais avec des fichiers Ini.

Je scan ma form de tout ses composants et si je trouve une correspondant dans le fichier ini (charger en memoire dans un TStringList), je mets à jour le caption du composant.

Ca oblige a nommer tous les composants de l'application différemment pour chaque form/frame.

[TicTacToe]

J'ai fait un peu pareil que TicTacToe mais avec des fichiers Ini.
Je scan ma form de tout ses composants et si je trouve une correspondant dans le fichier ini (charger en memoire dans un TStringList), je mets à jour le caption du composant.

J'y ai pensé, d'autant que cela permet également de modifier directement le fichier INI pour le dev.
-> c'est effectivement plus simple si il n'y a pas 15000 fenetres et compos.
Mais vu le nombre de fenêtre et de compos, pour une question de rapidité, j'ai préféré la DB afin d'obtenir les traduction rapidement (index sur tables)

Ca oblige a nommer tous les composants de l'application différemment pour chaque form/frame.

En réalité, j'identifis les compos avec (Form.Name + Compo.Name), pour éviter ce "petit" probleme.

[Lung]

Bon, bin s'il n'y a pas d'autre solution que le fichiers INI, je vais faire comme ça.

[Linkin]

Pour ma part, j'ai:
- un fichier pseudo-XML (sauvegarde d'un clientdataset)
qui correspond à une table avec un identifiant et une colonne par langue,
- un paramètre "global" qui me donne la langue
- dans chaque fenêtre j'ai une fonction Traduire appelé à la création, qui traduit tous les libellés dont j'ai besoin, en fonction de la langue définie.

Et un outil de pour créer le fichier de traduction (basé sur un clientdataset, donc tout simple).

ça permet de rajouter des langues sans avoir à recompiler mon application

[sbeu]

Bonjour.
Je vais devoir traduire une appli aussi en 2 autres langues que le français.
Pour les DFM vous avez apporté plusieurs solutions.
En ce qui concerne les showmessage, les inputbox etc... Le seul moyen de faire ça efficacement serait d'utiliser des constantes, n'est il pas?
Pas d'autre moyen?

[TicTacToe]

si tu as résolu ton problème pour les DFM, une solution pourrait consister a mettre tes chaines (les constantes) dans des composants cachés (pas beau mais tu peux intégrer un compos particulier dédié à cela) qui feront partis du DFM ...

C'est une roue de secours, mais cela permet d'avoir un seul et même moteur de traduction.