Wiktionnaire:Wikidémie/février 2021

Le dernier numéro des Actualités du Wiktionnaire vient de paraître !

Premières Actualités de 2021 avec un bon lot de brèves et de statistiques, la présentation d’un dictionnaire d’argot du bistrot (mais pas celui de Wikipédia !) et des photos avec un soleil rasant.

Découvrez le numéro 70 de janvier 2021 !

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

Merci aux huit personnes qui ont participé à ce numéro, et notamment Unsui qui poursuit avec assiduité la tenue à jour des statistiques, ce qui est précieux, ainsi que Lmaltier qui propose la présentation d’un dictionnaire ce mois-ci (et déjà pour le mois prochain !). J’ai moins de temps en ce moment pour rédiger des articles dans les Actualités, et j’apprécie de poursuivre ma participation à cette publication grâce aux personnes qui s’y impliquent et en font réellement une publication communautaire. Cette publication existe depuis plus de cinq ans, et je suis très heureux qu’elle se poursuive comme une aventure collective. Alors, n’hésitez pas à proposer également vos mots, vos idées ou découvertes. La revue de presse n’est que meilleure si elle intègre aussi vos pépites Noé 1 février 2021 à 11:04 (UTC)

J’en profite pour suggérer à nouveau de décaler d’un mois le mois cité dans le titre : le numéro de fin février devrait s’appeler le numéro de mars. C’est une tradition absolument systématique pour tous les mensuels, et cela pour une raison toute simple : c’est le mois où le numéro est lu. Un numéro qui paraît fin février est destiné à être lu en mars, c’est donc le numéro de mars. C’est la même chose pour les dictionnaires annuels : l’édition qui paraît fin 2020 est toujours l’édition 2021, car c’est celle destinée à être utilisée en 2021. La façon de faire actuelle est perturbante : on a l’impression d’avoir tous les mois un mois de retard. Lmaltier (discussion) 1 février 2021 à 12:56 (UTC)

Yep, j’ai déjà connaissance de tes arguments, et je préfère la façon de faire actuelle. Je pense que la plupart des gens ne lisent pas les numéros au moment où ils sont publiés, mais peuvent les lire jusqu’à des années plus tard, et il est préférable que les titres correspondent aux périodes qu’ils décrivent. Dans le numéro de janvier, on donne les stats pour janvier, les thèmes de la semaine (et/ou du mois) pour janvier, et les articles parus en janvier. Pour moi, ce serait davantage perturbant que le titre ne corresponde pas au contenu. Nos confrères du RAW publient les numéros avec la date exacte, plutôt qu’avec une période. C’est ainsi le numéro du 1^e février qui vient de paraître. C’est une très bonne option je trouve. Cependant, je n’ai aucune envie de changer la nomenclature des numéros, ni de renommer toutes les anciennes pages pour que ce soit uniforme. Je préfère maintenir la liste homogène Noé 1 février 2021 à 13:18 (UTC)

Oui, mentionner une date précise est aussi une bonne option. Je précise que je ne suggérais pas de changer les noms de tous les numéros passés, je parlais seulement des futurs. Et, dans tous les mensuels, on ne peut parler que de ce qui s’est passé le mois précédant la parution, pas de ce qui va se passer le mois suivant… Nous ne sommes en rien différent des autres mensuels. Lmaltier (discussion) 1 février 2021 à 14:24 (UTC)

Bonjour. Je viens de créer une page accélérationime qui comporte deux fautes. La bonne orthographe est : accélérationnisme. Je ne sais pas comment faire pour le corriger. D'avance, merci. Lekselle (discussion) 3 février 2021 à 13:27 (UTC)

@Lekselle : la page a été déplacé au bon endroit. Pamputt 3 février 2021 à 13:59 (UTC)

Merci @Pamputt :. Mais il reste un n à ajouter. Dans Wikipédia ils ont fait la faute aussi au titre de la page mais dans la notice c'est correct. Lekselle (discussion) 3 février 2021 à 14:58 (UTC)

Problème réglé. Sebleouf (discussion) 3 février 2021 à 18:41 (UTC)

Encore merci ! Lekselle (discussion) 3 février 2021 à 19:30 (UTC)

Bonjour à tous,

En décembre dernier, Lmaltier avait posté un message au sujet de la catégorie en titre de ce message. Je viens de finir de la vider mais il reste deux pages de prise de décision à son sujet qui y sont catégorisées :

• Wiktionnaire:Prise de décision/De l’utilité du paramètre équiv
• Wiktionnaire:Prise de décision/Modèle en remplacement du paramètre équiv

En tant qu’anciennes prises de décision, elles ont été verrouillées à la modification. Or je souhaiterais empêcher la catégorisation de ces deux pages (j’ai toutefois maintenu un lien vers elles) et pour cela il faudrait remplacer les occurrences de type {{m|équiv=blabla}} par leur équivalent visuel ''masculin (équivalent féminin : blabla)'' (masculin (équivalent féminin : blabla)).

Quelqu’un pourrait-il le faire pour moi ? Ce serait top !

Merci par avance Treehill (discussion) 3 février 2021 à 14:28 (UTC)

Pamputt 3 février 2021 à 20:11 (UTC)

Merci Pamputt ! Treehill (discussion) 3 février 2021 à 21:48 (UTC)

@Treehill : Merci d’avoir fini de vider la catégorie de maintenance… Je suggérerais maintenant de modifier les modèles m et f pour que, en cas d’utilisation du paramètre équiv, ils affichent un message explicatif pour dire quoi faire à la place. En effet, il peut se faire que certains contributeurs aient des modèles de pages dans des fichiers sur leur ordinateur personnel, et ce serait bête d’en voir réapparaître à cause de ça. Lmaltier (discussion) 11 février 2021 à 10:11 (UTC)

@Lmaltier : De nada ! Parfaitement d’accord. La fonction devrait être désactivée avec un message explicatif renvoyant au modèle correct. Je ne saurais pas mettre ça en place en revanche … Treehill (discussion) 12 février 2021 à 09:25 (UTC)

Dans le cadre de la mise à jour de l'habillage Vector, un nouveau bouton de sélection des langues est en préparation. Il viendra se placer à droite de la page, sur la même ligne que le titre de l'article.

Sur Wikipédia, cet emplacement n'est pas toujours vide (on y trouve notamment les coordonnées GPS pour les lieux), donc en prévision de l'arrivée de ce nouveau bouton (dans quelques semaines), les éléments s'y trouvant vont être déplacés (dans les heures ou jours à venir) pour prendre place sous la ligne grise de l'entête de l'article.

Sur le Wiktionnaire, il semble que cet emplacement soit généralement inoccupé (hors pages spéciales). A priori vous ne devriez donc pas constater de changement, mais si jamais certaines pages venaient à être affectées par des bogues, n'hésitez pas à me notifier.

Voici les tâches Phabricator correspondantes :

• https://phabricator.wikimedia.org/T263511
• https://phabricator.wikimedia.org/T248761

--DRanville (WMF) (discussion) 4 février 2021 à 14:57 (UTC)

Aidez-nous à traduire dans votre langue

You are humbly invited to participate in the Wiki Loves Folklore 2021 an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the 1st till the 28th of February.

You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and submitting them in this commons contest.

Please support us in translating the project page and a banner message to help us spread the word in your native language.

Kind regards,

Wiki loves Folklore International Team

MediaWiki message delivery (discussion) 6 février 2021 à 13:25 (UTC)

Il paraît que le français a le son API ɲ et le note gn, mais qu’on a tendance à le prononcer plutôt \nj\. Est-ce vrai aussi quand le son est final, dans des mots comme montagne ? N’y connaissant rien en phonétique, j’ai voulu chercher la différence entre les deux prononciations, et je ne l’ai pas trouvée ; j’ai bien trouvé des explications sur Wikipédia, mais pas d’enregistrement.

Pour les personnes qui ne sont pas familières avec cet alphabet, notre annexe Prononciation en français donne le renseignement sous forme de mots simples utilisant le son, mais ça ne m’aide pas dans ce cas particulier.

Ma suggestion : ajouter un enregistrement (ou plusieurs) à chaque article décrivant un symbole API, en veillant particulièrement à sa qualité. Cela peut être le son seul (pour un son voyelle) ou un enregistrement d’un mot simple contenant le son (de préférence un mot français, si possible).

On pourrait aussi faire une page récapitulative par langue, donnant la liste des symboles API utilisés dans cette langue, avec des enregistrements utilisant des mots de la langue (+ aussi des enregistrements de mots français quand le son est utilisé en français, en faisant bien la distinction entre les mots des deux langues).

Je ne sais pas si ce genre de chose existe déjà sur Internet.

Cela serait vraiment utile aux personnes qui ne connaissent pas l’API mais qui veulent s’y mettre. Quand pensez-vous ? Lmaltier (discussion) 6 février 2021 à 17:16 (UTC)

Je précise que je ne suis pas volontaire pour m’en occuper, ce serait à réserver à des personnes très compétentes en phonétique. je suppose qu’il y en a. Lmaltier (discussion) 7 février 2021 à 09:23 (UTC)

Bonjour @Lmaltier :

Le son exsite bien en français, même si, comme certains autres sons ( ou par exemple), il n'est plus produit par tous les locuteurs (en étant remplacé par suivi de ). Pour illustrer la différence entre et , que certains locuteurs font encore, voici deux enregistrements :

• France (Lyon) : écouter « Wikidémie/février 2021  »
• France (Lyon) : écouter « Wikidémie/février 2021  »

J'ai enregistré et ajouté hier une prononciation audio pour presque tous les mots illustrant les sons du français dans l'Annexe:Prononciation/français (j'ai laissé les mots illustrant des sons que je ne produis pas, comme et ).

Je ne sais pas si j'ai bien compris la suite de ton message, mais en tout cas on a déjà une annexe de prononciation pour chaque langue (ex. Annexe:Prononciation/italien, Annexe:Prononciation/anglais, il faudrait bien sûr en créer pour les langues qui n'en ont pas encore une), et lorsque l'on clique sur l'un des symboles API dans les tableaux, le son est joué depuis un fichier Commons correspondant, provenant de travaux universitaires en phonétique.

Les pages pourraient effectivement être améliorées pour mettre plus en avant ces enregistrements qui sont actuellement un peu "cachés".

J'espère t'avoir aidé, à bientôt ! — WikiLucas (🖋️) 7 février 2021 à 14:40 (UTC)

@WikiLucas00 : Merci… Ce que j’appelais de mes vœux existe donc déjà, et je ne le savais pas… J’ai écouté les deux enregistrements ci-dessus. La premier me semble parfaitement normal, le deuxième aussi, et j’ai beau essayer, je n’entends personnellement pas la différence entre les deux sons. Cette différence serait-elle perceptible seulement par certains ? Lmaltier (discussion) 7 février 2021 à 15:36 (UTC)

@Lmaltier : Il est possible que la différence s'entende mal sur mes deux enregistrements ci-dessus pour différentes raisons, mais j'ai bien produit les deux sons différemment au niveau articulatoire. Il faudrait savoir quel son tu produis personnellement lorsque tu dis "baignoire", ou "cagnard" par exemple. Si tu produis naturellement , ça pourrait expliquer pourquoi il t'est difficile de distinguer les deux variantes (surdité phonologique). Dans tous les cas, et sont assez proches acoustiquement, c'est d'ailleurs pour cette raison que le premier tend à remplacer le second sans que ça ne pose trop de problèmes aux locuteurs. — WikiLucas (🖋️) 7 février 2021 à 19:46 (UTC)

Sur le fond, je suis d’accord avec l’invitation de Lmaltier. Il est intéressant d’ajouter des exemples sonores aux pages qui présentent les prononciations des mots, avec des usages à l’initial d’une syllabe, en intervocalique et à la fin d’une syllabe, car des traits peuvent différer selon la position des sons dans un mot. Merci donc à WikiLucas d’en avoir ajouté ! Concernant « j’ai beau essayer, je n’entends personnellement pas la différence entre les deux sons », c’est tout à fait normal. Merci de l’admettre et de le formuler ainsi, c’est une caractéristique de l’oreille humaine de spécialiser sa distinction entre les sons avec son développement. À la naissance, un nouveau né humain peut potentiellement discriminer tous les sons de toutes les langues du monde, puis il apprend à rassembler les sons qui servent à la même chose et à ne plus les discriminer. Par exemple, les différentes façons de faire <r> en français sont confondues. C’est ce même phénomène qui rend plus difficile l’acquisition d’une langue étrangère à l’âge adulte, il faut apprendre à distinguer des sons que l’on confonds Noé 8 février 2021 à 08:39 (UTC)

@Noé : Dans le même genre, si certains pouvaient aller voir Discussion_utilisatrice:Hsarrazin (section sur la page de discussion de Corzé, à propos de l’enregistrement de la prononciation)… J’aimerais bien comprendre. Dans oser (par exemple), j’entends parfaitement le son z, mais dans Corzé, j’entends le son n à la place, et je ne suis pas le seul… Je n’ai jamais étudié la phonétique, mais j’aimerais bien avoir l’explication. Lmaltier (discussion) 25 avril 2021 à 17:18 (UTC)

Je suis allé écouter Corzé, par curiozité (!) et j’entends bien le son z. Voilà mon témoignage, si ça peut servir à quelque chose. Bonne journée.DenisdeShawi (discussion) 25 avril 2021 à 18:43 (UTC)

Salut,

nous avons déjà discuté de l’écriture inclusive ici et là et ça a mené à la création de Annexe:Écriture inclusive en français et de cette page : Utilisateur:Lepticed7/Brouillons/étudiant·e. J’ai pour but de faire accepter la description de telles graphies sur ce projet. Selon vous, quelles sont les conditions à respecter, les points d’ombres à éclairer et les pièges à éviter. Je ne cherche aucunement à lancer un débat sur « Est-ce que c’est du français ? », « Est-ce que ça désavantage les dyslexiques ? » ou n’importe quelle question qui pourrait venir polluer le débat. Il existe des usages, usages que nous décrivons ici. Ma question est de connaitre vos conditions pour l’acceptation de la description de telles graphies. Vous pouvez vous appuyer également sur mon brouillon pour soulever des points qui vous semblent bizarre ou des modifications que vous apporteriez. À +, Lepticed7 (À l’immortalité !) 7 février 2021 à 09:18 (UTC)

Deux points bizarres dans le brouillon :

• il y a des prononciations indiquées, alors que c’est une notation écrite par nature. Les prononciations sont-elles celles utilisées quand on essaie de lire un texte contenant cette notation ? Je ne comprends pas bien à quoi correspondent les dernières prononciations mentionnées (un enregistrement pourrait aider), mais ces prononciations "inclusives" sont-elles réellement utilisées en pratique ? Quelles références pouvons-nous donner pour justifier la mention de ces prononciations ?
• c’est indiqué Nom commun, sans indication de genre grammatical. Pourtant, en français, il faut savoir si un nom commun est masculin ou féminin, ça conditionne l’article à utiliser devant (un ou une, le ou la). Dans la grammaire traditionnelle, le genre inclusif, c’est le genre masculin, mais là ? Cela impliquerait logiquement la création d’un nouveau genre grammatical, et ça paraît difficile que nous le décidions…

Décrire les usages, oui, mais cet usage pose des difficultés de description inédites et qui me semblent difficiles à surmonter… Ce serait plus facile si une grammaire moderne déjà publiée (même si c’était une grammaire militante) résolvait ces problèmes pour nous. Lmaltier (discussion) 7 février 2021 à 10:01 (UTC)

@Lmaltier : Salut, pour la prononciation, j’ai demandé aux différentes personnes que je connais et qui l’utilise. Je ne sais pas si tu sais lire l’API, du coup, pour le singulier, c’est "étudiant ou étudiante", ou "étudian-te" avec un petit arrêt du son entre le "an" et le "te". Kvardek du (d · c · b) m’a dit qu’iel ferait un enregistrement, je ne sais pas si c’est fait. Et le mot est bien prononcé à l’oral, même si ça peut prendre la forme d’une double flexion "étudiants et étudiantes". Concernant le genre, je pense que c’est du neutre, mais je vais tâcher de trouver une grammaire existante. Lepticed7 (À l’immortalité !) 7 février 2021 à 14:18 (UTC)

Pour Éliane Viennot, quand même une référence en la matière, "étudiant·es" est une abréviation et se prononce à l'oral "étudiantes et étudiants". Parce qu'il ne viendrait à l'idée de personne de prononcer "M. & M^me" comme "emm-point-esperluette-emm-emm-euh". (Une référence facile à citer : Éliane Viennot, « Françaises, Français : le langage inclusif n’est pas une nouveauté », dans The Conversation, 15 octobre 2018 ).

S'il s'agit par contre de la création d'un genre neutre, dans la lignée des travaux d'Alpheratz (Genre neutre), c'est différent. Je ne sais pas si on peut l'enregistrer comme du français, mais pourquoi pas. Thomas Linard (discussion) 7 février 2021 à 18:02 (UTC)

C’est vrai, qu’après réflexion, ça ne peut pas vraiment être décrit comme nom commun : c’est seulement une manière abrégée d’écrire étudiant ou étudiante, et étudiant ou étudiante, ce n’est pas un nom commun. La question du genre ne se pose donc pas. Mais quel type grammatical ça pourrait avoir, ça, je ne sais pas. Lmaltier (discussion) 7 février 2021 à 19:14 (UTC)

Je n'y vois qu'une manière abrégée d'écrire. Par conséquent, il me semble pertinent de décrire ce -·e plutôt comme un suffixe signifiant "et + forme féminine" sans nécessairement créé tous les articles correspondant. Ce n'est pas la description d'un genre neutre non plus (contrairement à l'espagnol ou il y a par exemple changement de la terminaison pour créer un neutre, nous accolons ici un masculin et un féminin, mais ce n'est pas un neutre...). Treehill (discussion) 8 février 2021 à 07:02 (UTC)

Oui, l’annexe citée dit bien que ce n’est qu'une manière abrégée d'écrire. La proposition me semblerait un choix raisonnable, d’autant plus si on tient compte de mes réflexions ci-dessous. Lmaltier (discussion) 8 février 2021 à 07:56 (UTC)

Abréviation n’est pas une classe grammaticale. Regardez M. ou Mme. C’est bien noté comme des noms, je ne vois pas pourquoi étudiant·e ne serait pas un nom. Et si vous considérez également la deuxième définition, pour les personnes non-binaires, considérez ça comme une abréviation n’est plus possible. Lepticed7 (À l’immortalité !) 8 février 2021 à 11:28 (UTC)

Treehill ne propose pas Abréviation comme classe grammaticale, mais Suffixe, pour décrire le suffixe (-·e), valable pour plein de noms différents. Et on pourrait aussi décrire les variantes, par exemple -(e). C’est cette proposition qui me semblerait un choix raisonnable, qui règlerait tous les problèmes. Lmaltier (discussion) 10 février 2021 à 17:48 (UTC)

Pour se limiter au problème de la description de la langue, en oubliant tout aspect militant, je propose d’élargir la discussion, et de considérer deux points très importants :

• Variantes de notation :

  L’annexe citée parle de point médian, mais elle cite les différentes notations rencontrées :

  • point médian : étudiant·e
  • tiret : étudiant-es
  • point simple : étudiant.es
  • majuscules : étudiantEs
  • parenthèses : étudiant(e)s
  • barre oblique séparant les mots complets : Cher/Chère

  Quelle sont les notations les plus fréquentes ? Je ne sais pas, mais je parierais bien sur les tirets et les parenthèses, et la notation avec point médian est la plus difficile de toutes à saisir. En tout cas, la notation la plus classique, la plus ancienne, est celle avec les parenthèses.

  Il n’y a absolument aucune raison de privilégier la notation avec le point médian.

• Notations analogues utilisées dans d’autres contextes :

  La notation avec les parenthèses est couramment utilisée dans des contextes tout autres, par exemple avec le préfixe re-, et ceci avec exactement la même idée, le même sens que celui évoqué ici. J’en trouve très souvent quand je cherche des citations pour des verbes. Quelques exemples, avec les préfixes re- et inter- :

  • Halima Ouanada, (Re)penser le féminin, 2020
  • Si la proposition d’une innovation non-standard est séduisante, c’est aussi parce que (re)penser l’innovation n’est peut-être d’ailleurs pas une solution. — (Xavier Pavie, Philosophie critique de l’innovation et de l’innovateur, 2020, page 50)
  • Nous pouvons penser que (re)créer, élargir le sens aujourd’hui des mots exil, desexil, tout en créant le schème desexil de l’exil suppose de (re)considérer ces mots, ces concepts, non comme des définitions fixées dans des dictionnaires, des traditions, des institutions, des champs disciplinaires, des habitus, mais comme des processus de création de concepts (Deleuze) en mouvement, en les situant dans l’histoire, l’espace, dans des rapports de pouvoir contemporains en profonde transformation. — (Marie-Claire Caloz-Tschopp, Valeria Wagner, Marion Brepohl, Vers le desexil, 2020, page 40)
  • Se persuader qu’il est possible de (re)créer du lien social, de la camaraderie, de l’amitié à travers un club… — (Philippe Leroux, Football, planification et entraînement, 2006, page 112)
  • En effet, lorsqu’un individu change de lieu temporairement ou définitivement, de manière volontaire ou forcée, il est appelé consciemment ou inconsciemment à (re)définir, (re)considérer sa position sociale, ses valeurs culturelles, sa vision de l’espace, sa manière de préserver et de transmettre ses valeurs culturelles, d’assumer sa fonction citoyenne, son rôle de développeur, d’agent économique, etc. — (Abdoul Hameth Ba, Dynamiques territoriales, migratoires et (inter)culturelles contemporaines, 2019, page 23)

  Cette pratique me semble nettement plus courante dans la littérature que la pratique avec les (e) ou -e en fin de mot, et est plus fréquente pour certains mots. Faut-il pour autant créer des pages pour (re)créer ou (inter)culturelles ? Personnellement, je ne pense pas, car ce sont de simples façons abrégées d’écrire.

Lmaltier (discussion) 8 février 2021 à 07:56 (UTC)

Salut, je ne peux pas te dire laquelle des notations est la plus utilisée. Je suis d’accord que la plus classique est celle avec les parenthèses, mais je sais aussi qu’elle n’est pas apprécié pour sa symbolique. Tu mets généralement entre parenthèses quelque chose de moins important. Dans le but de démasculiniser le français, ça la fout mal de mettre le féminin entre parenthèses. Mais je ne sais pas dire entre le tiret et le point médian, lequel est le plus utilisé. J’ai l’impression que c’est le point médian pour un raison assez simple : dans les propositions pour une graphie inclusive, le but est que ça soit compris le plus vite possible, or, en utilisant un symbole utilisé ailleurs (tiret, point simple, parenthèse), tu rends possible la confusion avec autre chose. C’est pourquoi le point médian est préféré. Lepticed7 (À l’immortalité !) 8 février 2021 à 11:28 (UTC)

Je n’aurais jamais imaginé cette raison symbolique pour éviter les parenthèses : l’usage des parenthèses est liée uniquement à l’orthographe… À ce compte-là, il faudrait aussi remettre en cause l’ajout d’un e pour former le féminin : ça pourrait être considéré comme infamant pour les hommes, car le mot est moindre pour eux, ou pour les femmes, car le mot utilisé pour elles n’est pas le mot de base… Lmaltier (discussion) 8 février 2021 à 11:42 (UTC)

Le fait que le mot soit le même pour les hommes et pour les femmes apporte aussi des désavantages. Et c’est encore plus visible en anglais, par exemple, où tu dois rajouter un mot pour préciser le genre. Du coup, si tu prends juste "doctor", les préjugés te font tendre vers un homme, là où "nurse" te fait penser à une femme. Du coup, tu peux trouver des "female doctor" et des "male nurse". On a un peu pareil en français avec le mot secrétaire. Perso, je pense de suite à une femme, là où si on me dit PDG, je vois plus facilement un homme. En français, ce problème est soulagé grâce aux accords du déterminant et des adjectifs. Enfin, je sais pas si on peut considérer le féminin comme uniquement dérivé du masculin. Ça peut marcher dans le cas d’ajout d’un -e, mais pas pour d’autres terminaisons (-eur/-rice). Mais même dans les cas avec l’ajout du -e, est-ce que les deux formes (masculine et féminine) n’ont pas toujours existé, dans la plupart des cas ? Et je crois bien que c’est de cette manière qu’on le gère ici ? On ne dit pas que bouchère est le féminin de (flexion de nom commun) boucher. On le considère bien comme un lemme à part. Lepticed7 (À l’immortalité !) 8 février 2021 à 12:00 (UTC)

Remarque annexe : quand on pense que plus de 98% de langues sur terre ne possèdent pas de genres, donc pas d’accords de noms et du même coup pas d’articles, on ne peut que s’étonner qu’ils y aient survécu …— Unsui Discuter 8 février 2021 à 12:26 (UTC)

Pour bouchère : oui, on le traite comme un mot différent. Mais l’étymologie, c’est autre chose : il me semble évident que dans ce cas particulier, comme dans beaucoup d’autres, le mot masculin a existé en premier, et que le mot féminin en dérive. Il y a aussi des cas où c’est l’inverse. Mais nous nous écartons du sujet… Lmaltier (discussion) 8 février 2021 à 14:32 (UTC)

@Lmaltier : « il me semble évident que dans ce cas particulier, comme dans beaucoup d’autres, le mot masculin a existé en premier, et que le mot féminin en dérive. Il y a aussi des cas où c’est l’inverse. » c’est complétement faux. C’est ta vision personnelle de la langue et c’est faux. Arrête avec ça. De nombreuses études en psycholinguistique ont montré qu’il est fort probable que les locuteurs et locutrices natives du français mémorisent les formes au féminin avec leurs règles de transformation pour le masculin plutôt que l’inverse. Et dans bien des cas il s’agit de deux dérivations d’une forme unique. Il est complétement faux de considérer que Trégoroise dérive de Trégorois alors que les deux dérivent de Tréguier Noé 10 février 2021 à 08:01 (UTC)

Je ne parlais pas du tout de mémorisation, mais d’étymologie. Il y a des cas clairs, si. Par exemple, sage-femme a clairement existé en premier, et sage-homme a clairement été construit par adaptation de sage-femme. Pour boucher, c’est plutôt l’inverse, ça me semble évident : le mot bouchère a toujours été extrêmement rare, boucher est apparu en premier, et il est assez évident que les deux mots n’ont pas dérivé de bouc indépendamment l’un de l’autre, mais que bouchère est une adaptation de boucher. Il ne faut pas nier l’évidence. Lmaltier (discussion) 10 février 2021 à 09:35 (UTC)

@Lmaltier : L’évidence n’existe pas sans sources, surtout en étymologie on les gens pensent beaucoup de trucs faux. Soit tu nous sors des sources pour confirmer te propos, soit tu as arrête de croire que tes « évidences » linguistique sont réelles. Ça fait plusieurs fois que tu nous fais le coup à nous sortir des arguments tout moisis en faisant appel à la généralité à partir de tes préjugés sur la langue.
Et pour conclure sur bouchère, le mot féminin est apparu en même temps que le masculin, tout les deux vers 1180 (Source : TLFi). Donc ce n’est pas un bon exemple, surtout que les deux suffixes -ier et -ière sont apparus strictement en même temps en français puisqu’ils préexistaient en latin. Et donc, tout nom de métier formé par un de ces suffixes existent automatiquement avec l’autre genre qu’il soit écrit où non (je te renvois vers des analyses diachroniques sur l’établissement des suffixes dans le vocabulaire français : Précis de morphologie historique du français de Jaqueline Picoche par exemple).
Merci de faire attention à ce que tu dis si tu veux qu’on te crois… Lyokoï ^{(Discutez sur le péril mortel)} 10 février 2021 à 21:55 (UTC)

Vers 1180 : pour le TLFi, c’est pour le mot masculin, sous la forme bochier. Et le TLFi parle de bouc + suffixe -ier. Le TLFI confirme donc ce que je disais, tout au moins pour la forme bochier. Pour boucher, c’est effectivement apparu en premier par rapport à bouchère : voir : https://books.google.com/ngrams/graph?content=boucher%2Cbouch%C3%A8re&year_start=1600&year_end=1800&corpus=19&smoothing=3&direct_url=t1%3B%2Cboucher%3B%2Cc0%3B.t1%3B%2Cbouch%C3%A8re%3B%2Cc0#t1%3B%2Cboucher%3B%2Cc0%3B.t1%3B%2Cbouch%C3%A8re%3B%2Cc0

Je ne parlais pas du suffixe, seulement du mot, pour le suffixe, je n’en sais rien. tout nom de métier formé par un de ces suffixes existe automatiquement avec l’autre genre qu’il soit écrit ou non ?? Si personne n’a jamais utilisé un mot, ni décidé de son existence, ni même pensé au mot, ce mot n’existe pas. Lmaltier (discussion) 11 février 2021 à 07:44 (UTC)

Bouchiere est donné pour fin du 12è siècle d’après le TLFi, c’est équivalent à la même période que pour bochier (j’ai même trouvé le texte sur WS). Et je suis pas sûr de la pertinence d’utiliser Ngram. Il ne fait pas la distinction entre les classes grammaticales, et boucher est aussi un verbe. Lepticed7 (À l’immortalité !) 11 février 2021 à 09:19 (UTC)

Pour le verbe, bonne remarque, je n’y avais pas pensé. Voici l’équivalent pour les pluriels : https://books.google.com/ngrams/graph?content=bouchers%2Cbouch%C3%A8res&year_start=1600&year_end=1800&corpus=19&smoothing=3&direct_url=t1%3B%2Cbouchers%3B%2Cc0%3B.t1%3B%2Cbouch%C3%A8res%3B%2Cc0 Lmaltier (discussion) 11 février 2021 à 09:55 (UTC)

Laisse tomber Ngram, l’OCR des très vieux textes ne fonctionne qu’à moitié, on peut pas se reposer dessus. Et Voici la citation du TLFi pour Bouchère : « fin xiies. bouchiere (Aiol, éd. J. Normand et G. Raynaud, 2730-31); ». Donc vraiment on est au même moment. Lyokoï ^{(Discutez sur le péril mortel)} 11 février 2021 à 12:35 (UTC)

De toute façon, on s’éloigne de la question. Je propose de revenir au sujet initial. Lepticed7 (À l’immortalité !) 11 février 2021 à 14:01 (UTC)

Il faut sortir de la considération militante. C'est très important. Contrairement à l'espagnol ou il y a modification de la terminaison, contrairement aux termes / néologismes (ou reprise d'anciens termes) tels que "iel", on n'a ici qu'un suffixe servant à abréger l'écriture. étudiant·e /étudiant(e) (on ne peut privilégier une ou l'autre ici) n'est pas un nom. Ça s'analyse comme un nom suivit d'une abréviation servant à impliquer l'équivalent féminin. Il ne faut pas avoir pour but de faire accepter ce type de construction militante ici, il faut écouter les arguments linguistiques. Je n'ai rien contre -·e, -(e). Ou alors, devons-nous créer "attent°", "constitut°", "fabricat°", etc. ? C'est à ce type de point qu'il faut réfléchir. Treehill (discussion) 8 février 2021 à 22:32 (UTC)

Oui, on devrait créer atten°, constitu° et fabrica° car ce sont des formes assez courantes pour écrire ces mots. Et donc, oui, on doit considérer ces graphies dites « inclusives » car 1. elles sont attestées dans des contextes dont on peut écarter l’erreur, 2. elle pose question à beaucoup de gens et nous nous devons d’apporter une réponse.

Néanmoins, comme elles ont toutes les mêmes rôles (inclure visuellement tous les gens), je me demande si on devrait pas créer une sorte de boîte de flexion qui indiquerai systématiquement la graphie inclusive tout en renvoyant vers une annexe expliquant plus en détail les usages et la signification… Lyokoï ^{(Discutez sur le péril mortel)} 10 février 2021 à 21:55 (UTC)

@Treehill et @Lmaltier : Je ne suis pas certain que l’on puisse considérer ça comme un suffixe, ou du moins que le considérer uniquement en tant que tel suffise. Sur le brouillon que j’ai fourni, la deuxième définition ne peut pas être décomposée en « étudiant ou étudiante ». Il ne s’agit plus d’une abréviation que l’on peut développer (dans le sens mathématique). Lepticed7 (À l’immortalité !) 11 février 2021 à 14:01 (UTC)

Et toutes les autres variantes de cette notation aussi, donc ? Et aussi les verbes (re)créer, etc.> (qui, eux, au moins, n’ont pas le problème d’indication du genre grammatical) ? Lmaltier (discussion) 11 février 2021 à 14:10 (UTC)

@Lyokoï : Si on inclut cela dans un tableau, je me permets de te corriger : "on devrait pas créer une sorte de boîte de flexion qui indiquerai systématiquement les graphies inclusives tout en renvoyant vers une annexe". Il faut par ailleurs noter que :

• tout n’est pas que inclusifs, les participes passés en -é(e)s par exemple, je les utilisais avant même tout ces débats (et je ne suis pas le seul), par pure fainéantise dans mes notes persos. modif après avoir lu le message de Lmaltier : si on inclut les graphies inclusives, il faut bien sûr penser à tous ces cas de (re)-, terminaisons verbales, -(s) pour les cas où il s’agit de distinguer le singulier du pluriel dans une même phrase, etc.
• si on les inclut, il ne faut pas oublier le rôle de la perception. On devrait parler ici de "graphies perçues comme inclusives" car 1. pour certain réduire le genre féminin à un -·e à la fin du masculin c’est tout autant "peu flatteur" que d'utiliser la parenthèse dont parlait Lepticed7 plus haut (après tout, pour considérer vraiment tous les genres, ne devrions nous pas les écrire tous de manière pleine et entière ?). 2. il faut bien préciser cette perception est nuancée : -(e) est une graphie perçue comme inclusive parfois perçu comme péjorative …

@Lepticed7 : Je ne vois pas en quoi ça ne peut pas être un suffixe. Au contraire, c’est même le seul des deux cas où j’ai l’impression que ce n’est pas seulement une abréviation (sens n° 1 qui abrège la forme "étudiant et/ou étudiante") mais également porteur d'un sens puisqu’il s’étendrait aux personnes non-binaire.

Quant au genre, vu qu’en grammaire française, le "masculin" est le genre du neutre (non binaire, mais aussi masculin), et qu'on a le féminin (féminin) le modèle à appliquer est simple {{mf}}. Treehill (discussion) 11 février 2021 à 14:34 (UTC)

Effectivement, dans le deuxième cas, c’est un suffixe, mais pas une abréviation. Toujours est-il que nous ne contentons pas de décrire uniquement les suffixes, mais également les mots utilisant ces suffixes. Je ne vois pas pourquoi ces pages n’auraient pas leur place. Lepticed7 (À l’immortalité !) 12 février 2021 à 13:55 (UTC)

@Lepticed7 : ce que je dis plus haut -> ce n'est pas que je suis pour ou contre, je veux simplement insister sur le fait que le Wiktionnaire n'est pas militant mais un dictionnaire. Il doit donc se baser sur la grammaire et pas sur des considérations politiques. La question de l'ajout des formes en ...·e ne peut et ne doit donc absolument pas être distinct ni privilégiée par rapport aux questions de l'ajout des formes en ...(e), ….e en (re)..., en (dé)..., en ...é(e)s, ...(s), ...°, etc. C'est un package (je ne suis absolument pas d'accord avec le titre de cette discussion par exemple, qui devrait être « Sous quelles modalités pourrait-on décrire les graphies abrégées (point médian, point, parenthèses, entre autres) »). Il ne faut donc pas inventer des choses qui n'existent pas en grammaire française non plus (ci-dessus, ma remarque sur la question abordée plus haut du genre à donner, qui est en fait très simple).

Enfin j'insiste sur les questions de perception. Ce qui est une graphie inclusive pour certains, ne l'est pas pour d'autres. Si nous acceptons toutes la ribambelle d'abréviation que je liste en début de message, celles étant considérée comme partie de la graphie inclusive ne doivent pas être présentée comme « Graphie inclusive de étudiant et/ou étudiante » mais comme « Graphie perçue comme inclusive de étudiant et/ou étudiante » (ou « ... considérée ... ») avec en en-tête la mention appropriée du lexique sur le militantisme. Il faut être complet, mais il faut l'être avec justesse. Treehill (discussion) 12 février 2021 à 14:40 (UTC)

(après conflit de modification, je ne retouche pas, même si ça recouvre en partie ce que dit Treehill) Pourquoi ? Je repose la question : et pour les cas du genre (re)créer (c’est strictement le même genre de procédé, et réalisé avec le même but : écrire deux mots séparés par "ou" en un seul mot pour abréger) : faudrait-il créer des pages pour ces "verbes" (et toutes les formes conjugués qui vont avec) ? Faudrait-il créer des pages avec toutes les variantes genre étudiant-e-s, étudiantEs, étudiant(s), étudiant(e)s ou étudiant(e) ? Faut-il créer des pages du genre né(e), soussigné(e) et autorisé(e) parce qu’on rencontre Je, soussigné(e), étant autorisé(e) par l'Association dentaire canadienne à subir… ? Un autre exemple d’abréviation, un peu moins proche : faudrait-il créer des pages du genre à ses risques & périls pour la raison qu’on rencontre la locution écrite sous cette forme ? Faudrait-il décrire tous les mots en -tion sous une forme genre constitu° dès l’instant qu’on les rencontre écrits ainsi ? Ou encore faudrait-il inclure tous les nombres ordinaux écrits en chiffres suivis de ^e, par exemple 123^e ? Mon impression très nette, c’est qu’il y a un point commun à tous ces exemples : ce sont toutes des façons abrégées d’écrire, des procédés systématiquement utilisables partout où ils ont un sens. Je suis tout à fait partisan d’inclure les abréviations classiques du genre km ou M^me parce que c’est utile, ce sont des abréviations particulières, mais là, c’est autre chose : on pourrait vite se retrouver avec une grande majorité des pages consacrées à ça, je suppose que ce n’est pas le but. 12 février 2021 à 15:06 (UTC)

S’il s’agit d’une abréviation, tu peux la développer. Toutefois, comment tu développes "les étudiant·es non-binaires" ? Lepticed7 (À l’immortalité !) 12 février 2021 à 16:47 (UTC)

les étudiants ou étudiantes non binaires ou les étudiants / étudiantes non binaires (ou bien les étudiants non binaires, quand on applique les règles traditionnelles du français), je suppose… Lmaltier (discussion) 12 février 2021 à 16:57 (UTC)

 Donc tu inscris dans la binarité les gens qui ne le sont pas. C’est bien pour ça que le point médian est plus que juste un (re)créer. C’est que ça fait un pas vers une solution qui n’est pas que par pure faignantise. Lepticed7 (À l’immortalité !) 12 février 2021 à 17:04 (UTC)

Dans ce cas, il suffit d'écrire les étudiants et étudiantes binaires ou non. Ça reste une abréviation aussi. Treehill (discussion) 12 février 2021 à 17:10 (UTC)

Le truc, c’est que tu ne cibles plus que les étudiant·es non-binaires. Mais bon, passons. J’ai pas envie de rester longtemps là-dessus. Je vais abandonner l’idée de description pour le moment, j’ai du travail sur les conjugaisons et l’espéranto. En tout cas, Lmaltier et Treehill, merci d’avoir pris le temps de discuter. Bonne soirée Lepticed7 (À l’immortalité !) 12 février 2021 à 17:38 (UTC)

Pour ma part, aucune envie de contribuer à ce type de graphie. Le système d'écriture du français est déjà un des plus compliqués au monde, je n'ai pas envie de contribuer à la normalisation d'une surcouche. Il faut se mettre aussi à la place de ceux qui apprennent l'écriture ; si on augmente encore le nombre de possibilité d'encoder un mot, comment s'en sortiront-ils sans l'assistance permanente d'un logiciel informatique ? Sans compter, que côté décodage, je trouve ça ralentit ma lecture, et je pense que ça devrait être le cas pour beaucoup de lecteurs (étant donné qu'il y a plus de caractères à lire). Marxav (discussion) 12 février 2021 à 20:12 (UTC)

Je lis ci-dessus, que le Wiktionnaire n'est pas militant mais un dictionnaire. Il doit donc se baser sur la grammaire et pas sur des considérations politiques. Je pense être largement avec la pétition de principe sous-jacente. Je tiens cependant à apporter quelques nuances sur ce sujet. D’abord, ça me paraîtrait fort naïf de croire qu’une grammaire, quelle quelle soit, soit exempt d’enjeux politiques et immaculés de tout présupposition intégrant des biais culturels. Sur ce plan, le Wikitionnaire n’est pas du tout neutre :

• les mots sont, en générales, supposés groupables de manière à ce que seul le terme désigné comme lemme se voit « honoré » de descriptions lexicologiques. Les autres « simples flexions » se voyant relégué au mieux à une page de renvoie au sacro-saint lemme. C'est pour une part lié à des considérations de traditions culturelles, à la suite de la tradition des dictionnaire papier qui ont pour leur part d’autres contraintes que celle du Wiktionnaire en terme d’espace. C’est aussi lié en partie aux choix techniques : la manière dont nous structurons les données ne favorise pas la réutilisation de définition entre les lexies. Je vois qu’il y a eu un appel à échanger sur ce point en février, je n'ai pas encore lu les échanges : je contribuai potentiellement sur le sujet prochainement, et je ne développerai donc pas plus avant ce point ici.
• la catégorisation des mots que nous employons relève de thèses linguistiques. Il serait bon de garder à l’esprit que les locutaires d’une langue n’ont pas besoin d’avoir une théorie grammaticale de leur langue pour la pratiquer efficacement en tant qu’outil de communication. Toute amplement diffusées puissent être au sein de ses locuteurs actuelles, des catégorisation comme adjectif/nom/verbe ou féminin/masculin sont des cadres conceptuels qui ne sont pas des préalable à l’avènement des pratiques. Et d’ailleurs, il est clair que toute catégorisation a ses limites. Ce qui fonctionne plus ou moins bien pour décrire grammaticalement les usages du français ne suffira pas pour d’autres langues, voir pourrait se révéler totalement inepte.

Voilà, ces nuances étant explicitées, je tiens à rappeler mon propos initiale, qui est que globalement, je suis d’accord, nous visons une certaine forme de neutralité descriptive des usages. Ça n’empêche que nous somme pas ailleurs des humains pris dans un contexte économico-culturo-hitorio-linguistico-sociologique, avec nos imperfections, nos biais, nos préjugés, etc. --Psychoslave (discussion) 3 mars 2021 à 09:48 (UTC)

Donc, pour ma part j’aime bien la proposition d’élargir le champ de réflexion proposé ci-dessus. À mon sens, le Wiktionnaire à vocation à être un outil qui sert les personnes qui le consulte pour comprendre le sens des termes qu’il rencontre en pratique dans leur vie. Cela veut dire qu’à minima, si quelqu’un trouve un terme dans une graphie quelconque quelque part, en recopiant cette graphie dans le moteur de recherche du Wiktionnaire, il devrait pouvoir trouver un article qui l’éclairera sur les connaissances lexicologiques qui y sont rattachable. Notons que dans l’absolue, ça ne doit pas nécessairement passer par une création d’article : le moteur de recherche pourrait aussi être peaufiné pour rajouter du liant. Enfin en pratique, ça paraît toujours plus intéressant d’avoir une solution qui présente une entrée complète et cohérente pour toute graphie recherchée, sans avoir à passer par un ou plusieurs renvoies.

De fait, je serais donc favorable à l’introduction d’articles comme atten°, constitu° et fabrica° – pour peut qu’il y ai au moins une attestation pour les documenter. Pour ma part, je n’utilise pas ces notations sur les supports numériques, éventuellement lors de sessions papier/stylo, et d’ailleurs je n’ai pas souvenir de les avoir jamais croisé autrement que sur une écriture stylographié. De plus, pour ma part je les aurais plutôt transcrit avec un o en exposant, comme atten^o'. Ici j’utilise du HTML pour la mise en exposant, mais il existe aussi un point unicode pour toutes les lettres de l'alphabet latin en exposant, il me semble. Le point important ici, c’est qu’une même graphie qui n’est pas nativement numérique, ne sera pas nécessairement retranscrite numériquement de la même manière selon les personnes (et encore, je met ici de côté les problèmes d’encodage).

J’en profite pour aussi amener la problématique de la documentation de termes issus de langage de programmation. Comme moult domaine métier, l’informatique regorge d’acronymes et abbréviation en tout genre. Par exemple ptr, (confère le Wiktionary ) est un terme courant. Et au delà de ça, il y a la problématique des notations spécifiques. Dans le langage C par exemple, un terme comme *ptr est tout à fait courant, de même que **args, et à une sémantique clairement définie. Cela étant, ça ne veut pas dire qu’il y a une manière de les prononcer vraiment standard, d’autant que pour ce qui concerne la francophonie, le franglais abonde dans le milieu.

Voila pour une synthèse des idées que la lecture de vos commentaires m’ont inspiré. Au plaisir de lire vos retours donc. --Psychoslave (discussion) 3 mars 2021 à 09:48 (UTC)

Bonjour, À l'instar de ce qui figure sur la page Trégorrois, une Trégorroise est aussi bien une habitante de Tréguier (Landregeriadez en breton) que du Trégor (Tregeriadez en breton). Salutations.--2A01:CB08:8BB7:F100:C146:3481:6461:C4D4 7 février 2021 à 14:04 (UTC)

J’ai complété. Oui, le mot est différent en breton pour les deux cas, mais est bien le même en français (même étymologie). Lmaltier (discussion) 7 février 2021 à 15:50 (UTC)

??????????--2A01:CB08:8BB7:F100:FCB3:753A:B344:8C90 7 février 2021 à 15:53 (UTC)

L'histoire retiendra que "?????????" veut sans doute aussi dire "mersi bras dec'h Lmaltier", "grand merci à vous Lmaltier" en langue trégorroise ;-) Marxav (discussion) 11 février 2021 à 19:53 (UTC)

Also found here on frwiki at Special:Contributions/88.148.212.79, initial discussion is at sv:Wiktionary:BB#Problemtyp_med_många_IP --62.98.98.150 10 février 2021 à 06:32 (UTC)

Bien le bonjour,

Nous avons un page qui permet de recenser les mots à créer (j’ignore où elle est, mais je sais qu’elle existe). A-t-on le même genre de chose pour les thésaurus et autres lexiques ?

Je pose la question parce qu’on nous a demandé ces jours-ci si on avait des mots en relation avec la poterie. Je n’ai pas trouvé de thésaurus ni de lexique. Quand ce genre de demande passe, ne serait-il pas intéressant de se noter dans un coin qu’une demande existe ?

Jpgibert (discussion) 10 février 2021 à 07:25 (UTC)

Pour les potentialités et les incitations à contribuer, le Wiktionnaire a des projets : Projet:Thésaurus et Projet:Lexiques Noé 10 février 2021 à 07:56 (UTC)

(Pas sûr que ce soit ici le bon endroit pour mettre cette note d'attention, et que ce ne soit pas à remonter vers Meta… Mais c'est sur le Wiktionnaire que j'utilise cet habillage, parce que c'est "ici" (dans la Wiktionnaire) que je l'y ai vu recommandé, juste ici que je l'utilise, et que je trouve effectivement que ça lui va bien. Vérifions d'abord, si vous voulez bien m'y aider, la véracité ou l'objectivité de mon observation. Donc Timeless, très bien, sauf que...)
  Sauf que, quand j'utilise un sommaire, pour aller plus loin sur une longue page (comme celles de la wikidémie :-)), le déplacement est toujours un poil trop important, et le titre cliqué dans le sommaire, se retrouve systématiquement juste caché par la ligne-palette fixe du haut de fenêtre (soulignée par un trait rouge), comme si l'ancre elle-même se situait à la ligne en dessous du titre de la section visée. Je note qu'avec l'habillage Vector, je n'ai pas cet effet. Par contre, cela met, selon moi, en évidence que c'est la ligne-palette fixe introduite par l'habillage Timeless(*), qui masque le haut de la zone de page affiché dans la fenêtre, le titre de section visé étant bien placé à ce niveau de la fenêtre, et non en haut de la zone “scrolable” (pardon) visible. Bref, pas vraiment un bug de l'ancrage en lui-même, mais une opposition de fonctionnalité entre l'effet de l'ancrage et la présence de la ligne-palette fixe. Question 0) : suis-je clair ? Question 1) : voyez-vous le même effet (actuellement, je suis sous le navigateur "Safari", version 14.0.1 sous macOS v.10.15.7).
  (*) Timeless, habillage que j'apprécie particulièrement, je viens de m'en rendre compte après mes essais à repasser à Vector pour vérifier mon observation ici décrite. De ce fait, si ce "bug" pouvait être corrigé, il en deviendrait… parfait :-). Cordialement. --@Éric38fr (On en cause ?) 10 février 2021 à 12:59 (UTC).

Salut Éric, j'ai trouvé cette page dédiée à Timeless : en bas de l'infobox se trouve un bouton "signaler un bogue" qui permet de déposer une tâche sur Phabricator pour que les développeurs qui maintiennent l'habillage puissent régler le problème.

Je vais aussi signaler ce problème à l'équipe qui est en train de mettre à jour Vector, puisqu'il se trouve qu'il est également prévu d'y introduire là aussi un entête figé, qui risque d'avoir le même type de conséquences. --DRanville (WMF) (discussion) 11 février 2021 à 13:13 (UTC)

Dans les pages de français, on trouve une section Traductions avec des traductions en rouge (pages encore inexistantes). Si les traductions sont indiquées elles sont censées être exactes (ou alors il y a un vrai problème de crédibilité). Alors, partant du principe que le Wiktionnaire est un dictionnaire auquel on peut se fier, pourquoi ne pas créer automatiquement les pages de traductions ? Ça permettrait d’ailleurs l’interwiki, et donc l’intérêt éventuel de contributeurs étrangers, d’une façon générale, mais aussi pour améliorer les pages, préciser les sens et les emplois, rectifier les erreurs en connaissance de cause, etc. L’interwiki permettrait aussi l’accès aux mêmes pages des wiks étrangers et donc permettrait une amélioration des pages françaises.
On pourrait donc se limiter à créer automatiquement les pages de traduction uniquement lorsqu’un interwiki existe, au départ. Et on peut le faire par étape, par langue par exemple…--Rapaloux (discussion) 11 février 2021 à 13:04 (UTC)

Salut, je suis moyen chaud en ayant connaissance du processus de patrouille. De nombreuses fois, je valide parce que ça n’a pas l’air d’un vandalisme, sans être sûr de la véracité de l’info. De plus, de nombreuses fois, les traductions sont rajoutées par import des pages des wikipédias, qui n’alignent pas nécessairement leurs concepts. Enfin, il arrive souvent qu’un unique bloc de traductions existe alors qu’il y a plusieurs définitions. Bien que le principe soit cool, nos pages contiennent beaucoup trop d’incertitudes pour faire ça. Lepticed7 (À l’immortalité !) 11 février 2021 à 13:57 (UTC)

Pages de traduction ? Il n’y a pas de pages de traduction. Mais j’ai bien compris qu’il s’agissait de la page décrivant le mot donné en tant que traduction avec un lien rouge. La question a déjà été soulevée. Le problème, c’est que c’est théoriquement impossible : quelle définition mettre ? Je suppose que l’idée est de mettre le mot français traduit en tant que définition, mais ça ne marche pas à tous les coups, loin de là… Une définition doit permettre de comprendre le mot, et seul un être humain peut en juger. On peut par exemple se retrouver avec une page d’un mot non français qui a plusieurs sens, et se retrouver avec, comme seule définition (et qui correspond peut-être au sens le plus rare du mot non français), un simple mot français (pas forcément dans son sens courant). Une page comme ça, c’est pire qu’un lien rouge, parce que c’est extrêmement trompeur.

Malgré tout, le wiktionnaire anglophone s’y était essayé, en prenant beaucoup de précautions. Je ne sais plus toutes les précautions prises, mais je me rappelle que, si on prend l’exemple d’un mot anglais traduit en français, le robot allait consulter le wiktionnaire francophone (je ne sais plus précisément pour y chercher quoi). Il y avait aussi un message d’avertissement dans la page créée, et cette page était mise dans une catégorie de maintenance spéciale (à vider manuellement après retouche de la page créée). Quand cette catégorie de maintenance atteignait une certaine taille, les créations étaient stoppées, pour laisser aux contributeurs le temps de la vider, et qu’ils ne soient pas submergés par le travail. J’ai l’impression que l’expérience n’a pas été concluante et qu’ils ont laissé tomber depuis longtemps.

Mais on peut bien sûr aller voir les autres wiktionnaires pour trouver des mots à créer ici, bien sûr. Lmaltier (discussion) 11 février 2021 à 14:04 (UTC)

Perso je suis contre, ça ressemble un peu trop aux créations (traductions) dans le Wiktionnaire malgache et ce qu’il s’est passé en scots. Si c’est pour faire du chiffre, ce n’est pas pertinent à mon sens car le fait est que ce sera une énième catégorie technique à contrôler, que ça prendra du temps et qu'il faudra des personnes pour la vider et que pendant ce temps, l’entrée existera (et un bandeau n’empêchera quelqu’un de se dire que "ça doit être juste"). Si on ajoute à cela le fait qu’un terme peut avoir plusieurs sens bien différents en fonction des langues ou à l’inverse qu'un terme à un sens plus spécialisé dans une langue cible mais qu'il fait partie des ’traductions’, ça me semble trop difficilement gérable. Treehill (discussion) 11 février 2021 à 15:26 (UTC)

Sans l'inclure au Wiktionnaire, ça serait un truc intéressant à prototyper pour regarder les résultats et les comparer avec ce qui existe actuellement dans le Wiktionnaire. D'ailleurs, ça me fait penser au site qaz.wiki qui fonctionne très bien sur la traduction - probablement automatique - d'articles du Wikipedia anglais vers 15 autres langues. Pour ce qui est de "juste" traduire un mot, j'imagine que ça devrait maintenant pouvoir fonctionner (au moins pour certaisn mots) avec l'avènement de techniques comme https://en.wikipedia.orghttps://dictious.com/fr/Transformer_(machine_learning_model), typiquement en simplifiant énormément, ces algos pourraient chercher dans une requête Q (définition du mot + citations), si on prend une clé K (mot) alors quelle est la valeur V (mot en autre langue) qui est le plus proche statistiquement. Sur des mots courants dans des langues où beaucoup de textes sont disponibles et pourraient nourrir cet algo, ça devrait fonctionner. Sur des mots plus rares, ou sur des langues moins documentées, ça ne fonctionnerait sans doute pas, mais bon, y'aurait peut-être moyen d'associer des scores de confiance quant à la traduction de chaque mot; ça aiderait à identifier les mots qui valent le plus la peine d'être traduits... enfin s'ils sont traduisibles ! Marxav (discussion) 11 février 2021 à 16:44 (UTC)

Oui, pour traduire, il y a eu de gros progrès. Mais là, il ne s’agit pas de traduire un texte, il s’agit de donner une définition à un mot. Ou alors est-ce que l’idée serait de traduire automatiquement la définition de l’autre wiktionnaire ? Lmaltier (discussion) 11 février 2021 à 18:00 (UTC)

l'un ou l'autre. c.f. par exemple ce site qui crée des mots en langue anglaise qui n'existent pas mais qui sont crédibles et surtout qui donne leur définition : https://www.thisworddoesnotexist.com Marxav (discussion) 11 février 2021 à 19:48 (UTC)

Je ne comprends pas la réponse : il ne s’agit pas là de traductions… Traduire automatiquement la définition donnée dans un autre wiktionnaire, ce ne serait pas évident, et je ne suis pas que ce serait une bonne idée. Lmaltier (discussion) 12 février 2021 à 19:43 (UTC)

Pour moi, l’un des problèmes de mettre des traductions, c’est que ça fait de nous un dictionnaire de traductions. Je veux pas un dictionnaire français-espéranto. Je veux un dictionnaire qui m’explique en français les mots en espéranto. Nous avons énormément d’entrées dans les langues autres que le français qui se contentent de mettre un mot vers la notion en français, et après, démerde toi pour trouver quelle définition en français il faut regarder. Pour l’anglais, on peut comparer la page rack avant et après mon passage. Pour l’espéranto, bufro ou kreski. On a trop de pages avec un mot et c’est tout. Je préfèrerai qu’on en génère pas des milliers d’autres. Lepticed7 (À l’immortalité !) 13 février 2021 à 09:49 (UTC)

Tout à fait. Même s’il y a des cas particuliers où un seul mot peut suffire, par exemple psychoanalyst. Lmaltier (discussion) 13 février 2021 à 13:59 (UTC)

Bonjour, en tant qu’utilisateur, je préfère tomber sur un lien me disant "désolé, on n’a pas", plutôt que sur une page qui ne me sert à rien ou, pire, qui m’induit en erreur. La confiance s’acquiert chèrement, mais la perte de confiance débaroule très vite. D’autant que si une page existe dans le wikitionnaire d’origine, on peut y accéder depuis la traduction. Jpgibert (discussion) 15 février 2021 à 07:29 (UTC)

Nous venons de dépasser les 37000 entrées dans la catégorie. Si on y ajoute les locutions verbales, on arrive à 45028, à comparer avec les 44,106 entrées pour les verbes anglais (et locutions verbales) dans le wiktionnaire anglophone.

Je ne pense pas que d’autres dictionnaires fassent mieux. Merci à ceux qui ont contribué à remplir cette catégorie. Je pense qu'il est réaliste de viser les 40000 d’ici un an ou deux… Lmaltier (discussion) 13 février 2021 à 14:03 (UTC)

C’est impressionnant. Merci pour tout le travail que tu effectues sur ce sujet Lmaltier Pamputt 13 février 2021 à 18:02 (UTC)

Salut,

je ne l’ai pas encore codé, mais ça me semble intéressant. Que pensez vous d’un modèle à mettre en section Voir aussi qui récupèrerai tous les liens existants vers les autres projets depuis Wikidata. La syntaxe pourrait être quelque chose comme {{Liens projets|Q84|fr}} avec le code de l’élément wikidata et le code de langue de la section. Cela permettrait d’avoir une liaison vers les autres projets qui se met à jour avec l’élément wikidata, vu qu’on ne peut pas proposer de telle chose, nos entrées n’étant pas sur wikidata. Lepticed7 (À l’immortalité !) 17 février 2021 à 09:42 (UTC)

Je ne comprends pas bien, nous définissons des mots et pas des concepts, tandis que les liens seraient depuis des concepts définis dans Wikidata, c’est ça ? Pour un mot ayant une dizaine de définitions, comment est-ce que le modèle pourrait fonctionner ? Noé 17 février 2021 à 10:30 (UTC)

La définition des mots n’empêche pas qu’on a des liens vers les pages Wikipédia, Wikisource, etc. Le but est d’automatiser en utilisant l’élément wikidata. Lepticed7 (À l’immortalité !) 17 février 2021 à 11:59 (UTC)

L’énorme problème que je vois, le problème rédhibitoire, c’est que ça devient totalement illisible par les contributeurs : Q84, qui comprend ça ? Les contributeurs du Wiktionnaire ne doivent pas être obligés de se plonger dans Wikidata. Il me semble que ça marche pas mal comme ça et que, même si une page de Wikipédia est renommée, il reste en principe une redirection qui permet de s’en sortir. Lmaltier (discussion) 17 février 2021 à 15:53 (UTC)

@Lmaltier : Salut, le truc, c’est que du coup, on a plein de liens manquants. Par exemple, sur Londres, il y a un lien vers WP, WN et WV, mais pas vers Commons. Et la WS anglophone a même une page qui traite de Londres, donc il faudrait que London est en plus un vers WS. Les contributeurs ne sont pas obligés de se plonger dans WD, de la même manière qu’ils ne sont pas obligés d’apprendre l’API, le fonctionnement des étymologies ou la création de thésaurus. Ils ne sont pas obligés, mais ils peuvent, si ça les intéresse. Lepticed7 (À l’immortalité !) 17 février 2021 à 16:19 (UTC)

Autre problème afférant : {{WD}} dont une partie de l’usage est similaire à celui de {{Wikipédia}}, c’est à dire dans la ligne des liens vers les autres projets, et une partie des usages est dans la source d’un exemple. J’ai voulu améliorer la mise en forme pour la faire correspondre à celle des modèles pointant vers Wikipédia, Wikisource, etc. Le problème est devenu encore plus visible. Il y a donc une centaine de pages à vérifier. Souvent pour nettoyer la source de l’exemple Noé 17 février 2021 à 16:13 (UTC)

Perso, je l’ai toujours utilisé dans la section voir. Lepticed7 (À l’immortalité !) 17 février 2021 à 16:19 (UTC)

Bonjour !

Au cours des deux prochaines semaines, nous améliorerons la barre de recherche ainsi que la couleur des liens internes (liant à des pages du même wiki).

Une moitié d'entre vous verra des images et des descriptions associées aux noms des pages suggérées. L'autre moitié ne verra aucun changement. Au bout de deux semaines, nous vérifierons si la première moitié accède à des résultats plus rapidement et efficacement. Une fois cela vérifié, cette nouvelle fonctionnalité de recherche deviendra l'expérience par défaut pour tout le monde. Chaque communauté (et non chaque utilisateur ou utilisatrice individuellement) aura la possibilité de demander l'option sans images ou sans descriptions. Pour en savoir plus, rendez-vous sur la page dédiiée aux améliorations de la barre de recherche.

Nous avons travaillé sur ce point en particulier à l'attention des personnes malvoyantes ou qui lisent dans des conditions lumineuses spécifiques (ex. lumière du soleil). Les couleurs que nous introduisons ne sont pas vraiment nouvelles. Depuis quelques années, elles sont déjà utilisées sur les portails Wikipédia, sur le navigateur mobile, et l'application mobile. Pour en savoir plus, consultez la page dédiée au changement de la couleur des liens.

Je vous écris de la part de l'équipe de la Wikimedia Foundation responsable des améliorations du bureau. Votre communauté et les internautes qui visitent votre wiki peuvent voir les nouveaux changements par défaut. Vous pouvez en apprendre plus sur nos plans.

Appréciez-vous les changements ? Avez-vous des idées d'améliorations ? Partagez votre avis sur la page principale du projet (dans la langue de votre choix).

Merci ! SGrabarczuk (WMF) (discussion) 17 février 2021 à 21:28 (UTC)

Décidément, je ne comprendrai jamais cette course à la gabegie énergétique. Pourquoi foutre des images et des textes qui réduisent le nombre de résultats visibles simultanément, gênent l’œil qui est naturellement attiré par les images, consomme de la bande passante réseau, de l’énergie et induisent des délais de réponse plus long, sans parler de l’utilisation inutile des forfaits data téléphoniques (oui, on n’est pas tous munis de forfaits sans limite dont l’existence même est débile et quid de certains pays comme en Afrique où les réseaux sont de piètre qualité). Jpgibert (discussion) 18 février 2021 à 15:33 (UTC)

Oui, mais les images, c’est joli =3 J’en vois pas l’intérêt non plus. Lepticed7 (À l’immortalité !) 18 février 2021 à 17:08 (UTC)

Bonjour !

Si vous êtes passés à côté du sujet, sur l’année 2020, un sympathique projet de Wiktionnariste en résidence a été mis en place, dont le compte-rendu a été diffusé le mois dernier. J’ai impulsé et organisé ce dispositif et je suis très heureux des multiples avancées, visibles ou peu visibles, que ce poste a permis. Des avancées pour le Wiktionnaire autant que pour Seb, la personne en résidence.

Nous avons préféré ne pas prolonger le dispositif sans avoir une nouvelle fiche de poste claire, de nouveaux objectifs plus ambitieux que les seules tâches de fonds de corrections de mise en forme. Je suis cependant convaincu que ce type de dispositif est très bénéfique pour le projet quand il peut être mis en place. D’ailleurs, nous allons en faire un pour Lingua Libre d’ici quelques mois. Un autre dispositif est possible à moyen terme, ou d’autres à imaginer.

Si ça se refait pour le Wiktionnaire, ou si un recrutement pouvait être lancé par la Wikimedia Foundation, par une association telle que Wikimédia France ou Wikimedia CH, ou même par un mécène, qu’est-ce que vous voudriez voir sur la fiche de poste ? Quelles tâches vous paraitraient mieux faites par une personne rémunérée que par des bénévoles ? Quels enjeux, objectifs, horizons, activités verriez-vous à un poste rémunéré dédié ? Quelles limites ? Est-ce que vous, personnellement, vous vous sentiriez d’être rémunéré ou auriez besoin d’être rémunéré pour certaines des tâches que vous faites dans le Wiktionnaire ? Des profils spécifiques à viser ? Et comment on pourrait faire pour l’encadrement de la personne (parce que là, sans Lepticed7 et le groupe lyonnais, ça aurait pas été pareil) ? Quelles autres questions ça vous pose toute cette réflexion ? Noé 18 février 2021 à 08:07 (UTC)

Salut, pour moi, si de l’argent doit être investi pour améliorer le Wiktionnaire, la première des missions est d’améliorer la gestion du plurilinguisme, avec un développement spécifique aux besoins du Wiktionnaire. Pour avoir suivi pas mal ce qu’a fait Seb, je pense que ce qu’il a fait est techniquement accessible à la plupart du contributorat. Bien que les tâches effectuées aient pu être pénibles, longues, etc., elles sont techniquement et en terme de permission d’accès faisables par tous. Alors que du développement spécifique, dont pourrait en fait bénéficier tout Wiktionnaire, n’est pas techniquement et permissivement accesible au contributorat. Lepticed7 (À l’immortalité !) 18 février 2021 à 08:19 (UTC)

C’est vrai. Et le point essentiel pour lequel un développement serait utile serait de pouvoir choisir la façon de trier, au niveau de chaque catégorie : nous avons des catégories en toutes les langues, et donc tri différent qu'on pourrait choisir selon la langue de la catégorie, et aussi choix de la façon de gérer pour le tri chaque caractère inhabituel (trait d’union, slash, apostrophes et autres). Cela bénéficierait à tous les wiktionnaires et même (pour le deuxième point) possiblement aux autres projets. Lmaltier (discussion) 18 février 2021 à 08:33 (UTC)

Je ne sais pas si c'est l'endroit pour proposer cela, mais le Wikeriadur (i.e. br.wiktionary.org) aurait besoin d'une mise à jour de son look. Peut-être pourrait-il bénéficier de l'expérience acquise dans de mêmes travaux déjà réalisés sur le Wiktionnaire. Marxav (discussion) 24 février 2021 à 06:00 (UTC)

Ça fait pas mal de questions, alors je vais tenter de répondre par point en sous sections. --Psychoslave (discussion) 3 mars 2021 à 13:04 (UTC)

Il me semble que plusieurs types de profils sont envisageable en fonction de ce que nous voulons voir réaliser.

Si nous partons de l’idée que la communauté défriche le terrain en créant des spécifications précises en amont et en se chargeant de remplir elle même les tâches à confier via un kanban ou autre, il faudra plutôt viser un profil "capable de rapidement mettre en œuvre avec une bonne aptitude à se focaliser sur des tâches données, intéressé par la réalisation de nombreuses petites actions qui améliorent petite touche à petite touche le Wiktionnaire sur le plan de son contenu ou de la solution technique qui le porte".

Si nous partons sur la volonté de trouver quelqu’un qui au contraire devra se charger de défricher les besoins, spécifier les tâches afférentes à réaliser, évaluer les ressources nécessaires pour chaque tâche et celles à disposition pour prioriser les actions, il faudra recherche plutôt un profil "sachant être à l'écoute d’une large communauté, n’hésitant pas à aller proactivement interroger ses membre pour mieux cerner les besoins tout en sachant voir au-delà (nous autres utilisateurs finaux avons souvent la tête dans le guidon) ; une remarquable capacité à collecter et synthétiser efficacement des larges spectres de demandes pour en dégager priorités pertinentes et définir les actions concrètes en tenant compte aussi bien des besoins que des ressources disponibles".

Une passion pour la lexicologie, une connaissance des outils utilisés par la communauté Wikimedia sont des plus appréciables (préciser la liste en fonction des objectifs du poste : Javascript, Lua, Mediawiki, Phabricator, PHP…). --Psychoslave (discussion) 3 mars 2021 à 13:27 (UTC)

Pour préciser, c’est un intérêt pour la lexicographie qu’il faudrait, plutôt que pour la lexicologie, le premier étant l’organisation des connaissances pour la fabrication de dictionnaires tandis que le second est une discipline de la linguistique qui s’intéresse à l’étude du lexique. Selon les besoins, je ne pense pas que ce soit un prérequis pour un travail sur le Wiktionnaire qui porterait sur l’ergonomie ou l’expérience utilisateur Noé 3 mars 2021 à 22:30 (UTC)

Ok, merci Noé pour cette mise au point lexicale. Je tenterai d’en tenir compte dans mes énoncés futurs. --Psychoslave (discussion) 4 mars 2021 à 21:37 (UTC)

Pour ma part, je n'ai pas grand chose à dire sur ce plan, n’ayant pas suivi les aventures de Seb, j’ignore ce que l’encadrement aura apporté à son action. Évidemment l’idéal c’est une personne totalement autonome, déjà complétement acculturé à la communauté, etc. Le temps passer à former quelqu’un, c'est du temps qui n’est pas consacré aux tâches sur lesquels nous voudrions voir des évolutions advenir. Sur ce plan, prolonger ou relancer le contrat de Seb serait une garantie de ne pas avoir à repartir de zéro sur ce plan. Comme je n’ai pas suivi le déroulement de son premier contrat, et que j'ignore les compétences qui seront demandées pour le poste, je ne saurais bien sûr pas évaluer la pertinence de son profil vis-à-vis des besoins spécifiques à la nouvelle mission. Cela étant, de mon point de vu des compétences techniques et des savoir faire, ce sont des usages qui s’acquièrent plus simplement que ce que demande une acculturation et un savoir être pertinent pour les relations avec la communauté. Cela dit, je ne sais pas comment a été vécu le contrat de Seb : est-ce que les personnes qui l’ont suivi accueilleraient positivement une telle continuité ? Est-ce que pour lui ça serait quelque chose de motivant de continuer, avec possiblement des objectifs un peu différents ? En résumé, je pense qu’ici j’apporte plus des questions dont chacun jugera de la pertinence, que de réponses prêtes à l’emploi. --Psychoslave (discussion) 3 mars 2021 à 13:41 (UTC)

Tu pourrais lire la page Projet:Wiktionnariste en résidence ainsi que le compte-rendu pour la communauté. Seb a actuellement un contrat à plein temps. Je le laisserai répondre à tes questions pour ce qui le concerne. De mon côté, comme impulseur, j’ai trouvé que ce n’était pas une perte de temps de convaincre les financeurs et partenaires de l’intérêt de ce projet, ni d’échanger avec Seb que j’ai formé autant qu’il m’a formé (et me forme encore). C’était vraiment très appréciable de pouvoir impliquer Lepticed7 et de pouvoir tous les trois former une équipe de travail. Les conditions étaient cependant très particulières et je doute que nous puissions y consacrer à nouveau autant de temps à l’avenir. Quoi qu’il en soit, un me semble important de délimiter une fiche de poste précise en amont et un cadre de travail qui permette ces réalisations. Réalisations à définir. Pour l’instant, je n’en vois pas qui nécessiteraient un tel dispositif Noé 3 mars 2021 à 22:40 (UTC)

Et bien sur le corolaire, tâches qu’il vaut mieux éviter de confier à une telle personne. --Psychoslave (discussion) 3 mars 2021 à 13:04 (UTC)

Je pense que la réponse peut s’axer autours des deux axes :

1. les mutiples petites tâches chiantes, potentiellement automatisables en tout ou partie, sur lesquels tout le monde s’accorde à dire que "oui, ce serait bien si quelqu’un le faisait", mais qui ne motive personne
2. les grosses tâches de longues halène qui s’accommode mal d’une réalisation par petites touches.

Et donc les tâches qu’il est peu pertinent de confier à un poste rémunéré, ce sont celles qui, comme il a déjà été dit précedemment, motivent de toute façon déjà les contributeurs et qui peuvent sans problème majeur se faire par petites touches.

En ce qui me concerne, les tâches que j’aimerais bien voir réaliser et qui me paraissent difficilement atteignable en dehors d’au moins une personne en temps plein sur au moins plusieurs mois, c’est la mise à disposition d’une nouvelle monture du Wiktionnaire où :

• les données lexicologiques sont stockés de manière requêtables, clairement séparées du rendu, et grâce à cela :
  • possibilité de partager des définitions entre plusieurs entrées
  • un corpus d’exemple de cas concrets, aussi bien texte, audio que vidéo (LSF)
    • avec des données de références également structurées pour être requêtables
      • donc avec possibilité simplifié de faire des études sur les métadonnées du corpus
  • des pages où toutes les flexions sont peuplées de définitions, étymologies, synonymes, etc. pertinentes, plutôt qu’une majorité faisant office de simple renvoi au lemme
  • possibilité de fournir une API REST pour construire facilement des applications reposant sur les connaissances lexicologiques accumulées dans le Wiktionnaire
  • possibilité de formuler des requêtes très poussés comme "les mots français de quatre syllabes qui riment en \sjɔ̃\ dans le domaine de l’architecture, attesté avant le XVII et dérivant au moins en partie d’une racine latine".
• mise en avant de dump facilement exploitable pour des applications hors ligne dès la page d’accueil
• le tout accompagné d’amélioraition IHM :
  • mise en avant de ce pour quoi une majorité de lectorat arrive sur le Wiktionnaire, confère la capture ci-contre
  • au moins une interface web qui rend la contribution plus aisée que ce qu’elle est aujourd'hui :
    • nécessité nulle ou largement décrue de connaître la syntaxe wikicode
    • nécessité largement décrue de connaître les conventions du Wiktionnaire, voire nulle pour des modifications mineures et en tout cas rien susceptible d’effrayer le néophyte qui souhaiterait faire une modeste contribution
  • fournir des applications mobiles dignes de ce nom pour le Wiktionnaire

Je pense que pour le succès de tels projets, outre les aspects connaissances techniques, il faudra les compétences communicationnelles pour agir en bonne coordination avec la communauté. Toutes les compétences et toutes les actions relatives peuvent certainement être partagées entre plusieurs personnes, aux compétences complémentaires, où de créatures certes à la perfection surhumaine dans tous les domaines, mais incapables d’œuvrer plus de 24 heures par jour.

J’ai aussi conscience que tout ou partie de ce que j’avance ne fera pas nécessairement l’unanimité, ce qui impliquera pour être dépassé, outre l’évolution de cette feuille de route, une communication qui soit efficace sur la durée pour que le projet suscite l’enthousiasme et l'adhésion de la communauté existante.

Pour terminer, si une équipe est montée avec comme objectif de monter un tel projet, je serai ravis de contribuer à sa réalisation, que ce soit en temps plein rémunéré ou en aide plus ponctuelle sur mon temps libre. --Psychoslave (discussion) 3 mars 2021 à 15:12 (UTC)

Les tâches que tu voudrais voir réaliser, et particulièrement la partie « les données lexicologiques sont stockés de manière requêtables, clairement séparées du rendu » correspondent à une discussion en cours d’où ne se dégage pas un consensus communautaire pour l’instant. Je n’ai pas l’impression que la communauté du Wiktionnaire appuiera une démarche en ce sens. Et même si c’était le cas, c’est une infrastructure de gestion de données de très grande ampleur qui ne sera pas mise en place par une seule personne, ni par le Wiktionnaire francophone seul. Et ton paragraphe sur susciter l’enthousiasme et l’adhésion fait froid dans le dos. Ce n’est pas en débarquant de l’extérieur avec une expertise plaquée sur le projet que les choses vont se faire.

Pour la partie sur l’amélioration de l’interface de consultation, c’est mort. Nous avons déjà tenté de faire passer Timeless comme habillage par défaut, ce qui a été refusé par la Wikimedia Foundation pour plusieurs arguments très valables tels que le coût à maintenir un habillage de plus et le refus d’avoir des interfaces disparates au sein des projets Wikimedia. Sans perspective de réaliser des changements, inutile d’embaucher quelqu’un pour travailler à des pistes d’amélioration.

Le développement d’application mobile, c’est un autre métier, donc un autre projet.

Pour l’instant, ce que tu proposes est trop ambitieux et hors-sol, déconnecté des besoins et possibilités que nous avons Noé 3 mars 2021 à 22:54 (UTC)

Je rejoins Noé sur cette proposition. C’est complètement hors de portée du projet et ça ne correspond qu’à ta seule vision de ce qu’il devrait être. Je ne m’y retrouve pas du tout. Lyokoï ^{(Discutez sur le péril mortel)} 4 mars 2021 à 00:10 (UTC)

Ok, merci pour ces retours. --Psychoslave (discussion) 4 mars 2021 à 21:41 (UTC)

Une tâche serait, selon moi, de structurer les données du Wiktionnaire. C’est un minimum pour un projet numérique. Exemples, définitions indépendantes, domaines. À partir de là, tous les projets sont possibles (dictionnaires de citations, dictionnaires spécialisés, etc.) Les lexiques existent, mais sont-ils suffisants, pertinents, prêts à l’emploi ?

Pour une description de poste, je verrais bien une personne qui analyse les données de tous ordres, à la demande, de façon à écrire des modèles de rédaction et de recherche exhaustifs. Compétences sémantiques, morphologiques et tic. Lekselle (discussion) 11 mars 2021 à 18:07 (UTC)

Ça dépend aussi du temps imparti. Entre un CDD de deux mois et un CDI, il est clair que tout ces points auront des réponses significativement différentes. Aussi avant de développer plus loin cette réponse, pourrais-tu stp @noé : donner un ordre de grandeur sur la durée visée, au moins initialement. --Psychoslave (discussion) 3 mars 2021 à 13:04 (UTC)

Non, je ne vise rien. Je tâte le terrain, je n’ai pas l’intention de mettre en place quoi que ce soit pour l’instant Noé 3 mars 2021 à 13:20 (UTC)

Bon, je pense que du coup, j’ai déjà fourni les éléments pertinents dans ma réponse à la section précédente. J’ajouterais juste ici qu’il y a des choses qui sont à mon avis réalisables en nécessitant relativement peu de ressources humaines tout en pouvant apporter une plus-value très importante. Par exemple, le rendu de la page par défaut (en tout cas chez moi, il me semble que c’est Vector et que c'est le thème par défaut sur Desktop), c'est simplement de l’amélioration de feuille de style. En voyant très large, en prenant en compte la réflexion du designer, quelques itérations avec retours de bêta-testeurs, construction de l'assentiment de la communauté sur le résultat, je pense que quelques mois tout au plus devrait largement suffire. Et pourtant, c'est la première chose que le lectorat desktop voit. Je ne sais plus de mémoire ce qu'il en est sur mobile, mais pour ce type de projet ça devrait être couvert dans l’analyse, y compris une analyse de la répartition statistique des consultation par type de terminal et de navigateur. --Psychoslave (discussion) 3 mars 2021 à 15:23 (UTC)

Les contributions rémunérées ne doivent pas se voir fournir un rôle dont les moyens offre une position de primauté sur les décisions communautaires, que ce soit en matière de ligne éditoriale ou de fonctionnement technique. Bien sûr, des personnes peuvent être embauché pour jouer les facilitateurs en communication, gestion du changement, évolution technologique, expression des besoins, etc. Tout cela n’empêche pas que la communauté qui constitue, à mon sens tout au moins, le bien le plus précieux du Wiktionnaire, juste devant la formidable base de connaissance lexicologique qu’elle a constitué. Bien sûr, comme tout ce qui touche à l’humain, ses membres et ses interactions sont plein de défauts – moi le premier. Tout le monde à toujours des axes d’amélioration qu’il peut creuser. Tout cela étant dit, il me paraît important de garder à l’esprit que des personnes rémunérées pour leurs contributions au Wiktionnaire ne sont acceptables que dans la mesure où elles participent à la prospérité de sa communauté. Dans les limites de ces conditions, pour ma part, toutes les actions rémunérés ou non sont acceptables et bienvenues. --Psychoslave (discussion) 3 mars 2021 à 15:37 (UTC)

Bonjour à tous,

J’allais voir si quelqu'un avait proposé une entrée pour demain et j’ai vu que Marxav avait proposé Iron Man (Modèle:Entrée étrangère du jour/2021/02/19). Je vais commencer par clarifier une chose car ce n’est pas le débat que je souhaite ouvrir ici : ma question n’a rien avoir avec l’opportunité ou non de les avoir dans le Wix. Il y en a déjà deux sujets dans les pages proposées à la suppression sur les noms propres, et je suis personnellement parfaitement en faveur de les avoir sur le Wiktionnaire, ne ce serait-ce que parce qu'ils ont une traduction …

Non, ma question est une entrée en lumière en langue étrangère doit faire découvrir un nouveau mot, etc. La langue anglaise en est truffée de drôles, ironiques, étonnants, etc. Je n’ai en soi rien contre la présence de noms propres dans ces entrées, mais elles doivent à mon avis apporter un plus. J’ai donc ici rajouté que Iron Man était également le surnom donné à un projet d’exosquelette militaire. Mais encore une fois, c’est un nom propre pour un nom propre.

J’aurai bien proposé le terme anglais Donald Duck par exemple (le nom propre désigne le personnage et un astéroïde), et le nom commun désigne la chance et des choses plus grivoises que nous nous serions abstenu de mentionner dans l’accueil en cockney rhyming slang. De même, Uncle Scrooge désigne bien sûr Picsou, mais c’est aussi et tout bonnement un riche avare.

Bref, quels sont vos avis sur ce type d’entrée en lumière ? Nom propre ou pas ? Nom propre avec un minimum de règles (genre un sens repris par la suite comme nom commun, un exemple, l’existence de traductions, etc.) ?

Merci par avance, Treehill (discussion) 18 février 2021 à 18:39 (UTC)

Il me semble que le mieux est de choisir un mot senti comme non français, plutôt qu’un mot emprunté en français. Lmaltier (discussion) 18 février 2021 à 19:07 (UTC)

Salut, je n’ai pas écrit de règles, mais on en avait discuté avec Noé quand on a mis le système en place. Pour moi, il faudrait au moins une attestation et l’image devrait plutôt adopter un formal horizontal. Le but, c’est que sur un écran puisse être affiché l’entrée en français et l’entrée étrangère. Lepticed7 (À l’immortalité !) 18 février 2021 à 19:24 (UTC)

Lmaltier Je ne suis pas certain de voir le lien (par exemple, le mot blasé qui est en fait parfaitement intégré à l’anglais) ?
Ok Lepticed7 pour le format de l’image (j’y veillerai de mon côté aussi). Pour info, sur le fond, j’ai corrigé 1. la prononciation (française, pas anglophone dans le texte de Marxav, c’est quelque chose auquel il faut bien veiller :) ; 2. le modèle lexique inadapté ici 3. j’ai rajouté un exemple de son emploi comme nom commun pour désigner un exosquelette. Treehill (discussion) 18 février 2021 à 19:31 (UTC)

Oui, pour des emprunts dans l’autre sens, ça peut être intéressant. Je pensais plutôt aux mots étrangers empruntés en français, comme jogging, Spiderman… Lmaltier (discussion) 18 février 2021 à 19:36 (UTC)

J'avais ajouté Dame de fer pour demain dans l'entrée en français et avais ajouté Iron Man en clin-d'oeil pour la sacro-sainte parité ;-) Mais j'avoue avoir fait ça trop vite (entre autres, l'étourderie de recopier la prononciation à la française) et j'espérais trouver le temps ce soir d'améliorer un peu. Mais je n'aurais jamais amélioré aussi bien que toi. Donc je te remercie une nouvelle fois pour ces améliorations. Maintenant, ça ne me pause aucun problème si vous décidiez de mettre un autre mot en valeur dans la 1ère page. Marxav (discussion) 18 février 2021 à 20:20 (UTC)

Avec le recul, un constat que je fais est qu'il est relativement assez facile d'ajouter des noms communs ou des noms propres car il y a souvent des images disponibles sur Wikimedia Commons pour illuster le mot (même si les images ne sont pas toujours esthétiques), par contre c'est beaucoup plus difficile pour les autres mots (ex: verbes, adjectifs, mots liés à des concepts)... d'où sans doute le fait que j'ai proposé deux noms propres pour demain, j'avoue être probablement tombé dans la facilité. Marxav (discussion) 18 février 2021 à 20:29 (UTC)

 Au passage, j’en profite pour attirer l’attention sur le fait que "Synonyme de …" n’est pas une bonne définition. La chose que désigne le mot n’est pas un synonyme. C’est le mot lui même qui est un synonyme. Lepticed7 (À l’immortalité !) 19 février 2021 à 07:41 (UTC)

J'ai fait ça à la va-vite. Je corrige (si ce n'est fait quand je passe).

Marxav : Ok, je comprends mieux ta démarche :) .

Lmaltier : Ahh ok je comprends, d'accord avec toi. Treehill (discussion) 19 février 2021 à 07:52 (UTC)

Bonjour à toutes et tous,

Dans le cadre de la préparation du prochain plan d'action de Wikimédia France, un appel à projets et à idées est ouvert à destination de la communauté wikimédienne. Que ce soit un besoin technique, un besoin de formation, un projet d'amélioration de certains contenus ou de l'organisation d'un évènement, toutes les idées sont les bienvenues. Les projets faisant consensus seront accompagnés et soutenus par Wikimédia France sur l'ensemble de l'année prochaine. La communauté pourra suivre l'avancement des projets depuis une page dédiée. Cet appel à projet est ouvert jusqu'au 10 mars prochain et vous pouvez apporter votre soutien aux idées et projets proposés sur cette page : Appel à projets/idées 2021-2022

Je vous rappelle également que si vous avez besoin d'avoir un accès à des sources (livres, abonnement presse), d'un prêt de matériel informatique ou photographique ou de la prise en charge de certains frais utiles à votre activité de contribution, la commission de micro-financement de Wikimédia France est à votre disposition.

Je vous souhaite une bonne journée,

Rémy Gerbet WMFr (discussion) 19 février 2021 à 10:00 (UTC)

Salut, une bonne idée, bien que techniquement velue, serait de nous permettre de gérer le plurilinguisme :D Lepticed7 (À l’immortalité !) 19 février 2021 à 10:45 (UTC)

Une autre idée: sachant qu'une image vaut mille mots, mettre au point un outil générateur d'image à la volée à partir d'un texte décrivant l'image (c.f. https://deepai.org/machine-learning-model/text2img) puis la déposer automatiquement dans Wikimedia Commons si elle est jugée satisfaisante par l'utilisateur. Cela permettrait d'étoffer le nombre d'images libres de droit pouvant être utilisées pour illustrer plus facilement des entrées du Wiktionnaire. La technologie étant extrêmement récente et en langue anglaise uniquement, ça serait probablement des travaux de recherche à réaliser pour réaliser un prototype. Marxav (discussion) 24 février 2021 à 06:09 (UTC)

Merci Noé d’avoir relayé l’appel ici. Ça m’a décidé à extraire et soumettre l’une des idées que j’ai pu mettre à plat plus tôt dans la journée suite à ton autre initiative de sonder les besoins perçus en personne rémunérée pour épauler le Wiktionnaire. Je ferai probablement d’autres propositions avant le 10 en me basant sur d’autres extractions de cette mise à plat. --Psychoslave (discussion) 3 mars 2021 à 21:36 (UTC)

Salut,

ça fait plusieurs mois que j’ai personnellement fait le constat. Mais notre manière de gérer notre contenu est nulle. Elle fonctionn, mais pourrait vraiment bénéficier d’améliorations qui donnerait plus de sens à ce que nous faisons. J’aimerai lancer une discussion sur ce que l’on pourrait faire, que ça soit possible ou que cela relève de l’utopie qui rendrait le contenu meilleur.

Le premier problème que je vois est la mauvaise granularité à laquelle nous nous situons. Actuellement, j’entrevois trois granularités de description : la graphie, le mot et la définition. La graphie est la suite de caractères, le mot est la graphie dans une langue et la définition est le mot avec un sens associé. Certaines de ces granularités sont divisibles. On peut considérer la classe grammaticale, et ainsi descendre en granularité dans la page. Toujours est-il que notre niveau actuel est le niveau le plus haut, la graphie. Nous pouvons, à l’aide d’ancres HTML, cibler plus finement le contenu, que ça soit la section de langue ou grammaticale. Il est rare que nous puissions cibler la définition même. Le gros problème des ancres repose sur le fait qu’on ne peut pas savoir si elle existe dans la page cible. Ainsi, un lien vers une page possédant une ancre inexistante sera quand même affiché en bleu et ne sera pas référencé par les pages spéciales.

La solution parait simple, il faut descendre dans les niveaux de granularité. Mais comment ? La solution a laquelle j’ai pensé, mais qui semble hors d’atteinte, est de créer des sous-pages par langue, sous-pages qui seraient incluses dans la page principale, dans un ordre fixé. Ainsi, nous aurions les pages la, la/fr, la/eo, la/es, les trois dernières étant transcluses dans la première. Cette idée est largement inspirée du fonctionnement de Wikisource, séparant page de transclusion et page de texte (espace principal et espace Page). Cette solution permettrait d’avoir des liens corrects à la langue près. Mais le problème reste pour les classes grammaticales et les définitions.

Le deuxième problème que je vois est que nos pages sont vides d’informations utiles au web sémantique. Tous les autres projets disposent de Wikidata, qu’ils peuvent utiliser pour faire de nombreuses choses. Ce n’est pas notre cas. Nous sommes un dictionnaire au format numérique, nous ne sommes pas un dictionnaire numérique. Ce que j’entends par là, c’est que notre contenu pourrait très bien figuré sur papier que ça ne ferait que très peu de différence. Nous n’utilisons pas toute la puissance que permet le numérique. Effectivement, certaines choses, comme les vidéos ou les enregistrements, ne peuvent pas figurer dans un dico papier. Toutefois, c’est le cas d’une bonne partie de notre contenu.

J’ai entendu certains me dire que nous ne sommes qu’un dépôt de connaissance, qu’il n’est pas de notre devoir d’innover. Effectivement, nous ne devons pas innover linguistiquement. Nous ne devons pas modifier la chose que nous décrivons. Toutefois, nous pouvons envisager de changer la manière dont nous la décrivons. Je m’intéresse au projet Lexèmes et discute avec ses membres qui a des choses à nous apporter. Peut-être pas tout, mais le web sémantique a de grands avantages dont nous pourrions profiter.

Quelques exemples en vrac pour rendre la chose plus concrète :

• gestion intelligente des flexions et des liens qui existent entre un lemme et ses flexions
• gestion des liens sémantiques entre les différentes définitions
• gestion des différentes prononciations régionales et des enregistrements
• gestion des lexiques, contextes, etc.

Voilà quelques exemples qui me paraissent intéressants. La vision que j’en ai est qu’actuellement, acquérir de l’information via le Wiktionnaire ne se fait qu’au goutte-à-goutte, ou avec l’aide d’outils extérieurs (Anagrimmes, Dbnary, PetScan). Notre contenu n’est pas accessible (ou difficilement) aux machines et surtout qu’à petit débit. Je ne sais pas si vous avez eu le plaisir d’utiliser Sparql sur des éléments wikidata, mais qu’un gain de temps de pouvoir trouver rapidement les éléments partageant une certaine caractéristique.

Voilà, ça fait un long message, mais j’avais envie d’exposer ce truc que je rumine depuis plusieurs mois. Comme ça, vous êtes au courant de la conception que je me fais du projet et de ce vers quoi il doit tendre à mon avis. À+, Lepticed7 (À l’immortalité !) 19 février 2021 à 11:18 (UTC)

@Lepticed7 et @JackPotte : J’ai une idée mais j’ignore si elle est utopique. Les robots sont très utiles pour réaliser des tâches fastidieuses. Nous n’avons qu’à regarder le nombre de contributions de robots dans les historiques. Mon idée est dystopique, mais je leur propose un wiki qui leur serait propre. Ils continueraient ici leur travail indispensable, mais auraient aussi un genre de clone où ils seraient les maîtres avec leurs dresseurs. Les robots s’alimenteraient des modifications récentes et/ou des dumps. Ils pourraient s’occuper de la transclusion automatique et de la séparation en sous-pages par langue sur leur wiki. Avant de lancer des actions sur le wiki des robots, des humains en chair et en os (et pas seulement les dresseurs) s’entendraient pour savoir ce qui serait profitable (la transclusion par exemple). Ce wiki des robots serait consultable par tous.

On pourrait se permettre du code et des requêtes un peu plus complexes. Par exemple rechercher uniquement dans les définitions des locutions nominales en français au féminin qui contiennent tel mot. Ou n’importe quoi de possible. On pourrait à l’aide de ce wiki des robots améliorer celui des humains en y trouvant des anomalies ou en réalisant des découvertes au fil des requêtes. Il faudrait aussi améliorer la manière de gérer le contenu sur ce wiki, mais pas en complexifiant la contribution des humains. --Snawei (discussion) 19 février 2021 à 12:54 (UTC)

A ma connaissance le plus gros problème des bots est lié à l'interprétation de ce que les humains ont écrit lors du parsing des articles. Donc si on retirait les humains d'un Wiktionnary4bot, sans synchro on pourrait alors retirer ce parsing et on retomberait alors sur le projet Omegawiki où tout élément est identifié structurellement. L'état de l'art voudrait qu'on puisse passer aussi sur du Web sémantique pour requêter.

Mais pour l'instant ce sont les outils extérieurs qui permettent encore le plus de souplesse, notamment pour des POC. JackPotte ($♠) 19 février 2021 à 13:32 (UTC)

Je voudrais mettre en évidence quelques avantages de notre façon de faire, car elle a aussi de gros avantages, et il ne faut pas les oublier :

• une page par graphie, regroupant toutes les langues : si on est intéressé, cela permet de voir globalement quelles langues utilisent cette graphie, les analogies de sens et les différences de sens entre les mots de ces langues, les faux amis… C’est utile pour les lecteurs, mais ça peut aussi être utile quand un contributeur ouvre la page, et ça lui permet de modifier toute la page d’un coup, si besoin est (pour les détails de syntaxe, par exemple). Le wiktionnaire en latin sépare les pages par langue, et perd cet avantage. Il n’est pas étonnant qu'il soit le seul à avoir pris cette option (à noter qu’il ne transclut pas les pages de chaque langue dans une page unique, ce n’est donc pas l’idée évoquée ci-dessus).
• le code interne de la page correspond au contenu affiché, comme sur Wikipédia, c’est donc simple à comprendre pour les contributeurs (de ce point de vue, en tout cas…). Les transclusions n’ont pas que des avantages, elles ont aussi des inconvénients : par exemple, il m’est déjà arrivé souvent de renoncer à rajouter un mot dans les voir de début de page parce que je ne pouvais pas le faire directement, et que je trouvais ça trop compliqué. Alors, pour les non-informaticiens, le risque est encore nettement plus grand.
• nos pages sont tout à fait exploitables par des outils externes : il y a eu de nombreuses recherches exploitant les pages telles qu’elles sont. Notre lectorat visé, ce sont avant tout les lecteurs humains, pas les programmes, il ne faut jamais l’oublier (tout comme il ne faut jamais oublier que ce sont avant tout les contributeurs humains qui fournissent une contribution intelligente et indispensable, pas les robots, ni les programmeurs). Malgré tout, une possibilité, pour faciliter la tâche des programmes qui veulent nous exploiter, serait de changer la place des catégories : elles sont en fin de section de langue, on pourrait les mettre plus près de l’endroit concerné. Par exemple, dans les sections de mot, si elles ne concernent qu’un seul mot, ou en fin de ligne de définition, si elles ne concernent qu’une définition. Ce serait à creuser.

Je ne comprends pas l’idée de Snawei, mais il est certain que des outils automatisés peuvent être extrêmement utiles, et il n’y a pas besoin d’un wiki spécial pour ça, les robots étant lancés depuis les ordinateurs de ceux qui les lancent. Est-ce qu’il s’agirait d’avoir une base de données spéciale correspondant au Wiktionnaire, mais avec des ajouts permettant de faciliter le programmation des robots ? Dans ce cas, quels ajouts ? S’il s’agit d’un genre d’Omegawiki comme le pense JackPotte, je rappelle que, pour moi, c’est impossible de faire ça correctement (la description de la langue exige une souplesse infinie, souplesse que nous avons actuellement). Je rappelle aussi qu’OmegaWiki a réussi (sans aucun mal) à faire partir tous les contributeurs qui s’y sont essayés.

Et il est certain aussi qu’il ne faut pas complexifier la contribution des humains, qui est déjà très compliquée. Lmaltier (discussion) 19 février 2021 à 14:09 (UTC)

Je pense que la transclusion n’est pas une mauvaise chose pour la contribution. Quand on demande à modifier une section, on n’a pas de risque de "baver" ailleurs. Quant à la difficulté de la notion de sous-page, on peut imaginer d’avoir un bouton "ajouter une section de langue" un peu comme sur Commons. On a une liste déroulante, on choisit la langue qui manque et on valide la création de la section. L’utilisateur n’aura pas à se soucier de savoir comment le contenu sera stocké.

Pour moi, la notion de sous-page ne viendrait pas compliquer la contribution.

Je sais que tu as déjà plusieurs fois fait cette remarque que la transclusion t’empêcherait de modifier toutes les langues d'une graphie en une seule fois. Et je le comprends. Mais je reste persuadé qu’il s’agit là d'une façon de travailler très marginale. Ce qui ne veut pas dire qu’il ne faut pas en tenir compte.

On pourrait imaginer d’avoir une fonction spéciale "modifier toutes les langues" avec une page ayant un bloc de modification pour chacune des sous-pages. Et quand on valide la modification, on la valide pour chaque bloc modifié. C’est tout à fait possible même si ça exige du dev particulier.

Jpgibert (discussion) 19 février 2021 à 15:57 (UTC)

Salut. Pour ne rien cacher, je m’attendais à ces arguments. Ils sont toujours les mêmes, et je comprends leur importance. Toutefois, je pense qu’il faut différencier le stockage, l’édition et la consultation. Rien n’empêche de développer un gadget qui permettait de modifier le modèle voir depuis la page sur laquelle on est. Il est certain que changer le stockage des pages nécessitent de changer la manière de les consulter, ainsi que de les éditer. Mais ça ne doit pas être un frein. C’est pourquoi je ne les considère pas comme un argument valable contre les modifications. À l’inverse, cela justifie d’autres adaptations. Nos pages sont difficilement exploitables par des outils externes. Il va s’agir de traitement se basant sur des chaines de caractère pour AWB, mais il n’y a un sens compréhensible à ce que nous écrivons. Il y a de nombreuses requêtes que nous ne pouvons pas faire, ou du moins, le seul moyen est de recherche une chaine de caractères, et non une information. Par exemple, les citations d’un certain auteur, les pages présentant deux définitions, ou ayant deux sections grammaticales. Il n’y a pas de moyen, autre qu’avec des regex, de faire ça. Dans le système actuel, tu ne peux pas faire comme sur wikidata. Et effectivement, si le seul lectorat visé est l’humain, nous faisons un dictionnaire au format numérique, et non un dictionnaire numérique. Nous n’exploitons pas les outils que permet le numérique. Et la place des catégories n’est que mineure dans l’utilisation qu’on peut faire. Elles n’apportent que peu d’informations sémantiques, étant donné qu’elles ne sont reliées qu’à une graphie. Enfin, la contribution est complexe uniquement parce que les outils pour contribuer le sont. Personne ne se soucie de faire des requêtes SQL pour mettre à jour les pages. S’il nous manque un niveau d’interface pour la contribution, il ne faut pas restreindre en conséquence la manière de gérer les données. Il faut faire le nécessaire pour le stockage et adapter l’interface de contribution pour en effacer toutes les difficultés. Lepticed7 (À l’immortalité !) 19 février 2021 à 18:06 (UTC)

+1 @Lepticed7 :, mais comment faire plus simple ?

@JackPotte : Merci beaucoup pour ta réponse. Question pour tous : Une extension comme Semantic MediaWiki pourrait-elle être installée sur un autre wiki. Ou sinon, qu’elles seraient les solutions pour le web sémantique. La dernière version de Semantic MediaWiki est la 3.2.2 (5 décembre 2020). La première version date de 2005. J’ignore comment cela ce comporterait sur nos 6 502 595 pages. Je cherche aussi des exemples de sites qui l’utilisent d’une façon semblable à l’usage qu’on en ferait. L’idée n’est pas de remplacer le Wiktionnaire actuel, mais d’avoir un outil complémentaire.

@Lmaltier : Avec Wiktionnary4bot ! on pourrait faire la transclusion de façon transparente et s’approcher de la granularité dont parle Lepticed7. Le robot s’en occuperait automatiquement. Ou d'autres façons de faire plus compliquées pour des humains seuls. On pourrait avoir du code plus complexe (sans exagérer) et des catégories inexistantes ici.

Je ne suis pas d’accord quand tu dis nos pages sont tout à fait exploitables par des outils externes. Nos pages sont très difficilement exploitables par des outils externes. Lepticed7 souligne un réel problème. On ne profite pas assez des possibilités du numérique.

Il reste beaucoup d’erreurs à corriger sur le Wiktionnaire et c’est un éternel recommencement. Cela démontre la vivacité du projet, mais aussi la complexité du code. Même les contributeurs les plus expérimentés commettent des erreurs. Seulement hier, j’ai corrigé ces coquilles de ta part (ce n’est pas pour faire ton procès, ton travail est imposant et de qualité d’après moi)  : 1. 2 3 4 5 6 7. Grâce à la Catégorie:Pluriels manquants en français de JackBot.

@Jpgibert : Je vois aussi des avantages à la transclusion que ce soit sur ce wiki ou sur un wikiderobots (je laisse tomber le wikiderobots si cela n’intéresse personne, c’était seulement pour lancer une idée). Je me demande seulement les conséquences sur la performance du moteur de wiki. Cela ferait beaucoup de pages supplémentaires. On pourrait par contre suivre des sections de langue plutôt que la page au complet, si je comprends bien. Cela amènerait une autre granularité. Je me pose la même question que Lmaltier à savoir si cela ne compliquera pas la contribution. --Snawei (discussion) 19 février 2021 à 18:14 (UTC)

@Lepticed7 : En fait, les catégories sont liées à une page, du point de vue technique, donc, pour nous, à une graphie, effectivement. Ce que j’avais en tête, c’est de pouvoir les associer à un mot, ou même à une définition, non pas du point de vue de Mediawiki, mais d’une façon qui permette aux outils externes de comprendre cette association grâce à l’emplacement choisi. Lmaltier (discussion) 19 février 2021 à 19:16 (UTC)

Je partage le constat qu’énonce ici Lepticed. Le Wiktionnaire est une collection d'information inouïe mais qui ne profite pas suffisamment des outils numériques. Et c'est un comble, car toutes les pages que nous écrivons sont clairement structurées. En témoigne les nombreux gadgets, modèles, bots qui permettent simplement de structurer et homogénéiser les pages (au prix d'un wikicode compliqué et d'un travail important).

J'ai tendance à penser que la gestion du contenu basée sur des pages et du wikicode n'est pas vraiment la meilleure solution. Il faut envisager l'usage de bases de données avec des contraintes et une interface liée. Les définitions seraient rassemblées automatiquement par mot et par langue sur chaque page. On conserve exactement le même rendu de page qu'actuellement. Pour contribuer on peut imaginer un bouton modifier cette définition qui conduit à une page de contribution spécifique. Les champs de remplissage apparaissent (image, def, synonymes, dérivés...), et il suffit de modifier ou d'ajouter ce que l'on veut. Idem pour les informations propres à un mot (flexions, prononciation, etc.).

Pour quels bénéfices ?

1. La structuration de l'information et la gestion fine des liens. Cela comblerait le manque décrit par Lepticed.
2. La simplification des contributions et donc une plus grande accessibilité au projet. Pas besoin d'affronter le wikicode, les trop nombreux modèles, pas besoin non plus de s'inquiéter de la structure de la page ou de sa mise en forme. Tout cela serait précontraint (et suivrait les règles déjà en place).
3. On limite également les petites tâches, pénibles mais nécessaires : les catégorisations, le tri des synonymes par définition, le tri des traductions, les corrections d'erreurs...  Bref, tout ce que l'on fait quand on repasse derrière un contributeur moins expérimenté.
4.  Certaines informations seraient automatiquement complétées sur les pages liées (ou avec la confirmation du contributeur, à voir). C'est le cas pour certaines relations : synonymes, antonymes, dérivé / étymologie, traductions, etc. Les flexions pourraient également être crées automatiquement. Sans doute d'autres trucs.
5. Ça permet de dépasser le conflit qui existe entre la facilité de contribution et la volonté de structurer toujours plus.

Non, ce n'est pas wikidata :

•  Le français et notre communauté restent au centre du projet.
•  Ce n'est qu'un changement technique, toutes les décisions prises au fil des années restent d'application.
• Les pages du wiktionnaire telles qu'elles apparaissent aujourd'hui continuent d'être la finalité du projet.
•  Rien ne nous empêche de garder des parties rédigées en wikicode si on l'estime nécessaire.
• La licence n'est pas la même.

Je me rends bien compte que tout cela est compliqué à mettre en place. Qu'un tel chantier serait gigantesque. Mais ce n'est pas une utopie... c'est même très raisonnable au regard de l'importance du wiktionnaire aujourd'hui, de sa pérennité, et des bénéfices visés. Au delà de ce que je propose, peut-on se demander quelle technologie est la plus adaptée à notre travail ? Mediawiki c'était pour une encyclopédie il y a 20 ans. (no troll ) --Hildepont (discussion) 23 février 2021 à 15:09 (UTC)

@Hildepont : Salut. Merci de ton message. Je suis entièrement d’accord. La vision à adopter me semble limpide. La question qui fâche reste de savoir comment atteindre ces objectifs. Parce que c’est pas avec 5 vœux tous les ans à la Wishlist qu’on va pouvoir atteindre ça. Et une équipe de développeurs, ça coûte des pépettes. Peut-être faut-il profiter de l’appel à projets lancés plus haut par @Rémy Gerbet WMFr :. Mais je sais pas si l’asso seule est capable de couvrir un tel projet. Lepticed7 (À l’immortalité !) 23 février 2021 à 15:31 (UTC)

Avoir une Wikibase pour et par les Wiktionnaires serait un moyen d’aller dans cette direction ; on profite des possibilités très intéressantes apportées par Wikibase pour les données lexicographiques mais on le fait à notre sauce, pas de manière imposée par le haut comme avec Wikidata (licence imposée contre l’avis de la communauté wiktionnaristes). Pamputt 23 février 2021 à 16:35 (UTC)

Je suis également favorable à une wikibase dédiée au wiktionnaire francophone. Chaque Wiktionnaire aurait la sienne. La puissance d’un telle projet serait phénoménale en terme de requètage et de toute l’exploration de la base. Lyokoï ^{(Discutez sur le péril mortel)} 23 février 2021 à 20:01 (UTC)

Je ne sais pas si c’est utile mais pour ce qui est de l’augmentation du nombre de pages qui résulterait du choix d’une langue par page, on arriverait, à première vue, à +167300 pages soit une augmentation de 4 % ce qui me semble ne pas être un problème en soit. — Unsui Discuter 24 février 2021 à 08:21 (UTC)

Pareil, une wikibase avec une interface de contribution bien adaptée, ça ouvrirait des perspectives en guidant d’avantage les nouveaux arrivant et en laissant moins de place aux erreurs d’inattention, de débutant, d’ignorance (je pense qu’il n’y a pas beaucoup de monde connaissant l’ensemble des règles d’organisation et les modèles qui vont avec)… Tu dis, Hildepont, que ce n’est pas du Wikidata, je suis d’accord, mais je pense que l’interface de contribution de cet outil est assez intéressante pour s’en inspirer. Elle guide bien l’utilisateur. Jpgibert (discussion) 24 février 2021 à 10:15 (UTC)

@Lepticed7 : Bonjour à tous, l'association peut tout à fait apporter son concours à un projet d'amélioration du Wiktionnaire avec la mise en place d'une Wikibase par exemple. Vu l'ampleur du projet ce ne sera sans doute pas très simple à chiffrer et il faudra sans aucun doute interagir avec les équipes techniques de la WMF mais cela ne m'inquiète pas. En plus, pour un projet comme celui-là, il doit être possible de trouver des financements externes. Si la communauté est partante cela pourrait être pas mal de l'inscrire dans le prochain plan d'action de l'association pour au moins entamer des travaux préparatoires et réaliser une "étude" de faisabilité de ce projet, une ébauche de cahier des charges, un budget prévisionnel ainsi qu'un cahier des charges etc... Mes compétences techniques sont assez limitées donc je ne m'aventurerais pas plus loin :) Discussion très intéressante à lire, merci, Rémy Gerbet WMFr (discussion) 25 février 2021 à 09:02 (UTC)

A propos d’une "wikibase dédiée au wiktionnaire francophone" : j’aimerais comprendre de quoi il s’agirait. Déjà, qu’est-ce que ça veut dire, wikibase ? La base dédiée au wiktionnaire francophone, on l’a déjà, bien sûr. L’interface de contribution, on l’a déjà aussi, bien sûr. Il est certain que la contribution est trop complexe, avec cet envahissement de modèles, mais il ne tient qu’à nous que ce soit plus simple. S’il s’agit du genre de base imaginée par Wikidata, je reste totalement contre. Pour arriver à ça, il faut forcément faire des hypothèses simplificatrices, alors que la description de la langue oblige à rester très souple. Le format texte actuel est idéal pour nous : à la fois extrêmement simple (sur son principe général, en tout cas) et extrêmement souple. Tout ce qui facilite la contribution est bon à étudier, mais tout ce qui complique est à éviter. J’en ai déjà parlé, mais j’avais commencé un jour à imaginer un format de base de données pour un genre de wiki (pas un dictionnaire), sur des principes très classiques, les mêmes que pour la base de dictionnaire de Wikidata. J’ai fini par me rendre à l’évidence : le format texte standard des wikis (un titre de page associé à un contenu de page, éventuellement en utilisant des modèles pour aider à la contribution) était bien meilleur. Lmaltier (discussion) 25 février 2021 à 12:49 (UTC)

Je pense qu'il y a une forme de consensus sur le fait que wikidata ne convient pas. Et je ne pense pas que le rôle (éventuel) de cette wikibase serait de vouloir mettre en place un schéma capable de représenter un système linguistique. En tout cas, ce n’est pas ce que j’envisageais personnellement.

Le premier intérêt que je vois dans l’utilisation d'une base pour ce que nous faisons, c’est de permettre la construction de liens entre les éléments. Aujourd’hui si on veut connaitre les liens entre les mots, de ce que j’ai compris, il faut analyser le wikicode et suivre les liens qui sont dedans en parcourant par la même occasion les modèles qui eux aussi peuvent construire des liens. Ceci rend complexe l’interrogation automatisée (ou non) des informations que nous collectons et agrégeons chaque jour un peu plus. Avec une wikibase, les liens HTTP deviendraient la version visuelle des liens en base au lieu d’être la source (avec tous les risques que ça comporte d’erreur et de maintenance).

<fantasme> Si on trouve en base une "table" lexème avec une graphie, une langue, une définition, des liens vers un ou plusieurs exemples, une ou plusieurs illustrations, une prononciation… on pourrait imaginer de construire une page graphie qui serait la composition de l’ensemble des lexèmes ayant la même graphie. Ces lexèmes organisés par langue, les définitions agrégées dans la même section, avec pour chaque le ou les exemples qui y sont associés, etc.

Ca autoriserait des usages auxquels on ne pense pas aujourd'hui. Comme celui de pouvoir proposer automatiquement une liste d’exemples déjà en base contenant le mot qu'on est en train de créer.

Ca permettrait également d’envisager d’autres structurations des articles pour des usages différents. Par exemple, j’ai envie de me constituer un dictionnaire des termes marins, je pourrais, en jouant sur des filtres, produire une version "maritime" du wiktionnaire sans pour autant le dupliquer ou avoir une version figée. A vot’ bon cœur</fantasme>

Mais je pense que ça s’écarte de la proposition initiale de Lepticed7 qui partait plutôt que une logique wiki mais tronçonnée par langue (à tout le moins). Jpgibert (discussion) 25 février 2021 à 13:39 (UTC)

@Jpgibert : Oui ça s’écarte du sujet, mais je crois comprendre que l’idée est de pouvoir faire des recherches via des requêtes simples genre SQL sans avoir à faire des recherches complexes dans des champs texte. Si c’est ça, une idée : qu’un outil (fourni par Wikidata par exemple, ou autrement) crée de temps en temps une grosse base structurée reprenant absolument tout le contenu du Wiktionnaire, avec la même licence, mais en mettant ce contenu sous forme structurée avec plein de tables liées entre elles : graphies, mots, définitions, synonymes (avec un sens précis pour la relation), etc. Problèmes : 1. dès qu’on change quoi que ce soit sur la structure des pages du Wiktionnaire ou la syntaxe associée, il faudrait adapter l’outil en conséquence. 2. comment respecter les licences, les historiques étant associés aux pages ? J’en profite pour redire que le contenu est déjà exploitable par programme, puisque d’autres l’ont souvent exploité, même s’ils auraient probablement préféré qu’on leur facilite plus la tâche, et même s’ils auraient peut-être pu faire plus avec une structure différente. Lmaltier (discussion) 25 février 2021 à 17:44 (UTC)

@Lmaltier : Pinaillage, ce n’est pas du SQL mais du fr:SPARQL, un langage pour faire des requêtes sur le web entier dans des graphes ;) . Par ailleurs dans ces reqûetes on peut aussi utiliser les moteur textuel de wikipedia grâce à un service dédié : cf. la doc et rechercher dans les catégories de Wikipedia ou des autres wikis, et les contenus textuels également. Ça permet bien des combinaisons. TomT0m (discussion) 1 mars 2021 à 15:14 (UTC)

Ok, visiblement, il y a des demandes, donc petit cours :

• le Web sémantique, aussi appelé Web 3.0, est un moyen d’envisager le web comme un dépôt d’informations qui peuvent être exploitées et partagées. Le but est d’ajouter des données qui décrivent les données : c’est ce qui donne les données structurées.
• les données structurées sont donc de l’information supplémentaire rajoutée en complément de l’information existante. Il s’agit de méta-information utilisée pour les moteurs de recherche ou les outils de requêtage. Par exemple, utiliser le modèle {{lang}} pour indiquer que telle portion de texte est dans cette langue, c’est des données structurées. Ça donne de l’information à la machine. Par contre, utiliser les boites à flexion ne fait pas de données structurées. Les différentes flexions ne sont pas taguées en tant que telles et ce n’est pas exploitable par une machine. La locution a un sens très précis dans le contexte du Web sémantique. Ce n’est pas parce qu’il y a une structure de présentation (par exemple à l’aide d’un tableau) que les données sont des données structurées.
• comment faire des données structurées ? Le début de la méta-donnée, c’est les fichiers avec une grammaire stricte, genre XML, qui indique à peu près à quoi correspond chaque champ dans le fichier. On sait ce qu’est la donnée. Mais XML, c’est le début et il est possible d’aller bien plus loin. Au moins jusqu’à RDF (Resource Description Framework, « Cadre de Description des Ressources »). RDF, c’est super simple à comprendre ! Déjà, pour avoir une structure exploitable, ça utilise XML (y a d’autres syntaxes, mais osef). Et on vient de voir que le XML permet de structurer les données. Le RDF donc, c’est un outil qui utilise des triplets du type . Pour les logiciens, c’est équivalent à prédicat(sujet, objet). Quelques exemples :
  •  : ici, j’ai encodé que Milou est l’animal de compagnie de Tintin
  •  : ici, la couleur de Milou
  •  : et ici, je dis que Milou est un chien
• le plus gros avantage là, c’est que dans mes trois "phrases", Milou désigne la même entité. Il ne s’agit pas uniquement d’une chaine de caractère, mais il s’agit de la même chose. En l’occurrence, le chien blanc de Tintin.
• maintenant qu’on a ce cadre de description, on en fait quoi ? Ben, on peut avoir envie de l’utiliser pour sémantiser la plus grande encyclopédie du monde. Mais pour ça, il faut un logiciel qui fonctionne avec Mediawiki (c’est l’un des logiciels des wikis). Et du coup, on crée l’extension Wikibase. Donc, Wikibase, c’est le nom de l’extension pour faire du RDF. Et par métonymie, on désigne chacune de ses utilisations par wikibase (avec une minuscule). Donc, comment fonctionne Wikibase ? Grâce à deux choses : le dépôt (Wikibase Repository), où sont stockées les données et le clien (Wikibase Client) qui sert à interagir avec le dépôt (en gros, la base de données et l’interface de contribution).
• quid de Wikidata ? Ben, c’est juste une wikibase. C’est la wikibase utilisée par les projets Wikimedia, mais voilà, c’est vraiment le bout de la chaine.
• il existe d’autres extensions Mediawiki de sémantisation. Par exemple, Semantic MediaWiki, où, à la place d’utiliser un client distinct, les données sont directement annotées dans le texte (voir la page wikipédia pour les exemples)

Maintenant, il faut évaluer laquelle des différentes solutions est la meilleure pour nous. Des deux solutions proposées ci-dessus, Semantic Mediawiki ne me semble pas envisageable tant que notre unité de description est la graphie.

Je pense que dans notre cas, la meilleure solution est la wikibase. Mais il ne faut pas faire ça n’importe comment ! D’abord, le modèle de données. Il existe déjà des ressources : OntoLex. Toutefois, OntoLex est encore incomplet. Il est développé par module et n’a pas, par exemple de module de gestion de l’étymologie. (Au passage, le champ disciplinaire qui s’occupe du développement des modèles sémantiques, c’est celui de l’ontologie.) Mais ça n’est un problème. Nous pouvons faire une gestion hybride en utilisant des champs de texte sur les données non encore sémantisées/sémantisables. À savoir que le modèle peut évoluer sans problème. La contribution devra être adaptée. L’interface en fichier texte, ça sera plus possible. On sera plus proche d’un formulaire. L’avantage, c’est qu’il n’y a plus à se soucier des modèles. Je ne peux pas vous en dire plus sur l’interface. Ce qui est sûr, c’est que c’est un point super important et qu’il doit être enfantin de rajouter une information. Enfin la consultation pourra être faite à la carte. En effet, les données sont sémantisées. On peut donc choisir quelles données on veut. Donc, si on veut se faire un dictionnaire du vocabulaire maritime, il suffit de demander. Un dictionnaire français-espéranto ? Suffit de demander. Un dictionnaire attesté avec des auteurs québecois, suffit de demander. Pensez-y, et c’est possible.

Voilà, j’espère que ça permet d’éclaircir le sujet. Si vous avez des questions, n’hésitez pas ! Lepticed7 (À l’immortalité !) 26 février 2021 à 10:52 (UTC)

@Lepticed7 : Merci des explications (nous n’avons toujours pas de page wikibase, ce serait très utile). Wikidata peut faire ce qu’elle veut, tant qu’elle ne complique pas la travail des contributeurs ici. Ce que je crois comprendre, c’est la volonté de mettre sur le Wiktionnaire beaucoup d’informations sémantiques exploitables par les machines de façon très simple, et qu'on ne peut le faire qu’en compliquant sérieusement le code interne des pages. Je rappelle que le Wiktionnaire n’est pas un logiciel réalisé par des informaticiens, et ne doit surtout pas le devenir, mais un dictionnaire réalisé par des contributeurs de cultures variées (et le trop grand pourcentage d’informaticiens est un réel problème, bien que j’en fasse partie). L’oublier ne peut que conduire à l’échec, et je vois que tu en as bien conscience. Un énorme problème, c’est celui que je citais plus haut : la plus grande souplesse est requise quand il s’agit de langue, et là, ce serait se donner un carcan (on le voit bien avec Ontolex, qui n’a pas encore de module étymologie) : à chaque fois qu’on voudrait rajouter un type de section, il faudrait en passer par des modifications logicielles pour rajouter un champ de formulaire. Si on veut expérimenter ça, il faut le faire ailleurs, et pourquoi pas via Wikidata ? Ou alors, laisser des organismes extérieurs reprendre le Wiktionnaire en le mettant sous cette forme (y a-t-il déjà eu des essais allant dans ce sens ?) En tout cas, il ne faut surtout pas faire fuir les contributeurs, c’est vraiment très vite fait, ni réserver la contribution à des gens qui aiment la technique, ni limiter la contribution à du remplissage de divers champs de formulaires pour créer une seule page, ce qui pourrait aider certains contributeurs, mais en rendrait d’autres beaucoup moins efficaces (vraiment beaucoup moins), et même les dissuaderait complètement de participer. Le mieux est l’ennemi du bien, et il ne faut surtout pas casser la réussite absolument exceptionnelle que constitue le projet. Lmaltier (discussion) 1 mars 2021 à 11:03 (UTC)

Quelques précisions sur Wikibase et ses données lexicographiques par rapport à ce que j’ai lu plus haut:

• Sur la souplesse, le modèle de données est bien plus souple qu’il en a l’air. Par exemple il y a un ensemble de « sens » pour chaque lexèmes, qui sont annotable virtuellement avec tout ce que la communauté décide de pertinent comme annotation. Il peut s’agir de connotation, de niveau de langue, … mais aussi de tout ce que la communauté jugera utile: par exemple une liste des propriétés d’annotations et qualificatifs wikidata utilisés actuellement avec les sens. C’est évidemment extensible à l’envie communautaire mais on peut déjà facilement décrire les attestations, niveau de langue, traductions, les lexèmes dont celui-ci dérive pour l’éthymologie, écrire des « glose » (texte sur le sens dans toute les langues) et indiquer l’élément Wikidata correspondant au sens
• Sur le dernier point précédent, indiquer l’élément Wikidata correspondant au sens, ça ouvre des tonnes de possibilité intéressantes. Quel mot pour « chien » dans toute les langues ? Voilà la réponse en quelques lignes de code : https://w.wiki/33FJ — de manière pas si compliquée à obtenir et avec une communauté Wikidata qui répond si on veut obtenir des variantes ou utiliser des données. Pour les curieux et curieuses, la requête en 3 lignes de langage SPARQL : 

   select ?lexeme ?lemma (lang(?lemma) as ?langue){
    ?sense wdt:P5137 wd:Q144 .
    ?lexeme ontolex:sense ?sense ;
            wikibase:lemma ?lemma .
  }
  

  Ce serait une requête plus difficile à effectuer si il fallait aller piocher les données dans différentes Wikibase, Wikidata est une opportunité de collaboration sur les données lexicales entre toutes les langues qu’il serait à mon avis dommage de rater.

  Ce qui rend la chose facile est l’existence d’une propriété qui permet de relier l’élément Wikidata qui correspond aux chiens, que voici aux sens les lexèmes correspondant grâce à la propriété « élément pour ce sens » P5137. Ce lien n’est à ma connaissance pas fait actuellement dans le wiktionnaire, ou pour retrouver un article Wikipédia qui correspond à un sens d’un mot il faut utiliser le moteur de recherche. Avec une variante de ma requête par contre on peut retrouver facilement l’article Wikipédia correspondant dans la langue du lexème.

• Il y a des projet intéressants qui vont se monter autour des données lexicographiques Wikidata. Par exemple l’équipe de Wikipédia abstraite a lancé un wiki prototype d’annotation des mots d’une phrase par les lexèmes correspodants : cf. https://annotation.wmcloud.orghttps://dictious.com/fr/Main_Page C’est un prototype encore dans une phase très très expérimentale mais qui permet de montrer les potentialité en terme de collaboration : on peut annoter les phrases dans toutes les langues, et il y a des phrases en français mais aussi en Breton. On peut imaginer utiliser un tel outil, à terme, comme aide à la traduction dans les projets Wikimedia — imaginons par exemple dans les pages d’aide Wikimedia meta ou les pages des outils techniques les textes de référence en anglais annotés par les lexèmes correspondants — des possibilité de traduction du lexème seraient trouvables automatiquement, par exemple en complément automatique de ce que tape un traducteur en langue Farsi ou quelque soit l’autre.

Dans mes points précédents, j’ai essayé de montrer que contribuer aux données lexicographique actuelle offre des possibilités de collaborations linguistiques entre les différente langue relativement simple techniquement. Je crains que multiplier les projets par langue ne rende les chose bien plus compliquée et multiplie les difficultés techniques d’exploitation des données, et au final ne fasse que disperser les efforts. TomT0m (discussion) 1 mars 2021 à 12:13 (UTC)

Salut TomT0m et merci du message. J’étais personnellement convaincu de l’intérêt de Wikidata Lexèmes. Pour moi, il y a deux problèmes : l’incompatibilité des licences (on ne peut pas verser le contenu du Wiktionnaire sur Lexèmes sans enfreindre les licences) et le fait que le contenu de Lexèmes est actuellement inutilisable car le Lua nécessaire à requêter les lexèmes n’est pas encore développé. Lepticed7 (À l’immortalité !) 1 mars 2021 à 12:25 (UTC)

Enregistré sur Phabricator
T195895

Lepticed7 Sur le second point au moins, ça ne change rien que le wiktionnaire actuel utilise sa propre Wikibase, le code est le même. Celà dit sur ce point il semble que ça ait avancé récemment et que les fonctions lua soient implémentées (voir Phabricator).

Sur le premier point, oui c’est problématique, surtout pour les gloses je pense, ça freine les choses indéniablement. Est-ce une raison suffisante pour couper les ponts ? TomT0m (discussion) 1 mars 2021 à 12:36 (UTC)

@TomT0m : Question ? Y a-t-il une notion de sens dans Wikidata, indépendamment de la langue, comme j’en ai l’impression après avoir lu ça ? C’était le cas dans Omegawiki, mais ça ne peut pas marcher de façon générale, même si ça peut fonctionner à peu près dans certains cas (en particulier pour beaucoup de noms propres). Très souvent, le sens perçu est indissociablement lié au mot de la langue. Par exemple, quand on utilise le mot chien pour parler d’un chien, certains répondent parfois : non, ce n’est pas un chien, c’est une chienne, alors que d’autres ne diraient jamais ça. Et on applique aussi le mot chien pour d’autres espèces que l’espèce habituelle, sans que ce soit toujours parfaitement défini, c’est parfois assez flou. Un autre animal : la pétoncle : je me demande bien quel "sens" est associé à ce mot dans Wikidata, bien que ce sens soit clair pour des francophones : c’est le même sens que le mot anglais scallop (dans le sens du mollusque), mais limité à certaines espèces d’assez petite taille (je ne sais pas si on pourrait définir une liste précise de ces espèces, ça reste probablement flou et subjectif). Et on pourrait poursuivre à l’infini pour les noms d’animaux et les noms de plantes, mais aussi pour plein d’autres mots. Les sens d’un mot dans une certaine langue, c’est une notion floue et ça le restera, on n’y peut rien. Si on oublie ça, on va à l’échec. Lmaltier (discussion) 1 mars 2021 à 12:42 (UTC)

@TomT0m : J’ai discuté le mois dernier avec Lea Lacroix (WMDE) (d · c · b), et les fonctions n’étaient pas utilisables sur les wikis. Du moins, pas dans la forme indiquée dans le peu de documentation trouvable…

@Lepticed7 : cf. le ticket parent, ça va venir ce n’est qu’une étape mais ça montre que c’est en cours de développement actuellement. TomT0m (discussion)

De plus, en ayant notre wikibase, on ne dépend que de nous et non des autres wiktionnaires. Et nous pouvons organiser notre contenu en respectant la licence.

@Lepticed7 : J’ai bien compris ça, j’essaye de montrer l’intérêt et les possibilités de coopérations en bossant directement sur WD. Cela en vaut à mon avis la chandelle de tenter le coup. TomT0m (discussion) 1 mars 2021 à 13:15 (UTC)

@Lmaltier : Les lexèmes sont dépendants de la langue. Voir celui du chien. Lepticed7 (À l’immortalité !) 1 mars 2021 à 12:51 (UTC)

Evidemment… Mais le petit code qui a été cité (ligne où il y a les mentions incompréhensibles wdt:P5137 wd:Q144) fait quand même bien référence à la notion de sens, d’où ma question. Lmaltier (discussion) 1 mars 2021 à 13:05 (UTC)

@Lmaltier : Il y a une notion d’élément, qui n’est pas linguistique, cf. d:Help:Items/fr. C’est ce à quoi sont liés les articles Wikipédia dans chaque langue. Autant que faire ce peut on va essayer de faire en sorte qu’un élément soit non ambigu. Il peut y en avoir également pour la notion de « chienne », d’ailleurs un tel élément existe, c’est d:Q29642078 et ils sont créables au besoin. Les éléments de sens sont liés entre eux, par exemple dans l’élément chienne il est clairement exprimé grâce à « sous-classe de » qu’une chienne est un chien femelle. À ce niveau on est dans la sémantique et pas dans la linguistique.

Pour les choses de vocabulaire, ou linguistique, qu’on arrive pas à capter ou pas facilement par des moyens sémantiques (par exemple les pronoms ou les articles, de manière non exhaustive évidemment), il y a aussi des liens directs possibles entre les sens des lexèmes, par exemple il existe une propriété « traduction » qui permet de relier deux sens. Voilà un extrait des traductions actuellement indiquées de cette manière dans Wikidata : (j’ai limité à 200 mais c’est extensible et affiché également l’élément correspondant au sens si il y en a un). Le libellé de la propriété qui lie « sens » et « élément » est également resté, volontairement je crois, assez vague pour pas forcer une correspondance trop contraignante (c’est « élément pour ce sens »). Donc il y a de la place pour faire les choses de différentes manières au besoin. On peut aussi potentiellement rajouter autant de « qualificatif » qu’on veut sur un « sens » d’un « lexème », donc indiquer si la notion est éventuellement plus précises. Faudra voir à l’usage ce qui relève de la bonne pratique ou de la fausse bonne idée. TomT0m (discussion) 1 mars 2021 à 13:07 (UTC)

@TomT0m : Les éléments représentent bien des sens, non ? Et ils sont censés être indépendants des langues, à ce que je comprends. C’est ça qui pose problème. En réalité, les sens des mots dépendent des langues, sauf exceptions. Tout simplement parce qu’ils sont très souvent flous (même pour des mots aussi courants que table), que ce flou est différent selon les langues, et que Les traductions entre langues ne sont que des approximations. Lmaltier (discussion) 1 mars 2021 à 13:15 (UTC)

@Lmaltier : Oui les éléments font référence à des sens (sémantique = science du sens). J’ai pas du bien me faire comprendre parce que j’essaye d’expliquer dans mon message les différentes possibilités de gestion de ce genre de soucis. TomT0m (discussion) 1 mars 2021 à 13:21 (UTC)

@TomT0m et @Lmaltier : Concernant wdt:P5137 wd:Q144, il s’agit de récupérer les lexèmes reliés à l’élément chien (Q144 sur wikidata). Le problème que j’ai, c’est que Wikidata est assez mauvais ontologiquement. Par exemple, je vois l’élément pour le chiot, la chienne, mais pas pour le chien mâle. Je me doute que cet élément est confondu avec celui de l’espèce, mais ce n’est pas correct. En français, il n’y a pas de différence de mot, mais certaines langues admettent une différence de mot pour désigner l’espèce et le genre. On pourrait écrire plusieurs livres pour montrer tous les problèmes ontologiques de Wikidata. C’est pourquoi je pense qu’un wikibase, qui pourrait être commune aux wiktionnaires, mais différente de wikidata, est nécessaire. Wikidata est un immense foutoir qui n’est pas exploitable lorsqu’on veut décrire des mots. Lepticed7 (À l’immortalité !) 1 mars 2021 à 13:34 (UTC)

Un bon exercice pour tester Lexèmes serait de prendre parmi nos meilleures entrées et voir combien d’informations on peut y mettre. Lorsque l’API pour requêter Lexèmes sera là, l’exercice inverse (générer une page depuis les infos de Lexème) pourra être fait. Lepticed7 (À l’immortalité !) 1 mars 2021 à 13:39 (UTC)

@Lepticed7 : Wikidata ne demande qu’à être enrichie ontologiquement et collaborativement. N’importe qui peut rajouter le concept de chien mâle dans Wikidata en lui créant un élément. Tu auras tout autant de mal à repartir de rien et à recréer un projet avec à peu prêt les même buts que Wikidata qu’à modifier Wikidata. Probablement plus, en fait, tout en dupliquant le travail entre les différentes langues. Quel intérêt ? Avoir un Wikidata en anglais, en français, en Breton, en je ne sais quoi ? Tous incomplêts ? Comment tu fais pour faire tous les liens entre les concepts de chien dans toutes ces Wikidata alternatives ? Le principe de Wikidata était de justement un peu centraliser certaines choses pour éviter les duplications … comme les liens interlangues. Faudrait par refaire la même choses avec des liens « interitems » dans toutes les combinaisons possibles. TomT0m (discussion) 1 mars 2021 à 13:48 (UTC)

@Lmaltier : J’ai étendu la requête que j’ai fait plus haut sur les chiens pour montrer comment on retrouve du vocabulaire également sur les chiens ou les races de chiens : en incluant les concepts qui sont des sous-classes de chiens, comme chienne ou chiots. Ça trouve également des races de chiens. C’est avec ce genre de technique qu’on pourra retrouver des correspondance de sens un peu plus lâches et moins exactes, pas explicites. TomT0m (discussion) 1 mars 2021 à 13:48 (UTC)

Je n’ai pas lu tous les derniers échanges mais sur le point qui soulève le problème potentiel de diluer les efforts en ayant les données lexicographiques de Wikidata d’un côté et les potentielles Wikibases des Wiktionnaires de l’autre, c’est bien ce qui avait été signalé lorsque la licence CC0 a été imposé unilatéralement. Donc on est sur un point de blocage de ce côté là étant donné qu’il est compréhensible que les contributeurs et contributrices au Wiktionnaire ne veulent pas recommencer le travail qu’ils et elles ont fait depuis 15 ans. Bref, pour sortir de cette impasse, on peut espérer que le développement des fédérations de Wikibase ait lieu et donne naissance à quelque chose d’exploitable (par exemple en requêtant dans la fédération avec Wikidata et le wikibase Wiktionnaire par exemple). Pamputt 1 mars 2021 à 14:24 (UTC)

@Pamputt : Il n’y a rien en vue pour utiliser dans les déclarations des valeurs d’autres Wikibase, il me semble, donc faut pas trop compter la dessus. Discutez-en avec l’équipe de développement de Wikidata. Il y a de la fédération entre les serveurs sparql, ou on peut utiliser un fragment de requête d’un autre serveur dans par exemple le point d’accès sparql de Wikidata, mais c’est pas du tout la même chose. De plus ce serait un beau bazar si chaque communauté linguistique développe son propre modèle indépendamment des autres, ça rendrait sans doute beaucoup plus difficile de développer des techniques de traductions qui utilisent les données dans d’autres langues si les modèles, les propriétés et les conventions sont différentes et surtout pas coordonnées … TomT0m (discussion) 1 mars 2021 à 14:35 (UTC)

@Lepticed7 : Wikidata est un immense foutoir qui n’est pas exploitable lorsqu’on veut décrire des mots : mais Wikidata ne cherche pas à être un dictionnaire, ni à inclure un dictionnaire, il me semble… Je rappelle ce qu’est un dictionnaire : quelque chose qu’on peut consulter quand on veut des renseignements sur un mot. Wikidata ne correspond pas à ça, et j’imagine que ce n’est jamais arrivé que quelqu’un soit allé sur Wikidata pour obtenir des renseignements sur un mot, alors qu’il a le Wiktionnaire à sa disposition. Rien n’est fait pour : Wikidata n’est qu’une base de données, avec un langage de requêtage associé. En tout ça, c’est ce que je crois comprendre.

@Lmaltier : Ce que je veux dire par là, c’est que les concepts (que les mots désignent) sont très mals rangés. Tu le sais maintenant, j’adore les relations sémantiques (synonymie et toute la clique). Et si les mots pointent vers les concepts et les concepts sont liés entre eux, alors, il est possible de déduire les relations entre les mots. Wikidata est trop en pagaille pour pouvoir faire ça. Voilà, c’est ça que je voulais dire . Lepticed7 (À l’immortalité !) 1 mars 2021 à 14:49 (UTC)

@TomT0m : Je ne parlais pas de races de chiens ou de ce genre de chose : je disais juste que le mot chien (en parlant d’un animal) est suffisamment flou pour que différentes personnes lui donnent des sens légèrement différents, y compris en l’utilisant pour des espèces différentes de Canis lupus. Le mot chien correspond à une image mentale suffisamment floue pour ça. Wikidata ne demande qu’à être enrichie ontologiquement : même en y adjoignant la notion de sens flou ? Cela m’étonnerait, puisque ce n’est pas du tout conforme aux idées de base derrière le projet. Je vois l’utilité de Wikidata pour les recherches manuelles (et encore cette utilité est limitée à quelques informaticiens ou personnes très adeptes de la technique). Le Wiktionnaire est un dictionnaire, tout comme Wikipédia est une encyclopédie, et Wikidata une pure base de données, il n’y a pas à sortir de là. Vu les hypothèses simplificatrices absolument énormes faites, et la complexité du langage, je ne vois pas bien l’intérêt pour des application de traitement des langues d’utiliser Wikidata (ni une autre wikibase fondée sur ce genre d’idées, même améliorée). Je suis reparti de ma journée au CNRS sur la question le 12 janvier avec la conviction que l’avenir dans ce domaine, c’est l’intelligence artificielle, les réseaux de neurones… Dans ce cas, le fait que le sens soit souvent flou n’est pas un problème. On pourrait se dire que, par exemple, ça pourrait être utile à un système de traduction automatique de parfois consulter un dictionnaire, quand il rencontre un mot inconnu et difficile à comprendre (même en essayant de l’analyser). J’ai posé la question à un spécialiste, et la réponse est non : pour l’instant, il n’y a pas encore de recherches sur la question. Je pense que ça va venir un jour, mais que le format textuel actuel sera alors pleinement approprié, aussi approprié pour une intelligence artificielle que pour une intelligence humaine. Le Wiktionnaire doit rester un dictionnaire, et garder les humains comme lectorat visé ! Lmaltier (discussion) 1 mars 2021 à 14:35 (UTC)

@Lmaltier : Évitons de partir d’idées préconçues, ça ferme des porte. Wikidata est un projet ouvert. Si les élément sont voulus comme des sens relativement définis, ça n’empêche pas d’introduire du flou d’une manière ou d’une autre : tout est extensible. Juste pour illustrer on pourrait imaginer par exemple créer une propriété « sens approximatif de » (ou des variantes genre « sens hypéronimique de » …) qui lie le sens d’un lexème à un élément et arriver à cette introduction de flou. Par ailleurs il ne faut surtout pas voir ça en opposition avec tout ce qui est algorithmes d’apprentissage. Un des enjeu de l’intelligence artificielle par ex. c’est de comprendre ce qui se passe en:Explainable artificial intelligence — bien souvent un algo d’apprentissage fournit un résultat qui fonctionne comme une boîte noire, ça fournit une solution mais personne ne sait vraiment comment ce résultat est obtenu. Les données lexicographiques et les liens explicites pourraient être des pistes qui permettent d’éclairer les solutions de traductions. En plus les données lexicographiques de Wikidata sont complètement multilingues et permettent de faire des liens transversaux, alors que les algorithmes sont souvent dépendant de paires de langues et doivent faire toutes les combinaisons. L’IA est très certainement une voie très intéressante en linguistique et en traduction, mais pas nécessairement l’alpha et l’oméga de la panacée pour tout à elle seule ! TomT0m (discussion) 1 mars 2021 à 14:53 (UTC)

(j’ajouterai que l’IA linguistique, en pratique c’est Google et/ou Deepl/linguee, des gros acteurs propriétaires qui gardent bien précieusement leurs jeux de données et leurs algorithmes, de bonnes grosses boîtes noires qui profitent sans doute sans trop de problèmes des données du wiktionnaire ou de Wikipédia pour leur apprentissage, en plus de bien d’autres sources de données. Bref, je doute que la licence du wiktionnaire soit un gros obstacle pour qu’ils en utilisent les données tout en profitant du fait qu’on doive utiliser leur serveurs pour faire du trafic. On lutte pas vraiment à armes égales avec eux, ces énormes jeux de données sont nécessaires aux algos d’apprentissages. Raison de plus pour se serrer les coudes entre projet pour fournir des alternatives ? TomT0m (discussion) 1 mars 2021 à 15:08 (UTC))

Le spécialiste que j’ai interrogé m’a dit le contraire à propos de la consultation des dictionnaires, qu’il y avait suffisamment de problèmes à régler avant, et je n’ai aucun mal à le croire… Mais j’aimerais bien que ce soit le cas, que le Wiktionnaire leur soit utile pour ça… Fournir des alternatives ? S’il y a un projet de la Fondation créé pour faire de la traduction automatique, j’aimerais bien aller voir ça de près, ça m’intéresserait. Mais ce n’est pas du tout le rôle du Wiktionnaire, ni d’un quelconque dictionnaire… Lmaltier (discussion) 1 mars 2021 à 15:18 (UTC)

@Lmaltier : L’intérêt d’un dictionnaire n’est évidemment pas de faire la traduction bien évidemment, c’est de fournir des données pour aider à la traduction. C’est le cas pour un traducteur humain d’ailleurs. Sans même parler de traduction automatique totale et automatique, il y a moyen d’utiliser les données fournies par un dictionnaire pour aider à la traduction, faire des suggestions de traductions par exemple. Et là des données structurées peuvent aider !

 Il y a forcément un vieil intérêt pour la traduction dans le monde Wikimedia cf. cette page sur meta ou encore celle là et un outillage de traduction de pages qui ont utilisé/utilisent des services externes pour suggérer des traductions genre Apertium. Il y a les outils d’aide à la traduction sur les wikis multilingues, les outils d’aide à la traduction d’articles d’une wikipédia à une autre. Tout ça avec plus ou moins de succès forcément, je pense pas qu’il y ait vraiment d’outil de traduction automatique Wikimedia fonctionnel à l’heure actuelle — L’outil « ContentTranslation » propose d’utiliser Google translate ou Yandex pour fournir les ébauches de traductions d’anglais en français, donc des APIs externes.

Une approche originale est celle de du projet Wikimedia Abstract Wikipedia qui vient de démarrer vise non pas à traduire une langue dans une autre mais carrément à créer une langue pivot à l’aide des données Wikidata, pour écrire des articles sur tous les sujets, et du code pour traduire cette langue pivot dans toutes les langues qui n’auraient pas d’articles sur ce sujet. Il est prévu qu’il utilise les données Wikidata (éléments et lexèmes/données linguistiques) — cf. « Anglais » la lettre d’info Wikipedia abstraite. TomT0m (discussion) 1 mars 2021 à 15:45 (UTC)

Je découvre (mais le lien vers le projet ne marche pas)… Quelles genres de techniques sont-elles envisagées ? Simplement considérer que les lexèmes de différentes langues liés au même élément Wikidata peuvent être remplacés les uns par les autres, et se concentrer seulement sur les petits mots outils pour le reste de la traduction ? Je n’ai pas trouvé de réponse à cette question, mais il est normal que Wikimedia soit séduit par l’idée. Encore faut-il y arriver, et je ne vois pas bien comment on pourrait arriver à un résultat de qualité en procédant comme ça (si ma supposition est correcte)… Lmaltier (discussion) 1 mars 2021 à 16:09 (UTC)

@Lmaltier : Le choix des lexèmes, je ne pense pas qu’il y ait vraiment rien de précis sur la table pour l’instant. Il y a pleins de points à éclaircir, la production de la langue abstraite qui sera communautaire, principalement la création des « constructeurs ». Il y a quelques exemples dans l’article qui décrit le projet : https://arxiv.org/pdf/2004.04733.pdf . La traduction dans les différentes langues c’est plusieurs projets : un « méta projet » à part entière, wikifunction, qui stockera le code de traduction en plus d’être une sorte de wiki de fonctions au sens informatique du terme, utilisable à d’autre fin, qui stockera les traducteurs et permettra de les écrire. Les traducteurs pourront traduire en plusieurs passes potentiellement les contructeurs en d’autres constructeurs qui représenteront des éléments de langue de plus en plus concrêts, éventuellement partagés entre des langues de structures similaires, et en partant de formulation potentiellement très abstraites. Beaucoup dépendra de la communauté qui fera des choix important, le projet fournira l’architecture et les interface nécessaires à la création de la langue abstraite et des traducteurs, le reste dépendra de la communauté. TomT0m (discussion) 1 mars 2021 à 16:31 (UTC)

Est-ce que je me trompe, ou est-ce que l’idée est de rédiger à la main cette Wikipédia abstraite sous forme d’un code utilisant (entre autres) des éléments Wikidata ? Cela règlerait (en partie) un des gros problème de la traduction automatique, à savoir comprendre dans quel sens un mot est utilisé dans un texte. Mais je n’ose pas imaginer la complexité, et j’imagine mal qu'il y ait beaucoup de volontaires pour créer ces pages… Lmaltier (discussion) 1 mars 2021 à 16:44 (UTC)

On verra, disons que si le nombre de personnes sera probablement au moins au début bien moins important qu’une grosse communauté Wikipédia le fait que ce soit une langue indépendante met toutes les communautés linguistiques sur un pied d’égalité et piocher un petit pourcentage dans toutes les communautés pourraient faire finalement un nombre de contributeurs qui rivalise avec la Wikipédia en anglais, qui sait ?

Le système sera fait pour que tout le monde puisse contribuer dans sa langue. Tout possèdera un libellé, à la manière des éléments Wikidata qui sont traduits dans toutes les langues. Les constructeurs et leurs paramètres, par exemple, tout sera des ZObject avec des libellés dans potentiellement toutes les langues, et une interface localisée donc. Il est prévu éventuellement des aides à la traduction avec des facilités pour que tu tapes une phrase dans ta langue et qu’une proposition te soit faite de version en langue abstraite, à terme … Rien n’est gagné d’avance évidemment, mais si un projet peut réussir un truc pareil je mettrai mes billes sur celui là :) Par exemple la traduction mot dans ta langue -> élément peut-être relativement efficace grâce aux données lexicographique avec un lexique suffisamment complet et des données suffisamment développées. Et puis si le système se goure c’est humainement rattrapable derrière. C’est un cercle vertueux qui pourrait tirer tout le monde vers le haut, tu rédiges, ça donne l’opportunité d’améliorer les données lexicographique et motiver d’autre à améliorer les choses dans leur langue de concert. Ormis les traducteurs qui risquent d’être quelque chose d’assez compliqué techniquement et qui vont nécessiter des compétences peut-être assez pointues en code et en linguistique, il y a de la place pour un peu tout le monde. TomT0m (discussion) 1 mars 2021 à 17:09 (UTC)

Je voudrai que le Wiktionnaire progresse sur de nombreux aspects que je ne peux pas explorer actuellement, alors que je pourrai le faire dans une base de données liées, grâce à l’inférence ou à des requêtes complexes. Et je suis curieux aussi. Quelques pistes, n’hésitez pas à compléter avec vos envies ou à expliciter plus bas comment vous obtiendriez ces informations dès aujourd’hui Noé 1 mars 2021 à 17:59 (UTC)

• Combien d’exemples proviennent de publication du Sénégal ?
• Les exemples écrits par des femmes proviennent-ils davantage de la littérature ou de la presse ?
• Quelle est la répartition chronologique des textes utilisés en référence d’exemples ?
• Quelles sont les définitions qui sont des usages seulement en Belgique dans le lexique de la boulangerie ? (Petscan peut croiser des catégories mais avec de nombreuses erreurs car il ne vérifie pas si ce sont les mêmes définitions qui ont les deux étiquettes, seulement si les deux étiquettes sont présentes sur la même page)
• Quelles pages ont des illustrations prises dans des pays d’Afrique ?
• Quels sont les domaines où l’on retrouve le plus de mots empruntés à l’anglais ?
• Quelles sont les étiquettes les plus utilisées pour les définitions marquées comme Suisse ?
• Quels sont les acronymes qui sont de genre masculin alors que le premier mot de l’acronyme est de genre féminin (ou l’inverse) ?

Bonjour à tous. Quelqu'un peut-il m'expliquer POC, transclusion, dev, regex, Lua et SQL sur ma page de discussion ? Pas urgent. Merci à Lmaltier pour wikibase (question et obtention de réponse). Bonne journée. DenisdeShawi (discussion) 1 mars 2021 à 18:37 (UTC)

De tout évidence, je ne sais pas comment vous y renvoyer, mais sur ma PdD, vous trouverez ce titre. Mille excuses DenisdeShawi (discussion) 1 mars 2021 à 18:39 (UTC)

Le mieux, ce serait d’aller voir d’abord les définitions dans le Wiktionnaire, non ? Noé 1 mars 2021 à 18:48 (UTC)

Bonjour, j'ai enfin pu prendre le temps de lire tout ces échanges. Je suis très enthousiaste de voir la communauté aussi intéressée et désireuse d’avoir des données plus simplement requêtables et réutilisables. Ça me semble aller globalement dans le même sens de que ce qui motive ma proposition en réponse à l’appel à projet Wikimédia France, que j'avais pourtant fait avant de lire cette section. Je précise que cette proposition n'a rien de figée : nous pouvons encore pleinement la remanier ensemble que ce soit avant la fin de l'appel à projet dans la perspective de cette candidature ou en dehors et au-delà sans ce soucier de cette candidature.

Côté Wikidata Lexeme, la dernière fois que j'ai regardé, il n'y a rien qui m’y intéresse, au sens où c'est vraiment l’antithèse de ce qu’il me semblerait souhaitable de voir mis à disposition du Wiktionnaire :

• imposition d’une licence qui est aux antipodes des valeurs qui m’animent
• un modèle de données intimement lié à un schéma statique et un parti un parti pris pour un modèle lexicologique centré sur l'abstraction de lexème

Le côté triplet prédicat, sujet, objet, paraît d’un réductionnisme impropre à modéliser une base de connaissances qui se soucie un tant soit peut d’un lien avec l’effectif. C’est assurément suffisant pour tout un tas de cas d’utilisation ; mais fondamentalement incompatible avec tout projet souhaitant incorporer une reconnaissance explicite des limites représentationnelles et de leurs impacts sur des assertions visant une objectivité la plus scrupuleuse que puisse exprimer une assertion. Les données ont toujours un sens pour un agent interprétant dans un contexte données. Donc le minimum vitale que je m’attendrais à voir pour un modèle de projet comme Wikidata c’est un quintuplet agent, prédicat, sujet, objet, contexte. Un projet comme Wikidata, en tout cas à mon sens, devrait viser à exprimer « Qui énonce quoi à propos de quoi dans quel contexte et par quels termes ? ». Et certainement pas « Quelles sont les attribus essentielles de tel chose ? ». Bon je disgresse un peu par rapport à notre sujet centrale, mais Wikidata Lexeme abonde il me semble exactement dans la même direction.

@Psychoslave : Tu devrais re-jeter un coup d’euil au modèle de donnée de Wikidata parce que c’est pas du tout réductible à des triplets sujet-prédicat-objet. Par exemple chaque lexème possède un ensemble de sens et un ensemble de formes.

Les formes comportent un ensemble de « déclarations », cf. d:Help:Statements/fr, qui ne sont elles même pas des triplets. Chaque déclaration possède une propriété et une valeur principale mais aussi un ensemble de qualificatifs qui permettent d’exprimer et préciser autant de choses, autant qu’on veut. Ça permet sans soucis de représenter « Qui énonce quoi à propos de quoi dans quel contexte et par quels termes ? » : les termes sont représentés par des lexèmes, ce qu’ils veulent dire par des sens, et le « qui et dans quel contextes » par une ou deux déclarations, précisables à l’envie par des qualificatifs.

Il y a aussi un ensemble de déclarations sur les lexèmes eux mêmes.

D’autant que les propriétés et les qualificatifs sont communautaires et que le vocabulaire est donc extensible à volonté de la communauté. TomT0m (discussion) 5 mars 2021 à 10:59 (UTC)

J’ajoute que c’est grâce au moteur de requête assez facile de passer d’un modèle centré sur les lexèmes à un modèle basé sur les domaines, c’est même possible de faire de la transformation de graphe RDF en graphe RDF. Par exemple, les interprêtes d’un rôle sont présents sur les éléments des pièces de théâtre, dans Wikidata. Les rôles interprétés ne sont pas présents sur les éléments des acteurs, ni sur les éléments des rôles. Pourtant on peut retrouver facilement qui a interprété le rôle d’un personnage inspiré de François Ier pour reprendre l’exemple d’hier :

SELECT ?acteur ?acteurLabel ?pièce ?pièceLabel WHERE {
  ?pièce p:P161 [
    ps:P161 ?acteur 
    ; pq:P453/wdt:P1074* wd:Q129857
  ]
    
  SERVICE wikibase:label { bd:serviceParam wikibase:language ",en". }
}

qui donne ce résultat. Donc la question de la perspective prise n’est absolument pas gênante pour en adopter une autre. TomT0m (discussion) 5 mars 2021 à 11:38 (UTC)

Merci d’avoir mis en lumière ces aspects. J’abonde en ton sens il me semble, en disant qu’effectivement qu’un point très important d’une telle structuration est qu’elle facilite grandement le fait de basculer d’un modèle à un autre. Encore une fois, il y a beaucoup de points que je trouve indéniablement techniquement très bon avec Wikidata.

Je trouve vraiment dommage qu’il soit couplé à une volonté de forcer un modèle sociale abject, sinon ça fait longtemps que je m’y serais plongé avec grand intérêt.

Bien sûr, techniquement, je le trouve quand même assez rebutant : le XML moins j’en vois, mieux je me porte ; les P123, Q45 et autres L6789, c’est franchement un summum d'antipattern: ni UUID, ni forme en anglais, poser le cul entre deux chaises et opter pour la solution qui retient le pire des deux alternatives les plus évidentes… Bref, je pense qu’il y aurait beaucoup de chose qui serait préférablement implémenté autrement…

Mais, le bousin est là et il permet de faire le taf, et ça je pense que ça balaie largement tous les détails imbuvables du socle. D’autant que ces gros tas de crasse peuvent se cacher avec plus ou moins de succès sous le tapis d’une IHM en mode clickdrome. Donc, si y a d'autres personnes motivés pour mettre quelque chose en place, « même » sur une base comme Wikidata Lexeme, mais sur une instance distinct qui permet de travailler avec la même licence que le Wiktionnaire, je suis fort motivé à apporter mon aide. Sur la licence, je serais même intéressé à adjoindre une ODBL (en plus de CC-BY-SA 3.0 unported) pour les contributions faites à travers ce potentiel projet annexe au Wiktionnaire, mais je ne crois pas que ce soit légalement possible, et OSM semble confirmer cela. --Psychoslave (discussion) 5 mars 2021 à 16:59 (UTC)

Le XML est totalement (presque) inexistant en pratique. Exemple tiré de d:Wikidata:Data_access avec Douglas Adams : Un lien vers les données sur Douglas Adams en json. Il y a également des représentations des mêmes données en différentes variantes de RDF : .ttl or .nt , seul le .rdf est du XML. Il y a également évidemment le point d’accès sparql, qui permet de récupérer différents formats genre du CSV parmis d’autres, et d’autres choses encore genre une interface linkeddatafragments et même un point d’accès graphQl qui permet également de sortir du json (je crois que ça marche pas avec les données lexicales cela dit)

En bref, techniquement, il y en a pour tout les gouts.

Le choix des identifiants numériques se justifie : En principe, on a quasi pas besoin de les utiliser, dans l’interface on utilise sa langue et l’autocompletion, et pareil dans le point d’accès sparql ou il y a un système de complément avec ctrl+espace . Je crois que le choix a été de ne pas favoriser l’anglais par rapport aux autres langues, et ça permet surtout d’avoir un identifiant stable : on a pas de renommage de page qui pourrait casser les références ou de noeuds qui changent d’identifiants au petit bonheur des modifications comme sur OSM. On crée un élément, il lui est attribué un numéro, point. Ça évite de se prendre la tête à trouver un libellé en anglais qu’on regrettera pas. Si on change le libellé de cet élément en anglais plus tard, le numéro reste le même et ça ne risque pas de casser les requêtes. Et … c’est quand même plus simple à manipuler qu’un long uuid encore plus abscons.

Sur la licence, pour moi il est un peu tard pour épiloguer, le choix est argumenté là si tu n’as pas déjà lu, je commenterai pas plus que ce que j’ai dit plus haut. TomT0m (discussion) 5 mars 2021 à 18:33 (UTC)

Oh, j'ai déjà creusé le sujet bien plus en profondeur, confère L’émergence des banques de données posomégaliques: enjeux, et prospections pour le mouvement de la culture libre : Le cas de Wikidata. --Psychoslave (discussion) 6 mars 2021 à 01:49 (UTC)

Pour ma part je serais intéressé certes d’avoir une base de connaissances qui permette de faire des requêtes automatiques de façon simple (relativement pour qui à les compétences techniques ou la possibilité de les acquérir) mais pas en y sacrifiant la flexibilité du modèle sous-jacent. Le wikitext a ses défauts, mais il n’embarque pas de parti pris lexicologique extrêmement prégnant et indétournable.

Je serais donc bien plus interressé par une modèle centré sur les énoncés effectifs en premier lieu. Ensuite, par la possibilité d’expliciter des modèles lexicologiques par le bias du modèle de données – qui serait donc un méta-modèle lexicologique. Et enfin, en troisième articulation, de fournir le mécanismes permettant d’exprimer des énnoncés « relationnellement structurées » sur des termes extraits des énnoncés à travers le prisme d’un modèle grammaticale spécifié. À noter que dans cette approche, les descriptions lexicologiques comme les définitions sont eux même de simples énnoncés effectifs.

J’en convient, tout au moins sur les dernières articulations d’un tel schéma, cela constitue un modèle quelque peu plus sophistiqué que de partir du principe que toute entité lexicologique doit être essentiellement rédutible à un lexème. Ça me paraît néanmoins le ticket d’entrée innévitable pour s’offrir la liberté d’une souplesse et d’une expressivité sans commune mesure avec un modèle partisan simpliste.

Voilà, je serai assurément très intéressé de lire vos retours. --Psychoslave (discussion) 4 mars 2021 à 21:35 (UTC)

Bon, après des premiers retours de Noé et de Lyokoï sous une autre discussion, il semblerait que mon enthousiasme ne soit en fait pas si partagé et que la proposition – outre l’ampleur de la tâche – paraît inspirer plutôt des sentiments d’inquiétude face à une menace exogène. Je reste bien sûr intéressé par les retours. --Psychoslave (discussion) 4 mars 2021 à 21:51 (UTC)

Bonjour, si quelqu'un.e veut répondre à ce message (les fans de Lingua LIbre par exemple ?). — Dara — 22 février 2021 à 10:30 (UTC)

J'ai déplacé ma réponse à la page Discussion:câlice. Vous pouvez répondre là-bas. --Snawei (discussion) 22 février 2021 à 13:24 (UTC)

Il arrive que l’on ait sous les yeux des choses qui, par habitude, paraissent normales quand on n’y prête pas attention. Concernant la page d’accueil, je ferais quelques remarques :

• Entrée du jour, ça fait menu de restaurant
• Travail collaboratif du mois et Travail collaboratif de la semaine, doit-on vraiment parler de travail ?
• Mot à créer aujourd’hui, c’est un peu impératif comme formule. --Rapaloux (discussion) 23 février 2021 à 16:23 (UTC)

Pour entrée du jour, je suis complètement d'accord : mot du jour serait un chouya moins exact pour les spécialistes, mais serait grandement plus compréhensible pour la plupart des autres lecteurs. Pour les deux autres items, je suis plutôt d'accord, mais je ne vois pas de meilleure alternative à proposer... Marxav (discussion) 24 février 2021 à 05:33 (UTC)

Le truc, c’est qu’il faut des noms courts, sinon, c’est pas très beau en titre. Donc, on pourrait passer par des périphrases à rallonge, mais ça me semble pas terrible. Après, s’il y a des propositions courtes qui font consensus, why not. (Pour l’entrée du jour, c’est une invitation à se régaler avec le reste du contenu .) Lepticed7 (À l’immortalité !) 24 février 2021 à 05:49 (UTC)

Suggestions : « Collaboration mensuelle », « Collaboration hebdomadaire ». Pour « Mot à créer aujourd'hui », je perçois une invitation, pas un ordre (au contraire par exemple de « Créez ce mot aujourd'hui »). Cantons-de-l'Est (discussion) 24 février 2021 à 15:44 (UTC)

Aller je m’y essaie :

• Lexie du jour, si l’on souhaite rester sur du vocabulaire précis et concis, mais honêtement pour la page principale Mot du jour me paraît bien plus pertinent.
• Thématique contributive mensuelle, Coopération du mois (adapter avec hebdomadaire/par semaine)
• Défi création du jour : poëtoproclésie, elle est pas belle la carotte ?

--Psychoslave (discussion) 3 mars 2021 à 23:34 (UTC)

Salut,

certains d’entre nous ont découvert ça hier soir sur Twitter, mais certains articles contenaient des propos transphobes. Le contenu incriminé est {{équiv-pour|une femme, une transexuelle ou une transgenre}}. Ce message n’est pas là pour afficher les personnes à l’origine de ça, de fait, je ne donnerai ni nom, ni diff. Toutefois, il faut que tout le monde ait en tête deux choses :

• l’utilisation du terme transsexuel est fortement déconseillée. Ne l’utilisez pas. Ce mot est perçu comme pathologisant et blessant ;
• l’utilisation du terme transgenre ou trans ne sert pas à désigner des genres. Une femme transgenre est une femme. Inutile de séparer les deux. Si vous avez du mal à comprendre, vous pouvez essayez de remplacer « transgenre » par « blonde », « noire » ou « grosse » dans l’exemple. « Une femme ou une grosse », sous entendu les grosses ne sont pas des femmes. C’est pas terrible… Enfin, question d’utilisation, il est préférable d’utiliser transgenre (ou trans) comme un adjectif et ainsi de dire « une femme trans » (si c’est utile à la discussion, sinon utilisez juste « femme »).

Enfin, sachez qu’une IP avait modifié le texte, mais a été annulé pour retourner sur le contenu incriminé. La personne a alors posté un message sur Twitter, que nous avons détecté parce que son message mentionne clairement le Wiktionnaire. Il ne faudrait pas que nous soyons identifié comme transphobes, parce qu’il me semble que ce n’est pas le cas. J’invite donc tout le monde à de la vigilance dans vos contributions.

Si vous avez des questions, n’hésitez pas à les poser. Je préfère qu’on en parle de suite, plutôt que ça tourne au scandale.

Bonne soirée, Lepticed7 (À l’immortalité !) 23 février 2021 à 19:25 (UTC)

Il faudra peut-être quand même qu'on en parle… Une connaissance est venu se plaindre auprès de moi à cause du patrouilleur en question (celui qui a utilisé la formule incriminée et qui a réverté la correction), me disant être dégoûté de son comportement (pour des contributions sur d'autres entrées, mais non sans rapport) et ne voulant plus contribuer à cause de cela, donc ce n'est pas tout à fait un comportement isolé. Thomas Linard (discussion) 23 février 2021 à 23:17 (UTC)

Effectivement. J’ai corrigé plusieurs pages qui utilisait transsexuel ou transgenre dans le modèle {{équiv-pour}}. Lepticed7 (À l’immortalité !) 24 février 2021 à 05:23 (UTC)

Pourquoi ne pas se contenter de masculin et féminin (termes grammaticaux) pour les équivalences ? Il n’y a pas de neutre en français. Alors qu’un certain nombre de personnes revendiques (ou non) de n’être ni homme ni femme. Jpgibert (discussion) 24 février 2021 à 10:20 (UTC)

@Jpgibert : Salut, je vais donner une version assez simplifiée. Il faut savoir que, comme tout dans le monde, il est possible d’approfondir la question. Pour répondre à la question, il s’agit de deux choses différentes : d’abord, il y a le genre, en particulier l’identité de genre. Le genre, c’est ce en quoi tu te reconnais (femme, homme, non-binaire, etc.). Ensuite, il y l’alignement (je sais pas s’il y a un terme consensuel) entre le genre dans lequel tu te reconnais et le genre qu’on t’a assigné à la naissance. C’est ici qu’on retrouve transgenre et cisgenre. Pour transgenre, le genre dans lequel tu te reconnais est différent du genre assigné. À l’inverse, si les deux correspondent, alors on parle de personne cisgenre. Donc, il existe des femmes trans et cis, mais dans tous les cas, ce sont des femmes. Du coup, identité de genre et « alignement » sont deux axes différents. En conséquence, dire « femme ou transgenre » n’est pas à utiliser si l’on souhaite indiquer le mot pour l’autre genre (en restreingnant la situation à une binarité). Mais, par exemple, il m’est arrivé pour l’espéranto de mettre deux modèles équiv-pour, car il y a un mot pour les hommes, un pour les femmes et un pour les personnes non-binaires. Mais il n’est jamais question de trans ou de cis. En français, cette distinction n’implique pas de distinction de mot. (Je ne sais pas si c’est le cas pour toutes les langues.) Voilà, j’espère que ma réponse est claire. Lepticed7 (À l’immortalité !) 24 février 2021 à 12:27 (UTC)

@Jpgibert : pour ce qui concerne le genre grammatical : il n’a rien à voir avec équiv-pour : équiv-pour est utilisé quand des noms différents sont utilisés selon le sexe, et cela indépendamment des genres grammaticaux des deux mots. Il est vrai que, le plus souvent, quand des noms différents sont utilisés, celui pour les hommes est masculin et celui pour les femmes est féminin. Mais pas toujours : cf. les mots allemand Junge (masculin, ce qui n’a rien de surprenant), qui devient pour parler d’une jeune fille Mädchen (genre grammatical neutre, et non pas féminin). Lmaltier (discussion) 24 février 2021 à 17:27 (UTC)

Bonjour,

« Le grand lit au carré. »

Vous pouvez lire ces mots comme « Le grand lit » -- « au carré », ce qui est insolite et porte à refuser que ces mots forment une phrase complète.

Vous pouvez lire ces mots comme « Le grand » -- « lit » -- « au carré », ce qui est (moins) insolite et porte à accepter que ces mots forment une phrase complète.

En anglais, vous avez peut-être vu « The old man the boat. » (une garden-path sentence), que j'ai traduite par « La vieille arme le bateau. »

Je crois que « lit » et « arme » sont des homographes (mot qui est aussi homographe, je crois ;-) et homophones (tiens, un quatrième homographe, si j'ai toujours raison ;-)).

J'ai trouvé Catégorie:Homographes non homophones en français et Catégorie:Noms multigenres en français, mais les mots « lit » et « arme » n'en font pas partie, ce qui élimine ces deux catégories comme possibilités.

Alors, à quelles catégories supplémentaires (inconnues ?) « lit » et « arme » appartiennent-ils ? De plus, est-ce que les phrases « Le grand lit au carré. » et « La vieille arme le bateau. » sont classées dans un groupe particulier ?

Cantons-de-l'Est (discussion) 24 février 2021 à 15:11 (UTC)

<aparté>Bonjour, quand j’ai fait mon service militaire, tous les matins, il fallait faire son lit "au carré". Donc la phrase est acceptable si quelqu’un vous annonce en désignant du doigt : "le grand lit au carré". Tout comme un agent immobilier pourra vous dire : "une grande salle de bain" ou "une belle chambre parentale spatieuse".

Dans la seconde version où c’est "le grand" (sous-entendu possible : garçon) qui est en train de lire, "au carré" peut s’entendre comme une apocope du "carré des officiers". La phrase est donc acceptable.

Voilà, c’était juste en passant et ne répond pas à la question. </aparté> Jpgibert (discussion) 24 février 2021 à 16:14 (UTC)

@Cantons-de-l'Est : Réponse à la question, telle que je l’ai comprise : Catégorie:Mots ayant des homophones en français. Mais c’est seulement, apparemment, quand l’orthographe est différente. Des mots à la fois homographes et homophones, il y en aurait de telles quantités… En fait, c’est presque à chaque fois qu’il y a plusieurs sections de mot dans la section Français. Par ailleurs, pour mot qui est aussi homographe, je n’ai pas compris : il faut au moins deux mots pour qu'ils soient homographes. Par exemple, rue (voie), rue (plante) et rue (forme conjuguée de ruer) sont des mots homographes, parce qu’ils s’écrivent pareil. Mais tout mot s’écrit forcément pareil que lui-même… Lmaltier (discussion) 24 février 2021 à 17:09 (UTC)

Bonjour Lmaltier, Je comprends pour l'homographie. L'ensemble est vaste, mais tous les mots de la langue française n'ont pas une double, triple... signification. Pour les deux ensembles de mots que j'ai mentionnés, peut-on dire qu'il s'agit d'expressions homographes ? Cantons-de-l'Est (discussion) 24 février 2021 à 18:51 (UTC)

@Cantons-de-l'Est : Oui, ce sont des phrases différentes qui s’écrivent pareil, ce sont donc des phrases homographes. A part ça, oui, on pourrait avoir une catégorie spéciale pour les graphies qui ont plusieurs sections de mot dans la même section de langue. Ce serait facile de le faire par robot. Mais je ne vois pas tellement l’utilité en pratique. Lmaltier (discussion) 24 février 2021 à 19:02 (UTC)

Bonjour,

Vous connaissez peut-être le conjugueur du Figaro. Est-ce que le Wiktionnaire offre une telle ressource pour les verbes en français ?

Cantons-de-l'Est (discussion) 24 février 2021 à 15:39 (UTC)

@Cantons-de-l'Est : Salut, le Wiktionnaire ne propose pas un tel outil. Mais on a commencé à bosser dessus : Projet:Amélioration des conjugaisons. Lepticed7 (À l’immortalité !) 24 février 2021 à 16:07 (UTC)

Bonjour @Cantons-de-l'Est :. @Lmaltier : pourra peut-être vous répondre (il est un spécialiste des verbes en français). Je sais qu'il est possible de rechercher uniquement des verbes (en utilisant les jokers) avec la recherche avancée. On clique sur Options puis dans le menu déroulant Type on sélectionne verbe. Ensuite, il y a l'espace conjugaison en cliquant sur la ligne de forme d'un verbe sur (voir la conjugaison). Je ne sais pas s'il existe une page avec la recherche avancée pré-réglée pour les verbes et d'autres fonctions ou pages intéressantes. Il y a la Catégorie:Verbes en français qui possède aussi une fonction de recherche, mais elle ne fonctionne pas pour moi. --Snawei (discussion) 24 février 2021 à 16:21 (UTC)

Il est aussi possible d'inclure les flexions avec la recherche avancée ou de n'avoir que le verbe à l'infinitif. J'avoue qu'il serait bien d'avoir un outil qui permette de mettre plus en valeur les nombreux verbes et les conjugaisons. --Snawei (discussion) 24 février 2021 à 16:30 (UTC)

Snawei, C'est une voie à explorer, mais je pensais à l'internaute lambda : il saisit un verbe à l'infinitif dans une barre (comme dans Le Conjugueur) et le Wiktionnaire renvoie le tableau des conjugaisons. Cantons-de-l'Est (discussion) 24 février 2021 à 16:41 (UTC)

@Cantons-de-l'Est : Ce qui existe, c’est de rechercher le verbe dans la zone de recherche, puis, une fois la page du verbe affichée, de cliquer pour obtenir la conjugaison. Il serait peut-être possible de faire quelque chose pour économiser ce clic en plus mais, à moins de mettre cette recherche de conjugaison dans la page d’accueil, je ne vois pas… Et, comme nous décrivons les mots de toutes les langues, je ne serais pas partisan de privilégier à ce point les verbes français dans la page d’accueil. Lmaltier (discussion) 24 février 2021 à 16:55 (UTC)

Lmaltier, Une page dédiée, et pas la page d'accueil (comme Le Figaro). Cantons-de-l'Est (discussion) 24 février 2021 à 18:20 (UTC)

@Cantons-de-l'Est : Je pense aussi qu'une page dédiée serait bien. --Snawei (discussion) 24 février 2021 à 18:26 (UTC)

Effectivement, pour gagner un clic, on peut toujours accéder directement à une page particulière via l’URL (en mettant un marque-page dans son navigateur, par exemple). C’est possible. Je ne sais pas trop ce que ça impliquerait du point de vue technique. Lmaltier (discussion) 24 février 2021 à 19:06 (UTC)

Si la page est stable et bien nommée, les moteurs de recherche vont lui donner une bonne cote à l'usage, qui va augmenter au fil des années. Cantons-de-l'Est (discussion) 26 février 2021 à 00:31 (UTC)

C’est un cas d’utilisation aussi pour les données structurée. Par curiosité j’ai écris une requête Wikidata (pas exhaustive) pour retrouver les conjugaisons des verbes en français, C’est encore très incomplet. Seul le verbe aimer semble un tantinet complet pour l’instant, sinon il y a quelques formes sporadiques, le travail d’import n’a pas encore été fait on dirait.

Je vais quand même tenter d’écrire un prototype de gadget pour ici qui va piocher dans ces données.TomT0m (discussion) 3 mars 2021 à 14:52 (UTC)

Si on veut la conjugaison d'un verbe X, il suffit de renvoyer à la page Conjugaison:français/X, non? du coup, la page particulière est assez vite faite... Micheletb (discussion) 26 avril 2021 à 08:14 (UTC)