|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Candidat au titre de Membre du Club
![]() Inscription : mars 2007 Messages : 44 ![]() |
Bonjour,
voilà, je fais la maintenance d'une base access qui va être déployer dans différents pays et je rencontre un problème concernant l'environnement du point de vue de la langue. En premier exemple, on importe un fichier excel avec les données sous ce format: "23-may-2008" Pour le stocker dans la base, je réalise un CDate() dessus. Si je suis en environnement FR, j'ai une erreur sur la fonction. Si je suis en environnement anglais, ça passe très bien. Vice et Versa si le mois est "écrit" en français ("23-mai-2008"), erreur dans un environnement anglais. Second exemple, il y a des formulaires avec des listbox ("Oui";"Non") sur des booléens. En environnement FR, pas de problèmes, en environnement anglais, problèmes. Vice et versa si je mets ("Yes";"No"). Est-ce que quelqu'un aurait déjà expérimenté ça et n'existe-t-il pas un "code" universel pour ces variables écrites? Serait-il pertinent de développer 2 apply (une pour la france, et une pour le reste?) Merci d'avance. |
|
|
00
|
|
|
#2 | ||
![]() ![]() René MAROTInscription : octobre 2005 Messages : 5 487 ![]() |
Ha les joies du multilinguisme :-).
Je ne pense pas que 2 appli soient une bonne soltions. Une internationalistion me parait préférable. Pour les liste j'utiliserai la table suivante : Table Valeurs : Code interne Code source Code élément Table Traduction Code élément Code source Code langue Texte dans la langue voulue. ex pour les oui non table valeurs True, Boolean, ChoixOui Table traduction ChoixOui, Boolean, Fr, Oui ChoixOui, Boolean, Us, Yes À chaque fois que tu offrira un choix, il faudra utiliser une requête qui affichera le bon libellé mais la valeur retenue la même quelque soit la langue. Pour les importations, comme tu travailles avec des chaînes je pense qu'il va falloir écrire ta propre fonction de traduction. Un truc qui va tester une partie de ta chaîne pour déterminer la langue source. du genre Code :
__________________
Vous voulez une réponse rapide et efficace à vos questions téchniques ? Ne les posez pas en message privé mais dans le forum, vous bénéficiez ainsi de la compétence et de la disponibilité de tous les contributeurs. |
||
|
|
00
|
|
|
#3 |
![]() ![]() |
salut,
j'oserai ajouter que si tu as la possibilité de passer en date MM/DD/YYYY ca serait beaucoup plus simple aussi +1 pour la table de traduction
__________________
Pas de question technique par MP, je ne réponds pas ![]() Mon perso ? Une vraie brute Tutos Access, Tâches planifiées et Batch,Tables de Paramètres sous Access, Excel et Batch, Tâches planifiées et Access |
|
00
|
|
|
#4 | |
|
Candidat au titre de Membre du Club
![]() Inscription : mars 2007 Messages : 44 ![]() |
Merci pour vos réponses. En effet les tables de traduc me paraissent être une bonne solution.
Mon principal problème est que je ne peux pas savoir dans quel langue je suis. (à moins de réaliser par exemple, un "try" sur un CDate("20/12/2008"), si ça marche, je suis en us, sinon en fr?) Et c'est parce que je ne sais quel langue domine l'environnement que je ne vois pas vraiment comment affecter telle variable et que donc, je cherchais à trouver un code universel pour des variables assez simple (je fus très étonné de voir que yes n'était pas reconnu...) C'est pour ça que Citation:
le programme l'importe d'un excel, c'est pour le moment un string. je le passe en date en faisant un CDate dessus pour l'instant. Je viens d'y penser, et s'il est possible de modifier le mois d'une date avec Month(date) = X par exemple, alors je pourrais créer une date, lui affecter chaque champ (jour, mois, année) sans me soucier de l'ordre lié à la langue. Je continue de réfléchir. Merci encore. |
|
|
|
00
|
|
|
#5 |
![]() ![]() René MAROTInscription : octobre 2005 Messages : 5 487 ![]() |
À propos des formats de date, le format inversé (YYYY/MM/DD) à l'avantage d'être beaucoup moins ambigu et donc d'être facilement lu quelques soit la langue.
Je suis au Québec, dans un environement bilingue, et je n'utilise plus que ce format la et je n'ai plus de maux de tête avec mes dates. A+
__________________
Vous voulez une réponse rapide et efficace à vos questions téchniques ? Ne les posez pas en message privé mais dans le forum, vous bénéficiez ainsi de la compétence et de la disponibilité de tous les contributeurs. |
|
|
00
|
|
|
#6 | |||
![]() ![]() Maintenance données produits Inscription : décembre 2005 Messages : 3 941 ![]() |
Citation:
Sinon, quel que soit le format (date) d'affichage dans Excel, la colonne sera importée avec le type Date/Time dans Access. Si tu as la possibilité d'agir à la source sur le fichier Excel ça devrait résoudre le problème des dates. Tu n'as pas de problèmes avec les nombres décimaux (séparateur décimal et milliers) ? Pour connaître l'identificateur des paramètres régionnaux tu peux essayer cette fonction de l'API windows. (A mettre dans la partie déclarations d'un module de code) Code :
Public Declare Function GetUserDefaultLCID Lib "kernel32" () As Long Les 10 premiers bits représentent la langue seule. Code :
Autrement sans API, te renverra "mai" ou "may" en fonction des paramètres régionnaux du PC. A+ |
|||
|
|
00
|
|
|
#7 | |
|
Candidat au titre de Membre du Club
![]() Inscription : mars 2007 Messages : 44 ![]() |
Citation:
Merci beaucoup pour la remarque sur les dates et pour la fonction API windows, je devrai m'en sortir avec ça |
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com