Utilisateur:Maëlan

Projets[modifier le wikicode]

trucs que j’ai faits sur le Wiktionnaire francophone :

extraction automatique des prononciations du Wiktionnaire (logs : ~~1/11/2023~~, 1/12/2023)
- sous-produit : détecte plein d’erreurs dans les prononciations ou l’usage des modèles d’accord
un modèle pour simplifier la saisie de l’alphabet phonétique (le modèle et sa doc, son code Lua, quelques tests)
- ne semble intéresser personne, tant pis
retrouver toutes mes sous-pages (au cas où il faudrait faire le ménage) modules, modèles, textes,

projets / idées en l’air :

faire le ménage dans Annexe:Prononciation/français, surtout les mystérieuses sections « Français moderne traditionnel » et « Troisième approche » (discussion)
faire une interface pratique, dans le style de https://typos.toolforge.org (code source), pour des corrections rapides de prononciations / modèles d’accord, basé sur les erreurs trouvées par mon programme d’extraction
en cours : Module:fr-flexion2 et Modèle:fr-flexion
j’aimerais, étant donné un temps infini, refondre les modèles d’accord, avec un modèle de base unique codé en Lua et une interface uniforme (la discussion où j’expose mes griefs avec les modèles actuels)
- en 2014/2015 une réimplémentation Lua a été faite pour une moitié des modèles d’accord : Module:fr-flexion, mis en production mais malheureusement laissé en plan, avec un changement incompatible des jeux de paramètres de ces modèles (le hack de compatibilité)
  - ⇒ ~~travail plus modeste (et probable préliminaire) : factoriser le code Lua de Module:fr-flexion et enfin terminer cette migration (!)~~
    - factorisation faite (2023-12-10), migration superflue (cf la catégorie ici ) puisque sera écrasée par la refonte globale envisagée
- en 2013 JackPotte a codé un nouveau modèle d’accord plus générique qui semble ne pas avoir été adopté : Utilisateur:JackPotte/fr-accord-rég2 (discussion)
- en 2020 une refonte similaire à celle que j’ai en tête a été faite (avec succès) pour l’italien : Module:it-flexion
- cahier des charges :
  1. un seul modèle pour tous les types de flexions, utilisation uniforme
    - il faut donc pouvoir générer un tableau à 1 case (invariable), 2 cases horizontales (s/p), 2 cases verticales (m/f) ou 4 cases (m/f × s/p)
      - voire être plus générique quant au nombre et à la signification des lignes ? (pour pouvoir implémenter p.ex. {{fr-accord-personne}}, 12 personnes×genres au lieu de 2 genres)
    - dans le cas m/f × s/p les formes sont identifiées par "ms", "mp", "fs", "fp" ; mais dans le cas s/p il ne faut pas faire référence au genre, dans le cas m/f il ne faut pas faire référence au nombre, et dans le cas inv il ne faut faire référence ni au genre ni au nombre => trouver un jeu pertinent de paramètres (noms et valeurs par défaut)
  2. spécification obligatoire du genre et nombre ? (le rendu synthétise alors toutes les infos et distingue entre agenre / un seul genre / épicène ; mais plus de choses à écrire, doublonne la ligne de forme)
  3. symétrie m/f : il suffit de donner indifféremment la forme masculine ou féminine pour en déduire l’autre (évite des prises de bec politiques)
  4. permettre des variantes (nombre arbitraire) pour chaque chaque « forme » (p.ex. {{fr-rég}} n’accepte que 3 prons mais on a parfois besoin de 4, cf xérès ou muleta)
  5. pas de paramètre numéroté, paramètres avec noms explicites (évite les confusions entre graphie et prononciation p.ex.)
  6. association claire entre graphies et prononciations (entrée : paramètres aux noms judicieux / sortie : tableau)
  7. rendu : fusionner automatiquement les cases identiques (pron ou graphie+pron) (rendu plus lisible, le contributeur n’a pas à s’en préoccuper)
    - => implé en 2 phases : (1) générer toutes les formes in-extenso, éventuellement plusieurs formes sont identiques (2) réduire le tableau
  8. permettre d’écrire un appel de modèle qui fonctionne à l’identique depuis toutes les pages de flexions (facilite l’usage en permettant le copié-collé)
  9. que tout appel de modèle fonctionne à l’identique depuis toutes les pages de flexions (pas d’erreur possible due à un copié-collé imprudent)
    - ✔ auto-détection de la graphie du radical depuis la graphie vedette
    - ✔ accepte indifféremment la prononciation de n’importe quelle flexion
  10. degré contrôlé d’automatisation, pas d’intelligence trop spécifique à la langue française (prévisibilité, réutilisabilité)
    - p.ex. ne pas essayer de reconnaitre le type à partir de la graphie (contrairement à Utilisateur:JackPotte/fr-accord-rég2), de reconnaitre les exceptions en -oux, ou de deviner la prononciation à partir de la graphie…
    - il pourrait y avoir par défaut un type légèrement automatisé qui décide que le mot est invariable s’il termine par -z ou -x ({{fr-inv}}), et variable avec un -s régulier sinon ({{fr-rég}}) ? pas très utile
    - un type automatisé « féminin régulier » qui reconnaitrait les altérations régulières comme -er→-ère, -in→-ine, -on→-onne … pourrait être utile, mais (1) ce qu’on met dedans serait arbitraire quand 2 graphies sont possibles (-et→-ète ou -ette) et en particulier il y aurait le risque de ne pas indiquer la bonne graphie et (2) pour les mots composés on sera de toute façon obligé de préciser les types
  11. une notion de « type » (ex: -s régulier du pluriel, -ins/-ines, -ers/-ères, -aux/-ales, -als/-aux/-ales…) qui pré-remplirait des paramètres tels que les terminaisons
  12. qu’un contributeur peu expert en Lua puisse facilement créer un nouveau type
  13. détecter les radicaux depuis la graphie vedette en cherchant des terminaisons spécifiques, dépendant du type (comme Module:fr-flexion et Module:it-flexion)
    - permettre à titre exceptionnel de fournir une typographie spéciale pour le rendu (ex: R_e, M^lle…)
    - permettre à titre exceptionnel de fournir une graphie autre que le mot vedette (pour invocation depuis les pages de doc)
  14. exiger de fournir la prononciation complète d’une forme ciblée (p.ex. ms ou fs), à partir de laquelle la prononciation du radical est extraite (évite des confusions entre prononciation du radical et prononciation complète, comme ce qui arrive souvent lors de la dissociation des noms communs masculins/féminins; évite l’oubli d’un séparateur de syllabes avant la terminaison; facilite l’extraction d’une prononciation valide sans y mettre trop d’intelligence)
  15. … mais la forme dont on fournit la prononciation est au choix, pas forcément la forme vedette (rend possible le copié-collé entre flexions) ni même celle du lemme (symétrie m/f)
  16. H muets/aspirés (comment ?)
    - => regarder à quoi est actuellement utilisé préfpron= en dehors des H
  17. en dernier ressort, permettre de spécifier chaque flexion complètement manuellement
    - => réduire au minimum les cas où c’est nécessaire en inspectant les occurrences actuelles, en identifiant les motifs récurrents et en concevant les types/fonctionnalité du modèle en conséquence
  18. mots composés : pouvoir profiter des types existants pour chaque composante (évite d’avoir à écrire in-extenso toutes les formes ; gros gain par rapport aux modèles actuels)
    - on spécifie le type de chaque composante, le nombre de composantes est égal au nombre de types spécifiés, le radical de chaque composante est détecté depuis la vedette en partant du principe qu’elles sont séparées par des espaces ou tirets (par défaut)
    - détecter automatiquement un suffixe invariable ? (comme l’actuel Module:fr-flexion) degré d’automatisation qui semble acceptable, et facilite la migration depuis Module:fr-flexion
    - liaison intelligente ?
  19. strict : catégorise et affiche des gros messages d’erreurs bien visibles
    - appel avec des paramètres incorrects
    - si la graphie ou la prononciation fournie n’a pas une terminaison attendue (limite les erreurs possibles)
    - contrôle les caractères de prononciation (désactivable)
    - etc.
  20. faciliter le traitement ou l’extraction automatique de données (p.ex. extraire les prononciations ou faire des substitutions de caractères API)
    - objectif en conflit avec celui d’automatiser le modèle : toute intelligence placée dans le modèle doit être comprise/réimplémentée par l’extracteur
    - ✔ facilite la tâche : paramètres nommés (regex marchent plus souvent)
    - X complexifie la tâche : alias de paramètres
    - ✔ facilite la tâche : le fait d’exiger de fournir une prononciation complète garantit qu’on peut au moins espérer extraire des données qui ont du sens (prononciation du lemme p.ex.)
    - X complexifie beaucoup la tâche : mots composés
- migration :
  - calcule automatiquement le type optimal pour produire le même résultat avec le nouveau modèle
  - conserve les paramètres ignorés des anciens modèles (et renseigne alors le nom de l’ancien modèle), pour examen manuel
  - demande intervention humaine au moindre truc suspect (erreur d’usage d’un modèle d’accord, prononciation suspecte, etc.), on aura besoin d’une interface pratique dans le style évoqué précédemment
- nécessaire réflexion/discussion globale : place des modèles d’accord dans le Wiktionnaire, redondance avec la ligne de forme, redondance entre pages des diverses flexions ; mon opinion :
  1. le modèle d’accord (rendu plus puissant) pourrait produire la ligne de forme ;
  2. il faudrait réduire au minimum vital les données sur les pages de flexion (donc pas de prononciation ni de modèle d’accord) pour pointer vers les lemmes où seraient centralisées toutes les infos.

ma philosophie

Pour expliquer un peu ma philosophie : Je vois le Wiktionnaire sous l’angle de l’informatique et du traitement automatique, pour moi il est important que l’info soit structurée, ce pour quoi je veux autant que possible des modèles plutôt que du texte libre laissé à la fantaisie des contributeurs. Certains gros contributeurs, dont l’avis semble prévaloir actuellement, estiment que le Wiktionnaire s’adresse à des êtres humains y compris son code source et veulent donc coder l’information en langage naturel, le plus verbeusement possible, avec le moins de modèles possibles ; cette même vision du projet professe que l’information doit être immédiatement lisible sans suivre un lien et donc que chaque flexion doit avoir sa propre entrée, plutôt que de simplement rediriger vers son lemme. Ça me gêne non seulement parce que (1) on perd toute facilité d’extraction de données, mais aussi parce que (2) fatalement, des contributeurs divergeront volontairement ou accidentellement de la structure qui, bien que pas techniquement imposée (et pas toujours documentée), est malgré tout attendue ; et que (3) faire manuellement la présentation des données signifie beaucoup de redondances (comme on l’a dit), ce qui signifie efforts manuels pour maintenir en synchronisation l’information dupliquée (et hop, faire le tour des 4 pages de flexions / variantes orthographiques à chaque ajout ou correction d’info) ou, à défaut (très souvent à défaut, dans le cas des flexions !) info qui diverge. Produire du contenu et soigner sa forme sont deux boulots complètement différents (le 1er rôle est celui d’un auteur quand le 2e, technique, est traditionnellement celui d’un éditeur), mais le Wiktionnaire nous demande de porter les 2 casquettes, même quand on manque de compétence ou d’intérêt pour la 2e. Dans mon expérience. on gaspille un temps absurde à simplement maintenir le Wiktionnaire en bonne forme. À ça il faut ajouter que le Wiktionnaire étant immense, on a évidemment besoin de robots pour automatiser des tâches très répétitives, et il y a donc des robots qui tournent dans tous les sens mais qui, malheureusement, font n’importe quoi parce que, précisément, le wikicode ne se prête pas au traitement automatique (par exemple : corrige une erreur à un endroit mais pas la même répliquée ailleurs, la redondance met en échec le focus (nécessairement) étroit du robot ; mélangent les arguments d’un modèle, transforment une graphie en une prononciation… un péché originel : parser le wikicode à coups de regex). Donc encore plus de bazar, et de temps perdu à corriger les bêtises des robots… Pour résumer, le Wiktionnaire représente une masse de travail collectif immense, qui a beaucoup de valeur, et je trouve extrêmement dommage que tout ça soit gâché parce que des tâches triviales absorbent une grande partie du temps investi, et parce que le produit utile de ce travail est inexploitable en dehors de son cadre d’origine. Fin du lamento.

erreurs à signaler ?

liste

Liens utiles[modifier le wikicode]

à suivre :

Utilisateur:LmaltierBot/Formes conjuguées pour demander des rectifications de prononciation en lot pour toutes les flexions d’un verbe

discussions :

comment gérer les modèles obsolètes ? faut-il les supprimer, etc. (exemple de modèle obsolète conservé avec avertissement : {{it-accord-oi}}, rendu sur une page d’historique)

outils (p.ex. pour créer un robot) :

les dumps bi-mensuels
Toolforge : aide Toolforge, tuto pour les API de Wikimédia
exemple de bot : code de JackBot
AWB
pywikibot, doc
MWParserFromHell (un parseur de wikicode en Python, pour programmes externes) : doc
Lua/Scribunto (la bibliothèque de MediaWiki en Lua, pour implémenter des modèles) : doc, manuel de Lua, page pertinente du Wiktionnaire (pas grand-chose à voir), page pertinente de Wikipédia (guide, infos utiles)
- doc sur les arguments de frame (attention : ordre arbitraire, les args nommés sont rognés mais pas les args positionnels sauf si donnés comme 1=...)
- Module:paramètres pour gérer des arguments de frame (voir aussi la fonction non-documentée checkParametersFromTemplate utilisée par {{fr-rég}} pour signaler les arguments inutilisés)
  - développer ce module pour gérer les arguments doublonnés (alias), les arguments ignorés, les arguments inattendus et les arguments en nombre arbitraire (fonction qui génère une description de paramètre à la volée)
- w:Module:Outils pour gérer des chaînes d’alias pour les arguments ? inutile si le Module:paramètres le fait bien
- w:Module:Yesno pour parser des booléens => inutile car le Module:paramètres le fait déjà
- w:Projet:Scribunto/Guide/Les erreurs et Error handling : utiliser pcall() qui équivaut à try ... catch

trucs intéressants extra-wikt :

Marxav a bossé sur les prononciations du Wiktionnaire, dans ce qui m’intéresse directement il a produit une table de correspondance graphie--prononciation et un test de plausabilité d’une prononciation vis-à-vis de la graphie

autre :

Wiktionnaire:Wikidémie/janvier 2024#Configuration des moteurs de recherche (et liens vers les docs des API de MédiaWiki)