Re: [Dolibarr-dev] A propos des appels à price2num et price et de la locale fr_BE

[Yannick Warnier]

Le vendredi 05 septembre 2008 à 11:11 +0100, Antoine Delvaux a écrit :
> Bonjour Eldy,
> 
> 
> Merci pour ta réponse.
> 
> >> Seulement, la solution n'est pas simple, car les appels à price2num() 
> >> colorent
> >> très fort le code.  J'ai pour le moment contourné le problème, en 
> >> commentant le
> >> code récupérant le séparateur des milliers de la locale,  L'autre solution 
> >> est
> >> d'utiliser la locale 'fr_FR' mais aucune des 2 n'est une solution durable.
> >>
> >> Bref, qu'en pensez-vous ?  Si je m'attaque au problème, quel chemin me
> >> préconisez-vous ?  Merci pour vos avis !
> >>   
> > Je me suis attaqué au problème.
> > Un gros boulot car le seul moyen de s'en sortir en l'état actuel avec
> > fr_BE et que tout soit en fr_BE (PHP, OS, Mysql), ce qui n'est casiment
> > jamais le cas surtout mysql qui garde quelquesoit la langue, le "."
> > comme séparateur de décimal.
> 
> De mon opinion, le principal problème de price2num est qu'elle est utilisée 
> dans
> 2 contextes assez différents :
> - pour reprendre des prix en provenance de l'I/F web, formatés suivant la 
> locale
> - pour reprendre des prix en provenance de la BD, formatés avec le '.' comme
> séparateur décimal
> 
> L'idéal ne serait-il pas de séparer cette fonction en 2, suivant son usage ?  
> Ce
> qui permettrait dès lors de résoudre ce bug de manière plus propre.  Mais le
> gros inconvénient, j'en conviens, est que cela demande un gros refactoring car
> price2num est appelée en bcp d'endroits.
> 
> > Autre solution, passer tous les code Dolibarr et ne plus permettre la
> > saisie ouverte (droit de saisir un nombre sans le séparateur de milliers
> > qui emmerdent tout le monde et utilisation obligatoire de la virgule).
> > Hors ceci me parait beaucoup trop contraignant juste pour avoir le droit
> > de "voir" des nombres affichées au format Belgique.
> 
> Oui, je suis d'accord avec toi, bcp plus contraignant.
> 
> > Il y a une solution beaucoup plus simple.
> > Prendre la version CVS de la branche DOLIBARR_2_4_BRANCH ou la 2.5 dev
> > dans laquelle on a modifié le fichier main.lang de fr_BE et la ligne
> > SeparatorThousand=.
> > par
> > SeparatorThousand=
> 
> Oui, c'est une autre idée qui a l'avantage d'être immédiate.
> 
> Je proposerais bien encore une autre solution, qui a l'avantage de pouvoir
> garder le '.' et a juste un petit inconvénient.  C'est dans le patch joint 
> (diff
> contre la 2.4.0).  Le petit inconvénient est que lorsqu'on a un nombre tel que
> "1.001" on ne peut pas trancher entre "mille et un" et "un virgule zéro zéro 
> un".
> 
> Cela dit, ce problème est potentiellement plus large que la locale fr_BE, il 
> se
> pose pour toute locale utilisant le '.' comme séparateur de milliers.  D'après
> http://www.unicode.org/cldr/version/1.6.1.html cela en représente tout de même
> 35 hors de 454 (voir liste en annexe également).  Même s'il est peu probable 
> que
> Dolibarr soit traduit dans toutes ces locales prochainement, ça vaut peut-être
> la peine de trouver une solution à long terme ?

Oui parce que bon... même si la Belgique est un tout petit pays au bord
de la dissolution (humour), il n'en reste pas moins que certains de ses
fiers représentants contribuent de temps en temps au code de
Dolibarr :-D

De toute façon c'est clair, tout bon système ERP doit pouvoir gérer les
variations de représentation numérique.

Yannick