Journal Mandriva et les caractères accentués

Posté par  .
Étiquettes : aucune
0
16
juin
2006
Que penser d'un système informatique qui, bien que très sophistiqué, serait incapable d'afficher du texte brut correctement ?
En particulier quand il s'agit de texte livré avec le système lui-même ?

Chez Mandriva, c'est possible.
- gedit est pourri par un patch qui empêche l'auto-détection correcte du codage UTF-8 (ironiquement, tout nouveau fichier créé par gedit l'est en UTF-8, ce qui fait qu'il ne sera pas relu correctement à la prochaine ouverture...) :
http://qa.mandriva.com/show_bug.cgi?id=20277
- les pages de manuel sont codées de façon incohérente - certaines en UTF-8, d'autres en ISO-8859-15 :
http://qa.mandriva.com/show_bug.cgi?id=17554

Deux bugs à la fois simples et graves que personne ne semble pressé de corriger. Il faut se demander si le français (avec accents et cédilles) est encore une langue utilisée couramment chez Mandriva, ou peut-être qu'ils pensent que lire l'UTF-8 en représentation ISO-8859-15 est user-friendly...

Ce problème montre assez bien ce qui arrive quand un projet, tout à la résolution de problèmes de plus en plus compliqués, oublie les fondamentaux de l'informatique (afficher et modifier du texte, fonctionnalité basique et rigoureusement indispensable).

On se demande aussi s'il y a un pilote dans l'équipe QA de Mandriva.

  • # Même pas peur !

    Posté par  . Évalué à 4.

    Bah, les concurrents ont le même genre de problème :D. Y'a-t-il un pilote dans l'avion ?

    http://linuxfr.org/~dup/21898.html

  • # En même temps

    Posté par  . Évalué à -2.

    en cooker, c'est normal d'avoir des problèmes, je dirais que c'est même conseillé pour avoir plus de retexp.
    après que la mandriva one ou Mandriva 2006.1 le soit, ce serait plus grave. A priori,ce n'est pas le cas.

    • [^] # Re: En même temps

      Posté par  . Évalué à 2.

      Regarde la date de soumission des bugs.
      Au moins l'un des deux bugs (celui des man pages) était présent dans la dernière version stable.

      • [^] # Re: En même temps

        Posté par  . Évalué à -2.

        Si tu le dis :-) Mais moi, concernant les pages de manuel, je n'ai jamais eu de soucis, en même temps, peut-^tre n'ais je pas fait attention.


        question subsidiaire: combien de temps avant que des ubunteros viennant blanacer des commentaires en disant "dans ubuntu, il n'y a pas ce bug" ?

        • [^] # Re: En même temps

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

          Dans breezy, j'avais un bug avec les manpages effectivement.
          Mais bon sur dapper, plus rien ;)

          • [^] # Re: En même temps

            Posté par  . Évalué à 2.

            je pense que là est le soucis de trop de choix:
            UTF-8 ou ISO-885915


            Il y a toujours des soucis quand deux soft, protocoles ou methodes doivent cohabiter.
            Il faudrait que Mandriva se prononce une bonne fois pour toute: UTF-8 ou ISO-885915 une bonne fois pour toute.
            D'ailleurs, je pense que dapper drake a fait le choix de l'UTF-8.
            Maintenant, on peux se demander si c'est pas trop lourd pour quelqu'un qui ne gère que des caractères Français.

            • [^] # Re: En même temps

              Posté par  . Évalué à 6.

              AMHA, le choix logique pour Mandriva serait de passer entièrement à UTF-8.
              Cela entraînera pas mal de remous et de soucis pendant quelques temps mais avec leur nouveau planning de sortie annuel, ils ont plus de temps qu'avant.
              Maintenant c'est aussi une question de volonté politique.

              • [^] # Re: En même temps

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

                enfin oui mais non !

                Extrait de http://manpagesfr.free.fr/ , site de traduction des pages de manuel linux :

                Depuis la version 1.59.0, les pages de manuels sont fournies dans l'encodage UTF8. Si votre système ne supporte pas l'UTF8, vous pouvez convertir ces pages en ISO-8859-1 (latin1) mais sachez que certaines pages seront « abimées » car elles comportent des caractères qui n'ont pas d'équivalent en ISO-8859-1. C'est le cas, par exemple, des pages qui décrivent les divers encodages : ISO-8859-2.7, ISO-8859-16.7, etc.


                voilà !

                • [^] # Re: En même temps

                  Posté par  . Évalué à 3.

                  Je ne parlais pas juste des pages de manuel mais de l'ensemble des applications, locales par défaut, etc.
                  Sinon, oui, pour les pages de manuel, la résolution devrait être aisée (ce qui rend incompréhensible l'absence de correction du bug).

                  • [^] # Re: En même temps

                    Posté par  . Évalué à 4.

                    Ca sera resolu ce soir sans doute.
                    Le "nouveau" bug ne date que d'hier.

                    Je pense d'aiileurs que tu aurais du ouvrir un nouvel incident.
                    Ce n'est plus les mêmes causes qu'il y a quelques moiis, donc autre fix, donc autre incident.

                    • [^] # Re: En même temps

                      Posté par  . Évalué à 0.

                      ??? Je ne sais pas de quoi tu parles.
                      Pour gedit, c'est le même bug qu'à l'origine, le même "patch" étant à la source du problème....

                      • [^] # Re: En même temps

                        Posté par  . Évalué à 2.

                        Donc pour toi,quand X11 ne se lance pas, c'est toujours le même bug?
                        Et oui, X11, c'est toujours le même package, patché mandriva

    • [^] # Re: En même temps

      Posté par  . Évalué à 7.

      Ben si, c'est le cas avec ma 2006 éd. hiver. Mes pages man ont ce problème, je dois en avoir quelques autres et pour ce qui est de mon OOo adapté à kde, je suis quand même obligé d'utiliser les boîtes natives de dialogue de OOo pour les chemins des fichiers car celles de KDE proposées par défaut ne supportent pas les accents.

      Bref, en gros pour moi, pour ça et pour d'autres choses, le travail accompli mar mandriva pour la mouture 2006 est un travail baclé et il n'y a pas d'autres mots. Je suis vraiment très loin de comprendre ceux qui ont émis des critiques positives à l'égard de la 2006 qui serait représentative de la maturité de plus en plus grande de cette distro. C'est faux, pour moi il y a même eu un sacré bon en arrière.

      • [^] # Re: En même temps

        Posté par  . Évalué à 1.

        Moi c'est mon gmail, configuré en utf-8, qui sait mal lire les mails venant d'un autre prestataire de courriers electronique, qui encode les mails francophones en iso-8859-15

  • # et moi ...

    Posté par  . Évalué à -4.

    Et moi sous Ubuntu j'ai le clavier qui s'blo

    • [^] # Re: et moi ...

      Posté par  . Évalué à 2.

      ttis en reclamant des caresses et des calins?

  • # C'est pas un peu un troll, ce journal ?

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

    Gedit a été corrigé, d'aprés les liens postés, mais le bug est revenu hier.

    Solution intelligente : venir crier sur linuxfr que ç'est mal fait, que c'est horrible, en amalgamant bug sur stable et bug sur cooker ( car ce bug est entré pour cooker ).

    Solution conne : attendre que le mainteneur regarde le probléme. Tout les gens qui ont lu le rapport de bug auront vu que le problème est revenu ... hier. Intolérable d'avoir un bug non corrigé aprés 24 h sur un produit de developpement

    C'est connu qu'il est toujours utile d'insulter les gens en les traitant d'incompétents sur un bugzilla ( cf http://qa.mandriva.com/show_bug.cgi?id=17554#c20 )

    • [^] # Re: C'est pas un peu un troll, ce journal ?

      Posté par  . Évalué à -1.

      En même temps, c'est vendredi après midi

    • [^] # Re: C'est pas un peu un troll, ce journal ?

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

      Euh... je suis désolé mais le problème d'encodage gedit + pages de man sous mandriva, je le rencontre aussi, et pourtant je suis en mandriva 2006 official...

      Clairement la forme de l'intervenant n'est pas la bonne, mais il faut aussi pouvoir admettre que le problème existe (je parle du bug gedit) et est relativement gênant...

      Je m'étonne alors de découvrir que cooker a été corrigé à ce niveau et qu'il n'y a pas eu de correctif pour mandriva 2006...

      Enfin, je m'étonne aussi du fait que pour une distribution "française", ces problèmes d'accents n'aient pas eu vraiment l'air de l'embêter... Pourtant je trouve gedit presque inutilisable à cause de ça... Tu ne peux plus double cliquer sur un fichier pour l'ouvrir, il faut ouvrir gedit, aller dans "Ouvrir -> Fichier", changer l'encodage pour utf-8, cliquer "Ouvrir".

      Moi qui ais mon nautilus configuré en simple clic, j'ai tout ça à me taper pour ouvrir un fichier au lieu d'un seul clic...

    • [^] # Re: C'est pas un peu un troll, ce journal ?

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

      Misc, heu c'est bien beau les bugs sur cooker, mais bon, en ce moment y a des bugs très chiants triviaux qui sont pas corrigés depuis des mois...

      Genre setkeycode où il suffirait "simplement" de monter le numéro de touche maximum 128 à 256 comme l'ont fait toutes les autres distributions (gentoo/debian) pour le corriger :
      http://qa.mandriva.com/show_bug.cgi?id=21741

      Bon c'est "seulement" le premier bug reporté de ma liste encore ouvert de la cooker...
      Et y a encore une petite liste qui le suit...

      Bref, pour répondre a l'utilisateur de 2006.0, considère tes problèmes d'utf-8 comme mort et pas résolus... (enfin si c'est comme les bugs cosmétiques pour lesquels j'ai pleurés et qui ont jamais été corrigés pour la 9.2/LE2005/etc...)

      Par contre hésite pas a venir pleurer sur la cooker maintenant pour qu'on passe (enfin) en full UTF-8 et qu'on puisse enfin corriger les choses proprement pour TOUTES les langues...

      Rappelez vous que la 2007 sera d'une durée de 1an !!! Donc si on passe pas ce coup ci en UTF-8, ce sera pour 2008 !
      Alors que toutes les autres distributions grand public seront en utf-8 par défaut (ubuntu/gentoo/etc...)

      Je suis en train de refaire le paquet des man-pages-fr en UTF-8 pour la cooker (avec la dernière version des man-pages-fr et un fichier spec PROPRE), rendez-vous sur :
      http://rapsys.free.fr/mandriva
      Pour avoir la version pour mandriva cooker :
      urpmi.addmedia rapsys http://rapsys.free.fr/mandriva/cooker with hdlist.cz

      Pour la 2006.0 :
      urpmi.addmedia rapsys http://rapsys.free.fr/mandriva/2006.0 with hdlist.cz

      Pour les autres, soit vous recompilez groff-utf8 (nécessaire pour afficher correctement les man pages utf8) et idem pour man-pages-fr pour la 2006.0, sois vous attendez quelques jours que je recompile le tout sur la machine d'un copain ;)

      ps: il y aura un sacré nombre de bugs de conflit de man-pages a priori, donc hésitez pas a me rapporter les bugs : rapsys.free@fr
      s/.free@fr/@free.fr/g

    • [^] # pas corrigé

      Posté par  . Évalué à 3.

      Gedit a été corrigé, d'aprés les liens postés, mais le bug est revenu hier.

      En fait, non, il n'a pas été corrigé.
      C'est une version préparée par un autre mainteneur (Götz Waschk) sur un repository non-officiel (*) (destiné à l'inclusion finale de GNOME 2.14) qui ne présentait pas le bug, car n'incluait pas le patch incriminé. Cette version a l'extension "gpw" comme tu peux le lire dans les commentaires. J'espérais naïvement que cette version bien préparée serait reprise telle quelle une fois l'inclusion de GNOME 2.14 finalisée.

      Mais la version du repository main (celle qui a l'extension "mdk" ou "mdv") a toujours été buggée, depuis plus de six mois.

      (*) http://gpwgnome.osknowledge.org/

      • [^] # Re: pas corrigé

        Posté par  . Évalué à 3.

        Le patch incriminé, selon toi , n'est pas responsable car même apres un rebuild sans lui le bug est toujours présent, maintenant reste à touver la réèlle cause du problème.

  • # l'utf-8 n'est pas du texte brut.

    Posté par  . Évalué à -5.

    l'ascii 7 bits, oui.

    • [^] # Re: l'utf-8 n'est pas du texte brut.

      Posté par  . Évalué à 2.

      Non.

      Tu définis « texte brut » par « texte brut en ascii 7 bits » alors évidemment, l'utf-8 n'est pas un bon codage (car 8 bits, déjà).

      Et, généralement, on entend par « texte brut » un « texte sans information de présentation¹ ». Un texte codé en utf-8 peut entrer dans cette définition et un texte codé en ascii 7 bits pourrait ne pas y entrer (usage de caractères de contrôle p.ex.)

      ¹ : ce qui est insuffisant car il faut au moins ajouter la gestion des sauts de ligne.

  • # Bon c'est décidé

    Posté par  . Évalué à -4.

    Avec ce problème inacceptable, je migre en kubuntu
































    Non, je blague en fait.

Suivre le flux des commentaires

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