Discussion module:section

Pages de test : Discussion module:section/test et Discussion module:section/test espace. — Dakdada 8 juillet 2013 à 13:32 (UTC)

Paramètre "num"

Je me demandais si c’était fait exprès de numéroter le num que quand il vaut 2 (ne doit-on pas le faire aussi quand il vaut 1, comme actuellement quand il y a un 2 ? Automatik (discussion) 11 juillet 2013 à 02:52 (UTC)

Si, c'est prévu, ce n'était juste pas représenté dans les tests. — Dakdada 11 juillet 2013 à 09:08 (UTC)

Modifications à apporter

Symbole  

Le modèle {{-déf-}} permet une exception pour le modèle {{-symb-}} qui permet de ne pas préciser de langue (du coup le défaut est "conv"). Doit-on ajouter une règle spéciale ici aussi ou harmoniser et préciser systématiquement le code "conv" ? (Je suis d’avis d’harmoniser.) Il faudrait savoir quel est l’usage actuel des sections de symbole. — Dakdada 5 décembre 2013 à 17:41 (UTC)

J’ai posé la question par là-bas : Gestion des modèles. La discussion mène à la suppression de cette règle : il n’y a donc rien à modifier. S'il y a des modèles -symb- sans langue, ils seront de toute façon listés dans Catégorie:Wiktionnaire:Sections de titre sans langue donnée. — Dakdada 8 janvier 2014 à 21:43 (UTC)

Prénom

Le modèle {{-prénom-}} actuel accepte un paramètre genre= pour catégoriser les prénoms en sous-catégorie de genre. Doit-on ajouter cette règle spéciale pour les prénoms ou l’abandonner (et la remplacer par autre chose du coup) ? — Dakdada 5 décembre 2013 à 17:42 (UTC)

Comme je le disais ici, je trouve beaucoup plus simple de mettre « |genre=mf » dans {{S}}, répercuté de la ligne de forme toute proche, que de me décaler de Dieu sait combien de lignes (blocs -trad-, -pron-, -voir-, etc.) pour ensuite taper un interminable « [[Catégorie:Prénoms épicènes en français]] ». On parle de 9 caractères versus entre 40 et 50. {{S}} pourrait-il avoir un mécanisme générique d’ajout de paramètres supplémentaires occasionnels ? « |genre= » serait ignoré dans la plupart des cas, mais invoquerait un peu de code dans le cas S|prénom. Urhixidur (discussion) 5 décembre 2013 à 18:07 (UTC)

Le coupcoût technique est très négligeable (tant en terme de code que de temps d’exécution). Le plus important est la facilité d’usage. Si écrire la catégorie en fin de section est rédhibitoire (c’est le cas pour tout en fait), pourquoi ne pas par exemple mettre un modèle catégorisant sur la ligne de forme ou la ligne de définition, par exemple {{prénom|mf|fr}} ? — Dakdada 5 décembre 2013 à 20:03 (UTC)

C’était précisément l’idée derrière le paramètre genre de {{-prénom-}}. Ça me semblait plus simple de donner une petite extension à {{-prénom-}}, déjà nécessaire et présent, que de créer un autre modèle dans la lignée de {{pays}}, {{localités}}, etc. Ça évite également de créer d’éventuels problèmes du genre {{prénom}} sous un {{-nom-}}. J’ajoute qu’il fallait absolument mettre la catégorisation avec genre dans {{-prénom-}} pour éviter la catégorisation redondante (Catégorie:Prénoms en français de la part de {{-prénom-}}, suivi de Catégorie:Prénoms épicènes en français de la part de {{prénom|mf}}).Urhixidur (discussion) 6 décembre 2013 à 17:03 (UTC)

Je suis d’accord avec Urhixidur, l’ajout de ce paramètre avait grandement simplifié la gestion des catégories de prénoms. Et pareil, ce serait absurde de rajouter un nouveau modèle de l’acabit de {{pays}} pour la ligne de forme alors que ceux du même genre sont régulièrement critiqués (Modèle:pays affiche Géographie en début de ligne de forme ce qui surprend certains contributeurs). V!v£ l@ Rosière ^{/Murmurer…/} 8 décembre 2013 à 07:43 (UTC)

Pourquoi ajouter une catégorie en fin de section serait-il rédhibitoire ? On le fait couramment ici, et sur Wikipédia aussi, c'est une technique de base des wikis, que tous les contributeurs apprennent très vite. Et c'est simple et facile à comprendre, même pour ceux qui ne connaissent pas encore. Compliquer des modèles, c'est tout l'inverse : plus on les complique, plus ils sont difficiles à comprendre et à utiliser, plus les volontaires risquent d'être rebutés. Et le problème n'est pas théorique, il se pose déjà très souvent pour beaucoup de personnes de bonne volonté qui voudraient contribuer (on a eu des témoignages), y compris pour des contributeurs anciens (moi par exemple). Il ne faut jamais oublier que nous sommes un dictionnaire, pas un logiciel, que les contributeurs s'intéressent aux mots, et n'ont pas des réflexes d'informaticien (bien que j'ai peur que, d'ores et déjà, la complexité actuelle ait fait qu'une bonne partie des contributeurs réguliers sont des informaticiens, ce qui est complètement aberrant). Lmaltier (discussion) 8 décembre 2013 à 09:06 (UTC)

Le problème avec l’ajout des catégories en fin de section et qu’elles sont du coup déconnectées de la partie de la page concernée (en général une définition spécifique). L’idéal serait d’avoir les catégories placées à ces endroits. Le plus simple, même, serait de laisser les modèles catégoriser à notre place : c’est fait en partie, mais il est possible de faire beaucoup mieux.

Quoiqu’il en soit, je vais rajouter le paramètre pour les prénoms, pour respecter l’état actuel des modèles. Si on change d’avis plus tard, il sera toujours possible de changer ça. — Dakdada 8 décembre 2013 à 13:00 (UTC)

Voilà, c’est fait. — Dakdada 9 décembre 2013 à 22:04 (UTC)

Ancres des types de mots

Le code pour générer les ancres des types de mots devrait être corrigé dans la fonction publique entree :

    local ancre = _fait_ancre(lang, typen, flex, loc, num)

ne peut pas marcher vu la définition de _fait_ancre : il faut ajouter article en premier paramètre.

De plus je crains que les alias ne soient pas pris en compte pour l’ancre : la fonction get_abrev ne va vérifier que si le type de mot le plus "standard" a été choisi. Il faudrait modifier ça dans Module:types de mots, si possible. — Automatik (discussion) 6 décembre 2013 à 08:55 (UTC)

En effet, je pense que c’est réparé. J’ai aussi corrigé la prise en compte des alias. — Dakdada 6 décembre 2013 à 23:48 (UTC)

Merci pour ton intervention. — Automatik (discussion) 7 décembre 2013 à 23:11 (UTC)

Paramètre clé ?

Bonjour,

Le paramètre clé= est parfois utilisé dans les pages : par exemple pour empeñado. En passant par {{S}}, serait-il encore pris en compte ? — Automatik (discussion) 8 janvier 2014 à 12:20 (UTC)

Oh, encore un paramètre caché… je ne l’avais pas vu celui-là. Il faudrait voir s'il est vraiment utilisé et utile. — Dakdada 8 janvier 2014 à 12:27 (UTC)

À titre informatif, il s’est avéré être nécessaire pour les entrées ossètes -- voir Wiktionnaire:Bot/Requêtes/Archives/2013#clés de tri ossètes. — Automatik (discussion) 8 janvier 2014 à 12:33 (UTC)

Le truc c’est que ça ne va marcher que pour les titres. Tous les autres modèles catégoriseront avec le tri par défaut. Et c’est pas super de devoir donner une clé de tri à chaque modèle…

Le mieux serait de faire les clé de tri automatiquement selon la langue donné en paramètre de modèle. C’est possible et ça peut être fait efficacement si on le fait intelligemment (sans recalculer la clé à chaque appel de modèle…). Bien sûr ça demandera du code en plus, mais c’est plus intéressant pour le long terme (on aura pas à modifier chaque clé individuellement s'il y a des erreurs, si on change de règle ou si on décide de les enlever). — Dakdada 8 janvier 2014 à 13:46 (UTC)

Après tout dépend : si ce code n’est pas souvent utilisé, je peux ajouter le paramètre au module le temps de trouver une solution plus élégante. Mais s’il y en a plein, ce serait mieux de passer à une version automatique. — Dakdada 8 janvier 2014 à 13:48 (UTC)

Sans être très répandu, le paramètre clé= est toutefois utilisé quand on a besoin d’avoir des tris différents selon la langue pour une entrée donnée. Je l’utilise dans ce cas systématiquement (ossète, same du Nord, espéranto, etc.). Voir par exemple Ásia qui vient entre "asfódelo" et "asiano" en portugais mais bien après "avvin" en same du Nord avec tous les mots commençant par á. — Unsui Discuter 8 janvier 2014 à 14:23 (UTC)

Bon, j’ai (facilement) ajouté le paramètre. En attendant d’avoir une meilleure gestion des clés (idéalement de Mediawiki même, on peut toujours rêver). — Dakdada 8 janvier 2014 à 16:02 (UTC)

On peut toujours faire un vœu, c’est la bonne période . Sinon, merci. — Unsui Discuter 8 janvier 2014 à 16:06 (UTC)

À titre indicatif : 43 163 pages sont concernées. — Dakdada 9 janvier 2014 à 16:28 (UTC)

Clé de tri, suite

Euh, c’est quoi la syntaxe pour placer une clé de tri. J’ai mis === {{S|nom|se|flexion|clé=ha’la}} === dans hála mais ça ne fonctionne pas (l’entrée est mal placée). — Unsui Discuter 17 janvier 2014 à 16:43 (UTC)

Le code créé me semble correct. Les autres entrées ont-elles aussi la clé ? — Dakdada 17 janvier 2014 à 22:11 (UTC)

Ok, en fait la catégorie de langue plante mais pas la catégorie "Nom en langue". Or la catégorie de langue est créée par le modèle de section de langue {{langue}}. Du coup il vaut mieux faire créer la catégorie de langue par les modèles de section de langue pour qu'ils bénéficient de la clef le cas échéant… — Dakdada 17 janvier 2014 à 22:18 (UTC)

Merci d’avoir remarqué ce bug. — Dakdada 17 janvier 2014 à 22:53 (UTC)

Merci ! Par contre, je ne comprends pas vraiment : "Du coup il vaut mieux faire créer la catégorie de langue par les modèles de section de langue pour qu'ils bénéficient de la clef le cas échéant…" (désolé). Y-a-t-il quelque chose de spécial à faire ? À partir du moment où le modèle {{langue}} est rencontré, l’entrée est catégorisée dans sa catégorie de langue, non ? — Unsui Discuter 18 janvier 2014 à 09:33 (UTC)

{{langue}} catégorise, mais sans clé. Si une clé de tri est donnée à un modèle de section, la catégorie de langue est maintenant réécrite avec la clé donnée (sinon elle n’utiliserait pas de clé, ou {{clé de tri}}). — Dakdada 18 janvier 2014 à 11:54 (UTC)

Ah d’accord, je n’avais en effet pas compris. Merci. — Unsui Discuter 18 janvier 2014 à 13:44 (UTC)

Locution forcée ?

On a créé Catégorie:Wiktionnaire:Sections de type avec locution forcée, mais il faudrait savoir que l’on n’utilise pas d’espace en chinois et en japonais. Aucune entrées dans Catégorie:Locutions en chinois et dans Catégorie:Locutions en japonais n’a d’espace. — TAKASUGI Shinji (d) 24 janvier 2014 à 13:38 (UTC)

L’approche est ici de considérer comme locutions les termes qui ont des espaces (en gros). Ça marche pour les alphabets latin, cyryllique, grec… Mais apparemment pas pour les alphasyllabaires (dis-moi si je me trompe de termes).

Si on connaît la liste des langues pour qui les locutions n’ont pas besoin d’espaces, je peux introduire cet aspect dans le code pour les reconnaître. Il faudra, du coup, que l'on garde dans le code du titre l’information qu’il s’agit de locutions (avec le paramètre locution=oui, sauf dans le cas où il s’agit de types comme locution-phrase ou proverbe), et donc il faudra adapter le code de conversion quand on arrivera à ces langues. — Dakdada 24 janvier 2014 à 13:49 (UTC)

Paramètre spéc

Dans la foulée du genre des prénoms, il faudrait un paramètre spéc (pour « spécialisation ») qui fasse quelque chose de très semblable dans le cas des nom-fam. Par exemple, Parker a une entrée nom-fam qui, naturellement, catégorise sous Catégorie:Noms de famille en français, mais la page spécialise ensuite cette catégorisation en Catégorie:Noms de famille anglais en français. Si on pouvait écrire {{S|nom-fam|fr|spéc=anglais}} pour créer cette seconde catégorisation tout en évitant la première, ce serait l’idéal.

À bien y penser, ça peut se généraliser à toutes les sections (ou presque). Même des sections comme adj-indéf devraient pouvoir s’écrire adj|spéc=indéfinis. D’autant plus qu’on a Catégorie:Adjectifs comparatifs, Catégorie:Adjectifs diptotes, Catégorie:Adjectifs superlatifs, Catégorie:Adjectifs variables, Catégorie:Adverbes comparatifs, Catégorie:Adverbes de lieu, Catégorie:Adverbes de temps, Catégorie:Adverbes superlatifs, etc., sans pour autant avoir {{-adj-compos-}} ni {{-adj-dipt-}}, etc. Règle générale, le paramètre spéc s’insérerait dans la catégorisation toujours au même endroit : « Catégorie:<nom de la section> <spécialisation> en <nom de langue> ».

On pourrait même convertir les genre en spéc si on était prêts à se passer de la validation en m, f, mf. Cependant ce serait indésirable car on a Catégorie:Prénoms par origine ce qui fait que {{S|prénom|fr|genre=f|spéc=anglais}} doit donner deux catégorisations parallèles (Prénoms féminins en français et Prénoms anglais en français). Urhixidur (discussion) 5 février 2014 à 15:32 (UTC)

Je suis assez frileux à cette idée. Par exemple, les adjectifs xxx, mis à part qualificatifs, ne sont pas des adjectifs à proprement parler. Et écrire « S|adjectif|spéc=variable » est plus compliqué que « S|adjectif variable », pour un gain quasi-nul.

J’étais déjà retissantréticent à l’ajout du paramètre de genre, mais là c’est vraiment trop de surcharge. Les modèles de titre doivent rester simples (ils sont déjà trop complexes). — Dakdada 5 février 2014 à 15:53 (UTC)

Je comprends ta réticence, et l’effort est louable. Mais il faut considérer l’effet sur le rendu. Comparons :

=== {{S|nom de famille anglais|fr}} ===

Nom de famille anglais (section inconnue)

Avec :

=== {{S|nom de famille|spéc=anglais|fr}} ===

Nom de famille

À mon avis, le libellé spécialisé dilue un petit peu la cohérence du Wiktionnaire, et je trouve l’insertion de |spéc « dans » le paramètre principal de {{S}} facile à comprendre et naturelle. Ne perdons pas de vue que ce paramètre ne sera utilisé que très occasionnellement. L’apparition de l’astérisque final et la disparition de l’icône (dans le libellé spécialisé) donnent l’impression d’une erreur, ce qui est un irritant plus sérieux. D’autres sons de cloche ? Urhixidur (discussion) 5 février 2014 à 21:28 (UTC)

Le problème avec {{S|nom de famille anglais|fr}} ou {{S|nom de famille|spéc=anglais|fr}} par rapport aux catégories est l'obligation de se limiter à une seule langue, pourquoi pas plusieurs ou un pays ? Ne serait-ce pas redondant de {{étyl}} (avec {{S|nom de famille|spéc=en|fr}}) ? JackPotte ($♠) 5 février 2014 à 21:45 (UTC)

Ce que je dis c’est que si les paramètres supplémentaires ne sont pas utilisés par le titre de section, alors ils n’ont rien à y faire. En l’occurrence le fait qu’il s’agit d’un nom d'origine anglaise n’a pas grand intérêt pour le titre : on pourrait aussi vouloir préciser le genre, la déclinaison, l’époque d’utilisation, que sais-je ? De même pour la plupart des autres paramètres que tu proposes. Si le seul but est seulement de catégoriser, alors il y a d’autres moyens que d’encombrer le titre de section. Le titre de section a pour vocation première de faire des titres, pas des catégories. — Dakdada 5 février 2014 à 21:55 (UTC)

On en revient à mon ancienne proposition d'y fusionner le {{PAGENAME}} et les {{fr-rég}} comme sur certains autres Wiktionnaires. JackPotte ($♠) 5 février 2014 à 22:42 (UTC)

Impossible si on veut garder la modification des titres, qui est le but premier du nouveau modèle. Et aussi trop complexe. Un titre de section est un titre de section, arrêtez de vouloir tout y mettre. — Dakdada 6 février 2014 à 08:55 (UTC)

« si les paramètres supplémentaires ne sont pas utilisés par le titre de section, alors ils n’ont rien à y faire. » Le problème, c’est la catégorisation automatique, qui a besoin d’être modifiée par spécialisation. D’où la nécessité de passer cette instruction au modèle qui catégorise, c.-à-d. {{S}}. Urhixidur (discussion) 6 février 2014 à 13:59 (UTC)

Pour faire des catégories spécialisées, il faut utiliser un autre modèle spécialisé. Ou alors je n’ai pas compris ce que tu as dis… — Dakdada 6 février 2014 à 15:55 (UTC)

En effet, je ne me fais pas comprendre. Pour spécialiser la catégorisation induite par {{S}}, on a deux choix : a) Classer la section sous nocat au lieu de fr et catégoriser manuellement (avec [[Catégorie:… dans le code ou avec un modèle spécialisé comme {{chimie}}), sinon b) refiler un paramètre (pas encore pris en charge, d’où cette discussion) à {{S}} pour qu’il l’insère verbatim dans sa catégorisation. L’option b) me semble plus simple d’emploi et moins sujette à l’erreur. Urhixidur (discussion) 7 février 2014 à 17:49 (UTC)

Je comprend encore moins : donne un exemple, car parler de nocat et de chimie est encore plus confus : qu’est-ce que ça a à voir avec un titre de section ? — Dakdada 7 février 2014 à 19:02 (UTC)

Pour ajouter de nouveaux titres de section comme Nom de famille anglais, discutez dans la Wikidémie. C’est un gros changement et il n’y a pas beaucoup de gens qui lisent cette page-ci. — TAKASUGI Shinji (d) 7 février 2014 à 02:30 (UTC)

Nous ne voulons surtout pas ajouter des titres de section surspécialisés ! Urhixidur (discussion) 7 février 2014 à 17:49 (UTC)

Locution = 1

Je demande l'annulation de la révocation de Dak car il se contente d'interdire ce que les autres utilisent depuis des années, alors que cela ne changerait rien pour lui d'adopter cette ergonomie répandue qui ne remet pas en cause le nommage qu'il a défini tout seul.

De plus ses arguments pour forcer les éditeurs à taper uniquement "oui" malgré tout sont loin d'être clairs. JackPotte ($♠) 9 mars 2014 à 12:42 (UTC)

Qu'est-ce qui n'est pas clair exactement dans la distinction "oui"/"non" ? Tu essayes d'introduire une valeur de paramètre incohérente que seul un programmeur pourrait comprendre.

Il faudrait que tu m'expliques en quoi quelque chose qui est utilisé « depuis des années » ailleurs et pour un autre problème a quoi que ce soit à voir avec le paramètre locution= du modèle {{S}}. — Dakdada 9 mars 2014 à 12:49 (UTC)

num=1

Quand il y a un seul nom dans une section française, son ancre est clairement fr-nom. Il y aura quelques utilisations de cette ancre. Si on ajoute un autre nom de la même orthographe, leurs ancres seront fr-nom-1 et fr-nom-2. Le problème, c’est que le premier nom ne sera plus accessible par fr-nom. Est-il possible de donner au premier nom les deux ancres, fr-nom et fr-nom-1 ? Ou vaut-il mieux supprimer le numéro s’il est de 1, comme fr-nom pour le premier et fr-nom-2 pour le deuxième ? J’ai trouvé en réalité quelques ancres qui ne marchent plus. — TAKASUGI Shinji (d) 4 septembre 2015 à 15:41 (UTC)

J’ai modifié le code pour l’ancre : [1]. Maintenant l’ancre pour Nom commun 1 en français est fr-nom, non pas fr-nom-1.

Type de mot	Ancre
Nom commun	fr-nom
Nom commun 1	fr-nom
Nom commun 2	fr-nom-2

— TAKASUGI Shinji (d) 6 novembre 2015 à 02:54 (UTC)

→ Wiktionnaire:Wikidémie/avril 2016#Lien vers la première section d'un mot. — TAKASUGI Shinji (d) 10 avril 2016 à 06:06 (UTC)

Code langue manquant mal traité

Lorsque le code langue manque, par exemple {{S|adj}}, le modèle rend plutôt mal. On aurait préféré un rendu avec un message d’erreur clair. Comparer avec {{S|adj|flexion}}, qui rend une erreur discrète en apostille. Urhixidur (discussion) 30 juillet 2017 à 11:57 (UTC)

Utilisation d'un alias de section

Bonjour,
Pourquoi l'utilisation d'un alias de section ne donne pas le même résultat que l'utilisation du nom classique de la section ? Par exemple, je constate que la page bol utilise {{S|homo}} et n'est pas catégorisée dans la catégorie:Mots ayant des homophones, alors que ce serait le cas si elle utilisait {{S|homophones}}.
Cordialement --NicoScribe (discussion) 23 décembre 2017 à 17:31 (UTC)

C'est réparé. JackPotte ($♠) 23 décembre 2017 à 20:13 (UTC)

Catégorisation

Comment éviter la catégorisation dans un espace de noms autre que le principal ? Le modèle {{S}} catégorise Annexe:test mais pas Discussion Annexe:test. Je ne sais pas où est le code pour ne pas catégoriser ce deuxième. — TAKASUGI Shinji (d) 24 février 2018 à 03:32 (UTC)

Moi non plus, mais je ne comprends pourquoi tu voudrais ajouter d'un paramètre pour forcer la catégorisation d'une section dans une page de discussion. JackPotte ($♠) 24 février 2018 à 11:59 (UTC)

La catégorisation dans les espaces de contenu est faite par fait_categorie_contenu dans Module:bases pour info. — Automatik (discussion) 24 février 2018 à 18:10 (UTC)

Je voudrais ne pas catégoriser les pages de conjugaison comme Conjugaison:coréen/되다. J’utilise {{S}} pour séparer le verbe et l’adjectif de la même orthographe. — TAKASUGI Shinji (d) 25 février 2018 à 00:01 (UTC)

Ah c’est la fonction page_de_contenu dans Module:bases qui traite les annexes comme des pages principales. Merci. — TAKASUGI Shinji (d) 25 février 2018 à 09:11 (UTC)

Corrigé. — TAKASUGI Shinji (d) 25 février 2018 à 12:42 (UTC)

Mais maintenant les annexes de proto-langue ne sont plus catégorisées ? Exemple : Reconstruction:indo-européen commun/*h₁en – en fait seulement les annexes catégorisées manuellement apparaissent encore dans la catégorie (ex : Reconstruction:proto-same/*čëlmē), ce qui n’est pas optimal. Peut-être qu’il vaudrait mieux permettre de désactiver la catégorisation d’annexes avec un paramètre ? — Automatik (discussion) 27 février 2018 à 14:53 (UTC)

Merci pour l’information. J’ai annulé ma modification. Il vaudrait mieux créer un nouveau paramètre. — TAKASUGI Shinji (d) 28 février 2018 à 22:29 (UTC)

Le paramètre nocat ajouté. — TAKASUGI Shinji (d) 28 février 2018 à 23:42 (UTC)

Catégorisation inversée

Bonjour,

Comme discuté dans Wiktionnaire:Wikidémie/octobre 2019#Index inversé, est-il possible de modifier ce module pour qu’il rajoute les entrées dans des catégories de type « Catégorie:Index inversé en français » ? Voir le fonctionnement du modèle latin : [2] pour inspiration. Otourly (discussion) 21 novembre 2019 à 16:04 (UTC)

+ @Darkdadaah, @TAKASUGI Shinji et @JackPotte : Otourly (discussion) 3 décembre 2019 à 13:16 (UTC)

Je ne suis pas convaincu de l'utilité de la chose, comparée à son coût (compliquer le code, rajouter des calculs dans toutes les pages). Ce genre de tri devrait être automatisé au niveau des catégories elles-mêmes (e.g. juste en cochant une case), ou à l'aide d'un moteur de recherche prévu à cet effet. Si le but du jeu est de « trouver les mots qui finissent par [un certain groupe de lettres] », on a la recherche avancée anagrimes (qui est certes moins maintenable à long terme). — Dakdada 3 décembre 2019 à 17:08 (UTC)

@Darkdadaah : Anagrimes beugue ce soir (503) et ne permet pas d’avoir tout l’index inversé par langues. C’est une fonctionnalité qu’on trouve ailleurs, et la rendre disponible sur le Wiktionnaire sera pratique. Otourly (discussion) 3 décembre 2019 à 18:56 (UTC)

Je ne pense pas non plus que cela justifie l’ajout d'une catégorie dans toutes les pages. On doit pouvoir trouver une autre solution. Quant à avoir tout l’index inversé par langue ce que Anagrimes ne ferait pas, quel en serait l’intérêt ? — Automatik (discussion) 3 décembre 2019 à 19:52 (UTC)

Il s’agit d’élargir le champs des possibles. Tout les ouvrages classiques proposent l’ordre alphabétique. À cause de cela, sont apparu des dictionnaires de rimes. C’est inédit pour un site comme le notre de proposer les deux. La volonté de rechercher par fin de mot n’est pas nouvelle et c’est pour ça qu’Anagrimes a été créé. Mais il n’est pas mis à jour régulièrement et j’ai déjà trouvé des lacunes de la recherche de cet outil qui datent de 2012 ! Je pense vraiment que l’index inversé est un plus nécessaire, ne serait-ce que pour vérifier les données. Otourly (discussion) 4 décembre 2019 à 05:01 (UTC)

Créer des centaines de catégories supplémentaires juste pour vérifier me semble bien lourd. Encore une fois, ce genre de chose devrait être fait par un tri automatique, par Mediawiki, pas par nous. — Dakdada 4 décembre 2019 à 14:18 (UTC)

C’est clair que si c’était possible via médiawiki ce serait pratique; malheureusement je crains qu’un tel développement risque de prendre des lustres. Otourly (discussion) 4 décembre 2019 à 20:19 (UTC)

Ce n’est pas difficile du tout, et le calcul ne sera pas lourd, mais on devrait attendre un consensus de la communauté. — TAKASUGI Shinji (d) 3 décembre 2019 à 23:20 (UTC)

Rajouter une énième fonctionnalité à un modèle non prévu à cet effet est toujours une lourdeur à mon sens (j'en suis moi-même coupable). Un problème à éclairer est : comment génère-t-on la clé de tri inversée en s'assurant que les diacritiques etc. sont bien traités ? — Dakdada 4 décembre 2019 à 14:18 (UTC)

En tout cas proposer un outil supplémentaire permettrait d’attirer davantage de lecteurs. Otourly (discussion) 19 décembre 2019 à 18:11 (UTC) Je suis d’accord avec Darkdadaah et Automatik, ça ne me semble pas vraiment utile. Je ne vois guère que ceux qui font des mots croisés et n’ont trouvé que la fin du mot, mais pour ça, ils ont déjà Anagrimes, qui est mieux adapté dans ce cas. Ce qui est utile dans le même genre, par contre, c’est le même genre de chose mais du point de vue phonétique, pour très facilement trouver les rimes les plus riches possibles pour un mot donné. Mais même ça, ça ne serait pas utile à grand monde… Lmaltier (discussion) 19 décembre 2019 à 18:51 (UTC)

Ce n’est pas la même chose qu’anagrimes puisque celui-ci est basé sur des requêtes. C’est plutôt d’obtenir un résultat semblable à des dictionnaires de rimes comme celui là mais beaucoup plus à jour. Et ça rien de tel n’existe. Si rechercher par ordre alphabétique nous semble évidant d’efficacité, je pense que ça serait bien de proposer une navigation par suffixes. Et ce, sans faire X requêtes Anagrimes. Et si on attends la WMF pour l’obtenir, je crois que dans trente ans on attendra encore. Otourly (discussion) 20 décembre 2019 à 05:35 (UTC)

Peu importe comment on s’y prend, il y a des requêtes, et ça a un coût. Qu’il y ait un coût quand ça répond à un besoin ponctuel, comme avec Anagrimes, pas de souci, et c’est une meilleure solution que de tout compliquer, ce qui est susceptible d’entraîner un coût permanent (TAKASUGI Shinji parle de calcul, je ne sais pas ce qu’il a en tête), pour tout le monde, pour quelque chose qui n’intéresserait presque personne. Maintenant, il faudrait que chacun explique ce qu’il a en tête plus précisément du point de vue fonctionnalité, et ce qu’il a en tête du point de vue solution technique, car ce n’est pas clair, et ça aiderait à se faire une idée. Lmaltier (discussion) 20 décembre 2019 à 06:14 (UTC)

Si on s’arrête à la moindre difficulté, on ne ferait jamais rien ! Inclure le code dans le module lua ne complexifierait en rien l’édition, si c’est ça qui te fait peur. Point de vue fonctionnalité c’est de créer une catégorisation triée de droite à gauche en plus de la catégorisation de gauche à droite. Si on veut obtenir une telle liste avec Anagrimes il faudrait des centaines de requêtes. La solution technique, je ne l’ai pas si ce n’est de s’inspirer de la version latine comme écrit plus haut. Tout me semble clair. Otourly (discussion) 20 décembre 2019 à 07:00 (UTC)

Clé de tri ignorée dans les catégories de lemmes

Je remarque que, depuis son introduction en 2017, la catégorie de lemmes ignore complètement la clé donnée au modèle, contrairement aux catégories de langue et de type de mot. Voir le tri de äänestää, dans Catégorie:Verbes en finnois et dans Catégorie:Lemmes en finnois : ce n'est pas le même !

C'est fort étonnant que ça n'ait jamais été remarqué... Je propose de remédier à cela à moins que quelqu'un ait une explication à cette différence. Automatik (discussion) 3 décembre 2023 à 00:28 (UTC)

Corrigé : la clé est désormais prise en compte par par le module lors de l’ajout de la catégorie de lemme. — Automatik (discussion) 14 janvier 2024 à 03:33 (UTC)