Re: Passage en UTF-8 par d éfaut
(paquet convmv qui permet de changer l'encodage de noms de fichiers sur une arborescence entière...je remets -devel-french qui a sauté du CC) Quoting Valéry Perrin ([EMAIL PROTECTED]): Impeccable. Merci Denis. Je viens d'installer le paquet du même nom et de lire le man, ça à l'air de marcher exactement comme j'en rêvais... Ce paquet m'a sauvé la vie à moi aussi, le jour où j'ai déplacé un peu trop vite les fichiers d'un utilisateur entre deux serveurs samba, en oubliant de vérifier qu'ils utilisaient des encodages différents. Peut-être serait-il intéressant de mettre ce paquet dans la tâche french (et probablement toutes les tâches des langues qu'on fait passer par défaut en UTF-8)? Je compte de toute façon vous faire relire cette tâche, ainsi que french-desktop un de ces quatre. J'attends le devenir d'une proposition que j'ai faire, pour tasksel, pour les tâches de localisation (la proposition demandait des commentaires, mais Joey n'a pas été bien clair sur le fait qu'il aime ou pas ma proposition..:-))) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Wed, Sep 07, 2005 at 07:21:39AM +0200, Christian Perrier wrote: (paquet convmv qui permet de changer l'encodage de noms de fichiers sur une arborescence entière...je remets -devel-french qui a sauté du CC) Quoting Valéry Perrin ([EMAIL PROTECTED]): Impeccable. Merci Denis. Je viens d'installer le paquet du même nom et de lire le man, ça à l'air de marcher exactement comme j'en rêvais... Ce paquet m'a sauvé la vie à moi aussi, le jour où j'ai déplacé un peu trop vite les fichiers d'un utilisateur entre deux serveurs samba, en oubliant de vérifier qu'ils utilisaient des encodages différents. Peut-être serait-il intéressant de mettre ce paquet dans la tâche french (et probablement toutes les tâches des langues qu'on fait passer par défaut en UTF-8)? Oui, moi aussi il a sauvé mon ame. J'en étais réduit à parcourir tous les répertoires à la main et faire les mv à la mimine. Sur 9Go d'ogg (tous légaux!), ca devient vite lassant. Je pense que ca vaut une note dans les release notes d'etch. Bye, Mt. signature.asc Description: Digital signature
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 07:32:19AM +0200, Sven Luther wrote: Le ralentissement deviens donc plus important quand la machine est lente. On a tous les 2 un facteur 100 sur le temps user, j'aurais tendance à dire que le traitement par grep est donc 100 fois plus long, mais cela peut être masqué par le temps des IO, du noyau, et autres, ce qui explique que le gain sur le temps écoulé n'est pas le même. Mais bon, je n'y connais rien en benchmark de telles commandes, commentaires bienvenus pour éclairer ma lanterne ;) Non, le choix de l'UTF-8 par défaut me semble judicieux, mais je voulais simplement souligner que ceux qui veulent rester en latin9 ne sont pas forcément des emmerdeurs accrochés à leurs habitudes, ils peuvent avoir de bonnes raisons de faire ce choix. Sur, mais il peuvent simplement decider de ne pas passer en UTF-8. Je veux dire, ils sont assez grand pour passer en mode expert et choisir latin9, non ? Bien sûr, tant qu'on ne leur met pas plus de bâtons dans les roues. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Sun, Sep 04, 2005 at 07:06:33PM +0200, Valéry Perrin wrote: Entièrement d'accord avec Patrice. L'UTF-8 c'est peut-être très bien, mais ça devient vite inexploitable avec les milliers de fichiers et de répertoires stockés sur les serveurs. Le minimum AVANT, serait de proposer un outil simple et efficace de conversion des noms de ISO-machin vers UTF-8, sinon, on arrive vite dans un réseau composé, par exemple, d'ubuntu et de woody à une non interopérabilité et à l'impossibilité d'exploiter le fond commun. C'est un peu triste quand même. Non ? d'autant que ce sont toutes les deux des Debian ! Quand je dis simple, c'est le genre : convert -R --iso-8859-15 --utf-8 /home Euh... l'outil existe peut-être mais je ne l'ai pas trouvé ! Le programme convmv a été écrit par l'expert i18n de SuSE pour résoudre ce problème. Je n'ai pas testé, mais ça doit bien marcher. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 08:02:45AM +0200, Denis Barbier wrote: On Tue, Sep 06, 2005 at 07:32:19AM +0200, Sven Luther wrote: Le ralentissement deviens donc plus important quand la machine est lente. On a tous les 2 un facteur 100 sur le temps user, j'aurais tendance à Ah, moi je regardait uniquement le temps reel. dire que le traitement par grep est donc 100 fois plus long, mais cela peut être masqué par le temps des IO, du noyau, et autres, ce qui explique que le gain sur le temps écoulé n'est pas le même. Mais bon, je n'y connais rien en benchmark de telles commandes, commentaires bienvenus pour éclairer ma lanterne ;) BTW, tu utilise quel kernel, 2.4 ou 2.6 ? Non, le choix de l'UTF-8 par défaut me semble judicieux, mais je voulais simplement souligner que ceux qui veulent rester en latin9 ne sont pas forcément des emmerdeurs accrochés à leurs habitudes, ils peuvent avoir de bonnes raisons de faire ce choix. Sur, mais il peuvent simplement decider de ne pas passer en UTF-8. Je veux dire, ils sont assez grand pour passer en mode expert et choisir latin9, non ? Bien sûr, tant qu'on ne leur met pas plus de bâtons dans les roues. j'ai pas l'impression qu'on en met, mais bon j'ai peut-etre pas tout compris. Amicalement, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 08:15:23AM +0200, Sven Luther wrote: On Tue, Sep 06, 2005 at 08:02:45AM +0200, Denis Barbier wrote: On Tue, Sep 06, 2005 at 07:32:19AM +0200, Sven Luther wrote: Le ralentissement deviens donc plus important quand la machine est lente. On a tous les 2 un facteur 100 sur le temps user, j'aurais tendance à Ah, moi je regardait uniquement le temps reel. Sur ma machine, j'avais aussi un temps réel assez semblable, mais c'est dû au cache du disque. Sinon, j'ai vu que c'est un bogue connu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181378 Et qu'il y a deux patchs (sur une Fedora): grep-2.5.1-dfa-optional.patch grep-2.5.1-egf-speedup.patch qui doivent permettre d'améliorer les performances d'un grep pour l'UTF-8. (J'ai pas l'impression qu'il s'agisse du même patch que sur le BTS) Je vais les mettre à jour pour Debian et les soumettre. (Pour l'instant, j'ai essayé en désarchivant un rpm, et je ne vois pas de différence entre UTF-8 et C (pour l'expression rationnelle très simple de Denis, et j'arrive à faire une recherche en UTF-8) -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 08:15:23AM +0200, Sven Luther wrote: dire que le traitement par grep est donc 100 fois plus long, mais cela peut être masqué par le temps des IO, du noyau, et autres, ce qui explique que le gain sur le temps écoulé n'est pas le même. Mais bon, je n'y connais rien en benchmark de telles commandes, commentaires bienvenus pour éclairer ma lanterne ;) BTW, tu utilise quel kernel, 2.4 ou 2.6 ? $ cat /proc/version /proc/cpuinfo Linux version 2.6.12-1-386 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050806 (prerelease) (Debian 4.0.1-4)) #1 Tue Aug 16 21:23:21 UTC 2005 processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 0 cpu MHz : 350.970 ... (noyau linux-image-2.6.12-1-386 officiel) Mais tu dois aussi pouvoir obtenir des gains similaires, avec une expression rationnelle compliquée. [...] Sur, mais il peuvent simplement decider de ne pas passer en UTF-8. Je veux dire, ils sont assez grand pour passer en mode expert et choisir latin9, non ? Bien sûr, tant qu'on ne leur met pas plus de bâtons dans les roues. j'ai pas l'impression qu'on en met, mais bon j'ai peut-etre pas tout compris. Non, tu as bien compris, mais je digresse ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 07:20:48PM +0200, Nicolas François wrote: [...] Sinon, j'ai vu que c'est un bogue connu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181378 Et qu'il y a deux patchs (sur une Fedora): grep-2.5.1-dfa-optional.patch grep-2.5.1-egf-speedup.patch qui doivent permettre d'améliorer les performances d'un grep pour l'UTF-8. (J'ai pas l'impression qu'il s'agisse du même patch que sur le BTS) Je vais les mettre à jour pour Debian et les soumettre. (Pour l'instant, j'ai essayé en désarchivant un rpm, et je ne vois pas de différence entre UTF-8 et C (pour l'expression rationnelle très simple de Denis, et j'arrive à faire une recherche en UTF-8) J'avais essayé le patch gofast de #181378 il y a un mois, sans grands résultats. Mais je viens de réessayer le grep extrait du binaire RPM de l'époque (je ne sais plus lequel c'était), il est effectivement aussi rapide en UTF-8 qu'en C avec mon test. Dans mes souvenirs, ce n'était pas le cas, c'est bizarre. Mais au moins, on sait que ce problème a une solution ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 10:23:26PM +0200, Denis Barbier wrote: On Tue, Sep 06, 2005 at 07:20:48PM +0200, Nicolas François wrote: [...] Sinon, j'ai vu que c'est un bogue connu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181378 Et qu'il y a deux patchs (sur une Fedora): grep-2.5.1-dfa-optional.patch grep-2.5.1-egf-speedup.patch qui doivent permettre d'améliorer les performances d'un grep pour l'UTF-8. (J'ai pas l'impression qu'il s'agisse du même patch que sur le BTS) Je vais les mettre à jour pour Debian et les soumettre. (Pour l'instant, j'ai essayé en désarchivant un rpm, et je ne vois pas de différence entre UTF-8 et C (pour l'expression rationnelle très simple de Denis, et j'arrive à faire une recherche en UTF-8) J'avais essayé le patch gofast de #181378 il y a un mois, sans grands résultats. Mais je viens de réessayer le grep extrait du binaire RPM de l'époque (je ne sais plus lequel c'était), il est effectivement aussi rapide en UTF-8 qu'en C avec mon test. Dans mes souvenirs, ce n'était pas le cas, c'est bizarre. Mais au moins, on sait que ce problème a une solution ;) Ah, mais depuis on a peut-etre changer de glibc ? Amicalement, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Tue, Sep 06, 2005 at 10:23:26PM +0200, Denis Barbier wrote: J'avais essayé le patch gofast de #181378 il y a un mois, sans grands résultats. Mais je viens de réessayer le grep extrait du binaire RPM de l'époque (je ne sais plus lequel c'était), il est effectivement aussi rapide en UTF-8 qu'en C avec mon test. Dans mes souvenirs, ce n'était pas le cas, c'est bizarre. Mais au moins, on sait que ce problème a une solution ;) J'ai aussi essayer gofast, ça ne donne rien. En revanche les patches du paquet Fedora 4 c'est parfait. Il n'y a que très peu de perte de perf pour la locale C et pas de différence entre la locale C et UTF-8. Je vais faire quelques tests et envoyer les patches. (Mon soucis, c'est que le patche Fedora fait 850 lignes, et que quasiment aucun morceau ne passe (à part les header) et que je ne suis pas capable de comprendre/d'expliquer ces 850 lignes). J'ai trouvé ça qui explique bien pourquoi c'est plus rapide: http://savannah.gnu.org/patch/?func=detailitemitem_id=3803 Je mets les patches (mis à jour) à disposition sur : https://nekral.homelinux.net/trad/grep/patches/ (il faut tout mettre dans debian/patches) 64-egf-speedup.patch fait le gros du boulot 65-dfa-optional.patch Je ne sais pas trop s'il est nécessaire. En gros j'ai lu que l'algo DFA est lent pour l'UTF-8, et donc que c'est une bonne idée de le désactiver. Mais peut-être que ça date d'avant le patch egf-speedup.patch Il se peut que ce soit important pour des expression rationnelles un peu plus complexes. (qu'est-ce que j'y connait moi au DFA ?) grep-2.5.1-tests.patch Il y avait des tests de non-régression supplémentaires pour l'UTF-8 dans le paquet Fedora. 66-match_icase.patch 67-w.patch J'ai peut-être bien fait de tester grep-2.5.1-tests.patch, parce que quelques test ne passaient pas (Note: Un test de non-régression ne passe pas, mais je ne pense pas que ce soit de ma faute) Il se peut que d'autres outils soufrent de lenteurs avec l'UTF-8 (sort (il parrait que c'est finit), mais j'imagine que ça peut être un problème pour d'autres logiciels qui traitent des expressions rationnelles (perl, awk)) Sur ce bonne nuit (donc les patches c'est pour demain), -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Mon, Sep 05, 2005 at 09:49:32AM +0200, Sven Luther wrote: Moi je suis passer en UTF-8 recement aussi, mais a part un probleme avec mutt (due au fait que mon .muttrc mettait charset a latin1, qui confondait mutt, donc un probleme utilisateur), tout marche a merveille. À merveille, faut quand même pas déconner : - grep est beaucoup, beaucoup plus lent : $ time LC_ALL=C grep abcd /var/lib/dpkg/available /dev/null real0m0.312s user0m0.135s sys 0m0.160s $ time LC_ALL=fr_FR.UTF-8 grep abcd /var/lib/dpkg/available /dev/null real0m13.219s user0m12.029s sys 0m0.188s - quelques comandes de base ne marchent pas, p.ex. tr : $ echo écran | tr '[:lower:]' '[:upper:]' éCRAN - la console est difficilement utilisable - etc. Pour un environnement graphique sur un ordinateur rapide, il y a effectivement peu de pronlèmes, ce qui justifie le passage à l'UTF-8 par défaut pour les nouvelles installations. Mais sur des ordis peu véloces ou pour des utilisateurs de la console, le choix de rester en latin9 me semble tenir la route. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Mon, Sep 05, 2005 at 10:07:29PM +0200, Denis Barbier wrote: On Mon, Sep 05, 2005 at 09:49:32AM +0200, Sven Luther wrote: Moi je suis passer en UTF-8 recement aussi, mais a part un probleme avec mutt (due au fait que mon .muttrc mettait charset a latin1, qui confondait mutt, donc un probleme utilisateur), tout marche a merveille. À merveille, faut quand même pas déconner : - grep est beaucoup, beaucoup plus lent : $ time LC_ALL=C grep abcd /var/lib/dpkg/available /dev/null real0m0.312s user0m0.135s sys 0m0.160s $ time LC_ALL=fr_FR.UTF-8 grep abcd /var/lib/dpkg/available /dev/null real0m13.219s user0m12.029s sys 0m0.188s Bon, ... $ time LC_ALL=C grep abcd /var/lib/dpkg/available /dev/null real0m0.093s user0m0.002s sys 0m0.010s $ time LC_ALL=fr_FR.UTF-8 grep abcd /var/lib/dpkg/available /dev/null real0m0.321s user0m0.260s sys 0m0.006s C'est effectivement plus lent, mais sans commune mesure avec les resultat que tu a. Tu a quoi comme machine ? - quelques comandes de base ne marchent pas, p.ex. tr : $ echo écran | tr '[:lower:]' '[:upper:]' éCRAN C'est un bug dans tr donc, et qu'on a jusqu'a la release de etch pour resoudre. - la console est difficilement utilisable Marche bien, mais bon j'ai un framebuffer de toute facon. Pour un environnement graphique sur un ordinateur rapide, il y a effectivement peu de pronlèmes, ce qui justifie le passage à l'UTF-8 par défaut pour les nouvelles installations. Mais sur des ordis peu véloces ou pour des utilisateurs de la console, le choix de rester en latin9 me semble tenir la route. Ceux qui veulent vraiment ne avoir utf-8, ils peuvent toujours en faire le choix en mode expert, donc ... Amicalement, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Mon, Sep 05, 2005 at 10:15:23PM +0200, Sven Luther wrote: Bon, ... $ time LC_ALL=C grep abcd /var/lib/dpkg/available /dev/null real0m0.093s user0m0.002s sys 0m0.010s $ time LC_ALL=fr_FR.UTF-8 grep abcd /var/lib/dpkg/available /dev/null real0m0.321s user0m0.260s sys 0m0.006s C'est effectivement plus lent, mais sans commune mesure avec les resultat que tu a. Tu a quoi comme machine ? Ben, une brouette. Et ce ralentissement est tellement flagrant pour moi que depuis que je suis passé en UTF-8, je mets LC_ALL=C devant tous les appels à grep dans mes paquets, le gain est appréciable. Pour un environnement graphique sur un ordinateur rapide, il y a effectivement peu de pronlèmes, ce qui justifie le passage à l'UTF-8 par défaut pour les nouvelles installations. Mais sur des ordis peu véloces ou pour des utilisateurs de la console, le choix de rester en latin9 me semble tenir la route. Ceux qui veulent vraiment ne avoir utf-8, ils peuvent toujours en faire le choix en mode expert, donc ... Non, le choix de l'UTF-8 par défaut me semble judicieux, mais je voulais simplement souligner que ceux qui veulent rester en latin9 ne sont pas forcément des emmerdeurs accrochés à leurs habitudes, ils peuvent avoir de bonnes raisons de faire ce choix. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Mon, Sep 05, 2005 at 11:02:53PM +0200, Denis Barbier wrote: On Mon, Sep 05, 2005 at 10:15:23PM +0200, Sven Luther wrote: Bon, ... $ time LC_ALL=C grep abcd /var/lib/dpkg/available /dev/null real0m0.093s user0m0.002s sys 0m0.010s $ time LC_ALL=fr_FR.UTF-8 grep abcd /var/lib/dpkg/available /dev/null real0m0.321s user0m0.260s sys 0m0.006s C'est effectivement plus lent, mais sans commune mesure avec les resultat que tu a. Tu a quoi comme machine ? Ben, une brouette. Et ce ralentissement est tellement flagrant pour moi que depuis que je suis passé en UTF-8, je mets LC_ALL=C devant tous les appels à grep dans mes paquets, le gain est appréciable. Le ralentissement deviens donc plus important quand la machine est lente. Pour un environnement graphique sur un ordinateur rapide, il y a effectivement peu de pronlèmes, ce qui justifie le passage à l'UTF-8 par défaut pour les nouvelles installations. Mais sur des ordis peu véloces ou pour des utilisateurs de la console, le choix de rester en latin9 me semble tenir la route. Ceux qui veulent vraiment ne avoir utf-8, ils peuvent toujours en faire le choix en mode expert, donc ... Non, le choix de l'UTF-8 par défaut me semble judicieux, mais je voulais simplement souligner que ceux qui veulent rester en latin9 ne sont pas forcément des emmerdeurs accrochés à leurs habitudes, ils peuvent avoir de bonnes raisons de faire ce choix. Sur, mais il peuvent simplement decider de ne pas passer en UTF-8. Je veux dire, ils sont assez grand pour passer en mode expert et choisir latin9, non ? Amicalement, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
Je n'ai rien contre le fait de proposer par défaut UTF-8... à condition d'ajouter pour les latins le latin9 aussi... et les variables qui vont bien pour GTK2 (je ne connais pas Qt), à savoir Ce serait gentil de lire en entier les messages que je poste. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
À vrai dire, je ne comprends pas pourquoi ça n'a pas été fait pour sarge. Il manquait juste une ou deux broutilles comme le patch de nano. Un certain traumatisme ressenti après que Redhat ou Fedora (enfin un machin commercial) l'ait fait de façon un peu cavalière. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
Quoting Patrice Karatchentzeff ([EMAIL PROTECTED]): 2005/9/4, Christian Perrier [EMAIL PROTECTED]: Je n'ai rien contre le fait de proposer par défaut UTF-8... à condition d'ajouter pour les latins le latin9 aussi... et les variables qui vont bien pour GTK2 (je ne connais pas Qt), à savoir Ce serait gentil de lire en entier les messages que je poste. Qu'est-ce qui est en contradiction ? Tu n'as pas compris ce que j'ai dit manifestement... Ne me dis pas que tu veux qu'on mette la locale fr_FR.ISO-dino *en plus*, juste pour le français? Le dino moyen saura parfaitement aller le faire tout seul en priorité moyenne, je ne vois pas pourquoi on rendrait tout cela confus pour l'utilisateur de base. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
Le dimanche 4 septembre 2005, Patrice Karatchentzeff écrit : 2005/9/4, Christian Perrier [EMAIL PROTECTED]: Quoting Patrice Karatchentzeff ([EMAIL PROTECTED]): [...] Qu'est-ce qui est en contradiction ? Tu n'as pas compris ce que j'ai dit manifestement... Ne me dis pas que tu veux qu'on mette la locale fr_FR.ISO-dino *en plus*, juste pour le français? Pour les latins en général... cela fait un peu plus que le français... Le dino moyen saura parfaitement aller le faire tout seul en priorité moyenne, je ne vois pas pourquoi on rendrait tout cela confus pour l'utilisateur de base. L'utilisateur de base, il n'a aucune idée de ce qu'est une locale... s'il débute en informatique, cela ne changera rien pour lui... Par contre, s'il a un historique dans un coin - le cas fréquent aujourd'hui - il ne comprendra pourquoi ses fichiers seront illisibles... Qu'est-ce que coûte ma propostion aujourd'hui ? Un peu d'espace disque et beaucoup de facilité d'utilisation... c'est tout. Il sera toujours temps de supprimer cela dans quelques années, quand l'UTF-8 sera *vraiment* une réalité... j'ai une machine en utf-8 le reste en iso-...-15, et le noms de fichiers posent problèmes, je confirme donc qu'il faut bien faire quelque chose de ce côté-là au moins. En tant qu'utilisateur je ne vois pas pourquoi ce changement devrait mettre la pagaille dans mes noms de fichiers ni dans leur contenu. Nicolas -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passage en UTF-8 par d éfaut
On Sun, Sep 04, 2005 at 07:38:35PM +0200, Josselin Mouette wrote: Le dimanche 04 septembre 2005 à 14:23 +0200, Christian Perrier a écrit : Cela n'a pas posé de problème grave (en fait, ça n'en pose apparamment aucun). Suffisamment pour que j'envisage désormais de basculer la locale par défaut des installations françaises sur une locale UTF-8. Le passage en UTF-8 est un des objectifs d'etch, pour mémoire. À vrai dire, je ne comprends pas pourquoi ça n'a pas été fait pour sarge. Parce que zsh manquait de support pour UTF-8 ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Passage en UTF-8 par d éfaut
Qu'est-ce que coûte ma propostion aujourd'hui ? Un peu d'espace disque et beaucoup de facilité d'utilisation... c'est tout. Il sera toujours temps de supprimer cela dans quelques années, quand l'UTF-8 sera *vraiment* une réalité... j'ai une machine en utf-8 le reste en iso-...-15, et le noms de fichiers posent problèmes, je confirme donc qu'il faut bien faire quelque chose de ce côté-là au moins. En tant qu'utilisateur je ne vois pas pourquoi ce changement devrait mettre la pagaille dans mes noms de fichiers ni dans leur contenu. Il va quand même falloir m'expliquer en quoi générer deux locales au lieu d'une va régler le problème d'affichage des noms de fichiers. Curieusement, à un instant donné, on n'utilisera toujours qu'une des deux locales. Donc, quand on utilisera la locale UTF-8 et un environnement UTF-8, on aura un souci pour afficher les noms de fichiers en ISO-dino. De même pour les fichiers dont le contenu est ISO-dino. Qu'on ait généré la locale ISO-dino à côté n'aidera en rien, que je sache. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
