Gestion d'une locale applicative

[prytoegrian]

Plusieurs tickets (#83 #81 #72) soulèvent le problème de la présence de virgule à la place de point dans les requêtes SQL, ce qui retourne une erreur. Ce problème vient du fait que le typecast float renvoyait un nombre à virgule (séparateur décimal français) à la place d'un point (séparateur décimal anglais).

La « racine du Mal » vient du fait que Libertempo est multilingue que la solution choisie pour gérer les traductions a été de définir la locale et toutes ses catégories dans la langue demandée.

Dans notre cas, le problème principal de cette méthode est que PHP joue en permanence avec les nombres à point « 3.14 » que nous fournissons en dur et ceux qui sont le résultat d'un typecast « 2,71 ». La syntaxe à virgule étant la syntaxe absorbante, les systèmes qui dépendent d'une syntaxe anglophone ne comprennent pas de quel nombre on parle, sans que le développeur comprenne où le bas blesse.
Il y a certainement d'autres soucis dû à la solution actuelle mais nous n'en avons pas encore connaissance.

Je propose donc de ne pas toucher à la locale serveur afin que les divers systèmes puissent travailler en paix et de définir une fois pour toute la langue de l'application dans le fichier de configuration.

Nous laissons à la charge de la méthode de traduction de vérifier si la locale applicative demandée correspond bien à une langue connue et si ce n'est pas le cas de retomber sur la langue par défaut.

Dernier besoin à résoudre : l'affichage. Il nous sera nécessaire d'avoir une classe de formatage des textes afin que les prix, les nombres décimaux, les date time, etc. soient dans un affichage cohérent pour l'utilisateur et donc de se baser sur la locale applicative. Il est possible de s'appuyer sur la suite de classes Intl pour cela.

Dites-moi si j'ai oublié quelques chose.

---

J'ai bien conscience que c'est encore beaucoup de travail et que ça implique de reprendre tous les affichages de float pour les encapsuler dans une méthode de formatage. Je pense que de toute façon le comportement de l'application et l'affichage des résultats doivent être séparés donc ça devrait faciliter le travail (#63 et les PR associées ont déjà exprimé ce fait).

[wouldsmina]

j'ai remarqué la fonction verif_saisie_decimal() dans fonction_conges.php. Elle sert à corriger ce problème, mais elle n'est pas systématiquement employée (je viens moi même de la découvrir). Je pense qu'elle pourrait être optimisée et utilisée le temps d'avoir une classe nickel...

// verif validité d'un nombre saisi (decimal ou non)
//  (attention : le $nombre est passé par référence car on le modifie si besoin)
function verif_saisie_decimal(&$nombre, $DEBUG=FALSE)
{
    if ( !preg_match('/^-?([0-9]+)([\.\,]?[0-9]?[0-9]?)$/', $nombre) )
    {
        echo "<br>". _('verif_saisie_erreur_nb_bad') ." ($nombre)<br>\n";
        return false;
    }

    if( preg_match('/^([0-9]+)\,([0-9]{1,2})$/', $nombre, $reg) )
        $nombre=$reg[1].".".$reg[2]; // on remplace la virgule par un point pour les décimaux
    elseif( preg_match('/^-([0-9]+)\,([0-9]{1,2})$/', $nombre, $reg) )
        $nombre="-".$reg[1].".".$reg[2]; // on remplace la virgule par un point pour les décimaux

    return true;
}

t'en pense quoi?

[prytoegrian]

Oui, une fonction pourrait faire le job en attendant. Celle-ci a quelques erreurs qu'il faudrait optimiser / corriger comme tu le dis, mais ça pourrait le faire.

[wouldsmina]

Avec setlocale(LC_NUMERIC, 'en_US'); placé dans includes/lang_profile.php ça à l'air de marcher (php ne remplace plus le point par une virgule).
Par contre, lorsque c'est l'utilisateur qui saisi une virgule ça marche pas. Mais la saisi du nombre de jours devrait, je pense, systématiquement passer par verif_saisie_decimal(). Avec la combinaison de floatval() et number_format() on devrait arriver à un truc pas trop dégueu.

[wouldsmina]

Après avoir testé sur différentes config, setlocale(LC_NUMERIC, 'en_US'); n'est pas une solution, même temporaire. Pour la prochaine version, je vais employer la fonction verif_saisie_decimal (amélioré).

[prytoegrian]

Tu peux nous détailler ce qui te fait penser à un cul de sac ?

[wouldsmina]

ce paramètre est trop dépendant de la config du serveur. l'idée d'une classe de formatage pour l'affichage et pour le contrôle des valeurs saisies me semble plus sur.

[prytoegrian]

Ce ticket n'est pas faisable en l'état, et même pire, s'il est ce sera à un coût astronomique que nous ne pouvons pas encaisser, tant en maintenance qu'en gestion des impacts. L'objectif sera donc de satisfaire ce besoin en faisant les autres tickets, au fil de l'eau de la vie du soft (puisque ce besoin est toujours pertinent).