Discussion modèle:clé de tri

Ajouter une discussion
Discussions actives

Discussions sur ce modèleModifier

Critères de tri selon les languesModifier

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)

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:
[[Catégorie:Thématique de mots anglais classée en anglais|{{clé de tri/en|clé primaire|clé tertiaire}}]]
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)
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)
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)

Clé de tri pour le bretonModifier

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)

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)
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)
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)
  @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)
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)
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)

JaponaisModifier

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)

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)
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)
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)

CatalanModifier

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)

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)
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)

CatégorieModifier

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)

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

Chiffres romainsModifier

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)

Distinction radical / affixe pour gérer les tiretsModifier

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)

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 : [1] : 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)
Tout à fait. JackPotte ($) 8 décembre 2013 à 11:58 (UTC)

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)

Clé en tri en grec et trémaModifier

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)

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)

Modèle:clé par langueModifier

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)

Eszett (ß)Modifier

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)

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