Discussion modèle:Tri

Point d'exclamation

Bonjour,
Pourquoi ce modèle ajoute-t-il un point d'exclamation invisible à la fin des caractères de tri ? — Riba ^(discuter) 23 octobre 2010 à 16:18 (CEST)

Problème

Il y a un problème avec la nouvelle version de ce modèle (celle de 10 novembre 2012), voir Championnat de Belgique de football D2 1956-1957. Rabah201130 (d) Je fais beaucoup de fautes d'orthographe, merci de me les corriger 11 novembre 2012 à 19:21 (CET)

Renommage de Tri1 en Tri

Le modèle {{Tri}} était destiné aux modèles fournissant une clé de tri facultative avec "t=". En pratique, cela ne concernait que les drapeaux. Avec l'évolution de l'algorithme de tri de MediaWiki, rendre la clé de tri facultative n'était plus très utile. J'ai récemment supprimé cette possibilité des modèles de drapeaux.

Maintenant, {{Tri0}} n'est plus utilisé du tout et {{Tri}} n'est plus utilisé dans l'espace des modèles. Je propose donc de renommer {{Tri1}} en {{Tri}} en écrasant la version actuelle de {{Tri}}, dans un but de simplicité.

Il reste un grand nombre d'articles utilisant directement {{Tri}} :

• sur ceux où t=1 (17000 appels dans 1900 pages), ça ne changera rien, le paramètre sera juste ignoré
• sur ceux où t est absent (2000 appels dans 320 pages), c'est qu'il y a actuellement une erreur de syntaxe (il n'y a pas de raison d'utiliser {{Tri}} sans t=1 hors d'un modèle). Donc cela va a priori améliorer la situation : les tableaux qui n'étaient pas triés correctement le seront. Au pire, des tableaux où les clés de tris sont mal définies ne seront toujours pas bien triés.

Orlodrim ^[discuter] 16 juin 2013 à 15:28 (CEST)

C'est fait. Orlodrim ^[discuter] 17 juin 2013 à 19:22 (CEST)

Je viens un peu tard, mais le paramètre t n'était PAS obligatoire (donc t absent n'était pas une erreur dans les 320 pages), puisqu'il prenait une valeur par défaut "0" qui utilisait donc le modèle Tri0, pour justement désactiver la clé de tri (ce qui permettait de construire des modèles incluant ou pas la clé de tri (la clé de tri n'était utilisable que si le modèle génénant du texte triable est utilisé TOUT SEUL et pas associé à d'autres données.

De fait on avait le modèle Tri0 dont le seul rôle était de copier le texte sans ajouter la clé de tri, contrairement à Tri11 qui l'ajoutait.

Cela a été fait pour soit-disant régler un problème d'accessibilité, ce qui n'a jamais été démontré, mais maintenant avec le code actuel, les clés de tri sont ajoutées partout et incluent dans le texte un caractère ZWJ: si on lit le tableau de données dans une euille Excel, même en mode texte seul, impossible de remplacer ce ZWJ présent au début des cellules (certaines seulement, et seulement celles qui sont munies d'une clé de tri).

Ce ZWJ ne respecte pas le tri correct puisque "A[ZWJ]" est maintenant """supérieur """ à "AB[ZWJ]", ce qui place donc "A" après "AB".

La seule valeur correcte du séparateur n'était pas ZWJ mais bien la plus petite séquence de texte HTML inférieure à toutes les chaines non vides, et la seule possible en MediaWiki est l'espace ASCII suivi du point d'exclamation, puisqu'on ne peut pas mettre un caractère de contrôle, et puisque MediaWiki unifie les espaces. En HTML sinon cela aurait été la TABULATION (U+0009), le plus petit caractère valide en HTML (avec aussi l'intérêt de rester "accessible" et aussi filtrable facilement lors d'un import d'un tableau dans une feuille Excel (aujourd'hui devenu impossible ou seulement avec des manipulations très compliquées; en plus du fait que ZWJ force les cellules importées à devenir de type texte (calculs impossibles), et même la fonction CNUM() ne sait pas lire ce WZJ et retourne une erreur. la fonction SUPPRESPACE() ne sait pas filtrer non plus ce ZWJ initial.

La solution c'est donc certainement pas ce ZWJ complètement incongru apparu suite à une modif de quelqu'un qui n'avait pas compris pourquoi on utilisait l'espce suivi d'un point d'exclamation (expliqué pourtant avant), mais bien une tabulation ou le code qui existait avant.

Et sinon on se retrouve avec des tableaux qui ne sont plus triés correctement là où la clé de tri était optionelle (notamment des cellules de texte où une clé de tri n'était ajoutée que pour celles contenant des caractères spéciaux): on est maintenant obligé de mettre des clés de tri dans toutes les cellules texte, même celles n'ayant aucun caractère spécial (et cela concerne par exemple les listes de noms de pays (pas que les modèles de drapeaux où il était malgré tout possible aussi de désactiver complètement la génération de toutes les clés de tri là où elles ne sont pas nécessaires quand le modèle n'était pas inséré dans un tableau).

On se retrouve mantenant avec des clés de tri insérées aussi dans des paragraphes quelconques par les modèles, et un texte rendu gangréné de ZWJ (même s'ils sont rendus invisibles avec display:none).

Les navigateurs en mode texte seul ne savent plus lire les tableaux, les feuilles de calcul non plus. ZWJ a un effet de bord bien pire que " !" qui en plus était désactivable avant là où on ne demandait pas de clé de tri.

Je ne sais pas qui est le crétin qui a eu l'idée de ce caractère ZWJ soit-disant invisible !!! Je constate qu'il n'est plus possible d'utiliser les données des tableaux de Wikipédia pour ses propres feuilles de calcul; alors qu'avant il n'y avait aucun problème. Si MediaWiki ne remplaçait pas les tabulations par des expaces qu'il compresse ensuite, on aurait du pouvoir utiliser <nowiki>&#9;</nowiki> comme séparateur idéal; et si HTML était plus permissif, on aurait pu utiliser SIH (U+0001) ou NUL (U+0000) et cela aurait été encore mieux (la nécessité étant que ce séparateur doit être la chaîne non vide inférieure à toutes les autres possibles, ce qui n'est PAS du tout le cas de ZWJ). Bizarrement personne n'a jamais eu l'idée de me contacter ou m'interroger sur ces raisons alors que j'avais créé le modèle et même expliqué tout ça et testé le modèle avant même qu'il soit ensuite très utilisé, puis modifié sans réfléchir aux raisons (ni comprendre réellement puisque l'explication d'Orlodrim montre qu'il s'est carrément trompé avec une explication fausse (et ensuite cette modif a cassé toute une série de tables et créé des problèmes bien pires qui existent aujourd'hui).

Ne plus pouvoir utiliser les tableaux de Wikipédia dans une feuille de calcul est un problème sérieux, même pour préparer d'autres tableaux croisés destinés ensuite à être réimportés dans Wikipédia (et c'est là que je me suis aperçu du problème).

Verdy p (discuter) 25 juin 2014 à 08:13 (CEST)

Bonjour,

J'ai rajouté un "!" manquant. Le caractère zwj est ignoré par la fonction de le tri des tableaux. La mise à jour du modèle n'a pas ajouté de caractère zwj là où la clé de tri était précédemment désactivée.

Cordialement,

Orlodrim (discuter) 25 juin 2014 à 08:54 (CEST)

┌─────────────────────────────────────────────────┘
Bonjour  Orlodrim, Verdy p, Zebulon84 et Lofhi,

Je reviens sur ce sujet, 5 ans plus tard, au hasard d'une discussion sur le bistro concernant le modèle {{tri}} : Wikipédia:Le Bistro/28 juillet 2019#Question sur les tables triables.. Dans le cadre de ce sujet, et étant en même temps en train de faire une très grosse mise à jour de Aide:Insérer un tableau (wikicode, expert) depuis quelques jours, j'ai creusé un peu plus le sujet du modèle {{tri}}, concernant notamment son utilisation sans contenu, avec seulement une clé de tri. Utilisation parfois plus pratique que d'inclure le contenu dans le modèle, qui complique l'édition avec l'éditeur visuel.

Actuellement, comme contesté plus haut par Verdy p, le modèle ajoute un caractère de contrôle ‍ à l'intérieur de la balise <span>, de la manière suivante : <span data-sort-value="clédetri!" style="display:none;">&zwj;</span>.

Effectuant quelques recherches sur la raison de ce caractère de contrôle, qui même s'il est masqué, reste un élément indésirable, je suis arrivé à cette ancienne discussion de 2012 : Discussion Projet:Modèle/Archive 2012#Tablaux triables :Tri1, où Zebulon84 indique (dans la discussion mise en boîte déroulante) :

« note : le ‍ sert à obliger MediaWiki à conserver le span, sans pour autant afficher quoi que ce soit. Si vous avez une meilleure méthode je veux bien l'adopter. »

— Zebulon84, Discussion Projet:Modèle/Archive 2012#Tablaux triables :Tri1

Enregistré sur Phabricator
Tâche 29786 corrigé

Le bug phab:T29786 « let empty metadata-elements pass through tidy » est également mentionné. Mais il est maintenant indiqué comme étant résolu suite au passage à RemexHTML, qui ne souffre pas des mêmes défauts de Tidy.

J'en conclus donc que l'unique but de ce caractère de contrôle — masqué en plus par un display:none; — était d'empêcher la suppression de la balise par l'analyseur syntaxique Tidy, qui supprimait les balises sans contenu ou ne comportant que des espaces blancs conventionnels. Mais étant donné que Tidy a été remplacé par RemexHTML en 2018, et que RemexHTML ne supprime plus les balises vides, je pense que l'on peut supprimer ce bricolage.

Cette syntaxe bizarre (balise <span> contenant un caractère de contrôle, masqué par du CSS) apporte également un autre problème, c'est que l'éditeur visuel n'affiche aucune indication relative à la présence du modèle quand on édite un tableau. En effet, l'éditeur visuel indique la présence d'un modèle par deux manières possibles :

1. Par son contenu, quand un modèle produit du contenu visible, ou en tout cas visible théoriquement.
2. Par une icône suivie du nom du modèle quand le modèle ne produit aucun contenu visible.

Dans les deux cas, il est ainsi possible d'identifier la présence d'un modèle, et de pouvoir le modifier si besoin. Par contre, avec la version actuelle, il n'est pas possible de savoir qu'un modèle est présent, car l'éditeur visuel le traite comme un modèle produisant du contenu, donc théoriquement sélectionnable en cliquant sur le contenu (le modèle risque donc très fortement d'être purement et simplement supprimé au moment de la sélection du contenu de la cellule, si on veut réécrire par-dessus).

Apparence dans l'éditeur visuel du modèle tri (sans contenu) selon les versions

#	Contenu
1	Version actuelle
2	Tri  Nouvelle version proposée

J'ai fait quelques tests avec une version modifiée de {{tri}} sur mon brouillon Utilisateur:Tractopelle-jaune/BrouillonK, dont le résultat est visible sur les deux tableaux. Je vous invite également à tester l'édition de ce brouillon dans l'éditeur visuel, pour voir comment se présente l'indication d'un modèle ne générant pas de contenu (à noter que l'indication de la présence d'un modèle ne générant pas de contenu est très longue dans le cas présent, car c'est le nom complet de mon brouillon qui est affiché à la place de « Tri », qui serait normalement affiché).

Cette modification, en plus de supprimer un caractère indésirable devenu inutile, apporterait également un meilleur support du modèle dans l'éditeur visuel.

Ma proposition est donc de remplacer dans le modèle {{tri}} le code actuel :

<includeonly><span data-sort-value="{{{1|}}}{{#if:{{{2|}}}|">{{{2}}}|!" style="display:none;">&zwj;}}</span></includeonly><noinclude>{{Documentation}}</noinclude>

Par :

<includeonly><span data-sort-value="{{{1|}}}{{#if:{{{2|}}}||!}}">{{{2|}}}</span></includeonly><noinclude>{{Documentation}}</noinclude>

Seconde version, suite message ci-dessous de Verdy p :

<includeonly><span data-sort-value="{{{1|}}}{{#if:{{{2|}}}||&#32;!}}">{{{2|}}}</span></includeonly><noinclude>{{Documentation}}</noinclude>

Qu'en pensez-vous ?

--Tractopelle-jaune (discuter) 30 juillet 2019 à 10:48 (CEST)

Je note que tu conserves le "!" mais tu oublies l'espace qui le précédait (et reste nécessaire pour le tri correct) avant que quelqu'un soit venu casser le tri en mettant un ZWJ qui n'a jamais marché correctement. Il faudrait restaurer cette espace dans le if: {{{1|}}}{{#if:{{{2|}}}||&#32;!}}">{{{2|}}}</span> (la raison de l'espace a été expliquée il y a des années et c'était ce qu'il y avait au début et qui marchait très bien avant ce stupide ZWJ; la séquence espace-point d'exclamation est la plus petite (dans l'ordre de tri) qu'on puisse écrire en HTML valide car on ne peut pas utiliser de caractère nul pour le séparateur; l'espace facilite aussi l'export des données; cette espace DOIT être encodée d'une part pour que le #if le conserve, d'autre part pour éviter qu'elle soit changée par Mediawiki en une espace insécable, justement avant un "!", ce qui conduirait un tri incorrect; note: la clé de tri tri ici est fait utilisée en Javascript, ce n'est pas MediaWiki qui trie les tableaux, mais Javascript ne supporte pas les fonctions avancées de collation; le tri des tableaux tenant compte des règles complexes de collation est très compliqué à écrire et lourd à supporter, et c'est bien pour ça qu'on doit indiquer manuellement les clés de tri dans les pages). Verdy p (discuter) 30 juillet 2019 à 11:06 (CEST)

 Verdy p : J'ai complété les tests sur Utilisateur:Tractopelle-jaune/BrouillonK, avec les deux variantes (avec ou sans espace avant le point d'exclamation), et le résultat n'est effectivement correct qu'en ajoutant l'espace avant le point d'exclamation.

Sur mon brouillon, en prenant les trois clés (mélange de clés forcées et naturelles) B, BA et B A seul l'ajout de l'espace permet de trier B avant B A (suivi de BA). Sans l'espace, B A est placé avant B.

Le résultat est donc assez évident, l'espace est nécessaire.

J'ai donc modifié le code proposé, et soutiens en conséquence le rétablissement de cet espace avant le point d'exclamation.

Sachant que l'espace et le point d'exclamation ne sont générés, comme actuellement, que quand le modèle {{tri}} n'englobe pas de contenu (paramètre 2 vide).

--Tractopelle-jaune (discuter) 30 juillet 2019 à 11:32 (CEST)

Note: "espace-point d'exclamation" est utilisé au lieu de "espace-espace", qui ne fonctionne pas à cause de la compression des blancs en HTML; de même la tentative de remplacer l'espace par une tabulation (théoriquement inférieure) ou un autre contrôle valide en HTML (saut de ligne) ne fonctionne pas non plus car la tabulation est remplacée aussi par une espace. Le tout premier caractère valide en HTML qui ne soit pas affecté par la compression des blancs est l'espace; et là on doit distinguer l'espace normal séparant deux mots de l'espace nécessaire aux clés; "espace-point d'exclamation" dans la clé fontionne aussi avec les titres contenant une séquence "espace-point d'exclamation" non encodée, car là cette espace est transformée par MediaWiki en espace insécable.

Cette solution (espace encodé plus point d'exclamation) existe depuis des années et fonctionne très bien et je ne l'ai jamais trouvée en défaut nulle part en pratique même si théoriquement ce séparateur est insuffisant (en pratique avec Mediawiki cela suffit du fait justement de sa compression des blancs et de la transformation des espaces-non-encodés avant "!" en espaces insécables). Verdy p (discuter) 30 juillet 2019 à 12:15 (CEST)

Note aussi: celui (Orlodrim) qui a stupidement supprimé l'espace nécessaire a utilisé à tord un bot qui a remplacé l'encodage sous forme de référence numérique   par une espace non encodée, ce qui l'a fait ignorer dans la valeur retournée par #if. L'ajout de ZWJ ensuite (après le point d'exclamation) n'a fait qu'empirer les choses (celui qui a fait ça ne s'est même pas demandé à quoi servait ce point d'exclamation). Le fait que ce soit en "display:none" ne change rien au tri Javascript quand il doit extraire le texte seul des cellules (avec la propriété innerText qui ne tient pas du tout compte du balisage et des styles indiqués). Pour éviter qu'un Bot à nouveau vienne remplacer   par une espace et casse le modèle, je suggère d'y inclure un commentaire HTML au milieu: &<!--doit être encodé-->#32; (on pourrait aussi passer par un modèle non substitué, mais c'est plus coûteux pour le parseur).

En gros, on revient à ce que j'avais fait il y a 12 ans (en 2007 !) et qui a marché depuis le début, et ne marchait plus du tout depuis la modif abusive (car protégée et faite sans aucun test ni discussion quoi qu'il prétendait) par Orlodrim 5 ans après en 2012. Ma solution initiale marche encore sans faille hors de Wikipédia, notamment dans le Wiktionnaire pour ses clés de tri). Verdy p (discuter) 30 juillet 2019 à 13:58 (CEST)

 Tractopelle-jaune : Ça me semble bon, j'ai modifié le modèle. Orlodrim (discuter) 14 août 2019 à 18:52 (CEST)

Cas des accents

Bonjour. Où est le problème avec les accents ? Par exemple, le tri du tableau ci-dessous est OK :

Texte de l’en-tête	Texte de l’en-tête	Texte de l’en-tête
entrée 2	entrée 2	entrée 2
élément 1	élément 1	élément 1
évènement 3	évènement 3	évènement 3

--Cjp24 (discuter) 6 décembre 2018 à 21:40 (CET)

Il n'y a pas (ou en tout cas plus) de problème avec les accents. Voici l'ordre de triage selon MediaWiki :

!"#$%&'()*+,-./0123456789:;<=>?@
ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_'
abcdefghijklmnopqrstuvwxyz{|}~
¡¢£¤¥¦§¨©ª«­®¯°±²³´µ•¸¹º»¼½¾¿
ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
ĀāĂ㥹ĆćĈĉĊċČčĎďĐđĒēĔĕĖėĘęĚěĜĝĞğĠġĢģĤĥĦħĨĩĪīĬĭĮįİıIJijĴĵĶķĸĹĺĻļĽľĿŀŁłŃńŅņŇňʼnŊŋ
ŌōŎŏŐőŒœŔŕŖŗŘřŚśŜŝŞşŠšŢţŤťŦŧŨũŪūŬŭŮůŰűŲųŴŵŶŷŸŹźŻżŽžſ
ǺǻǼǽǾǿ΄΅Ά·ΈΉΊΌΎΏΐ
ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩΪΫάέήίΰ
αβγδεζηθικλμνξοπρςστυφχψωϊϋόύώ

Lofhi (me contacter) 28 juillet 2019 à 17:50 (CEST)

 Lofhi : Que signifie ce tableau que tu as recopié dans la documentation ? Pourquoi y a-t-il "Z" avant "a", ou bien les lettres accentuées après toutes les lettres non accentuées ? Orlodrim (discuter) 28 juillet 2019 à 18:50 (CEST)

 Orlodrim : : c'est l'ordre de tri comme indiqué. Je n'ai pas d'explications à te donner : c'est dans le même ordre que celui du standard Unicode, donc le tri est bien sensible à la casse pour les tableaux. Je pense que c'est une implémentation de Array.prototype.sort() qui a le même comportement. Lofhi (me contacter) 28 juillet 2019 à 19:06 (CEST)

 Lofhi : Une explication serait pourtant utile. Il y a peut-être un truc qui te semble évident mais qui m'échappe. En effet, comme tu dis, MediaWiki gère de façon naturelle les majuscules et les accents. Ainsi, l'ordre de tri de {a, A, z, Z, é} dans un tableau triable sera "a < A < é < z < Z". Le bloc que tu donnes semble signifier que l'ordre serait "A < Z < a < z < é", mais ce n'est pas le cas. Orlodrim (discuter) 28 juillet 2019 à 19:47 (CEST)

En fait, j'ai l'impression que cette liste est celle des caractères unicode par code croissant. Ce n'est pas la même chose que l'ordre de tri, qui est un truc dépendant de la langue et qui ne se fait pas caractère par caractère (par exemple, od < œuf < oeuf < of). Orlodrim (discuter) 28 juillet 2019 à 20:02 (CEST)

 Orlodrim : en fouillant un peu en profondeur, ils disent que tous les caractères sont lowercased pour le tri. Aussi, le tri des accents est inscrit dans notre MediaWiki:Common.js : mw.config.set( 'tableSorterCollation', {'à':'a', 'â':'a', 'æ':'ae', 'é':'e', 'è':'e', 'ê':'e', 'î':'i', 'ï':'i', 'ô':'o', 'œ':'oe', 'û':'u', 'ç':'c', } );. Lofhi (me contacter) 28 juillet 2019 à 20:37 (CEST)

 Lofhi : Intéressant, mais cette table semble être obsolète. En effet, "ö" est trié correctement entre "n" et "p" dans les tableaux triables, bien qu'il ne soit pas présent dans la table. En tout cas chez moi. En cherchant "tableSorterCollation", j'ai trouvé phab:T72157 → phab:T32674, où je lis qu'il y a eu une amélioration ultérieure, mais ça semble dépendre du navigateur.

Pour en revenir au problème de départ : tu veux bien retirer cette liste de la documentation ? Parce qu'au final, elle n'aide pas à comprendre comment {{tri}} fonctionne.

Orlodrim (discuter) 28 juillet 2019 à 21:04 (CEST)

 Orlodrim : en lisant rapidement les tickets que tu cites, je me demande si la table n'était pas encore à jour il y a un mois (comme certaines autres infos de la doc). Enfin bref, je retire la liste, plus qu'à trouver plus de détails sur Intl.Collator. Lofhi (me contacter) 28 juillet 2019 à 21:15 (CEST)

 Orlodrim : en reprenant l'ancienne liste et en la triant avec :

let liste = [...`!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_'abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«­®¯°±²³´µ•¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿĀāĂ㥹ĆćĈĉĊċČčĎďĐđĒēĔĕĖėĘęĚěĜĝĞğĠġĢģĤĥĦħĨĩĪīĬĭĮįİıIJijĴĵĶķĸĹĺĻļĽľĿŀŁłŃńŅņŇňʼnŊŋŌōŎŏŐőŒœŔŕŖŗŘřŚśŜŝŞşŠšŢţŤťŦŧŨũŪūŬŭŮůŰűŲųŴŵŶŷŸŹźŻżŽžſǺǻǼǽǾǿ΄΅Ά·ΈΉΊΌΎΏΐΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩΪΫάέήίΰαβγδεζηθικλμνξοπρςστυφχψωϊϋόύώ`];
let collator = new Intl.Collator( [
                mw.config.get( 'wgPageContentLanguage' ),
                mw.config.get( 'wgUserLanguage' )
            ], {
                numeric: true
            } );
liste.sort( ( x, y ) => collator.compare( x, y ) ).join( '' );

On obtient :

_-,;:!¡?¿.·''\"«»()[]{}§@*/&#%•΄´^¯¨΅¸°©®+±÷×<=>|¦~¤¢$£¥0123456789¹½¼²³¾aAªáÁàÀăĂâÂåÅǻǺäÄãÃąĄāĀæÆǽǼbBcCćĆĉĈčČċĊçÇdDďĎđĐðÐeEéÉèÈĕĔêÊěĚëËėĖęĘēĒfFgGğĞĝĜġĠģĢhHĥĤħĦiIíÍìÌĭĬîÎïÏĩĨİįĮīĪijIJıjJĵĴkKķĶlLĺĹľĽļĻłŁŀĿmMnNńŃňŇñÑņŅŋŊoOºóÓòÒŏŎôÔöÖőŐõÕøØǿǾōŌœŒpPqQĸrRŕŔřŘŗŖsSśŚŝŜšŠşŞſßtTťŤţŢŧŦuUúÚùÙŭŬûÛůŮüÜűŰũŨųŲūŪvVwWŵŴxXyYýÝŷŶÿŸzZźŹžŽżŻþÞʼnαΑάΆβΒγΓδΔεΕέΈζΖηΗήΉθΘιΙίΊϊΪΐκΚλΛμµΜνΝξΞοΟόΌπΠρΡσΣςτΤυΥύΎϋΫΰφΦχΧψΨωΩώΏ

Si cela intéresse quelqu'un... Lofhi (me contacter) 28 juillet 2019 à 22:01 (CEST)

L'essentiel me semble être le principe général selon lequel les diacritiques sont ignorés pour le tri. Après, savoir si "(" vient avant ou après "[", ça ne change sans doute pas grand chose. Orlodrim (discuter) 28 juillet 2019 à 23:28 (CEST)

Oui mais un tri correct devrait triers tous les blancs ensemble, avant tous les symboles, puis toutes les ponctuations, puis tous les chiffres (ou la valeur numérique du nombre à plusieurs chiffres si on peut le délimiter, on trie ensuite sur les chiffres individuels en cas d'égalité numérique), puis toutes les lettres (en ignorant d'abord la casse, puis en triant les lettres accentuées après les non accentuées, puis en triant les minuscules avant les majuscules), puis enfin en groupant les codages canoniquement équivalents, puis enfin en utilisant un trio binaire en dernier lieu (s'il reste encore des sous-groupes canoniquement équivalents qui ne non pas réduits à un seul élément). Tout cela est décri dans l'algo Unicode standard "UCA", cela s'appelle une "collation multiniveau". Un tri incomplet mais suffisant dans la plupart des cas devrait au moins utiliser les deux premiers niveaux puis le tri binaire en dernier lieu.

Le tableau de "triage" (sic!) indiqué au début de ce sujet par Lofhi est totalement faux et absurde, il est à moitié correct pour le latin (il omet de trier ensemble toutes les ponctuations avant les chiffres et lettres), totalement faux pour le grec (en fait il faut enlever toutes les majuscules du tableau, et d'abord comparer les chaines entièrement converties en minuscules avant de trier les accents, puis à la fin trier les différences de casse). Ce tableau ci-dessus correspond à fait à l'ordre binaire UTF-8 (donc sans aucune collation, car Mediawiki n'en fait strictement aucune et ne fait QUE le tri binaire; pas besoin de table, l'ordre UTF-8 est identique à celui des points de code Unicode, et ce tableau ne sert même à rien du tout d'utile dans la doc de Mediawiki, c'est juste certains morceaux extraits de la table de codage Unicode, dont le premier commence évidemment par l'ordre binaire de l'ISO 8859-1, lui-même commençant par l'ordre binaire de l'ASCII !). Mais quand on voit les justifications de Lohfi, on voit bien qu'il ne comprend toujours pas en quoi ce n'est pas un ordre de "triage" (sic!) juste un ordre strictement binaire lié au codage UTF-8 utilisé. Mediawiki ne trie donc strictement rien, et c'est à nous de spécifier le tri avec des clés (l'ordre binaire est juste utilisé par défaut en absence de clé de tri, pour les listes de noms de pages comme les catégories ou les listes de page commençant par un préfixe donné; MediaWiki même ignore qu'on utilise le codage UTF-8, du moment que le codage utilisé est compatible avec l'ASCII sur 7-bit qu'il représente sur un seul octet; Mediawiki peut aussi bien fonctionner avec d'autres codages et c'est ce qu'il a fait au début avec l'ISO 8859-1 ou plus tard avec les codages chinois, dont GB18030, qui code les lettres latines accentuées différemment et donc les "triera" très différemment en ordre binaire). Verdy p (discuter) 30 juillet 2019 à 14:11 (CEST)

Vous aimez jouer avec les mots, non ? Enfin bref... Lofhi (me contacter) 30 juillet 2019 à 19:39 (CEST)

Lua ou MesdiaWiki ne sont pas concernés du tout par les clés de tri générées par ce modèle, qui est destiné au tri du côté client qui clique une icône en tête de colonne: pour ça, il FAUT un code Javascript.

Mais le collateur "Intl.Collator()" n'est pas supporté dans nombre de navigateurs (cela demande un package assez lourd et très lent en plus s'il n'est pas implémenté nativement dans le moteur Javascript). Il y a bien un collateur dans les packages associés à jQuery mais il est lui aussi tout aussi lourd.

Ma page perso contient une fonction de collation simple mais suffisante pour trier la plupart des tableaux en Javascript (au moins pour les langues à écriture latine)... Ce code est activé sur mon compte sur tous les wikis de Wikimédia (et même d'autres...) dans toutes les langues (et même toutes les écritures non latines, même si sur elles ce code n'a pas d'effet).

Je l'utilise depuis des années (sur tous les navigateurs de divers OS, même sur mobile ou tablette) sans aucun problème de performance, même sur les pages avec de très grands tableaux (et avec cette fonction même les tableaux créés sans clés de tri peuvent être triés convenablement). La fonction au moins effectue un tri primaire et secondaire correct mais tri partiellement les accents entre eux, mais au moins toujours après les lettres latines de base (qui sont triées d'abord en ignorant la casse).

Mediawiki ne génère pas ce code javascript et pas plus ce wiki dont la fonction de tri par défaut est vraiment trop basique et ne fait qu'un tri binaire (dans l'ordre binaire des octets du codage UTF-8 sans savoir ce que c'est). Verdy p (discuter) 30 juillet 2019 à 11:12 (CEST)