Discussion modèle:clé de tri

• Ce modèle a été créé suite à la discussion : Wiktionnaire:Wikidémie/avril_2007#Tri ascii
• Ce modèle a été généralisé à tous les articles suite à la discussion : Wiktionnaire:Wikidémie/mai_2007#Clé de tri ascii : plus simple encore
• Un problème (semblant résolu depuis) a été évoqué dans la discussion : Wiktionnaire:Wikidémie/février_2008#Problème de {{clé de tri}} ?
• Wiktionnaire:Wikidémie/juillet 2013#Simplification du système de clés de tri
• Wiktionnaire:Wikidémie/septembre 2016#Tri des catégories par défaut
• Wiktionnaire:Prise de décision/Clés de tri françaises par défaut (juillet 2017)
• Wiktionnaire:Wikidémie/juillet 2017#Pour conclure Wiktionnaire:Prise de décision/Clés de tri françaises par défaut
• Discussion module:clé de tri

Est-ce qu'il n'y a pas un problème avec ce modèle quand une page comporte plusieurs langues n'ayant pas les mêmes critères de tri pour le mot ? Est-ce que si, dans ce cas, on indique les clés de tri dans chaque cas particulier, comme auparavant, ces clés manuelles empêchent de prendre en compte le modèle ? Lmaltier 13 juin 2007 à 17:29 (UTC)Répondre

Nombre de mots sont utilisés dans plusieurs langues avec des tris différents.

Nouveau: le calcul de la clé de tri est paramétrable par langue, cependant il faut passer le paraètre lang= et on ne peut inclure ce modèle qu'une fois par article (car il indique le tri par défaut pour toutes les catégories. Cela convient à un article ne contenant qu'une seule langue de classement.

Sinon, on peut vouloir classer dans une catégorie spécifique avec une clé de tri conforme à la langue:

]

La clé secondaire est toujours calculée à partie de la clé tertiaire forcée en minuscule (sans différence de casse).

Le modèle établit automatiquement les différences nécessaires et calcule une clé unique triée de façon appropriée pour la langue.

Je ne comprends pas cette histoire de clés primaire, secondaire, tertiaire... Il y a aussi le cas des catégories générées automatiquement (par exemple par le modèle -nom-). Il faudrait mettre à jour l'aide pour expliquer tout ça clairement pour le cas des pages multilangues.

Par ailleurs, il faudrait ajouter les règles particulières à chaque langue (par exemple, comment faire pour que, en espagnol, ll apparaisse après lz ? Une solution pourrait être de remplacer dans la clé de tri tous les ll par lzzzzz (par exemple), mais il faut avoir des conventions claires. Lmaltier 27 octobre 2007 à 08:44 (UTC)Répondre

D'après cet article, il n'y aurait pas à séparer les mots en l- et les mots en ll-. Ftiercel 21 février 2008 à 07:26 (UTC)Répondre

Oui mais on ne peut pas indexer différemment selon les langues, s'il y a plusieurs langues dans la même page.

Sans le support de clés multiples par langue, il n'y a aucun moyen de régler le problème correctement avec une seule clé de tri par défaut (et passer une clé de tri dans chaque modèle utilisé est trop compliqué.

Patience, cela va être réglé, voir discussions en cours sur Bugzilla:164 qui devrait permettre à terme des clés multiples pour des langues différentes, avec chacune leurs propres règles, et la possibilité d'indexer une catégorie sur une langue particulière par défaut, cette langue étant prise en compte dans le calcul de la clé effective de tri.

Parmi les changements qui vont arriver, {{DEFAULTSORT:préfixe}} et {{Catégorie:...|préfixe}} ne traiteront plus leur paramètre que comme un champ préfixe, le nom de la page étant ensuite utilisé dans un champ séparé, mais les deux étant utilisés ensuite selon la langue choisie par l'utilisateur. Il y aura un changement dans le schéma de base de données, mais à côté de ça j'ai proposé aussi que les fonctions de calcul de clé UCA soient utilisables en MediaWiki (pour trier les tables par exemple, là encore selon la langue de l'utilisateur ou une langue précisée dans la table). verdy_p (d) 30 juillet 2010 à 18:19 (UTC)Répondre

Le breton utilise trois graphèmes c, ch et c'h qui sont rangés dans cet ordre dans les dictionnaires (le c étant extrêmement rare et n'intervenant que dans les mots étrangers). Par exemple : chupenn, « veste », apparaît avant c'hoant, « envie ». Serait-il possible de conserver cet ordre dans les catégories du Wiktionnaire ? Merci.--Yun (causer) 27 octobre 2007 à 12:33 (UTC)Répondre

Là aussi, on pourrait remplacer ch par czzz et c'h par czzzzzz (par exemple). Le tout pour que ça marche est de toujours faire la même chose. Il faut proposer une convention qui marche pour le breton. Lmaltier 27 octobre 2007 à 13:02 (UTC)Répondre

Oui c'est une bonne idée. Ainsi le "c" apparaîtrait avant "ch" et "c'h". Peut-être que "czz" et "czzzz" suffirait ? --Yun (causer) 27 octobre 2007 à 13:17 (UTC)Répondre

Je ne sais pas si une décision a déjà été prise mais plutôt que cette convention, je proposerais plutôt un tri considérant 3 catégories de c :

• c → c1
• ch → c2
• c'h → c3 Ftiercel 21 février 2008 à 07:26 (UTC)Répondre

@Ftiercel : Moi non plus, je ne sais pas si une décision a été prise. Je ne pense pas que ce soit judicieux de mettre une clé de tri quand il y a simplement un c dans le mot, car il n’y en a pas besoin en général… Par ailleurs, n’existe-t-il pas de mot en breton incluant un chiffre (comme, par exemple, K2 ou A2 en français) ? Il ne faudrait pas que les clés de tri mises perturbent le tri dans ces cas. Ce qui était proposé est la façon de faire classique, il suffit juste de prendre une décision. Lmaltier (discussion) 13 janvier 2021 à 20:22 (UTC)Répondre

Wow ! Cette alerte me replonge 13 ans en arrière ! Cette discussion est plus proche de la création de Wikipédia que du Coronavirus. Si aucune décision n'a été prise, il faut croire que ça ne pose pas beaucoup de problème. Je n'ai jamais parlé le breton. Je pense qu'il faut envisager le statu quo. Ftiercel (discussion) 14 janvier 2021 à 11:42 (UTC)Répondre

Oui, c’est le voyage dans le temps… Mais, sinon une décision formelle, il y a eu un Module:clé de tri écrit qui traite le problème, et génère automatiquement la clé de tri si on appelle le modèle clé de tri avec le paramètre lang=br. Lmaltier (discussion) 14 janvier 2021 à 12:21 (UTC)Répondre

@Unsui, @Pamputt, @JackPotte, @TAKASUGI Shinji, @Automatik et @Ftiercel : Je reviens sur les solutions proposées et celle en cours. Considérant que 1) les mots bretons contenant un c non suivi de h ni de ʼh sont extrêmement rares, et 2) le graphème "cʼh" est rangé naturellement (sans clé de tri) à la bonne place, je propose de simplifier ainsi le traitement de c, ch et cʼh en breton :

• c : rien dans le module - c + espace dans les titres des sections de type de mot ;
• ch : rien dans le module - rien dans les titres des sections de type de mot ;
• cʼh : rien dans le module - rien dans les titres des sections de type de mot.

--Yun (causer) 25 avril 2024 à 06:47 (UTC)Répondre

Bonjour,

Vu que le c est rare et que le reste est bien placé, ça me semble une bonne solution. — Unsui Discuter 25 avril 2024 à 11:47 (UTC)Répondre

Merci. Puisqu’aucune objection n’a été formulée, je pense qu’on peut adopter cette solution. --Yun (causer) 29 avril 2024 à 05:09 (UTC)Répondre

Est-ce qu'on trie par écriture en rōmaji (=transcription en caractères latin) ?

• Si oui, comment fait-on pour les caractères vedettes qui ont deux prononciations (on'yomi et kun'yomi) ?
• Garde-t-on les indices {{CatégorieTDMJaponais}} dans les catégories ?

Est-ce qu'on trie par écriture en kana ?

• Si oui, comment fait-on pour les caractères vedettes qui ont deux prononciations ?

Est-ce qu'on trie par écriture en japonais ?

• Garde-t-on les indices {{CatégorieTDMJaponais}} dans les catégories ?
• Il y a un problème dans la navigation des catégories. La navigation fini par s'enrayer. Par exemple, si on veut passer à la page suivant celle-ci, on retombe sur la même. Ça enraye aussi les bots.

Ftiercel 14 février 2008 à 11:18 (UTC)Répondre

En fait, il faudrait pouvoir faire des recherches en utilisant toutes ces méthodes. Le wiktionnaire n'est pas trop conçu pour cela a priori. LBO disc 20 février 2008 à 19:32 (UTC)Répondre

Une solution (je dis pas qu'elle bonne) serait d'ajouter deux nouvelles catégories, Catégorie:japonais par kana et Catégorie:japonais par romaji, et que la Catégorie:japonais trie par kanji, la catégorie japonais par kana trie par kana, la catégorie par romaji trie par romaji. Il faudrait ainsi mentionner trois catégories dans les articles. Ça me semble quand même assez lourd.

Dans tous les cas, si tri par kanji il y a, je pense qu'un tri en prenant la racine des kanji ne suffit pas (ex : 餞). Avec cette technique, trop d'articles ont la même clé et après, on n'arrive plus à naviguer dans la catégorie. Il faudrait convertir soit

• 餞 → 食8

soit

• 餞 → 食餞

Bon, pour ma génération d'article, je pense que je ne vais pas faire de tri. Ce sera à rajouter plus tard. Les clés de tri peuvent facilement être retravaillées dans les articles ultérieurement. Ftiercel 21 février 2008 à 07:26 (UTC)Répondre

Ne pas créer de modèle pour ça, de toute façon passer les bons paramètres serait trop compliqué à vérifier. Mais grâce à la résolution en cours de travaux de Bugzilla:164, on devrait pouvoir le faire automatiquement (et même sans ajouter aucune catégorie, la même catégorie pouvant supporter plusieurs tris linguistiques différents et sélectionnables d'un seul clic, sur les catégories qui autont été marquées dans leur page wiki pour permettre des tris multiples).

Si Bugzilla:164 se finalise, il ne sera même plus nécessaire de préciser des clés de tri par défaut dans la quasi-totalité des articles (le modèle d'une part sera modifié pour ne pas surcharger les clés de tri automatiques, là où il sera encore utilisé, mais en plus il ne sera souvent même plus nécessaire du tout, ce qui évitera de les vérifier un par un, et on pourra même en supprimer un bon nombre automatiquement, et le modèle actuel pourra même signaler automatiquement la plupart des endroits où il sera totalement inutile et pourra être ensuite supprimé par un bot, les autres endroits restant alors à vérifier manuellement). On fera des catégories spécifiques pour le suivi de ces cas à nettoyer (car la mise à jour prendra des heures voire quelques jours, et beaucoup de ressources serveur, avant même qu'on utilise un bot pour ôter les emplois qui seront devenus inutiles. verdy_p (d) 30 juillet 2010 à 18:27 (UTC)Répondre

En catalan on trie l·l comme ll. Alors, il faut simplement éliminer le point médian et ne pas le remplacer par un espace comme il dit maintenant le modèle. Références : Académie catalane. --Vriullop 11 avril 2009 à 16:44 (UTC)Répondre

Je suis aussi totalement d’accord : ce point médian est un signe diacritique modifiant le premier l (exactement comme un accent) et perd son rôle de ponctuation dans ce cas, car ce n’est pas un séparateur de mot dans un composé mais une distinction pour la prononciation géminée du l et non mouillée (le français ne fait pas cette distinction dans les formes en -ill-, le catalan si !)

La doc est fausse sur ce point (et je ne sais pas qui a inventé cette règle pour l’appliquer au catalan).

La solution est pourtant simple : tout point médian entre deux l doit être supprimé (et tant pis si dans des cas exceptionnels, car inconnus jusqu'à présents, il aurait la valeur de ponctuation, dans un article qui mentionnerait un usage homographe non catalan, par ex. comme une unité de mesure notée de cette façon telle que « cal·l^-1 » pour « calorie par litre », car l’usage recommande dans ce cas des espaces autour du point médian dan la notation stricte : « cal · l^-1 » ou bien la barre de fraction « cal/l ») ; sinon on le transforme en espace. verdy_p (d) 30 juillet 2010 à 17:37 (UTC)Répondre

Note : en catalan, les deux ll ou l·l sont traités normalement comme un seul l dans le tri (ce sont des digrammes ou trigrammes, avec une différence mineure par rapport au l simple), mais là on a un problème de cohabitation avec les autres langues dans le même article. Malheureusement on ne peut pas encore mentionner des clés de tri spécifiques pour une langue particulière (patience, ça va venir !) s'il y a d'autres langues dans le même article. La gestion des digrammes (comme ch) ou trigrammes (comme c’h en breton) va venir quand on pourra distinguer les langues dans les clés de tri de catégories. verdy_p (d) 30 juillet 2010 à 17:45 (UTC)Répondre

Je pense qu'il faut ajouter ce modèle à :Catégorie:Extension_du_langage_MediaWiki, ou supprimer cette dernière. JackPotte 22 octobre 2009 à 14:43 (UTC)Répondre

 Pour Quelqu’un s’y oppose-t-il ? → voir Catégorie:Extensions du langage MediaWiki. Automatik (discussion) 9 juin 2013 à 18:37 (UTC)Répondre

— Automatik (discussion) 27 août 2014 à 01:10 (UTC)Répondre

Wikipédia traduit les chiffres romains en chiffres arabes. Faudrait-il faire de même au risque de les mélanger dans les catégories ensuite ? JackPotte ($♠) 17 juin 2012 à 18:21 (UTC)Répondre

Je trouve que la méthodologie actuelle serait grandement simplifiée si nous traitions les tirets des radicaux de la même façon que ceux des affixes. Outre les degrés de compétences et concentration requis, cela permettrait de le faire par bot avec un degré de certitude nettement plus élevé qu'actuellement. D'ailleurs je ne connais pas de dictionnaire qui les traite différemment. JackPotte ($♠) 6 décembre 2013 à 14:35 (UTC)Répondre

En pratique, cela signifierait de passer de :

• boulanger
• boulanger-pâtissier
• boulangerie

à :

• boulanger
• boulangerie
• boulanger-pâtissier

pour (re)prendre un exemple simple.

Dans la catégorie "français", avec tous les mots en coupe-, cela donne le classement suivant avec le traitement actuel des tirets :  : seul coupe-boulons ne suit pas ce classement (il a le tiret supprimé dans sa clé de tri contrairement aux autres mots en coupe- où le tiret est remplacé par une espace), cela permet de voir la différence puisqu’il se situe après coupeau. Personnellement, je préfère garder le classement actuel, mais ça dépend du prix à payer en terme de maintenance.

Négociations : j’imagine que la disjonction de cas doit être traitable plutôt facilement par bot : ce que je ferais (en supposant que c’est possible avec JackBot), c’est traiter dans un premier temps tous les tirets comme à remplacer par des espaces dans la clé de tri. À la fin des calculs pour la clé de tri, je ferais un trim sur celle-ci. Est-ce envisageable ? — Automatik (discussion) 8 décembre 2013 à 01:37 (UTC)Répondre

Tout à fait. JackPotte ($♠) 8 décembre 2013 à 11:58 (UTC)Répondre

Moi aussi, je préfère le traitement actuel, de très très loin. Effectivement, les dictionnaires habituels font autrement (pas seulement pour les mots avec trait d’union, mais aussi pour les locutions genre pomme de terre ou chemin de fer) : la logique proposée amènerait donc logiquement à supprimer tous les espaces, apostrophes, traits d’union, etc. indistinctement. Mais ce n’est pas le cas des dictionnaires qui ont une forte proportion de mots composés et locutions : je pense en particulier à un dictionnaire anglais d’argot qui explique les deux façons de trier classiques, et qui adopte celle qui est en pratique la même que la nôtre (je ne connais pas d’autre cas pour les dictionnaires, mais il y en a probablement). La proportion des noms composés et locutions y est forte, là aussi, et ils sont traités à part, comme chez nous. Les listes de noms de rue ou de stations de métro, qui ont aussi une forte proportion de mots composés de plusieurs mots, adoptent elles aussi cet ordre, en général. Cela permet d’autre part de se rapprocher des dictionnaires classiques, paradoxalement : les locutions y sont généralement regroupées avec le premier mot simple, nous les regroupons nous aussi au moins dans les catégories. Je suis d’accord avec Automatik pour l’automatisation proposée pour ce cas. Mais, pour moi, il est délicat d’automatiser tous les cas, ce n’est pas impossible, mais c’est très facile de se tromper. Lmaltier (discussion) 5 juin 2018 à 05:25 (UTC)Répondre

La page de documentation ne spécifie pas quoi faire pour les lettres grecques avec tréma (ϊ et ϋ). L'usage veut de les remplacer par ι et υ respectectivement. Chinedine (discussion) 4 janvier 2014 à 10:29 (UTC)Répondre

La documentation se contente de décrire en détail seulement l’alphabet latin, et pour le reste elle reste générale mais c’est ça : les diacritiques doivent être retirés des lettres dès qu’ils ne font pas partie de l’alphabet — par exemple ä est une lettre de l’alphabet suédois, donc on ne crée pas de clé de tri en suédois pour cela, mais ce n’est pas une lettre de l’alphabet français, donc dans ce cas la clé de tri est nécessaire. Ici ϊ et ϋ n’étant pas des lettres de l’alphabet grec, ils doivent être remplacés en effet. — Automatik (discussion) 4 janvier 2014 à 20:47 (UTC)Répondre

J’ai créé le nouveau modèle {{clé par langue}}. Ce modèle n’ajoute pas {{DEFAULTSORT:}} à une clé de tri comme {{clé de tri}}. — TAKASUGI Shinji (d) 10 septembre 2017 à 01:54 (UTC)Répondre

Quid de l’eszett allemand (caractère ß) ? Il semblerait qu’il faille lui associer la chaîne ss dans la clé de tri ; si oui, à signaler dans la présente documentation ? Je demande, car j’ai vu certaines entrées simplement le remplacer par un s, voire ne pas indiquer de clé de tri du tout. — SniperMaské (discussion) 16 août 2018 à 10:23 (UTC)Répondre

C’est automatiquement trié immédiatement après ss : . On n’a plus besoin de spécifier une clé de tri pour ‹ ß ›. — TAKASUGI Shinji (d) 16 août 2018 à 16:28 (UTC)Répondre

Il y a quelques problèmes avec le modèle/module tel qu’il existe pour le moment :

• Les ligatures ne sont pas éclatées
• Les tirets/traits d’union, parenthèses et points en début ou fin de mot ne sont pas supprimés

Urhixidur (discussion) 16 avril 2024 à 14:13 (UTC)Répondre

Thomas le numéro 24 l'a constaté aussi. Keymap9 (discussion) 18 août 2024 à 12:19 (UTC)Répondre

Visiblement le problème vient du module quand on lui passe {{PAGENAME}} en paramètre.

Bizarrement quand on met le titre manuellement, le module fait son travail correctement. Thomas le numéro 24 (discussion) 18 août 2024 à 13:07 (UTC)Répondre