Ton application est volumineuse ?
Tu codes bien ?
Je pars de la table de traduction suivante :
1 2 3 4 5
| tblFrNl
NomObjet Requis (état ou module)
Identifiant Requis(nom du champ ou chaîne texte)
TexteFR
TexteNL |
Avec NomObjet+Identifiant unique
Pour les étiquettes des Frm et Rpt, je pourrais me contenter d'une impression papier.
Tu en as beaucoup ? C'est peut être la partie la plus facile à traiter en automatisme : tu fais une boucle pour chaque état, puis pour chaque étiquette tu génères une ligne d'une table avec Nom de l'état, Nom du champ, Libellé FR, Libellé NL. A chaque état tu ajoutes un code sur ouverture qui, en fonction d'une variable globale, réaffecte l'un ou l'autre des champs. Je l'ai appliqué une fois et c'était royal et facile à maintenir. Je peux te donner du code.
Mais dans les états, tu as aussi les données : c'est déjà prévu, je suppose. Sinon, c'est chaud...
Ensuite pour ton code, tu peux envisager une moulinette qui remplace toute chaîne entre guillemets par un appel de fonction. Dans la même table, au lieu du nom de champ, tu met le contenu de la chaîne en identifiant, et tu remplis la colonne FR avec la même chose.
Devient par la moulinette :
MsgBox FrNl("Bonjour Monde")
Faire ce code pour une seule passe sera assez facile. Le prévoir pour être relançable à volonté, c'est autre chose. Cela dépend de là ou tu te situes dans le développement. Si tu as encore beaucoup à faire, il vaut mieux penser l'hypothèse deux...
Si je te suggère cette structure, c'est pour pouvoir lever des ambiguïtés facilement. En effet, le texte entré dans le code peut devenir une indirection pour un libellé multiple que tu changera ponctuellement. La maintenabilité du code sera simplifiée.
Cette structure te laisse aussi la possibilité de modifier les libellés FR de l'extérieur, sans toucher au code.
Partager