Journal Pourquoi je hais les locales

Posté par  (site web personnel) .
Étiquettes : aucune
4
16
jan.
2007
Mon cher journalounet,
Je ne suis en aucun cas un expert en matière d'i18n ou de localization, j'ai même été parfois pris en flagrant délit d'anti utf8isme primaire. Néanmoins je m'interroge très fortement sur la santé mentale des gens qui ont trouvé que c'était une bonne idée de localiser le séparateur décimal (cad virgule pour les français et point pour le reste du monde). Encore plus pour les quelques guignols qui ont jugé utile de rendre toutes les fonctions de "base" (atof, scanf etc) de la libc "locale-aware" alors qu'elles n'ont pas été conçues pour ça. Ainsi que le côté "global" de la locale: quand on fait un appel à setlocale ça s'applique à tout le monde dans l'appli: le programme comme les libs, et toutes les threads.

Alors à quoi on abouti, mon journalounet ? j'ai mon module python qui lit des fichiers de données. Ces fichiers sont en texte (pour la portabilité et la facilité d'édition), c'est de l'ascii tout gentil. Ils contiennent entre autres plein de nombres en virgule flottante. C'est du C à l'ancienne, sans fioritures ni headers exotiques. C'est du costaud, du robuste, ça a voyagé et vu plein d'Unix et de compilateurs différents. Tout marche bien, c'est super. Et là tout à coup je charge un autre module python, qui en charge un autre etc et dans le paquet y'en a un qui se dit "et si je faisais un setlocale pour bien causer la langue de l'autochtone?" . Et il le fait ce con. Et du coup, ben au lieu de lire des nombres à virgule flottante mon module ne lit plus que la partie à gauche du point décimal, parce qu'après il attend une virgule. Et qu'est-ce qui se passe ? ben ça bugge, le moteur gauche de la fusée demarre avec 0.5 seconde d'avance, elle part en vrille et va s'abattre sur la maison blanche, En représaille le président des Etats Unis d'Amerique appuie sur son bouton rouge et 3000 missiles vont s'abattre sur la russie et la corée du nord. Qui répliquent. Game over.

voilà pourquoi je hais les locales (et particulierement LC_NUMERIC)

  • # Je compatis

    Posté par  . Évalué à 10.

    J'ai déjà rencontré le même problème sur une appli POSIX que j'ai devel, portable sous HP-UX, AIX, Solaris, Cygwin, Linux, etc...

    Après de bonne prises de tête sur tous ces systèmes, je suis 100% d'accord avec toi : les locales Unix c'est de la merde en boite et moi aussi je m'interroge très fortement sur la santé mentale des gens qui ont spécifié ce bordel.

    • [^] # Re: Je compatis

      Posté par  . Évalué à 4.

      dans le genre j'ai un effet "interessant" sur certains sites comme MySpace (je regarde mes referer car j'héberge quelques images rigolotes) et je constate que la moitié de la page est en français et l'autre en anglais, mais bien subtilement mélangé.

      mon navigateur est réglé pour réclamer du contenu en anglais en priorité (le Accept-Language) et pas spécialement du français ou autre chose, mais comme ces génies ont décidé de se baser sur mon ip pour déterminer que je suis français, une bonne partie de l'application MySpace se retrouve en français, pas mal de chaines de caractères qu'ils ont localisées, mais pas le reste.

      bref, c'est un beau foutoir, et c'est surtout raté. caca.

  • # Bof

    Posté par  . Évalué à 7.

    Y'en a bien qui parlent en Inch et d'autres en Mètres et ensuite ils se pleignent de crasher des satellites qui ont couté des millions sur Mars.... ^^
    Alors, c'est pas parce que ton phalomètre indique 0.5 au lieu de 50 qu'il faut pleurer.

  • # perl

    Posté par  (site web personnel) . Évalué à -1.

    Suffit de reformater ton fichier :

    perl -pi -e "s/./,/g" ton_fichier

    • [^] # Re: perl

      Posté par  . Évalué à 3.

      "Ils contiennent entre autres plein de nombres en virgule flottante."

      ou l'art de flinguer un fichier de données.

      Je pense que la solution serait d'utiliser un format xml pour le stockage des données :-)

      Il y en a marre de devoir écrire des tonnes de parseurs buggés tout le temps.

      • [^] # Re: perl

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        je pense que la solution serait d'utiliser un format xml pour le stockage des données

        Quand tu exposes un problème que tu as en informatique, il y a toujours une bonne âme pour te proposer une solution avec XML. Ensuite, tu as DEUX problèmes...

        • [^] # Re: perl

          Posté par  . Évalué à 2.

          Quand on fait une citation, il est plus honnête de laisser le smiley qui indique la déconnade.

          Maintenant, la horde de moinsseurs de panurge vont s'abattre sur mon misérable petit post.

          • [^] # Re: perl

            Posté par  . Évalué à -3.

            Quand on fait des smileys, il est préférable d'en connaitre l'usage approprié.

        • [^] # Re: perl

          Posté par  (site web personnel) . Évalué à 2.

          AFAIK à la base on (jwz ?) disait ça pour les expressions rationnelles donc tout le monde à tord dans ce thread en fait.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: perl

            Posté par  . Évalué à 4.

            donc tout le monde à tord

            Et surtout toi, car, ne l'oublions pas, le tord due !

      • [^] # Re: perl

        Posté par  . Évalué à 10.

        XML is like violence : if it doesn't work, use more.

      • [^] # Re: perl

        Posté par  . Évalué à 1.

        Moi je vote pour le format binaire optimisé, léger et tellement plus fun :-)

    • [^] # Re: perl

      Posté par  . Évalué à 2.

      Ou ptete un (pseudocode)

      -> setlocale(localeinit)

      parsing du fichier

      -> setlocale(localedest)

      (ré)écriture du fichier



      Ceci suppose bien évidemment de connaître la locale init et la locale dest. C'est un problème parce que c'est rarement gardé (idéalement ça devrait être des metas-données du fichiers) et que dans les vieux progs on s'en foutais.

      • [^] # Re: perl

        Posté par  (site web personnel) . Évalué à 4.

        en plus le setlocale c'est pas super thread-safe donc si t'as un autre thread en même temps qui lit des trucs ça risque de pas être beau

    • [^] # Re: perl

      Posté par  (site web personnel) . Évalué à 1.

      $ echo 13,37 | perl -pe's/./,/g'
      ,,,,,

      Avec le -i sans argument ça aurait été beau tiens.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: perl

      Posté par  . Évalué à 2.

      On pourrait peut etre verifier qu'il y a des nombres avant et apres le point pour etre sur d'etre sur un nombre flottant et changer le . que dans ce cas

      • [^] # Re: perl

        Posté par  . Évalué à 2.

        dans ce cas
        cat file | sed 's/\([0-9]\),\([0-9]\)/\1\.\2/g'

        et pas besoin de perl
        (pas besoin de perl avant non plus ;))

        • [^] # Re: perl

          Posté par  . Évalué à 1.

          Alors autant y aller comme ça:
          sed -i 's/\([0-9]\),\([0-9]\)/\1\.\2/g' monfichier
          si le but c'est de modifier le fichier de base.

          • [^] # Re: perl

            Posté par  . Évalué à 2.

            oui, mais avec perl tu peux utiliser les look around (quelqu'un connaitrait le terme francisé, d'ailleurs ?) :)
            s/(?<=\d)(?=\d),/./

  • # ouais bofff

    Posté par  (site web personnel) . Évalué à -3.

    tu fais un s/,/\./ ou l'inverse et cela marche pareil. (c'est facile uniquement si le parseur de fichier est bien écris...)

    "La première sécurité est la liberté"

  • # Sacrebleu, encore une exception française !

    Posté par  . Évalué à 10.

    cad virgule pour les français et point pour le reste du monde


    Il n'y a vraiment que la France pour utiliser la virgule. Et quelques autres pays*, mais bon ils ne comptent pas.

    * Albania, Andorra, Argentina, Austria, Azerbaijan, Belarus, Belgium, Bolivia, Bosnia and Herzegovina, Brazil, Bulgaria, Cameroon, Canada, Costa Rica, Croatia, Cuba, Chile, Colombia, Cyprus, Czech Republic, Denmark, Ecuador, Estonia, Faroes, Finland, Germany, Greece, Greenland, Hungary, Indonesia, Iceland, Italy, Latvia, Lithuania, Luxembourg, Macedonia, Moldova, Netherlands, Norway, Paraguay, Poland, Portugal, Romania, Russia, Serbia, Slovakia, South Africa, Slovenia, Spain, Sweden, Switzerland, Turkey, Ukraine, Uruguay, Venezuela, Vietnam, Zimbabwe

  • # utiliser aussi les locales ?

    Posté par  . Évalué à 6.

    Et si tout simplement tu utilisais toi aussi les locales ?

    A savoir ici donc positionner la locale C. Ton bousin ne marcherait-il pas direct ?

    Tu fais un wrapper autour de ton executable qui positionne les locales à C, et le tour est joué non ?

    Personnellement, c'est ce que je fais pour éviter les emmerdres avec les trucs prélocales. Si ça peut aider ...

  • # meme souci en php

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Si tu fais un setlocale dans un script, la modif s'applique à tous les autres scripts en cours d'execution. Super.

    http://fr2.php.net/setlocale (section warning)

    Franchement, c'est pourri...

    • [^] # Re: meme souci en php

      Posté par  . Évalué à 2.

      elle s'applique aux threads du meme processus.
      ce qui veut donc dire que dans beaucoup de cas, ca fonctionnera bien comme il faut et dans beaucoup d'autres cas et ben ca fonctionnera pas bien....

  • # T'embales pas

    Posté par  (site web personnel) . Évalué à 8.

    « je charge un autre module python, qui en charge un autre etc et dans le paquet y'en a un qui se dit "et si je faisais un setlocale pour bien causer la langue de l'autochtone?" . Et il le fait ce con. »

    Seul le programme principal doit changer de locale car :
    - c'est pas thread safe
    - vaut mieux ne changer qu'une seule fois de locale (à cause de trucs vaudou, cherchez pas)
    - un module n'a pas à imposer sa locale

    Corrige le module en question pour éviter une 3e guerre mondiale.

    • [^] # Re: T'embales pas

      Posté par  (site web personnel) . Évalué à 5.

      complètement d'accord. c'est un bug du module. J'ai eu le même genre de problème en C.

      Ne pas oublier de faire un bugreport chez les auteurs du module, ou via bugreport (si tu as une Debian) sinon ca va trainer dans les greniers pendant 5 ans.

      Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie

  • # Comme quoi le Python, ça pux !

    Posté par  (site web personnel) . Évalué à 3.

    Et peux-tu nous dire quel est le petit module coupable qu'on puisse châtier son auteur comme il le mérite ?

  • # A verifier ?

    Posté par  . Évalué à -4.

    open( filename[, mode[, bufsize]])
    Open a file, returning an object of the file type described in section 3.9, ``File Objects''. [...]

    If mode is omitted, it defaults to 'r'. When opening a binary file, you should append 'b' to the mode value to open the file in binary mode, which will improve portability.(Appending 'b' is useful even on systems that don't treat binary and text files differently, where it serves as documentation.)
    ...
    Source : http://docs.python.org/lib/built-in-funcs.html

  • # D'autant plus que...

    Posté par  . Évalué à 2.

    ... http://www.bipm.fr/jsp/fr/ViewCGPMResolution.jsp?CGPM=22&(...)

    • [^] # Re: D'autant plus que...

      Posté par  (site web personnel) . Évalué à 2.

      Encore une norme inachevée. Personne n'aura les couilles de spécifier clairement et en toutes lettres :
      - le séparateur décimal est le point "."
      - le séparateur par tranche de trois ne pourra être que l'espace " "

      Parce qu'avec leur résolution inachevée à la noix on peut penser qu'on peut écrire :
      15@000.00 + 8#071#042,36 = 8"086"042.36

      Avec des bras cassés comme eux on en serait encore à mesurer en pouces ! Qui ? Quoi ? Les anquois ?

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: D'autant plus que...

        Posté par  . Évalué à 4.

        tout ca ne vaut pas les applis qui pour sortir un csv utilisent ',' pour séparer les décimales, et ',' pour séparer les champs, saufs qu'ils mettent des '"' autour de certains champs pour qu'on puisse faire la différence entre les ',' et les ',' quand on a besoin des ',' pour écrire un réel...

  • # coupable ?

    Posté par  (site web personnel) . Évalué à 2.

    Le problème ici ce n'est pas qu'on ait une locale, c'est que la locale ne corresponde pas au fichier en entrée non ?

    Je peux voir plusieurs responsables (au choix) :
    - celui qui a écrit le fichier, qui a bêtement mis un point au lieu d'utiliser la bonne locale
    - celui qui a lancé le programme et qui l'a lancé avec une locale différente de la locale des données en entrée
    - celui qui a configuré le système et qui a définit une locale non posix alors qu'il avait des programmes qui ne comprennent pas les locales ou qui imposent une locale différente
    - ceux qui ont décidé que tout les pays n'utilisent pas les mêmes conventions/langues/alphabets/unités/monnaies (bonne chance pour les individualiser ceux là ;)

    Si j'en crois ce que je lis plus haut ton module a changé la locale du programme principale et ça c'est mal, effectivement. Mais globalement les locales le problème ce n'est pas leur existence c'est celui qui les configure mal.

    • [^] # Re: coupable ?

      Posté par  . Évalué à 3.

      Et si on échange des fichiers avec quelqu'un qui n'utilise pas la même locale ?

      • [^] # Re: coupable ?

        Posté par  (site web personnel) . Évalué à 0.

        c'est pas prévu, c'est comme si tu disais « et si j'envoie un courrier en français à quelqu'un qui ne parle pas français ? ».

      • [^] # Re: coupable ?

        Posté par  (site web personnel) . Évalué à 0.

        On se met d'accord sur une convention ?
        Tu le fais déjà (probablement) pour le codage caractère, le type de fin de ligne, la langue, le format de date, les délimiteurs entre tes différentes données, ...

    • [^] # Re: coupable ?

      Posté par  (site web personnel) . Évalué à 5.

      Alors effectivement, je serais d'accord avec ton point de vue si le fichier en question était en quelque sorte un fichier final, le but du traitement. Mais ça ne l'est pas, c'est juste un fichier de données sources que j'injecte dans le bouzin, et il n'y a absolument aucune raison de le faire dépendre d'une locale. C'est comme si on demandait aux developpeurs francophones d'ecrire les nombres flottants avec une virgule au lieu d'un point dans leur code source !

      Ce qui me fout en rogne c'est qu'avec la libc on a pas le choix, au lieu de définir une famille de fonctions localisées du genre "atof_loc", "scanf_loc" etc ils ont choisi de modifier le comportement des fonctions de base et ça c'est une belle connerie.

      • [^] # Re: coupable ?

        Posté par  (site web personnel) . Évalué à 5.

        Je plussoie.

        Ca s'appelle un effet de bord, ça change le fonctionnement attendu de fonctions, et ça ne devrais pas être.

        Ils auraient pu définir qq chose comme:

        locale_t* get_locale(const char* localename) ;
        locale_t* get_user_locale() ; ou get_console_locale()

        et en effet des fonctions du style:

        double atof_loc(locale_t* loc, const char* s) ;

        Ca permettrais accessoirement de pouvoir travailler avec différentes locales...

        Comme l'a écrit GVR pour Python: explicit is better than implicit.

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: coupable ?

        Posté par  (site web personnel) . Évalué à 2.

        il y aurait pu y avoir deux fonctions, une localisée et une sur laquelle on peut compter quel que soit le contexte. Je te l'accorde avec grand plaisir.



        Par contre je ne suis pas d'accord sur le "aucune raison de dépendre d'une locale". Ton fichier dépend forcément d'une convention sur quoi mettre comme séparateur. Prendre comme convention de mettre le séparateur de ton pays n'est pas forcément plus crétin que prendre comme convention le séparateur d'un pays tierce.

        > Alors effectivement, je serais d'accord avec ton point de vue si le
        > fichier en question était en quelque sorte un fichier final, le but du
        > traitement. Mais ça ne l'est pas, c'est juste un fichier de données
        > sources que j'injecte dans le bouzin

        Si je peux me permettre, ça ça n'a aucun sens. Parce que si le fichier est "source" pour toi, il est "final" pour quelqu'un d'autre, une application ou un humain.
        Dire que la locale est pertinente en sortie mais pas en entrée c'est impliquer que les fichiers en entrée naissent par génération spontanée.

  • # Précision de vocabulaire...

    Posté par  (site web personnel) . Évalué à 6.

    On dit les autochtones et non les locales.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.