Wiktionnaire:Wikidémie/novembre 2023

Un nouveau numéro des Actualités du Wiktionnaire vient de paraître !

Dans ce numéro aux teintes crépusculaires, Romain Behar informe de l’ouverture de la Cité de la langue française, Noé parle d’une langue qui semble être un canular, Trace présente un ouvrage qui analyse les dictionnaires analogiques et Pamputt rend compte d’un article universitaire qui étudie la qualité des définitions du Wiktionnaire. Autour, une veille sur la presse et un résumé des discussions et des initiatives de création de nouvelles entrées.

Découvrez le numéro 103 d’octobre 2023 !

Brouillon du prochain — Anciens numéros — Abonnement-désabonnement

Le mois d’octobre s’achève avec treize personnes qui ont participé à ce numéro ! Félicitations Noé 1 novembre 2023 à 00:55 (UTC)

Bonjour. J’ai retravaillé sur un projet pour rechercher dans des définitions du Wiktionnaire.

J’ai réalisé des versions avec des filtres dont je publierai les liens plus tard. Il y a aussi une page pour rechercher que les mots.

Opérateurs supportés : "recherche exacte" -terme -terme. Tolérance aux typos.

Pas de publicités ni de service d’analyse d’audience.

https://dicoalto.com

Pour des commentaires, suggestions ou questions.

Une vidéo sur cette page d’un exemple avec des filtres. Snawei (discussion) 1 novembre 2023 à 14:28 (UTC)

A l’occasion de modifications sur Briis-sous-Forges, Castelroussin et indemnisable une IP a attiré mon attention sur un débat (et une prise de décision ?) sur Wikipédia concernant des sites Internet condamnés par la justice. Le Wiktionnaire doit-il aussi prendre une position ? Basnormand (discussion) 4 novembre 2023 à 13:49 (UTC)

On lira https://fr.wikipedia.orghttps://dictious.com/fr/Discussion_Wikip%C3%A9dia:Observatoire_des_sources#Sites_web_d'Advercity --Rapaloux (discussion) 4 novembre 2023 à 14:10 (UTC)

Ce qui est sûr, c’est qu’on n’a pas à laisser une citation en en supprimant la source. Et on ne fait pas de pub simplement en signalant une source, surtout sans lien. Mais c’est vrai qu’il peut être conseillable d’éviter les sites en question. Lmaltier (discussion) 6 novembre 2023 à 07:55 (UTC)

Enregistré sur Phabricator
T352660

Bonjour le Wiktionnaire ! Avec à peine 2 mois de retard (mes excuses à @Pamputt : à qui j’avais promis une mise à jour rapide… mon temps a été détourné ailleurs), voici venue la nouvelle mouture de mon programme d’extraction de prononciations du Wiktionnaire.

Rappel de l’épisode précédent : j’ai codé un programme qui, à partir d’un dump du Wiktionnaire francophone, extrait (presque) tous les mots français et leur prononciation, ainsi que quelques données grammaticales. Pour ça il prend les sections de langue fr, et extrait les infos trouvées dans les divers modèles d’accord ainsi que dans les modèles {{pron}}, {{m}}, etc. présents sur la ligne de forme. Mon programme produit un tableur (un mot par ligne) et, ce qui intéresse plus directement les wiktionaristes, il détecte et affiche tout plein d’erreurs ou du moins de choses suspectes dans les données du Wiktionnaire. Cette première version signalait les choses suivantes :

• quelques problèmes structurels : plusieurs sections langue fr, type grammatical inconnu (souvent, un titre de section au mauvais niveau) ;
• informations contradictoires de genre ou de nombre entre un modèle d’accord et la ligne de forme ;
• caractères inhabituels (c’est-à-dire qui ne sont pas des sons du français standard) dans une prononciation ;
• mauvais usage d’un modèle d’accord (divers types d’erreurs) ;
  • il est apparu que les modèles d’accord sont souvent mal employés, ce qui crée parfois des prononciations fausses.

Dans cette seconde mouture, j’ai mis à jour les données avec le dump le plus récent (1^er novembre 2023), et j’ai pas mal perfectionné mon programme. Outre la correction de petits bugs, il y a 5 grandes nouveautés, expliquées en détail plus loin.

1. prise en charge des modèles d’accord Lua ;
2. détection d’usages suspects avec 2 graphies et 2 prononciations (nouveauté plus mineure) ;
3. calcul d’un score pour détecter des prononciations suspectes (la killer feature !) ;
4. rectification de syllabes ;
5. fusion de prononciations.

Mon programme se trouve toujours là. Toute personne avec la fibre informaticienne peut l’exécuter ou le modifier (le code est en Python). Je dis ça si dans le futur vous voulez actualiser le résultat du programme.

La base de données produite se trouve là.

J’ai mis tous les messages du 1^er novembre ici, classés par type de message, triés par ordre alphabétique de mot-vedette et répartis dans plusieurs sous-pages. Il y a aussi la liste des scores les plus élevés, annotés manuellement (j’avais pris ces notes pour mettre au point mon calcul de score, autant vous en faire profiter). Si vous vous attaquez à corriger les problèmes repérés, n’hésitez pas à supprimer les messages traités.

Certains modèles d’accord du Wiktionnaire sont implémentés en Lua (Module:fr-flexion). Ma version précédente ne les comprenait pas ; c’est maintenant le cas, ainsi mon programme supporte maintenant tous les modèles d’accord existants (sauf {{fr-accord-personne}} et {{fr-accord-t-avant1835}} qui sont assez mineurs). Donc on arrive à extraire davantage de prononciations, et aussi, on vérifie l’usage de ces modèles Lua. Il y a d’ailleurs des nouvelles vérifications spécifiques à ces modèles, mais la seule qui produit des avertissements avec les données actuelles est la suivante :

ANOMALIE: "cendrarsiennes": {{fr-accord-en}} (Lua): ancien param. en conflit avec la valeur détectée: ms=cendrasien / détecté=cendrarsi+en

Explication : le code actuel en Lua a remplacé une implémentation précédente en Wikicode. Le nouveau code est plus intelligent (il devine automatiquement la graphie du lemme d’après la graphie du mot-vedette), et donc il attend moins de paramètres, et donc l’interface de ces modèles a changé. En l’occurrence, dans le message ci-dessus, mon programme signale que l’ancien paramètre ms=, désormais ignoré, diffère de la valeur auto-détectée ; il se trouve que dans toutes les instances, c’est l’auto-détection qui a raison et l’ancien paramètre renseigné manuellement qui était faux, donc l’automatisation était plutôt une bonne chose. Mais il vaudrait mieux repasser quand même sur ces instances, car ça peut trahir un mauvais usage du modèle.

j’avais oublié d’en parler : tous ces modèles Lua ont donc en commun que leur ancienne syntaxe acceptait trois paramètres nommés ms=, inv=, trait=, qu’ils ignorent maintenant allégrement. Alors que mon programme, par ailleurs, signale les paramètres ignorés par les modèles d’accord, j’ai désactivé le signalement pour ceux-là car il y a manifestement beaucoup d’instances qui n’ont pas été migrées (plus de 12 000 signalements supplémentaires). Au lieu de ça, comme je l’expliquais, on vérifie que les valeurs fournies sont égales à celles qui sont maintenant auto-détectées (ce qui mène à un nombre beaucoup plus raisonnable de nouveaux signalements : 111). Maëlan (discussion) 7 novembre 2023 à 15:23 (UTC)

À propos du changement d’interface de ces modèles : parfois l’interface a changé de façon incompatible ! À cause de paramètres non-nommés, dont le nombre a été réduit (voir aussi cette discussion, où j’ai expliqué entre autres pourquoi je pense qu’il ne faut pas utiliser de paramètres non-nommés pour ces modèles)… Un hack assez sale (la fonction nouvelle_ancienne_syntaxe_radic4 dans le code Lua) a été mis en place pour prendre en charge l’ancienne interface le temps de la migration. Ladite migration semble n’avoir jamais été terminée, il reste pas mal d’instances de l’ancienne syntaxe, et le hack est toujours en place. Il y a un risque qu’une syntaxe nouvelle soit interprétée à tort comme une syntaxe ancienne, mon programme détecte cette situation (ce qui n’affiche aucun avertissement à l’heure actuelle).

Mon programme peut signaler tous les usages qui utilisent l’ancienne syntaxe, mais j’ai désactivé ce message (une seule ligne à décommenter dans mon code) car il y en a beaucoup (environ 6400). De toute façon, on pourrait aussi modifier le code Lua pour catégoriser les pages qui utilisent l’ancienne syntaxe.

Remarque en passant : le code Lua actuel ( @ArséniureDeGallium :) est très répétitif, ce qui le rend fastidieux à lire et à maintenir. Il est facile de le factoriser, comme je l’ai fait dans ma ré-implémentation en Python (rechercher la fonction lua_agreement dans mon code).

Le but est de corriger le problème que j’ai exposé dans cette discussion avec les exemples "tonal" et "djich" : parfois un modèle d’accord renseigne plusieurs graphies possibles (par exemple le pluriel de "tonal" peut être "tonals" ou "tonaux"), et également plusieurs prononciations possibles (ici, \tɔ.nal\ et \tɔ.no\), mais c’est fait de telle sorte que le modèle indique à tort que les 2 prononciations s’appliquent chacune aux 2 graphies. Mon programme détecte ces situations et affiche 2 nouveaux messages :

INFO: "féral": {{fr-accord-mixte}}: 2 prons. pour 2 orthos au mp (motif reconnu): "férals", "féraux", , 
ATTENTION: "taxums": {{fr-rég}}: usage suspect de pron2 ou pp2: "taxums", , 
ATTENTION: "chat·te": {{fr-rég}}: usage suspect de pron2 ou pp2: "chat·tes", , , 

Le premier message concerne le modèle {{fr-accord-mixte}} pour lequel on ne peut pas faire grand-chose (limitation du modèle). La mention « motif reconnu » signifie que mon programme connait ce motif-là (paire de suffixes -als/-aux), et s’est débrouillé pour dissocier la prononciation de chaque graphie.

Le second message concerne les modèles {{fr-accord-mf}} et {{fr-rég}}, pour lesquels l’erreur peut être corrigée. Souvent, c’est parce qu’il y a 2 pluriels ("taxum" → "taxa" ou "taxums") mais que la prononciation du 2^e pluriel a été indiquée à tort avec le paramètre pp2= au lieu de p2p= (le nommage de ces paramètres induit en confusion…). Néanmoins certains usages sont légitimes. Par exemple pour "chat·tes" ??

Mon programme est maintenant capable de détecter de nombreuses prononciations erronées (ce pour quoi on n’avait guère d’outils jusqu’à présent, à part le signalement de mauvais caractères). On calcule un « score » pour chaque paire graphie–prononciation. Plus le score est élevé, plus c’est suspect. Les prononciations un peu / très / trop suspectes sont préfixées par un / deux / trois points d’exclamation "!". Les plus suspectes (un peu moins de 3000) produisent un avertissement :

ANOMALIE: "anticartésien": pron. sans doute erronée: 
ANOMALIE: "cishétérosexuel": pron. sans doute erronée: 
ANOMALIE: "bitolienne": pron. sans doute erronée: 
ANOMALIE: "illocaux": pron. sans doute erronée: 
ANOMALIE: "tweeteuses": pron. sans doute erronée: 
ANOMALIE: "cabochées": pron. sans doute erronée: 

(le seul crime de "cabochées" semble être de n’être pas syllabé)

Le programme enregistre aussi, dans un fichier scores.txt sur le côté, les scores de toutes les prononciations rencontrées. On peut ensuite trier ce fichier et ainsi lister plus exhaustivement les prononciations avec des scores élevés, y compris celles dont le score est insuffisant pour produire un avertissement.

Le calcul du score additionne, avec des coefficients ajustés à la mano, de nombreux critères qui tentent de détecter plusieurs types d’erreurs que j’ai remarquées à force de brasser le Wiktionnaire dans tous les sens. Par exemple (liste non exhaustive) :

• une différence trop importante de longueur entre la graphie et la prononciation ;
• des syllabes trop longues (détecte des prononciations qui sont correctes mais où il manque des indications de syllabes) ;
• la présence de caractères de prononciation invalides, comme \é, c, h, r…\ (trahissent qu’une graphie a été renseignée là où une prononciation était attendue) ;
• la présence de n-grammes suspects tels que \ch, eau, aux\, consonnes doubles… (idem) ;
• une prononciation qui se termine par \ fr\ (mauvais usage d’un modèle d’accord, où le code de langue fr a été donné à tort dans un paramètre non-nommé qui est interprété comme un suffixe de prononciation) ;
• une syllabe qui contient une semi-voyelle mais pas de voyelle, par exemple \lɛ.tj\ (mauvais usage où un préfixe de prononciation a été renseigné à la place d’une prononciation complète) ;
• une prononciation égale à un préfixe de la graphie, suivi de certains suffixes (encore un mauvais usage des modèles d’accord) ;
• critère radical : si le début de la graphie ne peut pas produire le début de la prononciation. Le programme a une liste (permissive) indiquant quels groupes de lettres peuvent produire quels groupes de sons (exemples : "a" non suivi de "i" ou "y" peut produire le son \a\ ou \ɑ\ ; "ay" peut produire \aj\ ou \ɛ\ ; "c" non suivi de "h" peut produire \s\ ou \k\ ; "ch" peut produire \ʃ\…). Si le début du mot ne correspond à aucun motif autorisé, c’est très certainement une erreur sérieuse, et donc ce critère donne d’emblée un score très élevé. À lui seul ce critère détecte un petit millier d’erreurs sérieuses.

Remarque : on peut imaginer étendre le dernier critère à l’ensemble du mot. Autrement dit, découper tout le mot en graphèmes mis en correspondances avec leur prononciation (par exemple "oiseaux" prononcé \wazo\ se découperait en "oi" prononcé \wa\, "s" prononcé \z\, "eau" prononcé \o\, "x" muet). C’est justement une donnée qui m’intéresse beaucoup, et ce serait aussi l’arme nucléaire de la détection d’erreurs ! Je l’ai fait dans un autre projet, pour une base de mots plus restreinte (Lexique3), mais pour le Wiktionnaire il y a davantage de boulot car les données sont moins contraintes (l’ensemble des caractères autorisés dans les graphies et dans les prononciations est beaucoup plus vaste) et il y a dix fois plus de mots, y compris des anglicismes et autres.

Faire profiter le Wiktionnaire des sous-produits de mon travail, c’est chouette, mais mon but premier reste de produire une base de données. Donc je bricole pour améliorer les données produites.

En plus de quelques nettoyages des prononciations (par exemple remplacer \r\ par \ʁ\, supprimer des points et des espaces en trop…), mon programme effectue maintenant de nombreuses rectifications de leur syllabation :

• (1) ajoute des coupures de syllabes manquantes ;
• (2) déplace des consonnes d’une syllabe vers la suivante (cas fréquent où des syllabes ont été coupées en suivant une règle graphique, à savoir entre deux consonnes, mais que ça ne correspond pas à la prononciation) ;
• (3) recolle une consonne à la syllabe précédente quand elle est toute seule dans sa syllabe (cas fréquent où un schwa a été complètement omis dans la prononciation) ;
• (4) corrige la notation des liaisons (souvent il y a un \‿\ mais il manque un point avant la consonne liée, ou alors \‿\ n’est pas placé au bon endroit) ;
• etc.

Les rectifications sont consignées (et il y en a… 27 000). Exemples (les numéros indiquent le type de rectification parmi la liste ci-dessus ; ils ne sont pas écrits par mon programme):

(1) INFO: "divergentes": pron. rectifiée:  -> 
(1) INFO: "pancréatiquement": pron. rectifiée:  -> 
(2) INFO: "mandrins": pron. rectifiée:  -> 
(2) INFO: "ardoise": pron. rectifiée:  -> 
(3) INFO: "aragne": pron. rectifiée:  -> 
(3) INFO: "acides-alcools": pron. rectifiée:  -> 
(4) INFO: "vive-eau": pron. rectifiée:  -> 
(4) INFO: "bien-être": pron. rectifiée:  -> 
(4,1) INFO: "lettres ouvertes": pron. rectifiée:  -> 
(2,4) INFO: "planche à billets": pron. rectifiée:  -> 
(1 puis 3) INFO: "piaillerie": pron. rectifiée:  -> 

Je vous partage la liste des rectifications car ça peut intéresser le Wiktionnaire quand même. D’une part il s’agit en général d’améliorations qui pourraient être faites dans le Wiktionnaire, d’autre part la rectification trahit parfois une erreur (que le score devrait aussi permettre de repérer). Par exemple

• (1) et (3) trahissent parfois un mauvais usage d’un modèle d’accord (pour "boulonnerie" une graphie est fournie là ou une prononciation est attendue ; pour "cocheniller" et "assesseuses" il manque la terminaison ; pour "sucreux" au contraire une terminaison est en double ; pour "aranéen" la prononciation est correcte mais à cause de l’usage du modèle d’accord, un point a été oublié avant la terminaison),
• ou une mauvaise écriture des voyelles phonétiques (voyelles longues qui devraient être courtes),
• voire des erreurs plus arbitraires :

(1) INFO: "boulonnerie": pron. rectifiée:  -> 
(3) INFO: "cocheniller": pron. rectifiée:  -> 
(3) INFO: "assesseuses": pron. rectifiée:  -> 
(1) INFO: "sucreux": pron. rectifiée:  -> 
(1) INFO: "aranéen": pron. rectifiée:  -> 

(1) INFO: "fouineur": pron. rectifiée:  -> 
(1) INFO: "jungiens": pron. rectifiée:  -> 

(1) INFO: "à l’intention de": pron. rectifiée:  -> 

Le plus souvent les rectifications améliorent la syllabation. Cependant la modification est parfois indésirable. Je vois deux types de modifs indésirables : déplacer des consonnes vers la syllabe suivante à travers un E muet :

(2) INFO: "chatterie": pron. rectifiée:  -> 
(2) INFO: "coqueluche": pron. rectifiée:  -> 
(2) INFO: "trompe-l’œil": pron. rectifiée:  -> 

ou en ignorant la morphologie des mots (l’algo ne prend évidemment pas du tout en compte la graphie des mots) :

(2) INFO: "DLL": pron. rectifiée:  -> 
(2) INFO: "tête-à-queue": pron. rectifiée:  -> 
(2) INFO: "quadrugby": pron. rectifiée:  -> 

(beaucoup de sigles sont dans ce cas) Malheureusement c’est difficile à éviter en appliquant un traitement automatique…

Je ne souhaitais pas, au départ, implémenter un algorithme complet de syllabation, mais à force de multiplier les motifs rectifiés, on doit en être très près… (cf exemple de "pancréatiquement" plus haut : en partant de zéro, le programme a syllabé complètement le mot). Manque notable : le programme préserve les liaisons existantes, mais n’en ajoute pas (par exemple pour "site web", \sit wɛb\ n’est pas rectifié en \si.t‿wɛb\). C’est une restriction volontaire : les lignes de code sont là mais je les ai commentées.

Les rectifications améliorent (le plus souvent) les prononciations, mais aussi elles favorisent leur dédoublonnage, encore plus quand combinées avec la fusion de prononciations.

Pour un mot donné, mon programme tente de fusionner les prononciations (rectifiées) qui sont presque identiques, ceci afin de compacter le résultat et de combiner les informations qui ne seraient pas données avec le même degré de précision dans les diverses prononciations : syllabes, liaisons, indication qu’un H est muet ou aspiré, indication qu’une voyelle est prolongée avec le symbole \ː\ (même si cette indication est désuette en français standard)…

Moins consensuel (mais je fais ce que je veux, na ! ) : on assimile aussi certaines paires de voyelles, \a≃ɑ, o≃ɔ, e≃ɛ\, pour lesquelles on préfère respectivement \ɑ, o, ɛ\. Premièrement car ça m’ennuie d’avoir des prononciations (parfois très longues) dupliquées pour des différences aussi mineures (quasi-allophones), deuxièmement car \ɑ\ et \o\ impliquent de toute façon l’existence de l’autre prononciation (respectivement \a\ et \ɔ\), troisièmement car, à vrai dire, ces \ɔ\ partout m’horripilent ! Pour la paire \e≃ɛ\, quand les deux sont donnés, c’est en général un \ɛ\ qui a tendance à se fermer \e\, et non le contraire, ce pour quoi je préfère \ɛ\.

Il y a plus de 6 000 fusions, qui sont consignées, même si ça intéresse moins les Wiktionnaristes. Exemples de fusions de voyelles :

INFO: "âgé": prons. fusionnées:  > 
INFO: "aigüe": prons. fusionnées (audacieusement):  > 
INFO: "obliger": prons. fusionnées (audacieusement):  < 
INFO: "OK": prons. fusionnées (audacieusement):  <> 

Une des prononciations indique un H muet/aspiré, et l’autre ne le précise pas (dans cette situation, idéalement, le Wiktionnaire devrait être complété) :

INFO: "huis": prons. fusionnées:  > 
INFO: "Hun": prons. fusionnées:  > 

Une des prononciations indique une liaison, et l’autre pas :

INFO: "appel entrant": prons. fusionnées:  < 

Quand les prononciations contiennent toutes deux des indications de syllabes, et qu’aucune n’est plus précise que l’autre, c’est un conflit, on affiche un avertissement (dans cette situation, le Wiktionnaire devrait être harmonisé ; par exemple pour "agnathes" la fusion produit \a.g.nat\ qui est erroné) :

ATTENTION: "âge mental": prons. fusionnées mais conflit de syllabes:  < 
ATTENTION: "agnathes": prons. fusionnées mais conflit de syllabes:  <> 

Plus rare : le programme considère que \ɑ\ et \ː\ sont des infos « riches » ; quand les deux prononciations sont « riches » mais de façon différente, c’est également un conflit signalé (mais je ne pense pas que cette situation soit problématique) :

ATTENTION: "miroir": prons. fusionnées mais conflit de voyelles:  > 
ATTENTION: "vases": prons. fusionnées mais conflit de voyelles:  <> 

Ouf ! Maëlan (discussion) 7 novembre 2023 à 01:36 (UTC)

Haut les cœurs ! Si on inclut les rectifications et fusions, il y a certes beaucoup plus de messages que dans la version précédente du programme… mais ce nombre a été notablement réduit entre les données du 20 août dernier et celles de ce 1^er novembre, grâce à l’effort collectif. (Sachant que, vous je ne sais pas, mais moi je n’ai pas contribué pendant presque 2 mois.) Dans le détail :

• erreurs diverses : 1 345 le 1^er novembre, soit −1 534 par rapport au 20 août ⇒ plus de la moitié a été corrigé
• mauvaises prononciations : 6 405 le 1^er novembre, soit −1 542 par rapport au 20 août ⇒ presque un quart a été corrigé
• rectifications et fusions : 33 236 le 1^er novembre, soit −1 252 par rapport au 20 août

Maëlan (discussion) 7 novembre 2023 à 02:29 (UTC)

Remarque : mon programme ignore certaines catégories grammaticales, donc il ne détecte pas d’éventuelles erreurs dans les mots de ces catégories :

grammar_kinds_ignore = {
    'variante typographique', 'variante par contrainte typographique', 'erreur',
    'lettre', 'symbole', 'symb', 'numéral',
    'racine', 'préfixe', 'préf', 'suffixe', 'infixe', 'interfixe',
    'nom propre', 'nom-pr', 'prénom', 'nom de famille', 'patronyme',
    'phrase', 'locution-phrase', 'locution phrase', 'proverbe',
}

Il ignore également la catégorie « nom scientifique » car je n’ai pas compris si c’était normal qu’on puisse en avoir dans une section « Français ». La catégorie Noms scientifiques en français  n’existe pas. Tous les noms scientifiques sont classés en « Conventions internationales » à l’exception d’une poignée, qui ont été ajoutés ces derniers mois. Maëlan (discussion) 7 novembre 2023 à 02:46 (UTC)

Je n’ai pas tout lu mais, pour les noms scientifiques, j’ai abordé le sujet plusieurs fois, il y a plein de renseignements qui dépendent de la langue (dont le genre grammatical, la prononciation, etc.) Personne ne m’a contredit. Et il y a des sections conv qui devraient très clairement être des sections Français vu leur contenu. Lmaltier (discussion) 7 novembre 2023 à 17:46 (UTC)

Oui, il peut y avoir des sections en français de nom scientifique mais ce sera alors décrit comme des noms (ou locutions nominales), pas comme un « nom scientifique ». C'est pour cela que la catégorie dont il est question juste au-dessus avait été supprimée. Pamputt 7 novembre 2023 à 18:40 (UTC)

Je veux bien mais autant supprimer le type Nom scientifique, dans ce cas… Lmaltier (discussion) 8 novembre 2023 à 13:28 (UTC)

Je ne me prononce pas, mais je m’excuse d’avoir prématurément reclassé certaines nouvelles entrées « Noms scientifiques » de « Français » vers « Conventions internationales », pensant au vu de l’existant que ces raretés étaient des erreurs. Maëlan (discussion) 8 novembre 2023 à 15:00 (UTC)

Eh bien, il se peut que ces reclassements aient conduit à des erreurs. Quand il y a une citation en français, elle doit être mise dans une section Français, de même quand il y a un genre grammatical pour le français (qui peut être différent du genre grammatical en latin scientifique), et de même quand il y a quoi que ce soit propre au français ou à la langue indiquée. Je ne pense pas qu’il y ait beaucoup de prononciations pour les noms scientifiques, mais là aussi, elles dépendent de la langue. Lmaltier (discussion) 8 novembre 2023 à 17:25 (UTC)

Eh bien je vous laisse juger, voici les pages que j’ai modifiées en ce sens : Ophrys apifera, Amorphophallus titanum, Mycoplasma genitalium, Chlamydia trachomatis, Rhopilema, Caenorhabditis elegans, Leymus, Leymus arenarius, Caenorhabditis elegans. Je ne crois pas, cependant, qu’une simple occurrence du mot dans un texte en français en fasse un mot français. Même si, pour les contraintes de la langue hôte, ledit mot s’est vu affublé d’un genre grammatical (qui souvent n’est pas le genre du mot lui-même mais transpire d’un autre mot parfois laissé en ellipse, par exemple « la (méduse) Rhopilema »). Maëlan (discussion) 12 novembre 2023 à 17:57 (UTC)

En principe, ce sont des noms latins, qui ont un genre grammatical latin. Mais ils sont en pratique rarement utilisés en latin, plutôt dans les diverses langues… Oui, l’utilisation d’un mot dans une langue fait qu’il mérite une section pour cette langue, c’est notre principe de base. Lmaltier (discussion) 13 novembre 2023 à 19:45 (UTC)

Mais n’importe quel nom propre et même, n’importe quel mot de n’importe quelle langue peut être cité dans n’importe quelle autre langue ? Maëlan (discussion) 13 novembre 2023 à 20:10 (UTC)

@Maëlan : Je ne parle pas de mots cités, mais de mots utilisés (la différence est fondamentale : dans la phrase Le mot anglais horse signifie cheval , horse est seulement cité, pas utilisé ; dans J’aime le porridge, le mot porridge est réellement utilisé). Oui, de façon générale, n’importe quel nom propre peut être utilisé dans un peu toutes les langues, mais en étant traduit ou au minimum adapté du point de vue de la prononciation. C’est pour ça que nous avons une section française dans Berlin, par exemple, ou des sections de plusieurs langues dans Paris. Il y a très peu de livres qui abordent la question de la prononciation des noms scientifiques, mais il y en a : j’ai un livre sur les poissons australiens qui décrit la prononciation (anglaise) de leurs noms scientifiques. J’avais donné un jour une liste de toutes les sections pour lesquelles les renseignements sur les noms scientifiques dépendent de la langue, il y en a pas mal… Lmaltier (discussion) 14 novembre 2023 à 08:00 (UTC)

Un énorme merci Maëlan pour cette impressionnante mise à jour. Ca fait pas mal de boulot de rectification en perspective mais on pourrait en faire un sujet de collaboration du mois pour espérer voir la liste des problèmes se réduire petit à petit. Ces listes m'ont déjà permis de corriger des erreurs de prononciations et même de mettre à jour des pages qui sont manifestement erronées (utilisation erronée du gadget créer-flexion).

Et merci aussi pour le code, je vais voir si je peux le mettre sur Toolforge pour qu'il s'exécute automatiquement à chaque nouveau dump (JackPotte, Darmo117 ou Lepticed7) pourrait être plus efficace que moi sur ce point).

Enfin, comme tu l'as souligné, il est peut-être temps de reprendre le portage des modèles de flexions vers Lua pour essayer de détecter un certain nombre d'erreurs le plus automatiquement possible. Pamputt 7 novembre 2023 à 18:45 (UTC)

Pour Toolforge, je ne connais pas du tout, pourquoi pas ! Je viens finalement de publier mon nouveau code, incluant les instructions pour l’exécuter. Maëlan (discussion) 8 novembre 2023 à 21:38 (UTC)

Enorme travail, félicitations. Je réalise d'autant plus la quantité de travail que j'avais aussi réalisé quelques cogitations de cette veine (par exemple ici : https://github.com/marxav/wikt_pron/tree/master).

Juste quelques remarques mineures:

• Pour certaines prononciations, un script (ou code informatique) ne peut pas être certain que la prononciation est mauvaise, il peut effectivement seulement indiquer un score de plausibilité, ce qui oblige un humain à vérifier (et encore... suivant les mots, ce n'est pas toujours faisable (par exemple pour moi, impossible de me prononcer sur les prononciations spécifiquement québecoises).
• Pour ce qui est de la syllabation, un mot peut donner lieu à plusieurs syllabations possibles (car il n'y a pas de norme à la fois assez détaillée et qui fasse consensus pour être largement acceptée (du moins à ma connaissance)). Par exemple, "fablab" peut donner ou et je pense que la 1ère est la plus didactique. De même pour beaucoup de sigles (ex: "SSL" peut donner , , ; là encore, pour les sigles, je préfère la première qui est plus didactique). Pas sûr qu'on souhaite automatiser les corrections sans une vérification des propositions de modification par un relecteur humain; D'ailleurs, ça me fait penser que j'avais aussi réalisé un script qui comptait le nombre de syllabations possibles (je ne sais plus où je l'ai sauvegardé): pour les entrées avec un très grand nombre de voyelles, il arrivait à un nombre très grand de possibilités
• J'avais haï le fait que la prononciation soit en doublon en étant dans les modèles en plus d'être déjà dans le tag "pron" de la ligne de forme. Je suis épaté que tu gères ces modèles, c'est un travail vraiment énorme.
• Un détail que je vois aussi : "âge mental" doit donner et non pas si l'on suit la règle de séparation des mots et syllabes de Aide:Prononciation_écrite car il y a un espace entre "âge" et "mental" sans liaison entre les deux.

Marxav (discussion) 15 novembre 2023 à 19:14 (UTC)

Merci ! Oui j’ai déjà regardé avec intérêt ton dépôt wikt_pron. ;-)

Concernant les mauvaises prononciations : absolument, c’est très difficile de décider complètement automatiquement ! Le seuil de score que j’ai fixé pour signaler une prononciation comme « sans doute » erronée signale les 3000 scores les plus élevés du 1er novembre, que j’avais tous examinés manuellement et dont plus des 9/10e contenaient des erreurs. (J’ai vu que dans ton dépôt tu as un calcul de plausabilité.)

Concernant les syllabes : oui en effet, ce sont les limitations que j’ai notées aussi. Malgré tout j’ai choisi de faire ces rectifications quand même car il y a beaucoup de vraies erreurs qui sont ainsi corrigées. Actuellement la syllabation ignore entièrement la graphie ; si jamais (j’aimerais, mais maintenant je compte mon temps) je finis par mettre en correspondance graphie et prononciation (ce que j’appelle « graphémisation », peut-être abusivement, je ne suis pas spécialiste), alors la syllabation pourrait en profiter, ce qui réduirait les défauts que tu mentionnes : en prenant en compte les lettre de sigles, les « e » muets, les espaces, les tirets… En cas de composé soudé par contre il n’y a rien qu’on puisse faire. Maëlan (discussion) 17 novembre 2023 à 21:06 (UTC)

@Maëlan : Oui, la syllabation est parfois aberrante sur le projet. Comme il y a des cas qui ne sont pas évidents, les spécialistes ont établi des règles qui permettent de trancher d’une façon acceptable dans ces cas difficiles. Mais j’ai l’impression que ces "règles" sont appliquées ici par certains de façon aveugle, même dans des cas où la syllabation naturelle est évidente et où les "règles" aboutissent à quelque chose de différent. La syllabation est présente uniquement pour aider les lecteurs à lire plus facilement les prononciations, pas à les perturber en allant contre leur intuition. Quand la syllabation de la prononciation va contre l’écriture du mot (contre les règles qui régissent la césure des mots en fin de ligne, par exemple), c’est qu’il y a quelque chose qui ne va pas. Lmaltier (discussion) 28 novembre 2023 à 07:47 (UTC)

Waouh ! quel boulot !!! Bravo. Même si beaucoup de détails me dépassent, j'en comprends tout l'intérêt, et si un jour (…), je me mets à la phonétique et tout ce genre de choses qui font son, je me plongerai volontiers dans votre travail. En attendant, une idée me vient : serait-il compliqué de créer une version de cet outil en ligne fonctionnant à la demande sur, au maxi, un article, ou peut-être plus idéalement, une section. Typiquement, je crée une nouvelle entrée (article ou section) et je veux la tester du point de vue de… ben, juste ce que sait faire (ce que je pense être) le noyau spécifique de votre programme, donc : tester des incohérences en matière de prononciation ? Je ne suis pas compétent en programmation de ce genre de chose dans ce genre d'environnement, mais il me semble qu'il « ne s'agirait que de » (hum ! pardon si je suis trop naïf) récupérer le cœur d'une boucle qui doit explorer les différents articles du wiktionnaire, et de le mettre dans un dispositif d'interaction simple, genre on lui passe le lien de la zone à tester (via un simple formulaire web ?), plus un bouton radio (tout l'article vs. juste la section pointée) et le bouton de lancement, et, après qu'il a réalisé son diagnostique, le dispositif /sort/ un texte explicite de ce(s) diagnostique(s) (le plus long à faire, probablement) l(es) expliquant et éventuelmt suggérant des remédiations… Ceci dans une version de premier niveau, une "v.1". Une "v.2" pourrait par la suite, permettre de lui indiquer les articles des formes en déclinaison (masculin-féminin ; singulier-pluriel ; etc.) pour qu'il croise son expertise vis-à-vis d'incohérences entre les diverses formes, ce qu'il sait faire, si j'ai bien compris. Mais déjà, la version 1 me semble pouvoir être des plus utiles. Cette idée me semble être complémentaire du travail de systématique que vous avez produit sur la masse des articles qui ont déjà été écrits et livrés dans le wiktionnaire actuel ; l'outil serait orienté vers les participants qui, comme moi, peuvent rajouter de ci, de là, quelques éléments, par ex. leur grain de voix via Lingua Libre, plus du coup une tentative de traduction phonétique…, et quoi qu'il en soit, bien moins "professionnellement" que les « Vrais Wiktionnairistes™ » :-). Alors donc : trop compliqué, ou bien envisageable à moyen terme ? Merci. Et encore une fois, chapeau pour le boulot. -- @Éric38fr (On en cause ?) 4 décembre 2023 à 22:43 (UTC).

@Eric.LEWIN : merci pour ton enthousiasme !

Sur la question technico-informatique : autant je sais programmer, autant les interfaces utilisateurs pratiques, interactives, en ligne, etc. dépassent malheureusement mes compétences (et mon intérêt personnel) ; je peux m’en dépatouiller sur le tas, mais ça coute du temps… Ceci dit, grâce à https://typos.toolforge.org/ dont le code source est public, j’ai maintenant le projet à moyen terme de faire une interface similaire pour mon propre programme, qui permettrait de corriger en lot des potentielles erreurs de prononciation. Finalement, si je fais ça (aucune promesse), une implémentation rudimentaire de ta « v1 » ne demanderait probablement guère plus que d’isoler le corps de la boucle principale, comme tu dis.

Néanmoins quel serait le service rendu par cet outil, employé à la rédaction de nouveau contenu ? Je pense que beaucoup des erreurs signalées pourraient être limitées en améliorant à la source les outils d’édition, ce qui serait plus efficace et plus pratique qu’un vérificateur externe qu’on serait libre d’utiliser ou pas. En effet, actuellement mon programme est surtout spécialisé pour les types d’erreurs suivants :

• mauvais usage des modèles d’accord, et erreurs de prononciations qui en résultent (p.ex. suffixe de prononciation manquant ou en double, mélange graphie/prononciation…) : je projette à court terme (dès que j’aurai du temps) de refondre les modèles d’accord du français, dans le but d’uniformiser et faciliter leur emploi, et de réduire grandement les erreurs d’emploi. En attendant, il y a toujours la prévisualisation… Et les modèles actuels pourraient être patchés (certains l’ont déjà été) pour catégoriser les appels avec paramètres invalides.
• mauvais caractères de prononciation (par exemple \r, c, é\) : j’ai proposé un nouveau modèle qui, tout en facilitant la saisie de caractères de prononciation, empêcherait de saisir des mauvais caractères ; mais ça ne semble pas avoir suscité l’intérêt de la communauté.
• erreurs de prononciation plus arbitraires : dans ce domaine, effectivement, je ne vois pas trop comment les modèles de rédaction pourraient offrir la même fonction sans y mettre une intelligence déraisonnable… Mais la détection actuelle reste assez limitée ; l’arme fatale, c’est la comparaison du début de la graphie avec le début de la prononciation (p.ex. si le mot commence par "p" et que la prononciation commence par \a\, c’est très suspect). On dirait que @Pamputt : a réglé leur compte à la plupart des erreurs trouvées (!), si bien que je projette à court terme d’étendre cette vérification à l’ensemble de la graphie mise en correspondance avec l’ensemble de la prononciation (la « graphémisation » que je mentionne plus haut) ; à ce moment-là, un outil comme tu décris aurait une vraie plus-value.
  • Dans une certaine mesure le programme signale aussi des syllabations douteuses ou absentes ; info à prendre avec des pincettes car il y a pas mal de liberté dans la façon de syllaber, et que mon programme commet beaucoup d’erreurs sur ce point car il ignore la morphologie des mots… une fois que j’aurais ma fameuse « graphémisation », ça sera déjà mieux.
  • Tu parles des extraits audios : attention, mon programme ignore les sections « Prononciation » et en particulier les extraits audios, hélas, car il parait inenvisageable de traiter automatiquement le contenu existant . Ceci dit, on pourrait envisager un outil d’aide pour les nouveaux audios, en supposant qu’on pousse les contributeurs à renseigner le texte prononcé et sa prononciation. Combiné à de la reconnaissance vocale (ce que je ne fais pas et ne sais pas faire du tout, mais @Marxav : en a fait), ça pourrait être assez pratique.

Enfin, garder à l’esprit qu’il ne faut pas prendre la sortie de mon programme pour pain bénit : il signale beaucoup de faux positifs et à l’inverse rate beaucoup d’erreurs.

Concernant ta « v2 » : en fait mon programme actuel vérifie seulement la cohérence interne d’une page (cohérence entre la ligne de forme et le modèle d’accord) ; vérifier la cohérence des infos données entre les pages des diverses flexions d’un même lemme fait partie de mes TODO, c’est de l’ordre du faisable (mais pas si facile : comment trouver la section du lemme d’une flexion donnée, sachant que tous les homographes sont mélangés sur la même page ?) mais ça signalerait tellement de choses que je ne sais pas si ça vaut la peine… Maëlan (discussion) 6 décembre 2023 à 16:08 (UTC)

Vous l’avez peut-être déjà expérimenté, lorsque vous créez pépouse votre entrée, bam, un lien interwiki apparaît direct ! Je perse que les anciens l’ont deviné, il s’agit d’une édition de masse faite par un robot sur l’édition en malgache du Wiktionnaire. Cette pratique est décriée et à déjà été réprimandée en septembre 2020. Sauf que cette année, le bot est relancé de plus belle aidé par une traduction auto assistée par IA, il a déjà près de 2 millions de pages créées et autant de pages modifiées avec un résultat aléatoire. Je n’ai bien évidemment pas vérifié toutes les créations, mais même les mots non patrouillés sont susceptibles de passer à la moulinette. Une entrée que j’ai créée et que j’avais notifié sur la page méta a été relue et corrigée par le dresseur . La page ⴰⵛⵎⴰⵣ a même été importée sans être traduite… mg:ⴰⵛⵎⴰⵣ. Il doit y en avoir bien d’autres puisqu’il est humainement impossible de vérifier l’intégralité des modifications sans une grosse équipe dédiée de patrouilleurs et patrouilleuses que même nous n’avons pas. Otourly (discussion) 7 novembre 2023 à 17:13 (UTC)

Diable ! l’intelligence artificielle est déjà en train de dévorer le travail « manuel » des petites mains du Wiktionnaire.

J’avoue prendre parfois du plaisir à entrer un mot « rare », l’IA semble ignorer cette notion.

mais bon je suis sans doute vieux jeu ou « has-been », il faut privilégier « l’efficacité » !

Basnormand (discussion) 7 novembre 2023 à 17:29 (UTC)

Est ce qu'un contact a été pris avec Jagwar pour essayer de comprendre pourquoi il a relancé son bot ? Pamputt 7 novembre 2023 à 19:06 (UTC)

Pour moi, c’est bien l’avenir, mais uniquement pour ce qu’on est capable de faire correctement de cette façon, et c’est donc très limité. Ce n’est bien sûr pas le cas du wiktionnaire en malgache obtenues par traduction automatique… Lmaltier (discussion) 7 novembre 2023 à 17:51 (UTC)

Face au rythme frénétique de création de certains bots, il me semble que la tâche des patrouilleurs, pas forcément très nombreux, devient difficile.

Il faudra sûrement automatiser la patrouille aussi…

Note : C’est un avis personnel et nullement un jugement de valeur (quoique !)

Basnormand (discussion) 7 novembre 2023 à 19:21 (UTC)

Après, si les machines pouvaient travailler et les humains s’adonner à l’otium, je suis le premier preneur.

Mais la réduction (ou l’abolition, rêvons un peu) du temps de travail ne semble guère à l’ordre du jour.

Paradoxe du « progrès »…

mais je m’égare un peu de notre cher Wiktionnaire.

Basnormand (discussion) 7 novembre 2023 à 19:27 (UTC)

Pour ajouter une petite référence littéraire, un rappel du commandement de la « Bible catholique orange » du roman Dune :

« Tu ne feras point de machine à l’esprit de l’Homme semblable ».

Basnormand (discussion) 7 novembre 2023 à 19:36 (UTC)

Bonjour,

Je trouve que, lorsqu'on atterrit sur une page d'aide telle que Wiktionnaire:Modèles, l'en-tête est très lourd, si bien qu'on ne voit pas le contenu, à première vue (je suis sur un écran 13 pouces). C'est une surprise, et pas une excellente surprise je pense pour l'utilisateur lambda, qui s'attend à voir du contenu en arrivant sur une page, plutôt qu'un modèle encombrant. Le "scrollage" s'impose donc, ce qui impacte l'expérience utilisateur.

Je doute, en outre, que ce bandeau soit très utile : quand on atterrit sur une page "A", c'est parce qu'on cherchait "A", ce n'est pas pour se voir proposer "B", "C" ou "D". L'approche est en quelque sorte promotionnelle.

Je vois plusieurs alternatives : mettre le bandeau en fin de page, ou le retirer pour ne mettre qu'un bandeau d'une ligne, qui redirigerait vers une page qui aiguillera l'utilisateur au bon endroit.

Qu'en pensez-vous ? Automatik (discussion) 19 novembre 2023 à 01:03 (UTC)

+1 --Rapaloux (discussion) 26 novembre 2023 à 15:44 (UTC)

Une autre proposition, encore plus facile à implémenter (sorte de compromis) : rendre ce sommaire d’aide déroulable (et enroulé/caché par défaut). — Automatik (discussion) 1 décembre 2023 à 03:01 (UTC)

Est ce que c'est possible de ne l'enrouler que sur mobile ? Car sur un PC fixe, j'aime bien y avoir accès rapidement, car parfois ça m'aide à trouver la page que je cherche. Pamputt 1 décembre 2023 à 06:52 (UTC)

Sur mobile, le problème est en effet encore plus présent. Je suis sur PC fixe, et obligé de scroller la hauteur de ce sommaire d'aide, qui la plupart du temps ne m'est pas utile. Est-ce utile à d'autres d'avoir ce sommaire présent par défaut ? J'ai tendance à penser qu'il vaut mieux un clic de plus quand on en a réellement besoin, qu'un encombrement par défaut… — Automatik (discussion) 2 décembre 2023 à 20:42 (UTC)

Convaincu. Donc d'accord pour reléguer ce sommaire en bas de la page (ou l'encapsuler dans une fenêtre déroulante enroulée par défaut). Pamputt 4 décembre 2023 à 12:39 (UTC)

J’ai mis en place la boite déroulante (voir WT:Modèles). Pour ceux qui voudraient afficher par défaut la boite, il est toujours possible de le faire an ajoutant à Special:MyPage/Common.js le bout de code suivant :

// Affiche le sommaire d'aide par défaut.
// Ce code est supposé être exécuté avant le gadget MediaWiki:Gadget-NavFrame.js — il semble que ce soit toujours le cas avec ]
(function($) {
	$('body').find('.NavFrame.collapsed.sommaire-aide').removeClass('collapsed');
})(jQuery);

J’espère toutefois qu'il ne sera pas utile à grand-monde, sinon c’est que ce changement n’était pas bienvenu — Automatik (discussion) 27 décembre 2023 à 23:07 (UTC)

Bonjour à toutes et tous ! J’ai créé le compte du Wiktionnaire sur BlueSky histoire qu’on ne se fasse pas prendre le nom. N’étant plus beaucoup actif sur Twitter depuis le rachat, j’envisage bien de l’animer dans ce réseau, et pas seul évidemment. Je me charge de faire la mise en place de la gestion de tout ça, mais si vous voulez d’ors et déjà vous impliquer n’hésitez pas à vous manifester ! :D Lyokoï ^(blablater) 22 novembre 2023 à 17:53 (UTC)

Et évidemment, je ne vous en donne pas le lien… Honte sur moi ! Voici donc le lien : https://bsky.app/profile/wiktionnaire.bsky.social. :D Lyokoï ^(blablater) 23 novembre 2023 à 11:30 (UTC)

Je préfèrerais que les exemples de Wiktionnaire soient plus simples

Les exemples donnés actuellement sont soit tirés de la littérature, soit très techniques. Je trouve que ce sont de beaux exemples pour celui qui connait déjà le mot, mais celui qui est en train de l'apprendre préfèrerait des exemples simples, sans ambiguïtés, et immédiatement compréhensibles. Quelqu'un est de mon avis? YossiPatt (discussion) 26 novembre 2023 à 05:11 (UTC)

+1 --Rapaloux (discussion) 26 novembre 2023 à 06:41 (UTC)

+1 --Bohème (discussion) 26 novembre 2023 à 17:19 (UTC)

On peut trouver des exemples simples tirés de la littérature. C’est vrai qu’à choisir, il vaut mieux des exemples courts et simples que des exemples longs et compliqués. Mais on est parfois obligés de faire avec ce qu’on trouve. En tout cas, je connais un dictionnaire à exemples inventés, bien adaptés au sens indiqué, mais avec ce sens indiqué parfois complètement faux, seulement imaginé. Des exemples d’emploi réels évitent cet écueil et sont donc à privilégier, pour moi. Lmaltier (discussion) 26 novembre 2023 à 17:40 (UTC)

Il m'arrive parfois de mettre des exemples "compliqués" parce que si je prends la seule phrase contenant le mot, l'utilisation n'est pas forcément claire. Le contexte est nécessaire. Mais à choisir le plus simple est le mieux, encore faut-il réussir à en trouver, ce n'est pas toujours évident.

Jpgibert (discussion) 28 novembre 2023 à 08:42 (UTC)

Il ne faut pas hésiter à remplacer une citation très longue par une autre plus simple, c’est mieux pour les lecteurs. Cela m’arrive de mettre une citation longue, et de la remplacer bien après par une autre plus simple. Pour ce qui est du contexte n’appartenant pas à la phrase contenant le mot, c’est parfois utile, mais rarement. En général, l’important est d’illustrer l’emploi du mot lui-même, pas de comprendre précisément pourquoi la phrase a été employée, compte tenu de son contexte : nous ne sommes pas un site littéraire. Lmaltier (discussion) 28 novembre 2023 à 09:01 (UTC)

Oui enfin, parfois il faut que le sens d’un exemple puisse être facilement apréhendable. Et je pense qu’il ne faut pas à tout prix remplacer un exemple par sa lecture du moment, surtout si le sens est moins clair à cause du contexte qui devient absent. Par exemple : Otourly (discussion) 28 novembre 2023 à 20:30 (UTC)

(Bien qu’on soit hors-sujet, je pense que dans l’exemple cité, Lmaltier a voulu (cf. résumé de modif) remplacer une citation traduite de l’anglais par une citation naturellement produite en français. Ca fait sens. Traduttore, traditore.) — Automatik (discussion) 2 décembre 2023 à 22:03 (UTC)

Bonjour à toutes et à tous et merci pour vos engagements respectifs. Contributeur volontairement très éphémère du Wiktionnaire, je suis mal à l'aise avec le formatage des sources et dans ce cas précis aussi indécis concernant le bon endroit pour caser le cirier (artiste) dont le métier se distingue de celui du cirier (artisan). Merci en avance au gentil contributeur qui voudrait bien corriger mes maladresses. Cdlt., Bohème (discussion) 26 novembre 2023 à 17:36 (UTC)

Bonjour @Bohème,

Merci pour votre ajout qui convient tout à fait. Le découpage, la segmentation de la réalité que nous devons faire dans un dictionnaire est une subjectivité moins visible que d'autres. On aurait pu mettre aussi :

1. Artisan, artiste, qui travaille la cire.

2. Vendeur d'objets en cire.

En effet l'activité d'un artiste et d'un artisan est factuellement la même, seuls l'intention et le but diffèrent. Tout autre est l'activité du vendeur. Dans la description actuelle du mot, en groupant l'artisan et le vendeur, l'on met en avant la filière, la corporation de la cire.

Cordialement, Lekselle (discussion) 27 novembre 2023 à 10:44 (UTC)

Oui, ce qui est décrit actuellement ne convient que si la norme est que la même personne vende et fabrique les objets en cire. Mais ce genre de norme évolue avec le temps. J’ai l’impression qu’il serait préférable, actuellement, de séparer les deux sens. Lmaltier (discussion) 28 novembre 2023 à 07:36 (UTC)

Il y a un désaccord sur la section Etymologie de ce mot. Quelqu'un veut bien regarder, s'il vous plaît ? Lekselle (discussion) 28 novembre 2023 à 15:27 (UTC)

L’étymologie cire + -ier me semble assez évidente, et j’ai un Petit Robert qui confirme que ça vient bien de cire. Je modifie donc en conséquence. Lmaltier (discussion) 28 novembre 2023 à 20:16 (UTC)

J’ai une série de citations contenant des noms de sport du genre "para natation", et j’ai l’impression que ce genre d’orthographe est privilégiée dans le cadre de Paris 2024. Mais ce choix me surprend : je préférerais personnellement, de loin, para-natation ou paranatation, orthographes qu’on trouve aussi. Je pense que je vais malgré tout créer les pages correspondantes, avec plusieurs citations à chaque fois, mais je préfère en parler ici avant. Lmaltier (discussion) 28 novembre 2023 à 07:30 (UTC)

para comme apocope de paralympique... ok, il m'a fallu un peu de temps pour comprendre, j'ai parfois le cerveau lent.

Je trouve surprenant de conserver paralympique alors qu'on parle d'handisport qui me semble plus général. Les jeux handilympiques, ça aurait plus de gueule, non ? Jpgibert (discussion) 28 novembre 2023 à 14:15 (UTC)

Je suppose que ça ne vient pas de paralympique, mais que l’origine est la même : le préfixe para-, peut-être lié à paraplégie (c’est en tout cas ce que dit notre page para- pour l’instant, c’est discutable, il faudrait peut-être retirer une section). Mais j’abordais uniquement la question de l’orthographe. Lmaltier (discussion) 28 novembre 2023 à 14:24 (UTC)

Effectivement, ça surprend. Je suppose que l’orthographe du site https://www.paris2024.org/fr/sports-paralympiques/ est calquée sur l’orthographe (anglaise) du site https://www.paralympic.org/cycling, qui utilise les orthographes para canoe, para cycling, etc., quand bien même la seule orthographe définie sur le Wiktionnaire anglophone est l’orthographe en un mot ou avec un trait d’union . — Automatik (discussion) 2 décembre 2023 à 21:59 (UTC)

Je viens de tomber sur cet article et je le trouve bizarrement structuré. Y a que moi que ça gêne de voir des définitions comme informatique ou figuré placées comme sous-partie d’un exemple qui devient un élément introductif ? Jpgibert (discussion) 28 novembre 2023 à 14:31 (UTC)

C’est réglé, j’ai simplifié. Lmaltier (discussion) 28 novembre 2023 à 20:26 (UTC)

Merci Lmaltier. Je pense qu'il faudrait conserver le sens informatique particulier qui, certes, correspond au premier item (couleur grise) mais qui est pensé comme une désactivation d'une fonctionnalité. Quand on me demande de griser un bouton, c'est qu'on ne veut plus pouvoir l'utiliser, pas seulement changer sa couleur. Jpgibert (discussion) 29 novembre 2023 à 09:21 (UTC)

Malgré tout, c’est bien le même sens, et je crois que j’ai adapté la définition qui parlait de colorier en gris, c’était pas assez général. J’ai fait de l’informatique toute ma vie, et je ne vois pas comment "griser" pourrait signifier "désactiver une fonctionnalité". La désactivation peut être une conséquence de l’action, c’est tout. Lmaltier (discussion) 29 novembre 2023 à 12:47 (UTC)

Bonjour, je me candide au poste d'admin, voici la page du vote ÀNCILU ^{(U sìculu)} 29 novembre 2023 à 10:55 (UTC)

Je connaissais le verbe candidater mais pas candider, j'aurai appris un truc... Jpgibert (discussion) 29 novembre 2023 à 12:41 (UTC)

@Jpgibert Etourderie de ma part car en italien on dit 'candidarsi', ce qui m'a induit en erreur :P ÀNCILU ^{(U sìculu)} 29 novembre 2023 à 12:43 (UTC)

Mais du coup, je découvre un verbe, québecois mais existant. sérendipité quand tu nous tiens . Jpgibert (discussion) 29 novembre 2023 à 12:49 (UTC)

Salut,
Je propose la création du lexique du punk, entre les sous-genres et les genres en -core et les différents éléments culturels liés, ça fera un bon paquet d'entrées. ÀNCILU ^{(U sìculu)} 30 novembre 2023 à 13:19 (UTC)