concept de traduction en 3 langues

[nevil]

Bonjour a tous,

Alors voila ce qu'il se passe et qui va pas me rendre la vie facile je pense:
vu que mon appli va etre utilisee en Italie, mon chef ma demande que lors de louverture il y ai une invitation de lutilisateur pour qu'il puisse changer de langue. Ce qui veut dire que tous les controles de tous mes formulaires et etats doivent etre traduits, en 3 langues qui plus est.
Le probleme est que je ne sais pas vraiment par ou commencer ni comment operer.

Je vais vous expliker ma premiere idee:
- creer une table "T_translation" avec 4 champs: le premier "ControlID" avec la clee primaire et reprentant le nom du control qui devra etre traduit; un second "Trans_english", un 3e "Trans_germ" et le dernier "Trans_ita"
- ensuite, lors de louverture d'un formulaire, a laide dune boucle je liste tous les noms des controles
- grace a ces noms et a laide dune requete, je vais chercher la traduction dans le bon champs selon le chois de la langue.

En fait, la ou je ne sais pas du tout comment optimiser, c a kel moment je tradui: est ce ke je traduit simplement le formulaire qui va etre ouvert ? ou alors, des que lutilisateur a choisi sa langue, je recupere tous les noms de tous les controles de TOUS mes formulaires pour ensuite faire la traduction ??

Je voudrais bien un peu d'aide la dessus car je suis dans le brouillard complet ...
Et si quelqu'un a deja fait ce genre de fonctionnalite, je veux bien quelques conseils!

Merci a tous

[pgz]

Bonsoir.

Je ne sais pas si je vais t'aider, mais sache bien que je compatis...
Tu évoques la questions des étiquettes des formulaires et des états, mais il peut y avoir aussi :

• les messages (MsgBox)
• des listes (civilité)
• des champs de texte ou mémo (bonjour!)
• le fichier d'aide (s'il y en a un)
• ...

Cela peut devenir très compliqué, suivant le niveau d'adaptation à la langue choisie requis.

Mais pour la question des étiquettes que tu évoques, je pencherais perso sur une traduction par code de tous les formulaires et états, donc en mode design, dès le choix de la langue. Cela ne devrait prendre que qq secondes. Pour que cela fonctionne, il ne faut pas une table de traduction, mais une du type : Objet (form ou report)/ NomObjet/ NomLabel/ ContenuLangue1/ ContenuLangue2/ ... et donc une procédure qui va chercher toutes les étiquettes des forms et reports.
Avec une langue "par défaut" pour les étiquettes qui ne seraient pas encore dotées de toutes les versions de langue.

Bon courage,

PGZ

[nevil]

Salut a toi pgz et a tout le monde,

Si je comprend bien, le principe que tu m'ennonce ressemble legerement au mien, a la difference que dans ta table "objet" tu rajoute l'emplacement de l'objet et son nom. Ce qui me ferait faire une seule et meme "big" table avec tous les controles et labels de tous mes formulaires et etats. Dis moi si j'ai rien compris ...
Ce que je pensais faire, et dont j'ai deja debute, c'est de creer une table de traduction par formulaire, avec a linterieur tous les controls et leur traduction dans les 3 langues.
Et pour savoir dans quelle langue il va falloir que je traduise (vu que le choix de la langue ne se fait qu'une seule fois au lancement de lappli), jecris betement dans un fichier INI la langue que j'ai choisi. Donc lors de louverture de mes formulaire je vais recuperer dans mon INI la langue choisi et traduire en consequence.

Je suis parti sur ce principe, mais je suis ouvert a toute proposition ...

Merci

[pgz]

Bonjour.

Tu as très bien compris.
A mon avis faire n tables, ça va très bien aussi.

Par contre, plutôt que de traduire avant l'ouverture de chaque objet, je traduirais plutôt tous ces objets dès le choix de la langue, pour être sûr :
- de ne pas en oublier,
- de ne pas faire n fois le même travail (à chaque ouverture...)

Bien sûr, ce n'est qu'un avis.

Bon courage,

PGZ

[nevil]

Je vois tres bien ce que tu veux dire mais je me pose une question:
c'est possible de traduire un controle dans un formulaire qui n'est pas ouvert ?? et a l'ouverture de ce formulaire ce control sera traduit ??

J'avoue que j'ai pas essaye mais ca me parait bizar, remarque pourquoi pas, ca serait pas plus mal.

Merci pour ton aide

[vodiem]

salut pgz et nevil,
c'est une discution qui m'interesse.
tu as encore la chance de ne pas être confronté au problème de table de caractère...

j'opterais plutot pour une table de traduction pour toute la base comme a dit pgz, c'est plus simple pour la maintenance quand il faut rajouter une langue.

je te conseil de faire ta base "normalement" en prévoyant suffisamment de largeur pour les étiquettes pour les différentes langues.
et faire une procédure qui va faire l'inventaire de tes forms, états et tous leur objet pouvant contenir du texte afin de mettre tout cela dans une table unique avec pour champs: form/objet/label
(recherche sur le developpez pour cela, il y a déjà du code pour énumérer les objets d'un form et un autre pour énumérer les forms de l'application)

tu auras une table unique de traduction et tu n'oublieras pas d'objet.
tu fais une procédure pour modifier tous les labels de tous les forms depuis cette table.

voici un exemple simplifié pour l'ouverture et l'enregistrement des forms si c'est cà qui est ton soucis:

Code :

1
2
3
4
5
6
7
Private Sub changer_langue_Click()
DoCmd.OpenForm "Formulaire1", acDesign, , , , acHidden
Forms![Formulaire1]![Etiquette0].Caption = "Etiquette0 modifié"
Forms![Formulaire1]![Etiquette1].Caption = "Etiquette1 modifié"
'...
DoCmd.Close acForm, "Formulaire1", acSaveYes
End Sub

[cbleas]

Bonjour,
Pour ma part j'ai une table listant l'ensemble des nom de formulaire le nom de tous les controles que je liste avant la mise en production.

Après lors de chaque ouverture je reprend la table et met les nom dans la meme langue.

il est vrai que faire cette manipulation lors de la première installation lors du choix de la langue semble la meilleure comme le dit JPZ, le problème vient si on utilise des runtime car il sera impossible d'ouvrir en mode création.

Maintenant ou cela est le plus compliqué c'est les msgbox qui sont dans le code et qui dans ce cas doivent etre luent dans une table.

Bon WE

[FreeAccess]

Bonjour à tous....

@ nevil....

Tu peux éventuellement t'inspirer du code de l'application "Multi langage" que tu trouveras sur ce lien:
http://www.carsoftaja.ch/DownloadIndex.html

La fonction 'Mod_Langue' semble très intéressante....

Bonne lecture et bonne application...

[Domi2]

Bonjour,

Bien que je ne pense pas être jamais confronté à ce problème, cette discussion m'intéresse également...

S'agissant des messages, il serait peut-être bien d'évaluer les possibilités offertes par la MsgBoxEx d'arkham46.

Notamment, la possibilité de stocker les messages dans des fichiers m'apparaît plus souple que l'emploi d'une table.

J'avais commencé par l'emploi de la table, mais j'ai vite abandonner pour passer aux fichiers.

Bon développement en tous cas

Domi2

[nevil]

salut tout le monde,

Merci pour le lien FreeAccess c'est toujours bon d'apprendre et merci a tous pour votre aide.

Je vais vous expliquer en quelques lignes sur quoi je suis parti:
Donc en fait jai une table de traduction par formulaire, avec comme champs : "Fields" (représentant le nom de tous es controles du formulaire en a traduire) / "Translation_Eng" / "Translation_Ger" / "Translation_Ital" / "Translati_Fr". Ensuite, a louverture de mon formulaire j'utilise le code suivant:

Code :

1
2
3
4
5
6
7
8
 
        dim field_name,traduction as string
        For Each Ctrl In Forms![NomDuFormulaire].Controls
        field_name = Ctrl.name
        On Error GoTo error
        traduction = DLookup("[NomDuFormulaire].translation_ger", "NomDuFormulaire", "[fields] = '" & field_name & "'")
        Ctrl.Caption = traduction
        Next

Donc tous les noms des controls qui se trouvent dans mon formulaire sont traduits.
Et ce que je voulais c'est que des l'ouverture de l'appli le 1er formulaire qui apparaisse soit directement dans la derniere langue utilisée (qui sera surment la meme langue pour tous les jours, donc leur éviter de reselectionner leur langue si celle ci nest pas la langue par défaut). Pour cela (sur que ca soit pas etre optimisé), dans le formulaire principal, lorsqu'ils choisissent leur langue, j'écris dans un ficher INI la langue choisie. Comme ca des l'ouverture de l'appli, je vais récuperer dans mon fichier INI la derniere langue utilisée et lancer la bonne fonction de traduction.
Et ca m'aide aussi a l'ouverture de tous les autres formulaires pour savoir dans quelle langue il va falloir traduire.
Ca fonctionne plutot bien. Traduction instantannée, pas "doubli" de traduire certains control, et une "espece de langue par défaut".
Mais vous inquietez pas que je prend note de tout ce que vous me dites.
Si un jour je dois refaire ce meme concept de traduction, je changerais de méthodes

Merci a tous pourvotre aide

[FreeAccess]

Re,

Pour la création de ta table de traduction, tu peux largement t'inspirer de la fonction 'ReadFormReportText' qui fera cela de façon automatique. (voir lien de mon post précédent...)

En appelant cette fonction sur n'importe quel Form ou Etat, tu va remplir ta table de traduction avec tous les objets (Label, bouton...) qui s'y trouvent et pour lesquels tu as remplis la propriété "Remarque" (Tag) avec un nombre.

En clair, chaque objet de ton Form ou Etat est identifié par son Tag correspondant à un enregistrement de ta table de traduction.
Ensuite, il ne te reste plus qu'en fonction de la langue choisie de "lire à la volée" la traduction correspondante dès l'ouverture de ton Form ou Etat.

....Bonne continuation.....

[mout1234]

Bonsoir,
je n'ai pas étudié en détail cette discussion mais je remarque ce code

Envoyé par nevil

Code :

Attention, un tel code supposera donc d'exécuter une requête (un dlookup) pour chaque contrôle du formulaire. Il faudrait je pense au moins remplacer le Dlookup par un recordset.


Une des questions initiales est de déterminer quand faire la traduction.
Une fois encore attention aux performances. Si l'application comporte bcp de formulaires et états, cela risque d'être long au démarrage!

Pour info, il y a un exemple d'application multilangues dans le code Source du kit de Développeur Access 2003.

Bon courage.

[vodiem]

salut à tous,

mout1234, je pense que tu as raison: le fond du problème est non pas la comment traduire mais plutot quand traduire.

on trouvera tous une manière de traduire d'une facon ou d'une autre mais quand dois-t-on traduire?
puisqu'il est possible de faire:
- une appli pour chaque langue séparemment et rattaché à la base.
- une appli unique avec toutes les forms et états de chaque langue
- une appli unique avec forms et état unique et changer tous les textes des objets une fois pour toute.
- une appli de base qui change tous les textes des objets à chaque ouverture de form et état.

je pense que chacune de ces possibilités (j'en oublie peut être) à ses avantages et inconvénients.

vos avis sur ces choix?

[nevil]

Salut vodiem et tous les autres,

La question du quand n'est pas évidente vu le nombre de possibilités qu'il y a.
Moi j'ai opté pour la traduction de mes formulaires et états des leur ouverture. Une fois que dans le menu principal l'utilisateur a choisi sa langue, les fomulaires qui s'ouvriront ensuite seront également dans cette langue.

Apres c'est sur que c'est peut etre pas la plus optimisée mais je me pose pas encore ce genre de question .

Mais je pense que les autres participants de ce sujet seront plus a meme de répondre.

[electrosat03]

Salut,

Comme Vodiem le dit,

Pourquoi ne pas faire 3 applis (3langues) tu fais un form d'install qui demande la langue et tu crées un raccourci sur le bureau qui ouvre l'appli avec le language sélectionné à l'install.

Je pense que pour la maintenace, se serait plus facile vu que tu ne touches pas aux tables mais seulement aux forms. Quand tu fais une modif, tu sais où tu doit les faires dans les autres languages.

A+

[Tofalu]

Si le problème des perfs se pose, pourquoi ne pas opter pour :

Le développeur crée sa base de données dans une langue avec les tables de traduction qui vont bien. Il lance la traduction depuis son poste de développement dans les deux autres langues et obtient ainsi trois fichiers.

Un fichier mdb composé d'un simple menu général permettra de lancer l'application dans la langue choisie.

Le process de traduction serait donc uniquement exécuté par le développeur.

Arf, la solution a déjà était donnée
Ceci dit, le risque c'est d'avoir des versions différentes de l'applicatifs mais de langue différentes.

On pourrait imaginer que suite à des installation différentes, l'utilisateur se retrouve avec :

• appli_fr_v1_02.mdb
• appli_en_v1_02.mdb
• appli_it_v2_00.mdb

Mais sincérement, avec des tables de traduction dans le frontale, je ne pense pas que l'ouverture d'un formulaire soit fort ralentie avec un chargement dynamique des libellés depuis une table, d'autant plus si celle-ci est indexée, que le recordset est de type table et que la méthode seek est correctement invoquée.

Aprés, plutot qu'une table; il pourrait aussi être possible de se servir de la propriété tag des contrôles :

Imaginons, un contrôle ayant ce tag (remarques)

"Lundi#Monday#Montag"

Une fonction utilisant split peut très facilement donné le texte en fonction de la langue passée en paramètre (avec les enum en vba, ou des constantes)