Bonjour, vous êtes venu ici pour chercher la signification du mot Wiktionnaire:Wikidémie/novembre 2022. Dans DICTIOUS, vous trouverez non seulement toutes les significations du dictionnaire pour le mot Wiktionnaire:Wikidémie/novembre 2022, mais vous apprendrez également son étymologie, ses caractéristiques et comment dire Wiktionnaire:Wikidémie/novembre 2022 au singulier et au pluriel. Tout ce que vous devez savoir sur le mot Wiktionnaire:Wikidémie/novembre 2022 est ici. La définition du mot Wiktionnaire:Wikidémie/novembre 2022 vous aidera à être plus précis et correct lorsque vous parlerez ou écrirez vos textes. Connaître la définition deWiktionnaire:Wikidémie/novembre 2022, ainsi que celles d'autres mots, enrichit votre vocabulaire et vous fournit des ressources linguistiques plus nombreuses et de meilleure qualité.
Actualités du Wiktionnaire, numéro 91, octobre 2022
Le dernier numéro des Actualités du Wiktionnaire vient de paraître !
À l’automne, les brèves se ramassent comme des feuilles mortes, par dizaines ! Elles cacheraient presque les statistiques et les illustrations faites de graphies anciennes. Les articles portent sur un atelier de lexicographie, une différence entre les versions françaises et anglaises des Wiktionnaire et l’œuvre dictionnairique de Pierre Perret. Le numéro se termine avec les thèmes de la semaine du mois écoulé et une belle liste de suggestions de vidéos et podcasts !
Contributions et consommation d’énergie : quelques conseils
Quelques conseils pour limiter votre consommation d’énergie lorsque vous contribuez :
Évitez les ordinateurs fonctionnant au gaz, préférez les ordinateurs fonctionnant à l’électricité, le gaz est inabordable
Choisissez l’appareil avec l’écran le plus petit possible, il consommera beaucoup moins ; à l’ordinateur de bureau, préférez l’ordinateur portable, ou, si possible, la tablette, ou, mieux, le téléphone portable, ou, pour les plus malins, la montre connectée (dans ce dernier cas se doter d’une loupe de qualité)
Contribuez de préférence sur votre lieu de travail ; pendant les heures creuses si vous appréciez votre patron, pendant les heures pleines si vous voulez plomber les comptes financiers de l’entreprise (vous détestez votre patron !)
Pour contribuer sur une page utilisez le style télégraphique qui diminuera votre temps de présence sur le réseau électrique, et ajoutez {{formater}}, un contributeur bienveillant ayant un accès écolo privilégié au courant électrique (panneaux solaires, éolienne de balcon, branchement sauvage sur la ligne du voisin, etc) se chargera de mettre de l’ordre dans votre prose…
À l’attention des administrateurs, bloquez sans ménagement les utilisateurs qui contribuent pendant les heures de pointe matin et soir, ils exagèrent tout de même !
Pour faire des économies d'énergie, limiter la bande passante utilisée et faciliter la compression des contenus pour ne pas trop bouffer d'espace disque, ainsi que faciliter l'accès aux personnes qui ont abandonné les forfaits illimités, faut passer toutes les illustrations en ASCII art . Jpgibert (discussion) 2 novembre 2022 à 13:17 (UTC)
Si besoin, vous pouvez également faire de la contribution hors-ligne. Rédigez vos modifications et envoyez les par la poste à la Wikimédia Fondation, qui s’occupe par la suite de les intégrer aux pages. Lepticed7 (À l’immortalité !) 3 novembre 2022 à 08:26 (UTC)
Salut. En me promenant sur le projet hier, j’ai (re)fait le constat du mésusage concernant les modèles {{spécifiquement}}, {{spécialement}}, {{génériquement}} et {{généralement}}, et tout particulièrement le deuxième, qui est utilisé 1000 fois, contre une centaine pour les trois autres. Petit jeu : sans regarder la documentation, savez-vous expliquer la différence entre {{spécifiquement}} et {{spécialement}}, ou à défaut, pouvez-vous essayer de deviner cette différence ? Personnellement, j’en suis incapable, il faut toujours que j’aille me référer à la documentation.
Du coup, la réponse est la suivante : {{spécifiquement}} permet de lier deux définitions qui ont un lien d’hyponymie, c’est-à-dire que l’une des définitions est un sous-ensemble de l’autre : ainsi, quand on parle du rideau au théâtre, il s’agit d’un cas spécifique de rideau, d’un sous-type de rideau.
Et pour {{spécialement}} ? C’est quand il y a une relation de méronymie, c’est-à-dire de tout à partie. Ainsi, dans "Les voiles s’éloignaient au loin", on désigne par une partie le tout, ici on désigne par "les voiles" le bateau. Remarque : dans ce sens là (de la partie vers le tout), c’est {{généralement}} qu’il faut utiliser. J’arrive pas à trouver de cas où {{spécialement}} est pertinent, d’autant que la plupart des usages actuels sur le projet sont un mésusage.
Je trouve cela très peu clair. Ma proposition est donc la suivante : renommer les modèles respectivement en "par hyponymie", "par méronymie", "par hyperonymie" et "par holonymie". C’est d’ailleurs la question que pose Noé dans le projet sur les infos lexicographiques.
Par ailleurs, à celleux qui vont avancer que c’est rendre le Wiktionnaire plus technique, avec des mots plus compliqués, je réponds que c’est faux. Ici, la signification de ces modèles n’est pas connue (en attestent le nombre d’erreurs d’utilisation). Ce qui est connu du lectorat, c’est la suite de lettres, mais pas le sens qu’a cette suite de lettres dans le domaine de la lexicographie. On pourrait se dire qu’on peut déjà intuiter que c’est un sens plus restreint pour {{spécifiquement}} et {{spécialement}}. Autant, pour {{spécifiquement}}, le rideau de théâtre est bien un cas spécifique de rideau, autant j’ai du mal à comprendre en quoi les voiles sont un cas spécial de bateau. Il y a des réflexions identiques pour {{généralement}} qui pourrait plutôt faire penser à une note concernant la définition la plus couramment utilisée. Enfin, j’aimerai rappeler à toustes que nous avons déjà des sections avec ces noms là. Lepticed7 (À l’immortalité !) 13 novembre 2022 à 11:30 (UTC)
PS : je viens de trouver un exemple de méronymie. Quand on dit « ma maison est blanche » quand c’est en fait une partie de la maison (ici la façade) qui est blanche.
Je me reconnais parmi ceux qui mettent « spécialement » ou « spécifiquement » sans trop savoir / comprendre quel est la différence entre les deux : j’apprends d’ailleurs qu’ils ne sont pas synonymes.
J’approuve donc l’idée de les renommer pour rendre clairement visible leur différence. Entre « spécialement » / « spécifiquement » et « par métonymie » / « par hyponymie », le deuxième cas me forcera à être bien plus attentif au choix entre les deux !
Enfin, je ne crois pas non plus à l’argument de la complexification du Wiktionnaire : d’abord pour le contributorat, une bonne définition avec des exemples d’utilisation lèvera toute ambigüité ; pour le lectorat, un lien vers l’entrée sur le Wiktionnaire ou le glossaire grammatical, à l’instar de {{par hyperbole}}, fera amplement l’affaire. Poslovitch (discussion) 13 novembre 2022 à 12:26 (UTC)
Je suis d’accord avec la proposition de renommage (après avoir lu l’ensemble de la conversation à cette date, je réponds également plus bas) Noé22 novembre 2022 à 21:29 (UTC)
Oui, c’est très peu clair. Et je ne pense pas que ces nuances aient été voulues, au départ : il s’agit probablement d’interprétations après coup. Ce qui explique la remarque J’arrive pas à trouver de cas où {{spécialement}} est pertinent. Personnellement, je me contenterais de supprimer le modèle spécifiquement et de donner au modèle spécialement le sens actuellement documenté pour spécifiquement. Ce serait beaucoup plus clair. Vouloir utiliser des mots que les lecteurs ne connaissent pas, ça ne leur est bien sûr pas vraiment utile, et ça donne une mauvaise image du projet (genre t’as vu comme ils s’la pètent…), et ce n’est pas la présence de liens qui aidera : on sait bien que les lecteurs veulent en général trouver tout de suite ce qu'ils cherchent, il ne veulent pas se compliquer la vie. Il faut traiter ces mots (connus seulement des linguistes) dans leurs pages, bien sûr, mais c’est tout. Rester simple, c’est fondamental, et c’est vrai aussi pour le vocabulaire utilisé dans nos pages. Lmaltier (discussion) 14 novembre 2022 à 18:52 (UTC)
C’est classique dans les dictionnaires : utilisation d’un mot dans un sens plus restreint.
Par ailleurs, voici quelques éléments supplémentaires, après réflexion. Nous trouvons dans le Wiktionnaire des mésusages des quatre mots proposés, en particulier avec des noms propres géographiques. Par exemple, dans Alsace, il y a une section Méronymes qui contient des noms de villes d’Alsace. Le créateur du mot méronyme serait très surpris de voir ça, car le mot est lié à des relations de sens entre mots, et n’est jamais utilisé dans ce genre de cas. En réalité, il s’agit seulement d’un prétexte pour donner des renseignements encyclopédiques, et non linguistiques. Comment ce mésusage a-t-il été possible ? Parce qu’on s’est basé sur une définition (toujours imparfaite), et non sur l’usage effectif du mot.
Dans le cas présent aussi, il s’agirait d’un mésusage des quatre mots. En effet, ces mots sont toujours utilisés pour décrire des relations de sens entre mots différents, jamais pour décrire des modes de formation de nouveaux sens d’un mot, alors que c’est ça que nous voulons. Alors y a-t-il un mot décrivant la formation d’un nouveau sens par utilisation du mot désignant le tout pour désigner une partie, ou d’un mot désignant une partie pour désigner le tout, ou d’un mot désignant un contenant pour désigner le contenu, ou d’un mot désignant un professionnel pour désigner son local d’activité, etc. (les cas sont innombrables). On a de la chance, la réponse est oui, c’est le mot métonymie (recherche Google : 776000 résultats, contre méronymie : 6470, holonymie : 3370, hyponymie : 24600, hyperonymie : 19000). Ce mot est certes très technique, mais tout de même entre 31 et 230 fois plus utilisé que les mots proposés, et, surtout, c’est le terme consacré, y compris pour beaucoup de cas où on chercherait en vain un autre -nymie. La métonymie est un des modes de formation de nouveaux sens les plus féconds, mais il y en a d’autres, comme la métaphore, l’euphémisme, etc. Notez que le modèle métonymie existe déjà à cet effet. Lmaltier (discussion) 15 novembre 2022 à 06:54 (UTC)
@Lmaltier : en effet, la métonymie est une relation d’association par le sens qui est floue, tandis que la méronymie et l’holonymie sont plus précises, de même que l’hyponymie et l’hyperonymie, qui sont aussi impliquées par la métonymie. C’est une étiquette qui ne spécifie pas et englobe quatre relations différentes. Pourquoi ne pas faire cohabiter les deux informations, selon les entrées ? Permettre une description floue et une description plus précise lorsqu’elle peut être établie ? Tu l’as dit, le terme "méronymie" est pas plus commun ni vulgarisé que les autres. C’est un peu comme l’indication régionalisme qui ne veut rien dire et pourra être affinée par des indications de régions plus précises avec l’évolution qualitative de la documentation.
De manière similaire aux lexiques, nous pourrions ajouter des bulles explicatives au survol pour ces étiquettes de relations entre définition, qui permettraient au lectorat de mieux capter les informations présentées. Le mot peut également être un lien vers une page d’explication.
Quant au fait que c’est utilisé uniquement pour des relations entre des mots différents et non entre des sens différents d’un même mot, c’est faux. Les sens différents sont reliés entre eux par des relations de natures similaires aux relations entre les mots car on considère que chaque association sens-forme est un terme différent. Ce ne sont pas uniquement des indications étymologiques mais des relations qui peuvent être encore dynamiques dans la langue. Il y a d’autres manières de lier des sens entre eux, c’est d’ailleurs listé dans un tableau qui est dans la doc de chaque modèle, ça tombe bien Noé22 novembre 2022 à 21:29 (UTC)
C’est faux ? Tu explique que ça pourrait être utilisé pour ça, je dis que ce n’est pas utilisé pour ça en pratique. Et j’ai donné des statistiques qui montrent que le mot métonymie, en plus d’être le terme correct, est tout de même beaucoup plus courant que les autres, bien que technique. Il y a un nombre énorme de relations possibles entre sens, il n’existe pas un mot pour chaque, alors autant utiliser les mots effectivement utilisés de façon habbituelle. Lmaltier (discussion) 22 novembre 2022 à 21:35 (UTC)
Oui c’est faux, je te l’avais déjà expliqué en décembre 2020, sources à l’appui, et tu n’avais pas compris mes explications, je t’y renvois. C’est utilisé en pratique couramment puisque ces relations sont définies entre des unités lexicales, et non entre des mots. Il n’y a pas un nombre énorme de relations possibles, il y en a une douzaine et nous les décrivons déjà. Il existe des mots qui caractérisent ces relations, et si tu ne veux pas les utiliser, et bien ne les utilise pas. Il me semble que tu n’utiliseras pas moins les modèles avec les noms proposés par Lepticed que tu ne les utilises actuellement avec leurs noms ambigus et incompréhensibles, alors bon… est-ce bien utile de poursuivre cette discussion ? Noé23 novembre 2022 à 01:07 (UTC)
@Noé : J’avais oublié cette discussion, elle avait effectivement déjà eu lieu. Et tu y faisais apparemment référence à des définitions, comme je l’explique ci-dessus, tu ne donnais pas d’exemples d’emplois effectifs de ces mots pour des relations entre différents sens d’un même mot. Je reste convaincu qu’on utiliserait ces mots de façon inédite. Et qu'il serait difficile de demander d’utiliser (par métonymie), sauf dans certains cas de métonymie. Lmaltier (discussion) 23 novembre 2022 à 16:18 (UTC)
Personnellement, dans ces situations, je mets tout simplement {{en particulier}} pour faire la distinction avec le sens général (ou le sens le plus courant, ou le sens générique, etc). Que l’on peut associer d’ailleurs avec bonheur à la mention du domaine d’emploi (mathématiques), (médecine), (poésie) etc.--Rapaloux (discussion) 15 novembre 2022 à 08:24 (UTC)
Merci de rappeler l’existence de cet autre indication floue. En effet, en particulier sert pour la moitié des cas de relations couverts par la relation par métonymie, c’est-à-dire pour par hyponymie ou par méronymieNoé22 novembre 2022 à 21:29 (UTC)
Historique incomplet
Micheletb (d · c · b) a considérablement amélioré la médiocre ébauche que j’avais impudemment commise – merci à lui (ou elle !) –, « بومتلوا », en la voyellant et redirigeant vers la forme complète « بُومَتْلُوَا » en en modifiant ce qu’il était nécessaire de faire. (À ce propos, je me demande si l’étymologie de « Boumetloua » ne devrait pas être revue !…) Le problème n’est pôs là, mais dans l’historique de « بومتلوا », icitte, où l’article paraît surgi ex nihilo !. Me fé-jeu bien comprendre ?…
Le nom de la page fait partie des éléments d'information, donc tu as créé « la page » et j'ai changé son nom en بُومَتْلُوَا(bûmatluwâ) (comme l'indique corretement la troisième ligne de l'historique). De même, l'historique de بومتلوا(bwmtlwA) indique que j'ai d'abord créé une (nouvelle) page de redirection en renommant la page initiale vers بُومَتْلُوَا(bûmatluwâ), puis que j'ai donné à cette nouvelle page un nouveau contenu.
C'est pour préserver l'historique que le renommage fonctionne comme ça. Quand une page a été lourdement éditée, et est renommée, il faut que tous les intervenants sous l'ancien nom puissent être crédités sous le nouveau. Dans ce cas précis ça paraît artificiel, mais c'est bien comme ça que ça doit marcher.
Il faut lire l'historique correctement : la page qui porte à présent le titre بُومَتْلُوَا(bûmatluwâ) a été créée « 2 octobre 2022 à 13:03 Budelberger » (première ligne). On voit ensuite en troisième ligne que « Micheletb a déplacé la page بومتلوا vers بُومَتْلُوَا : référence avec diacritiques » - C'est donc que le titre actuel n'est pas le titre de création. L'historique montre bien que Budelberger a créé une page sous le titre بومتلوا et que cette page a à présent pour titre بُومَتْلُوَا . Ce qui fait l'identité d'une page c'est son historique, pas son titre. Micheletb (discussion) 17 novembre 2022 à 09:54 (UTC)
Dans l'historique du mot test, quand je clique sur les diffs de l'IP 81.248.202.65, mon antivirus indique « Menace de type Cheval de Troie détectée », j'ai donc révoqué. Y-a-t-il quelque chose de particulier à faire dans ce cas, sinon le signaler ? Merci. --Jamain (discussion) 19 novembre 2022 à 06:23 (UTC)
Il faut avant tout élucider la raison de ce message. Pour moi, il n’y a pas de risque de ce genre. Si le risque est malgré tout avéré, c’est qu’il y a un souci très sérieux dans le logiciel, à corriger d’urgence. Lmaltier (discussion) 19 novembre 2022 à 08:48 (UTC)
Je précise ma pensée : quand on clique sur un diff, il ne peut normalement pas y avoir de risque de sécurité, car c’est purement textuel : les textes sont comparés, et la différence est affichée, c’est tout. Par ailleurs, les IP ne peuvent pas mettre de liens externes car il y a un filtre les empêchant de le faire, c’est du moins ce que je pensais… Mais l’IP a apparemment trouvé un moyen de contourner cette restriction, en incluant un lien externe à risque. Effectivement, il fallait révoquer, et il faut voir comment se protéger mieux. Lmaltier (discussion) 19 novembre 2022 à 09:31 (UTC)
Ce que je peux dire, c’est que par la suite, au redémarrage de l’ordinateur, j’ai eu un problème, j’ai dû m’y reprendre à deux fois, la première, ça ramait à n’en plus finir, et la deuxième, un message m’annonçait qu’il y avait une fonction (je ne sais plus trop quoi) de sécurité qui était désactivée sur Windows et me demandait de la réactivée, ce que j’ai fait, puis tout est reparti normalement. Cela avait-il un lien avec ce cheval de Troie !? --Jamain (discussion) 19 novembre 2022 à 09:41 (UTC)
Il faut que je rectifie, ce n’est pas quand j’ai cliqué sur le diff que j’ai eu ce message, mais quand j’ai cliqué ensuite sur Prévisualiser qu’il est apparu, parce que j’ai vu ce diff, c’était un lien vers Wikipédia je crois, j’ai donc révoqué et n’ai rien fait de plus. Pardon pour cette confusion. --Jamain (discussion) 19 novembre 2022 à 11:36 (UTC)
Prévisualiser ? C’est seulement quand on modifie qu'on a cette possibilité. Je peux comprendre le message en cas de clic sur un lien dangereux, mais je suis surpris qu’un antivirus détecte la présence d’un lien dangereux dans une page qu’on visualise (mais ce n’est pas impossible s’il est conçu pour ça). Lmaltier (discussion) 19 novembre 2022 à 12:50 (UTC)
En théorie, il suffirait d'interdire les tentatives d'exploitation de faille XSS via les balises HTML "iframe" et "script". Par contre, "script" est interprétée dans le namespace MediaWiki et Utilisateur, donc je mettrai des exceptions. JackPotte ($♠) 21 novembre 2022 à 06:52 (UTC)
Bonjour, j'ai codé un bot qui identifie automatiquement les anagrammes et ajoutent celles qui manquent dans les entrées concernées. Pour le moment, le bot ne s'intéresse qu'au français. J'ai fait tourner le bot sur quelques dizaines de pages et grâce au travail de Snawei, j'ai pu corriger divers bogues (le code est disponible ici). Le bot est donc à présent prêt pour intervenir sur toutes les entrées en français concernées. J'ai dénombré un peu moins de 680 000 entrées en français qui auraient besoin d'une section « anagrammes » (chiffres extraits du dump du 20 novembre). Ce chiffre est à comparer avec les 60 000 entrées qui possèdent déjà une section « anagrammes ».
Le bot s'appuie sur le module Module:anagrammes dont vous pouvez voir un exemple de rendu sur cet exemple. Les anagrammes sont stockées dans un endroit uniquement qui est de la forme « Modèle:anagrammes/code/alphagramme » (cette page pour l'exemple précédent), où « code » correspond au code de langue et « alphagramme » correspond à la suite de lettre qui compose le mot classée par ordre alphabétique (→ voir alphagramme).
Parmi les avantages à utiliser ce module, on peut citer (liste non exhaustive, n'hésitez pas à ajouter des choses) :
avoir une liste à jour sur toutes les entrées possédant le même alphagramme
ajouter une nouvelle anagramme se fait en une seule modification qui sera visible sur toutes les entrées partageant le même alphagramme
voir une présentation uniforme entre toutes les entrées du Wiktionnaire pour la présentation des anagrammes
les anagrammes sont triées suivant un ordre cohérent à toutes les entrées
Parmi les inconvénients, je pense que le principal est que le rendu affiché sur la page « ne correspond pas » au wikicode que l'on voit lorsqu'on modifie la page. Pour limiter (annuler ?) cet inconvénient, un message qui apparait au-dessus de la liste des anagrammes propose au contributorat de cliquer pour modifier directement la liste des anagrammes. Probablement que le système est perfectible mais je pense qu'il répond déjà en parti à le problématique. On peut éventuellement citer d'autres inconvénients de la mise en place de ce système à base de Module:anagrammes que je vous laisse ajouter.
Il faut remettre la question dans son contexte. L’idée de base est d’éviter que, quand on veut rajouter une anagramme, on ait à modifier manuellement n pages (dans certains cas, ça peut être pénible). Le problème est le même pour les modèles voir de début de page. Il y a deux approches possibles pour résoudre cela :
regrouper les anagrammes dans une même page (page supplémentaire à créer) et utiliser cette page pour afficher la listes des anagrammes dans chaque page (solution applicable aussi pour les modèles voir de début de page)
réaliser un robot pour que le travail soit automatique, par ajout automatique des anagrammes.
Ce sont deux solutions différentes à un même problème, et il n’y a pas à les mélanger. S’il y a un robot, il n’y a aucune raison de créer des pages spéciales pour les anagrammes. Il est vrai que, d’un côté, créer des pages spéciales réduit le nombre de modifications quand on veut rajouter une anagramme à une liste existante, mais, d’un autre côté, ça exige de faire des créations de pages supplémentaires pour mettre en place le système, et rien de permet de prévoir ce qui est le plus efficace.
Je comprends que la volonté de créer un robot est postérieure à la création de modèles spéciaux anagrammes, ainsi qu’à la création d’un module, mais il ne faut pas que ça perturbe le raisonnement. La solution de très loin la plus simple et la plus compréhensible pour tout le monde est que le robot mettre à jour les listes d’anagrammes sous forme de listes de liens simples et clairs. Et c’est vrai aussi pour les modèles voir de haut de page.
C’est important entre autres pour les candidats contributeurs, pour qu’ils n’aient pas la sensation d’un site incompréhensible, mais aussi pour les contributeurs actuels qui aiment comprendre les choses, et qui aiment la simplicité. Compliquer, puis compliquer encore plus pour essayer de résoudre les problèmes provoqués par la première complexification, ce n’est pas une bonne démarche.
J’appuie donc sans réserve la mise en place du robot, mais pas via plein de modèles et via un module. Le créateur de robot peut très bien s’en passer (éventuellement en s’aidant d’un fichier personnel sur son ordinateur). Lmaltier (discussion) 21 novembre 2022 à 17:49 (UTC)
Un petit détail : il n’y a en général pas à créer un tableau pour afficher les anagrammes. Une anagramme par ligne, c’est plus lisible. Un tableau n’est justifié que quand il y a beaucoup d’anagrammes, et un tableau avec les modèles "(" et ")" (sans paramètre) est idéal pour ça : cela permet un positionnement en colonnes automatique et cohérent avec le navigateur. Lmaltier (discussion)
Merci pour la remise en contexte. Il y a en effet 2 sujets : la solution technique utilisée et l’utilisation ou non d’un bot pour l’appliquer. Sachant que la tâche est facilement automatisable et que l’ajout manuel d’anagrammes ne présente aucune plus-value, je pense que l’utilisation d’un bot fait consensus.
Donc, concernant la solution technique, vous l’aurez compris, la solution à base du Module:anagrammes a ma préférence car elle présente également l’intérêt suivant. Prenons l’exemple dans lequel le bot crée toutes les pages de modèles nécessaires et modifie les sections « anagrammes »des entrées qui en ont besoin. Et après j’arrête ; le bot ne tourne plus jamais. Alors on se retrouve dans la situation actuelle (en moins pire), à savoir que les listes d’anagrammes vont de nouveau rediverger car les anagrammes seront ajouter sur une page et pas l’autre. Bref, pour que le système à base actuel fonctionne, il faut que le bot tourne régulièrement. Le jour où il ne tourne plus, les listes divergent à long terme. La solution à base du Module:anagrammes offre une solution sur le long terme. Pamputt21 novembre 2022 à 18:19 (UTC)
À propos de l’utilisation de {{(}} et {{)}}, je suis d’accord. J’en profite pour rebondir sur le fait que l’utilisation d’un modèle/module permet justement d’avoir une présentation uniforme sur l’ensemble des entrées du Wiktionnaire. Si on veut un tableau, il suffit d’adapter le code du module, idem si on veut une simple liste. Pamputt21 novembre 2022 à 18:25 (UTC)
Je n’avais pas compris que l’idée était de faire tourner le bot une seule fois, ce n’était pas du tout mon idée. Bien entendu, quelle que soit la solution, il faut que le bot tourne régulièrement, sinon il manquera toujours des anagrammes, c’est pareil que pour les autres bots. Le bot sera de toute façon un peu compliqué, mais au moins, s’il génère directement des liens dans les pages, il ne perturbe pas la compréhension, il ne fait pas apparaître le projet comme incompréhensible aux candidats contributeurs (ce point est fondamental pour la survie du projet à long terme, il ne faut pas penser à ses préférences personnelles, il faut penser à long terme, car on n’est pas éternel). Et, si le code est public, il peut être repris sans problème par un autre utilisateur de bot. L’utilisation additionnelle d’un module et sa maintenance rend les choses beaucoup plus compliquées, car ça exige des compétences supplémentaires. Pour ce qui est de la présentation du tableau, le fait d’utiliser un bot générant une simple liste de liens rend tout aussi bien la présentation uniforme qu’un module, il permet de gérer le critère "tableau ou non" en fonction du nombre d’anagrammes. Lmaltier (discussion) 22 novembre 2022 à 07:49 (UTC)
Salut. En fait, je crois que la compréhension du bot que vous avez est différente. Pamputt suggère d’utiliser un bot pour déployer le modèle, là où Lmaltier suggère d’utiliser un bot pour maintenir et synchroniser les listes sur les différentes pages. Ayant développé les modèles et le module, je suis favorable à leur utilisation. Je comprends que la solution proposée par Lmaltier, comme la plupart de — voire toutes — ses propositions, vise à avoir un code le plus clair et compréhensible possible pour tout le monde, et surtout les débutant·es et candidat·es. Toutefois, je pense qu’elle pose plusieurs problèmes. D’abord, les informations sont dupliquées, ensuite, la logique de rangement des anagrammes doit être connue de la personne qui ajoute un anagramme (notamment le fait que les mots qui sont identiques à la casse ou aux diacritiques près sont sur la même ligne), enfin, il n’y a aucune vérification sur la validité des données : si un mot est mis dans la mauvaise liste à cause d’une erreur d’alphagramme, c’est indétectable. Il faudrait, pour toutes ses tâches, un bot qui tourne régulièrement et qui vérifie les 680'000 entrées du français dénombrée par Pamputt. Pour ces raisons, je pense que la solution avec modèles et module est meilleure. En ce qui concerne la modification rapide, j’ai rajouté un lien qui permet de modifier en un clic la liste. À+, Lepticed7 (À l’immortalité !) 22 novembre 2022 à 15:28 (UTC)
Il y a malentendu : déjà, plus personne (ou à peu près) ne mettrait des anagrammes, puisque ce serait automatique (alors que la solution provisoire actuellement testée incite à en mettre, ce qui n’est pas judicieux). Ensuite, bien sûr que si, si quelqu’un en met et se trompe, cette erreur est détectable : il suffit que le robot la détecte et la corrige. Oui, tout ça exige un passage régulier du robot, à intervalle régulier (il n’y a pas besoin que ce soit trop fréquent). Lmaltier (discussion) 22 novembre 2022 à 17:06 (UTC)
La solution à base du module et des modèles présente l'avantage d'être résilient face à l'absence de passage du robot. Et je pense que c'est très important car aucun robot n'est immuable. Alors certes le code est libre et pourra donc être repris par quelqu'un d'autre si je ne m'en occupe plus mais ce n'est absolument pas garanti. Et dans ce cas de figure, on se retrouve avec les inconvénients que j'ai énoncé plus haut ainsi que ceux ajouté par Lepticed7. Pamputt22 novembre 2022 à 17:12 (UTC)
Un indice que le robot pourrait s'arrêter du jour au lendemain et ne pas être repris et que le sujet des anagrammes ne semble pas motiver les foules. Preuve en est que personne depuis les 18 d'existence du projet, personne n'a pris le temps de coder ou n’a montré d’intérêt pour un tel robot. Pamputt22 novembre 2022 à 17:16 (UTC)
Il y a très longtemps que j’ai ça en tête, c’est pour l’écrire que ça me posait problème. Et je crois que tout le monde serait ravi que ce soit automatisé. Par ailleurs, l’arrêter n’empêcherait pas, de toute façon, de revenir à une mise à jour manuelle. Alors que, si personne ne s’occupe de mettre à jour le module, par exemple, en cas de changements techniques qui nécessiteraient une adaptation du programme, on n’aurait plus aucune anagrammes dans les pages. En ce sens, la solution sans module est nettement plus résiliente. Lmaltier (discussion) 22 novembre 2022 à 18:46 (UTC)
Bonjour. J’ai rattrapé la lecture de la discussion. Je pense au contraire que la solution avec un module est plus résiliente car l’environnement nécessaire pour faire tourner un bot est également sujette à des changements techniques. Je trouve bien plus complexe le fonctionnement d’un bot qui passe constamment sur les pages par rapport à un fonctionnement avec un module. Et puis, le code du module et du modèle sont ouverts et dans le Wiktionnaire, contrairement au code d’un bot qui serait forcément sur une forge extérieure au Wiktionnaire, elle-même susceptible d’évoluer funestement. La proposition de Pamputt, améliorée par Snawei et Lepticed, me convainc pleinement et j’abonde dans le sens d’un déploiement prochain Noé22 novembre 2022 à 20:47 (UTC)
?? Le bot n’a pas à passer constamment sur les pages, il suffirait de le faire à intervalles réguliers… Oui, l’environnement des bots est aussi sujet à des changements techniques, mais si on a deux environnements différents (bot + module), les risques sont doublés. Ce n’est pas en doublant les risques qu’on les élimine. Et l’arrêt éventuel d’un simple bot n’aurait pas d’effet sur l’affichage ni sur la contribution, qui pourrait continuer normalement si le bot s’arrêtait, c’est en ce sens qu’elle est plus résiliente. Lmaltier (discussion) 22 novembre 2022 à 21:13 (UTC)
Je ne comprends rien à ton argumentaire, je ne sais pas s’il s’applique à la technique concrète et prête à être déployée par Pamputt ou à ta proposition d’une autre technique qui resterait à imaginer et à coder. Pour moi, Pamputt s’est investi sur un aspect délaissé du projet, et je trouve ça très bien. J’ai hâte de voir cette solution déployée Noé23 novembre 2022 à 01:00 (UTC)
Si je comprends bien, Lmaltier décrit un scénario catastrophe dans lequel les modules Lua ne sont plus supportés. Si c’est le cas, beaucoup de choses du Wiktionnaire (ne parlons même pas de Wikipédia) ne fonctionneront plus : les sections, les prononciations, les lexiques, les traductions, les attestations. Ça me semble improbable que du jour au lendemain les modules viennent à disparaitre. Si jamais la technologie devait évoluer, comme ça a déjà été le cas, on est prévenu, et on a le temps de s’adapter. Par ailleurs, Pamputt propose de passer une seule fois pour mettre en place le système. Donc il n’y a pas deux environnements différents qui peuvent chuter à long terme. Une fois le modèle répandu partout, c’est fini : un peu comme à chaque fois qu’on met en place un nouveau système : les sections, les lexiques, etc. Lepticed7 (À l’immortalité !) 23 novembre 2022 à 06:55 (UTC)
Non, je parle d’évolutions potentielles du langage Lua qui obligeraient à des évolutions du module, comme ça arrive avec Python, et qui exigeraient donc des compétences particulières. Et mes conditionnels s’appliquaient au type de robot que je propose. Je ne dis pas que Pamputt n’a pas travaillé, juste qu’il y a des inconvénients sérieux mais qu’il est possible d’éliminer (et je suis sûr qu’il comprend bien ma position). Lmaltier (discussion) 23 novembre 2022 à 16:08 (UTC)
En fait, j'ai bien réfléchi et dans le cas extrêmement hypothétique où personne ne saurait maintenir le module Lua et où personne ne voudrait reprendre le bot pour ajouter des anagrammes, alors l'utilisation du module me parait la moins mauvaise et voici pourquoi.
étape 1 : le bot passe sur toutes les pages et ajoute simplement le modèle {{voir anagrammes}} dans la section anagrammes (en remplaçant le contenu actuel). Toutes les anagrammes sont stockées à un seul endroit, dans une page de la forme « Modèle:anagrammes/fr/alphagramme ».
étape 2 : le code du module Lua n'est plus fonctionnel. Le modèle {{voir anagrammes}} ne fonctionne plus.
Alors dans ce cas de figure, il me parait énormément plus simple de redévelopper un bot qui analyserait toutes les pages de la forme « Modèle:anagrammes/fr/alphagramme » pour en extraire le contenu et le recopier sur chacune des pages impliquées (et ainsi revenir à la situation actuelle et ses inconvénients).
@Pamputt : Tu parles d’une étape 1. Mais, je le répète, il faut forcément un robot qui passe régulièrement si on veut en permanence avoir des listes d’anagrammes à peu près complètes. En effet, on rajoute des mots tous les jours, ce qui peut toujours conduire à de nouvelles anagrammes. Aucune solution qui ne respecte pas cette condition n’est satisfaisante. Par ailleurs, mes arguments portaient sur les compétences disponibles, pour les robots et pour le Lua, à un moment donné (ça peut être dans 10 ans, dans 50 ans, dans 100 ans, dans 200 ans, etc.). Si un bot qui marche existe, il pourra être repris (et éventuellement adapté aux évolutions techniques de l’infrastructure) tant qu’il y a des gens compétents au sujet des robots. S’il n’y en a plus, ne serait-ce que pour lancer le robot (sans même parler de développement), il y en aura encore moins pour développer un nouveau robot qui rattraperait le coup. Et, au sujet des inconvénients, il ne faut pas que tu oublies l’inconvénient fondamental : ça rend les choses difficilement compréhensibles, et ça peut donc dissuader beaucoup de se lancer dans la contribution. Lmaltier (discussion) 24 novembre 2022 à 08:18 (UTC)
L'étape 1 reste valide dès que le bot s'arrête de tourner (qu'il n'ait été lancé qu'une seule fois ou qu'il ait tourné pendant 10 ans). Dès que le bot s'arrête de mettre à jour automatiquement les entrées, alors la solution à base du module anagramme est meilleure (voir les arguments ci-dessus : un seul endroit où ajouter les nouvelles anagrammes, etc.). Donc quand tu écris qu'« aucune solution qui ne respecte pas cette condition n’est satisfaisante », c'est moins pire avec le module anagrammes étant donné que les listes d'anagrammes ne divergeront plus entre les entrées. Alors certes, ce n'est pas parfait mais c'est mieux que la situation actuelle.
il ne faut pas que tu oublies l’inconvénient fondamental : ça rend les choses difficilement compréhensibles, et ça peut donc dissuader beaucoup de se lancer dans la contribution.
La discussion devrait se concentrer principalement sur ce point. C'est l'objet du premier message : évaluer les avantages et les inconvénients. Et en ce qui me concerne les avantages du module anagrammes l'emportent sur les inconvénients et l'objet de cette discussion est de voir si d'autres personnes partagent mon avis. Je renvoie au message initial. Si on consulte l'entrée remilitai, ça me semble extrêmement simple de rajouter une nouvelle anagramme, du moins pas plus compliqué que la situation actuelle. Pamputt24 novembre 2022 à 08:48 (UTC)
On ne se comprend pas bien. Que certaines listes d’anagrammes puissent actuellement être incomplètes, ce n’est pas un problème en soi : tout, dans le projet est incomplet, et tout se complète progressivement. Le but principal du projet n’est quand même pas que ces listes soient cohérentes, comme on pourrait en avoir l’impression en te lisant… (si c’était ça le but principal, alors je serais d’accord que des pages d’anagrammes pourraient aider). Tu dis qu’il n’est pas difficile de rajouter une nouvelle anagramme avec ton modèle. C’est vrai, quand on contribue de façon purement interactive, mais la question n’est pas là : si les anagrammes sont remplies automatiquement, la question ne se pose même pas. Mais le point fondamental est que le projet a besoin de contributeurs, et que tout ce qui peut être nuisible au recrutement de contributeurs est à éviter. Je ne sais plus si tu étais là à l’époque, mais on a eu il y a longtemps des contributeurs Wikipédia qui ont essayé de commencer à contribuer ici et qui ont expliqué que c’était trop compliqué (et ça n’a fait que se compliquer depuis…). C’est rare qu’on ait ce genre de commentaire : en général, quand on sent qu’un projet n’est pas fait pour soi, on se contente de repartir sans rien dire. Lmaltier (discussion) 24 novembre 2022 à 09:46 (UTC)
Effectivement, on ne se comprends pas bien. Le but de la présente discussion est de peser le pour et le contre dans l'ajout massif d'anagrammes par robot en s'appuyant sur le module et les modèles d'anagrammes. Si on se concentre uniquement sur cette question alors, le passage du bot permet de s'assurer que les listes d'anagrammes sont cohérentes, ce qui va dans le bon sens (même si ce n'est pas le but principal du projet Wiktionnaire, je te l'accorde). Mais de toute façon, la présence ou non d'anagrammes n'est pas non plus le but principal du projet. J'ai l'impression que la discussion dérive un peu trop loin. Pamputt24 novembre 2022 à 10:04 (UTC)
Peser le pour et le contre, oui. Et dans le contre, il y a l’impératif fondamental du projet d’avoir des contributeurs, et donc de nouveaux contributeurs. Lmaltier (discussion) 24 novembre 2022 à 10:44 (UTC)
Il y a littéralement un lien qui s’affiche au dessus chaque liste d’anagrammes qui dit "Modifier la liste d’anagrammes". De plus, j’aimerai bien avoir de vrais chiffres sur la rétention des nouveaux et nouvelles. J’ai laissé un message à Trizek (WMF) (d · c · b), qui travaille sur le projet Croissance pour la Fondation. Peut-être pourra-t-il nous en dire plus sur ce qui bloque réellement les arrivant·es. Lepticed7 (À l’immortalité !) 24 novembre 2022 à 11:36 (UTC)
@Lepticed7, il serait plus simple d'avoir une liste précise de questions (sachant que je n'ai hélas pas lu la longe discussion ci-dessus).
Il y a eu une étude conduite il y a quelques années, sur deux Wikipédia totalement déconnectées : coréen et tchèque. Et, surprise, il y a eu plein de points communs trouvés.
Bien entendu, c'est sur Wikipédia (en particulier le point 4). Mais il est très facile d'appliquer la majorité des trouvailles au Wiktionaire (même le point 2).
Pour plus de détails, vous pouvez consulter le rapport complet (en anglais).
Les contributeurs éditent Wikipédia pour diverses raisons, et ils ont souvent des objectifs autres, au-delà d'éditer l'encyclopédie.
Commentaire perso : on a eu depuis des interviews complémentaires, qui montrent que les personnes ne sont pas motivées par une « grande cause », du type « la connaissance libre », mais par des trucs plus terre-à-terre, à savoir « ya un truc faux ».
La proéminence de Wikipédia est à la fois sa plus grande force et sa plus grande faiblesse pour attirer des nouveaux contributeurs.
Des intermédiaires inspirants, fiables et présents sont un élément essentiel pour attirer et soutenir de nouveaux contributeurs.
On parle là de personnes capable de donner envie de contribuer, et d'aider à contribuer.
En tant que lecteurs, beaucoup de contributeurs voient les Wikipédias en coréen et en tchèque comme limitées, et complètent leurs informations avec des sources plus compréhensibles et détaillées. Cela signifie qu'en tant que contributeurs, ils sont moins susceptibles de contribuer à ces Wikipédias, parce que le content gap, la différence de contenu qui doit être comblée est trop importante. Cette perception crée un cercle vicieux qui empêche les wikis de taille moyenne d'atteindre une masse de contenu conséquente.
La complexité de comment Wikipédia est faite, et la séparation avec la communauté qui construit l'encyclopédie, font qu'il est difficile de convertir les lecteurs en contributeurs, et les nouveaux contributeurs en des contributeurs expérimentés.
Les personnes doivent être confiantes en leur propre savoir pour éditer Wikipédia.
Les rédacteurs qui réussissent ont tendance à développer leurs 'compétences en matière de contribution' par le biais d'un apprentissage itératif et progressif dans des espaces sûrs, où les enjeux sont moindres.
Les plus grands défis des nouveaux éditeurs ne sont pas techniques mais conceptuels. Ils luttent pour apprendre les politiques de Wikipédia et comment façonner le contenu "à la manière de Wikipédia".
Les processus éditoriaux, et les mécanismes qui les entourent (comme par exemple la communications avec d'autres contributeurs ou les pages d'aide) ne sont pas intuitifs ou facilement accessibles, ce qui rend difficile la progression et l'apprentissage des nouveaux contributeurs.
Les nouveaux contributeurs vont chercher de l'aide hors de Wikipédia, car ils préfèrent un soutien ciblé et parfois personnel.
La façon dont un commentaire est formulé est déterminante pour savoir s'il encourage les nouveaux éditeurs à poursuivre le voyage sur Wikipédia ou s'il les déresponsabilise et les décourage de continuer à contribuer.
Les points bloquants ont dont été résumés depuis en trois grandes catégories :
@Trizek (WMF) : C’est intéressant, mais le problème que j’évoque, c’est celui de ceux qui auraient envie de contribuer normalement au Wiktionnaire (qu’ils soient ou non déjà contributeurs de Wikipédia), et qui tentent même d’essayer en cliquant sur Modifier, et qui renoncent parce qu’il sentent que ce n’est pas fait pour eux, que le wikicode qu’ils voient est trop complexe, que c’est pour une élite de techniciens. Et comment le nombre a-t-il évolué avec le temps ? Il était très faible à une époque, parce que, en cliquant sur Modifier, on voyait bien le texte affiché (avec des signes supplémentaires style double crochets, mais qui n’empêchaient pas de voir le texte), et que, quand on modifiait ce texte, on voyait bien le texte modifié s’afficher : c’est le principe même des wikis, ce qui a fait leur succès. Mais c’est de moins en moins vrai, même sur Wikipédia, et de façon encore plus marquée sur le Wiktionnaire.. On a eu des témoignages à ce sujet, et je sais que même moi, informaticien, je suis effrayé par le wikicode, et je ne commencerais certainement pas à contribuer aujourd’hui (j’ai commencé en 2005). Le cas le plus extrême est Wikivoyage, où il me semble impossible de sauter ce pas. Y a-t-il eu une étude à ce sujet ? Lmaltier (discussion) 26 novembre 2022 à 22:11 (UTC)
@Lmaltier, je n'ai pas d'étude, mais une observation. Le wikicode est une barrière technique d'entrée. À une époque, cela accepté car des syntaxes étaient utilisées ailleurs, comme sur les forums ou dans pas mal de SGC. À présent, l'évolution des outils font qu'utiliser une syntaxe est devenue totalement superflue, et la syntaxe est donc devenu une réelle barrière d'accès. Trizek (WMF) (discussion) 29 novembre 2022 à 13:22 (UTC)
Pamputt a raison, mais de toute façon je ne comprends pas la remarque : À une époque, cela accepté car des syntaxes étaient utilisées ailleurs, comme sur les forums ou dans pas mal de SGC. Depuis les débuts des wikis, il aurait été tout à fait possible de proposer des interfaces classiques genre traitement de texte, et il avait été choisi de ne pas le faire. Cela n’a pas été un frein au succès, au contraire, et je ne vois pas pourquoi cela le serait maintenant (même si proposer en plus un éditeur visuel n’est pas un inconvénient en soi). La mode a pu changer, mais la géniale méthode proposée est encore la plus adaptée aux wikis, cela n’a pas changé, à mon avis. Le problème, c’est tout ce qui fait apparaître le wikicode comme complexe, effrayant, ce qui est un frein au déclic de début de contribution. Lmaltier (discussion) 29 novembre 2022 à 18:01 (UTC)
Quelle est la difficulté pour ajouter un anagramme ? Il y a un lien pour éditer le modèle, qui contient une liste de mots séparée par des barres verticales. Il n’y a aucune difficulté. Je comprends pas. Lepticed7 (À l’immortalité !) 29 novembre 2022 à 22:30 (UTC)
L’idée est de rajouter les anagrammes par robot, la question ne se pose donc pas. Non, je ne parle pas de ça, je ne parle pas de contribution isolée pour ajouter une anagramme (contribution assez peu probable de toute façon), je parle de l’impression que peut avoir un candidat contributeur quand il regarde le wikicode. S’il voit plein de choses compliquées ou mystérieuses, des choses qui ne sont pas du tout claires pour lui, au lieu de voir le texte affiché, il y a de fortes chances qu’il abandonne tout de suite ses velléités de contribution. Lmaltier (discussion) 1 décembre 2022 à 08:32 (UTC)
Ce n’est pas la compréhension que j’ai de la proposition de Pamputt (d · c · b). Ce que j’ai compris, c’est que l’idée est de faire tourner le bot une fois pour synchroniser, et puis voilà. (Et peut-être de temps en temps si on se rend compte d’un problème). Mais quelqu’un qui rajouterai un mot pourrait vouloir rajouter un anagramme.
Si la question ne se pose pas, je sais pas pourquoi tu nous parles de difficulté. Si le candidat contributeur n’a aucun intérêt à modifier la section, on s’en balance pas mal qu’il la comprenne. Et s’il veut la modifier, il cliquer sur "Modifier la liste d’anagrammes". Lepticed7 (À l’immortalité !) 1 décembre 2022 à 14:46 (UTC)
Oui, c'est bien ça. Je peux faire tourner le bot de temps en temps mais je ne le garantis pas. En même en le faisant tourner une seule fois, le résultat sera une amélioration par rapport à ce que l'on a actuellement. C'est ça le but. Pamputt1 décembre 2022 à 14:50 (UTC)
Il ne faut pas raisonner à court terme. C’est dommage d’utiliser un travail important pour une fois, alors qu’il serait si simple d’être beaucoup plus ambitieux. Et ce travail pourrait servir aussi pour les Voir aussi de début de page, avec les adaptations nécessaires (ça exige de définir très clairement ce qu'on veut). Lmaltier (discussion) 2 décembre 2022 à 08:03 (UTC)
Juste au passage, j’ai remarqué une erreur avec le modèle dans l’article tłı̨chǫ, sans doute à cause du fait que ı̨ est composé de deux caractères le i sans point et le signe diacritique ogonek. --Moyogo(discuter)23 novembre 2022 à 05:32 (UTC)
Il semble aussi y avoir un problème avec l’apostrophe, par exemple dans mi’kmaw.
@Otourly je commence par le français mais je peux facilement m'attaquer à d'autres langues ensuite. Il faut juste que je connaisse les règles pour la langue en question si celles-ci sont différentes du français. A priori, je pense que pour l'italien, c'est pareil. Je peux regarder un peu et je te tiens au courant. Pamputt24 novembre 2022 à 20:05 (UTC)
Bon bah en fait, ça a été très vite. Si les règles sont les mêmes que le français, alors j'ai trouvé un peu plus de 16 000 entrées qui auraient besoin d'une section anagramme en italien (j'ai pas compté combien en avait déjà). Pamputt24 novembre 2022 à 20:13 (UTC)
Je pense que ceux et celles qui voulaient s'exprimer ont pu le faire. Hormis Lmaltier, j'en conclus que le reste est favorable à ce que le robot tourne. Je compte le mettre en marche une fois que le nouveau dump aura été publié (d'ici quelques heures normalement). Donc c'est le moment où jamais de vous manifester si vous avez quelque chose à dire (de bien ou de moins bien ). Pamputt1 décembre 2022 à 14:54 (UTC)
Petite expérience personnelle (hier) : j’étais en train de modifier une page, et j’ai voulu regarder les anagrammes, pour voir s’il y en avait à rajouter. Je n’ai pas pu, je n’ai vu qu’un appel de modèle… Lmaltier (discussion) 7 décembre 2022 à 17:40 (UTC)
C’est vrai que la plupart du lectorat consulte le Wiktionnaire en wikicode, pour se rendre compte que, malheur !, c’est un appel à un modèle. Pourquoi consulter le Wiktionnaire en mode lecture, une fois le code interprété, alors qu’on peut se peler le wikicode… Lepticed7 (À l’immortalité !) 7 décembre 2022 à 17:52 (UTC)
Franchement, j'ai vraiment du mal à comprendre l'argument. Lorsqu'on arrive dans la section « Anagrammes », on voit directement la liste des anagrammes présentes et juste au-dessus, il est écrit « → Modifier la liste d’anagrammes ». Donc, il est tout aussi facile e cliquer sur ce lien que de cliquer sur « Modifier » (ou « Modifier le wikicode »). Dans les eux cas, c'est un seul clic, et « → Modifier la liste d’anagrammes » a le mérite d'être hyper-explicite. Pamputt7 décembre 2022 à 19:08 (UTC)
Comme je l’ai écrit, j’étais en train de modifier la page. Je voulais juste donner cet exemple concret, et qui m’est arrivé, du fait que la méthode utilisée dévie de la méthode wiki normale (ce qui est une évidence…) et que c’est un inconvénient. Lmaltier (discussion) 8 décembre 2022 à 08:09 (UTC)
Un outil pour modifier dans les diffs
Salut. Sur le Bistro du 20, Trizek (d · c · b) présentait un gadget qui permet de faire une correction dans un diff. Ainsi plus la peine d’ouvrir la page pour corriger une coquille (notamment lors de la patrouille). Et vu que c’est un outil plutôt cool, je voulais le porter à la connaissance des wiktionnaristes. Je vous copie le message de Trizek (notamment parce qu’il y a des liens utiles qui dépendent du site)
La documentation (en français) est sur m:User:Jon Harald Søby/diffedit/fr
Pour l'utiliser, copiez-collez le code suivant dans votre common.js :
mw.loader.load( '//meta.wikimedia.orghttps://fr.wiktionary.org/w/index.php?title=User:Jon_Harald_Søby/diffedit.js&action=raw&ctype=text/javascript' );
J’avais lu le message laissé par Trizek sur le bistro Wikipédia mais merci de l’avoir copié ici car ce gadget est vraiment super. Par contre, ça ne prend pas les apostrophes courbes et autres caractères spéciaux qui sont transformer à la volée. Mais pour tous les autres cas, c’est très pratique. Pamputt23 novembre 2022 à 15:55 (UTC)
Nouvelle version du gadget Créer Nouveau Mot
Bonjoir à toutes et tous !
Petite annonce pour signaler que je viens de publier une nouvelle version du gadget qui simplifie grandement la rédaction des définitions et exemples. Il est maintenant possible d’ajouter plusieurs définitions en même temps grace à un formulaire dynamique. Les exemples ont désormais leurs propres champs, plus besoin d’écrire le code du modèle {{exemple}} dans le champ de définition (ce qui n’est plus possible de toute façon). La page d’aide a été mise à jour et explique plus en détail comment le formulaire dynamique fonctionne.
@Darmo117 : lorsqu’on ajoute une définition mais pas d’exemple, le gadget ajoute le code suivant « Exemple d’utilisation manquant.(Ajouter) ». Il manque le « #* » ; il devrait donc ajouter « #*Exemple d’utilisation manquant.(Ajouter) ». Je te laisse corriger.
@Darmo117 je viens d'ajouter un exemple à partir du nouveau gadget que tu as développé. Pour cela, j'ai simplement cliqué sur « Ajouter un exemple » qui apparait en-dessous de « Exemple d’utilisation manquant. (Ajouter) ». En cliquant là, je m'attendais à ce qu'une fois l'exemple ajouté, le gadget supprime le « Exemple d’utilisation manquant. (Ajouter) » étant donné qu'il y a maintenant un exemple. À la place, ça fait un rendu bizarre où ça indique successivement : exemple d'utilisation manquant, un exemple d'utilisation, puis Ajouter un exemple.
Si c'est compliqué de supprimer le {{exemple}} qui apparait en premier, est-il plus simple de faire apparaitre la fenêtre d'ajout d'exemple (qui apparait actuellement quand on cliquer sur « Ajouter un exemple ») en cliquant sur le « Ajouter » qui est généré par {{exemple}} ? Pamputt22 décembre 2022 à 20:06 (UTC)
Salut, le soucis provenait de la présence d’une espace dans le modèle vide qui du coup n’était pas détecté et donc pas supprimé. J’ai publié un fix qui devrait résoudre tout ça. Darmo (Viendez parler !) 29 décembre 2022 à 10:17 (UTC)
@Darmo117 : je viens de faire un nouveau test et « Exemple d’utilisation manquant. (Ajouter) » est toujours présent après l'ajout de l'exemple. Je m'attends à ce que cette ligne disparaisse. Pamputt6 janvier 2023 à 08:45 (UTC)
Limite au nombre de fichier de prononciation ajoutés?
Dans piqué, piquer, une belle floppée, ce n'est pas le seul exemple.
N'est-il pas possible d'imposer une limite? (disons 6 : deux pour le français "de France", un pour le québécois, l'occitan, le belge, le suisse)? Diligent (discussion) 26 novembre 2022 à 21:08 (UTC)
Le problème est le caractère automatique de ces ajouts. Je dirais bien que, s’il y a déjà au moins un enregistrement, il ne faudrait pas rajouter automatiquement mais simplement que ce soit signalé d’une façon ou d'une autre pour être ajouté manuellement si c’est utile. Il est difficile de fixer un nombre maximal qui empêcherait des ajouts utiles. Lmaltier (discussion) 26 novembre 2022 à 22:21 (UTC)
On a évoquer le sujet à la Wikiconvention francophone le weekend dernier (Poslovitch, Noé, Lyokoï, Darmo117, Lepticed7, Le Commissaire et d'autres étaient présents). On était globalement d'accord que des dizaines de prononciation audio quasi-identiques présentaient peu d'intérêt. Je ne me rappelle pas qu'on se soit arrêter sur une solution technique définitive. Il a cependant était évoqué d'ajouté un modèle pour indiquer à Lingua Libre Bot de ne plus ajouter les nouvelles prononciations dans la page. À la place, il pourrait simplement les ajouter dans une section de la page de discussion de la page. Si on retient cette idée alors il faudrait prévoir un nouveau modèle ou une nouvelle catégorie pour pouvoir retrouver rapidement toutes les pages qui ont « trop » de prononciations audio pour un éventuel traitement manuel.
Il faudrait donc définir une « solution » technique qui fasse consensus pour qu'ensuite celle-ci puisse être implémentée. Pamputt27 novembre 2022 à 19:05 (UTC)
Pourquoi pas celle que j’indiquais ci-dessus, en ajoutant l’enregistrement dans la page s’il n’y en a pas encore, et sans la page de discussion sinon, en rajoutant une catégorie de maintenance spéciale dans cette pages de discussion, pour signale qu’une décision est à prendre : virer les enregistrements inutiles, et ajouter à la page ceux qui sont utiles. Lmaltier (discussion) 27 novembre 2022 à 20:01 (UTC)
Oui, c'est aussi une possibilité. Le petit problème que je vois c'est que Lingua Libre vise à promouvoir les accents régionaux et donc si on limite la prononciation audio à 1, alors c'est le premier arrivé, premier servi. Je pense que quelque chose comme quelques prononciations (3, 6 comme le propose Diligent, etc.) serait mieux. Ca serait par exemple très utile pour les langues où plusieurs accents « majoritaires » font autorité comme l'anglais (prononciations américaine et britannique auxquelles on peut ajouter l'accent australien, indien, etc.). Pamputt27 novembre 2022 à 20:15 (UTC)
Et je serai plutôt d'avis d'en mettre 5 ou 6 qu'un seul.
Le but étant de promouvoir les différences d'accents ou de prononciation.
Ne pourrait-on pas imaginer également qu'au bout d'une dizaine d'enregistrement, Lingua Libre envoie un avertissement comme "Attention, ce mot possède déjà ... enregistrements. Ne voulez-vous pas plutôt enregistrer ..., qui n'en possède pas encore ?" Commissaire (discussion) 28 novembre 2022 à 08:44 (UTC)
En fait il y a deux niveaux d'action. Un concerne le Wiktionnaire, ce dont on discute maintenant (comment limiter le nombre d'ajout) et l'autre concerne le site Lingua Libre. Pour Lingua Libre, on pourrait envisager que le logiciel vérifie combien d'enregistrements existent déjà pour ce mot et si la personne qui veut enregistrer ce mot encore une fois vient d'une région qui a déjà beaucoup d'enregistrements (au hasard la région parisienne), Lingua Libre pourrait afficher un avertissement et lui proposer d'enregistrer d'autres mots à la place. Pamputt28 novembre 2022 à 08:58 (UTC)
@Pamputt : Je précise que je proposais de limiter à 1 seulement pour les ajouts automatiques dans la page du mot. Les autres ajouts seraient faits manuellement par copier/coller depuis la page de discussion, en fonction de ce qui s’y trouve, par ceux qui s’occuperaient de vider la catégorie de maintenance, en exerçant un jugement humain, indispensable sur ce point. Il ne sert à rien de fixer un maximum de 3 ou de 6, si c’est pour se retrouver avec 3 ou 6 prononciations strictement identiques… Lmaltier (discussion) 28 novembre 2022 à 09:18 (UTC)
Pourquoi pas mais comment fait-on ça en pratique. Comment Lingua Libre Bot peut-il savoir combien de mot est ce qu'il a déjà ajouté automatiquement ? Comment peut-il faire la différence entre les ajouts manuels et automatiques ? Pamputt28 novembre 2022 à 09:23 (UTC)
Si le bot peut modifier une page, il peut aussi la lire, et donc détecter ou non la chaîne de caractères qui permet de constater qu’un enregistrement est déjà présent. C’est ça qui importe. Peu importe si les ajouts ont été manuels ou automatiques. Le seul point qui resterait à décider, c’est où ajouter dans la page de discussion. Le mieux est sans doute de mettre une section à la fin avec un titre toujours identique. Si la section est déjà présente, on la complète, sinon on la crée en fin de page. Si la catégorie de maintenance n’existe pas, le bot la rajoute à la fin de la page de discussion. Lmaltier (discussion) 28 novembre 2022 à 10:50 (UTC)
Ah ok, je comprends. Limiter à 1 ajout automatique pose l'inconvénient que j'ai décrit ci-dessus (premier arrivé, manque de diversité, etc.). Il serait donc mieux de limiter à quelques enregistrements (5-6 max). Car il faut bien voir qu'il y a un très grand nombre d'enregistrements qui sont réalisés grâce à Lingua Libre. Et donc si on limite à un seul enregistrement automatique, j'ai bien peur les humains soient surchargés devant la masse d'enregistrement à gérer à la main ce qui se traduirait par le fait que ceux-ci resteraient cachés sur la page de discussion dans leur très grande majorité.
Avec 5-6 enregistrements max, ça montre qu'on peut ajouter plusieurs prononciations audio et il me semble qu'on se sentirait plus légitime à modifier à un enregistrement par un autre. Pamputt28 novembre 2022 à 11:03 (UTC)
Attention, de nombreuses pages contiennent plus d’une section dédiée aux fichiers audios, car une même suite de caractère peut avoir plusieurs prononciation en français (un exemple au hasard : parent et parent (du verbe parer)) ou plusieurs standards en variation libre (ananas, cassis). Et il y a souvent plusieurs langues décrites, avec autant de sections possibles. Quoi qu’il en soit, je suis opposé à la restriction à une seule prononciation, car le premier enregistrement ne sera pas forcément le plus représentatif ni celui de la meilleure qualité audio. Un échantillon avec 6 à 10 fichiers audio me paraît plus pertinent. D’autant qu’il y a plus de trente aires francophones avec autant d’accents variés, il ne s’agit pas de proposer seulement une prononciation parisienne et une méridionale, avec un soupçon d’exotisme. À moyen terme, ce qui me paraîtrait le mieux, ce serait un petit lecteur audio de petite taille, avec une liste de lecture dynamique et triable selon différents critères, qui permette une écoute plus rapide et prenne moins de place. Mais bon, difficile d’encore rêver de développement technologique, quand la Wikimedia Foundation fait le choix de n’être que l’hébergeur du Wiktionnaire, sans le soutenir Noé28 novembre 2022 à 11:09 (UTC)
Encore une fois, je suis contre le fait de limiter en nombre, je suis pour limiter à ce qui est utile. Et, pour ça, le risque d’être débordé est exactement le même quelle que soit la méthode choisie. Il y a malheureusement un risque que ceux qui gèrent la catégorie de maintenance hésitent à retirer un enregistrement inutile ou à le remplacer par un autre plus utile, il y a beaucoup moins de risque s’ils n’ont à choisir qu’entre rajouter ou ne pas rajouter à ce qui est déjà présent. Lmaltier (discussion) 28 novembre 2022 à 13:18 (UTC)
De ce que j'ai compris, tu proposes de limiter en nombre les ajouts automatiques ; mes arguments restent valides. Pamputt28 novembre 2022 à 15:23 (UTC)
Oui, sauf que de mon point de vue, c'est moins grave d'avoir 10 fichiers audio qu'un seul, qu'ils aient été ajoutés automatiquement ou non. Pamputt28 novembre 2022 à 20:14 (UTC)
Le but de la discussion, c’est quand même de trouver une solution pour ne pas avoir plein de fichiers de prononciation identiques ou quasiment identiques (ce qui ne peut que perturber les lecteurs sans leur être utile), non ? J’en reste à cet objectif : c’est mieux d’avoir un seul fichier audio que d’en avoir 3 ou 6 ou 10 identiques, et c’est encore mieux d’en avoir plusieurs et que tous soient réellement utiles, en montrant bien les différences régionales. Lmaltier (discussion) 29 novembre 2022 à 07:09 (UTC)
Je vais essayer de trouver le temps de faire des stats pour savoir de quoi on parle (la distribution du nombre de prononciations audio par page, etc.). Pamputt29 novembre 2022 à 08:04 (UTC)
Voici le nombre de pages du Wiktionnaire en fonction du nombre de prononciations audio présentes sur l'entrée. J'ai fait le travail pour le français mais je peux facilement le faire pour d'autres langues.
Nombre de prononciations présente dans l'entrée | Nombre d'entrées
1 -> 97147
2 -> 26867
3 -> 9583
4 -> 3771
5 -> 1657
6 -> 771
7 -> 390
8 -> 224
9 -> 133
10 -> 118
11-20 -> 326
21-30 -> 193
31-40 -> 42
41-50 -> 2
L'entrée qui a le plus de prononciations audio est blanc avec 46 fichiers audio.
Au total on a un peu plus de 500 entrées qui ont 11 prononciations audio ou plus, et ce 4 ans et demi après le lancement de Lingua Libre Bot. C'est en effet un nombre assez important qui mérite qu'on définisse une politique sur le sujet. Pamputt30 novembre 2022 à 22:37 (UTC)
Je me suis amusé à écouter les 46 fichiers de blanc. Toutes reflètent la même prononciation, sauf une, du Nouveau-Brunswick. L’idéal pour ce mot serait de choisir une prononciation bien nette parmi les autres (il y a l’embarras du choix) + celle du Nouveau-Brunswick. Ce mot est un cas pas très classique, car il n’y a apparemment pas de prononciations régionales en France, si on en croit les fichiers. Lmaltier (discussion) 1 décembre 2022 à 08:23 (UTC)
Salut. J’ai fait un test avec forêt en utilisant la galerie de fichiers. Ça donne ça : Utilisateur:Lepticed7/test209000. Par ailleurs, @Lmaltier :, tu dis faux. Il y a d’autres prononciations que celle du NB. Celle-ci est aussi différente et caractéristique du sud de la France : ou encore celle-ci, d’un locuteur du Tchad : . Les sons sont différents. Par ailleurs, que choisit-on comme unique fichier ? Celle d’un homme parisien moyen. Les mêmes problèmes de représentation qu’il y a dans la prononciation en ligne vedette sont répercutées ici. Plutôt que ça, pourquoi ne pas œuvrer à obtenir une vrai sonothèque. La Fondation, tout comme Wikimédia France, peuvent financer des projets de développement. À+, Lepticed7 (À l’immortalité !) 1 décembre 2022 à 14:57 (UTC)
Chaque personne a une voix différente, et je considérais ces deux prononciations comme des prononciations fondamentalement identiques. Mais je ne suis pas spécialiste en phonétique. Je n’ai jamais parlé d’avoir un unique fichier présent dans la page, seulement d’essayer de ne pas avoir de doublons. Lmaltier (discussion) 2 décembre 2022 à 07:57 (UTC)
Salut, j’aimerais rajouter ma petite pierre à la discussion. Selon moi, parmi l’ensemble des fichiers actuellement disponibles sur la page, seuls 4 me semblent différer de la majorité : le premier de Toulouse, celui de Saint-Étienne (subtil mais bien différent), celui de Shawinigan et du Nouveau-Brunswick. Cela dit, la majorité des fichiers de la page sont globalement indiscernables en terme de phonétique, mis à part la vitesse d’élocution et la voix bien entendu. Darmo (Viendez parler !) 2 décembre 2022 à 15:07 (UTC)
Bonjour ! Dans la langue sur laquelle je travaille (le haoussa), il y a une catégorie grammaticale, utilisée dans les dictionnaires de références, qui n'est à ce stade pas présente sur le Wiktionnaire : les idéophones. Elle existe dans un certain nombre de langues d'Afrique, d'Amérique et d'Asie mais est assez rare dans les langues d'Europe, cela explique peut-être en partie pourquoi elle n'existe pas encore. Il y en a beaucoup en haoussa (plusieurs centaines, dont une partie sont déjà répertoriés sur le Wiktionnaire en anglais). Avant de la créer, n'étant pas linguiste de formation et étant peu présent ici en-dehors de mes contributions sur le haoussa, je voulais simplement m'assurer que cela ne posait aucun problème, ou que la question n'avait pas déjà été posée. Un grand merci, --DonCamillo (discussion) 29 novembre 2022 à 07:58 (UTC)
Si c’est une catégorie grammaticale dans la langue, bien sûr. Mais, même si je comprends bien la définition que nous donnons pour idéophone, je ne comprends pas bien le sujet : d’après cette définition, presque tous les mots, y compris les mots français, sont des idéophones, non ? Est-ce qu’il ne faudrait pas améliorer la définition, si ce n’est pas le cas ? Qu’est-ce qui distingue ces mots des autres ? 29 novembre 2022 à 09:46 (UTC) Je comprends mieux en lisant w:en:Ideophone. Il faudrait effectivement améliorer grandement notre définition, mais je laisserai ce soin à quelqu’un qui connait bien une langue utilisant cette notion. Question : je lis dans la page citée : The grammatical function of ideophones varies by language. In some languages (e.g. Welayta, Yir-Yiront, Semai, Korean), they form a separate word class, while in others, they occur across a number of different word classes (e.g. Mundang, Ewe, Sotho, Hausa). Cela semble dire que ce n’est pas une classe de mot séparée en haoussa ? Ou alors, il existe une classe séparée, mais il y a en plus de cette classe spécifique d’autres mots de diverses classes de mots qui en sont aussi ? Lmaltier (discussion) 29 novembre 2022 à 10:05 (UTC)
Cette thèse (page 2) indique Although ideophones in African languages are often classified with adverbs. They do not always function as such. While it is true that ideophones often function in Hausa in a manner that might be labeled "adeerbial," they also function in other ways. Consequently, it seems best to define them primarily as a lexical category and only secondarily as a grammatical category. Donc ça me semble bien justifié d'ajouter les idéophones comme nouveaux « types de mots » Pamputt29 novembre 2022 à 10:37 (UTC)
D'une manière générale, je pense qu'il ne faut pas essayé de se calquer sur les classes grammaticales des langues européennes mais utiliser les mêmes objets qui sont utilisées dans les travaux de linguistiques et grammaire des langues en question. Pamputt29 novembre 2022 à 10:49 (UTC)
Merci pour vos remarques ! Je comprends que le statut des idéophones comme classe grammaticale à part en haoussa ne fait pas complètement consensus (certains linguistes l'accordent, d'autre non). Néanmoins le dictionnaire généralement reconnu comme faisant référence (celui de Paul Newman) leur donne ce statut, et le précis grammatical de Bernard Caron également. Ces sources poussent donc plutôt à créer une catégorie à part. Je vais quand même poser la question à un expert des langues tchadiques que je connais à l'INALCO avant de commencer, je vous tiens au courant. --DonCamillo (discussion) 30 novembre 2022 à 16:49 (UTC)
Ce qui serait bien, ce serait d'avoir des exemples dans l'article, avec signification et transcription phonétique. Parce que là, on ne voit pas très bien ce que c'est. En effet :
dans certaines langues, le redoublement d'un adjectif signifie "très" ;
la définition actuelle pourrait aussi bien correspondre à une onomatopée.
@Pamputt : Un grand merci ! J'ai pu échanger avec un linguiste spécialiste du haoussa qui confirme que les idéophones en tant que classe grammaticale ne font pas consensus (ni en haoussa ni dans d'autres langues), mais qu'ils sont néanmoins utilisés par un grand nombre de linguistes. --DonCamillo (discussion) 11 janvier 2023 à 09:07 (UTC)
Interface bureau : le bouton des langues en haut de la page d'accueil ?
Avec l'habillage Vector 2022, actuellement le bouton des langues ne se trouve pas en haut de la page d'accueil mais tout au fond. Cela est dû au déplacement des liens interlangues en haut de la page à côté du titre : sur la plupart des wikis, le Wiktionnaire parmi d'autres, le titre de la page d'accueil est caché donc le bouton des langues ne peut pas s'afficher à son côté. Au lieu de cela, il se trouve tout en bas de la page d'accueil. Cependant, il est possible de le faire apparaître tout en haut mais le changement doit se faire au niveau local, à la demande de la communauté.
Je copie ci-dessous un passage de la Foire aux questions (ici et ici les questions dédiées au complet) :
Le titre s'affichera sur Vector 2010, Minerva, Timeless et Vector 2022. Ne sera pas visible sur Monobook.
Testez à quoi ressemble la page d'accueil et comment elle fonctionne avec le bouton en haut de la page, en ajoutant le paramètre ?vectorlanguageinmainpageheader=1 à la fin de l'URL. La page d'accueil de la Wikipédia en basque affiche une phrase de bienvenue dans le titre. Vous pouvez également voir l'exemple de la Wikipédia en islandais (qui n'a pas de titre configuré, donc seul le bouton apparaît).
Si cela vous intéresse, notifiez-moi (ou contactez l'équipe Web autrement) pour demander le déplacement du bouton des langues vers le haut en page d'accueil. L'Équipe Web modifiera les paramètres de votre wiki. À ce moment là, le bouton sera visible en haut de la page avec Vector 2022. Avec d'autres habillages, la liste des liens des langues s'affichera à l'emplacement par défaut, qui est différent pour chaque habillage.
Noé 1 novembre 2022 à 00:39 (UTC)
--Rapaloux (discussion) 1 novembre 2022 à 06:33 (UTC)
. Jpgibert (discussion) 2 novembre 2022 à 13:17 (UTC)
Noé 22 novembre 2022 à 21:29 (UTC)
@Lmaltier : Salut. Dans ce cas, il faut que tu expliques à quoi servirait spécialement. Quelle information pourrait-on tirer d’une définition commençant par spécialement ? À+, Lepticed7 (À l’immortalité !) 14 novembre 2022 à 20:00 (UTC)
). Pamputt 1 décembre 2022 à 14:54 (UTC)
Pamputt 22 décembre 2022 à 20:08 (UTC)
