Vous vous souvenez de ça ? Ça fait plus d’un an que je trolle GNU/Linux parce que le tri Unicode est complètement aux fraises lorsque le système est configuré en locale FR.

Il y a du nouveau.

⤵️

Tout d’abord je dédicace ce thread à tout ceux qui m’ont répondu des trucs du genre :

« C’est un usage minoritaire, y’a que toi que ça emmerde »

« Ça changera jamais, c’est comme ça »

« Rapporte un bug, mais je sais pas où »

Notez qu’en cherchant un peu j'ai vu que d’autres personnes ont rencontré des problèmes similaires dans d’autres langues dans les dix dernières années et ont obtenu le même genre de réponse.

Pour la faire courte, je viens de me rendre compte que c’est complètement corrigé sur Debian 10, qui vient de sortir. Alors que c’était IMPOSSIBLE hein.
Sur Fedora c’est depuis la version 29.

Alors s’est-il passé ?

Et bien en 2012 (!!) un contributeur de glibc ouvre un bug car il s’est rendu compte que les fichiers de définition de locales (= langues) étaient basés sur Unicode 3.0, datant de 2000.

sourceware.org/bugzilla/show_b

Trois ans après, en 2015, première réponse : « tiens, pourquoi on a fait ça ? »

« Personne ne s’en occupe à part des gens qui patchent quand c’est trop le bordel, et puis ils disparaissent »

« Faudrait regarder quand même mais ça a l’air compliqué »

Fin 2017 (!!!), un gentil contributeur s’y colle.

« J’ai regardé mais c’est le bordel, on a 15 ans de retard, faut tout refaire »

2018, la réécriture des fichiers de définition est en cours et ça casse pas mal de trucs dans plein de langues.

Car en plus le format des fichiers de la norme a changé depuis 2000.

« Ça va péter les ranges mais de toute façon c’est pas fait pour, c’est déconseillé de les utiliser directement et c’était déjà pété »

(les notations type [a-z])

« Ah ben non mais faut pas laisser ça comme ça sinon les caractères hors locale ne sont pas triés »

OH ÇA ALORS REGARDEZ QUI AVAIT RAISON

Août 2018, release de glibc 2.28 remis à la norme Unicode 9.0 de 2016

On passe de 18 à 2 ans de retard 😌

PostgreSQL fait un communiqué en avertissant que ça peut corrompre les bases de données mal branlées.

Pendant ce temps je râle et personne n’a pu me rediriger vers ces infos (que je n’avais pas trouvées moi-même)... c’est considéré comme un sujet accessoire par la communauté et on m’envoyait paître 👿

Fedora release dans la foulée.

2019, avec 15 ans de retard donc (Unicode 4 date de 2004), release de glibc 2.28 dans Debian 10.

Un grand merci à Mike Fabian qui a pris le sujet au sérieux.

Rendez-vous dans 20 ans...

(y’a déjà eu deux mises à jour de la norme depuis 2016 🙃)

Je termine juste en rajoutant que dès que je parle d'internationalisation, et notamment de respect de norme Unicode et de user experience, je reçois souvent des "parle à ma main", notamment de libristes.

Alors que chez les logiciels privateurs, c'est un sujet sérieux. Apple et Microsoft ont des équipes dédiées et sont contributeurs de la norme depuis 30 ans.

Il faudrait que ça change, au bout d'un moment.

Follow

Depuis un an que je me plains régulièrement du problème, j'ai même eu un gros libriste qui m'a le plus sérieusement du monde asséné un "de toute façon les noms de fichiers c'est caractères alphanumériques sans espaces et c'est tout".

Voilà.

· Web · 10 · 13 · 13

Ceci étant dit au début des années 2000 quand je suis passé sous Windows 2000 (qui est 100% Unicode comme tout Windows NT), quand je faisais des rapports de bugs à divers projets (souvent privateurs) sur le fait qu'ils ne supportaient pas les noms de fichiers non-ANSI je me faisais jeter aussi avec des "Unicode pas une priorité" :)

Le plus beau ça a été le tout neuf Firefox qui avait été refait from scratch sans support Unicode pour les noms de fichiers :p

AH NON pardon le plus MAGNIFIQUE c'était cette bouse de Norton antivirus, qui était installé partout sur Windows à l'époque, et qui était incapable d'ouvrir les fichiers contenant des caractères hors-locale.

Je m'en suis rendu compte car j'avais un disque avec un énorme dossier nommé en japonais et Norton le scannait en zéro seconde (sans faire remonter d'erreur critique !).

@fenarinarsa Merci de ce fil instructif quoiqu'énervé (mais je comprends bien pourquoi :)

Pour info, ext4 peut maintenant être insensible à la casse. Je ne suis pas insensible au sujet, j'ai envie d'être violemment opposé à cette fonctionnalité, mais après tout, c'est optionnel.

@ffeth Après il faut définir ce qu'est la casse en fonction des langues.

En Unicode ce genre de choses est très bordélique.

La norme est passé au niveau au-dessus depuis un moment avec la représentation canonique des chaîne de caractères.

@fenarinarsa Mais... tu vois la blague que ça peut produire : si tu mets un fichier aAa là où se trouvait un fichier AaA, scritch scratch, ça l'écrase. Or, comme tu le soulignes, la notion de casse n'est pas absolument sans ambiguité...

@ffeth Exact... honnêtement c'est un nid à emmerdes, même si tu es insensible à la casse et que tu stockes les caractères tels quels tu peux avoir des problèmes. Par exemple A et A sont codés différemment et pourtant c'est le même caractère.

@fenarinarsa Thread super intéressant ! J'imaginais même pas qu'il puisse y avoir ce genre de problèmes.

@dada Alors que même dans les langues européennes le tri des caractères accentués change.

En suédois par exemple ils sont classés à la fin de l'alphabet.

Je parle même pas des problématiques de casse et de caractères équivalents qui sont représentés par différents point de code, qu'on ne peut comparer que par leur représentation canonique.

@fenarinarsa Le pire c'est que c'est complètement faux sous Unix:
Un nom de fichier c'est tout sauf / et l'octet nul et un truc genre 255 charactères. (le système de fichier peut mettre plus de restrictions, genre si tu utilise du FAT)

Donc tu peut mettre des retours à la ligne, des charactères de controle, …

@fenarinarsa Je suis désolée que tu sois tombé(e) sur des têtes de bois 😔… Ils sont malheureusement encore nombreux même si on essaie de les améliorer au fur et à mesure, même moi j'ai pu avoir ce genre de comportement à mes débuts. Et je m'en excuse 😶.

@nlavielle T'as pas à t'excuser, et deux ou trois ont cherché à m'aider mais ils sont pas allés beaucoup plus loin que moi. Je me suis cassé les dents sur les fichiers de définition i18n qui ne sont absolument pas documentés, et on ne savait pas quel projet en était en charge.

@fenarinarsa ah yes y a un logiciel libre que je peux pas utiliser car mon dossier principal sur windows a le malheur d'avoir un accent et je peux plus le modifier 👍

@fenarinarsa C'était facile de contourner l'analyse anti-virus dis donc…

@fenarinarsa c'est très chiant ce genre de réponse quand l'un des arguments du logiciel libre c'est d'être accessible à tous.tes

Genre "ça l'est mais si tu parle une langue ou y'a plus de caractères qu'en anglais va te faire voir" quoi

@fenarinarsa super thread et chapeau pour ta persévérance !

@fenarinarsa Laisse moi te dire, petit merdique de mes deux, totalement ignorant des importantes priorités du libre...

Ce que tu dis est très important !

Ca montre bien que l'IT reste bien dev- et anglo-centrée.

Moi-même j'ai la moitié du temps des caractères bizarres dans certains de mes noms de fichiers. Ca devient grave quand tu travaille avec X pc (avec chacun son OS).

@fenarinarsa Et bien sûr, je suis et reste un occidental. Donc impacté, mais on arrive à bosser. (mes alphabets restent proches de l'ascii standard)

J'imagine pas un laotien...

(J'ai resolu, pour l'instant, de m'en tenir à l'ascii pour les noms de fichiers critiques).

Sign in to participate in the conversation
Shelter

Bienvenue sur Shelter, l'instance Mastodon de la petite communauté otaku et geek du discord de l'Eden de la Nanami. Vous pouvez rejoindre le Discord par ce lien.

Discussions autour du jeu vidéo, du japon, de l'informatique et de l'animé/manga.

Les inscriptions sont pour le moment ouvertes.

Si vous avez des questions, n'hésitez pas à contacter l'administrateur de cette instance.

Pour une liste des émojis disponibles sur l'instance c'est par ici !

Shelter est le nom d'un clip musical de Porter Robinson & Madeon : Visionner sur Youtube.