Aller au contenu

Discussion utilisateur:Dr Brains/dfnBot.js

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.

Tests[modifier le code]

Gestion des modèles[modifier le code]

Salut Dr,

Quelques remarques. Si tu n'as pas été voir le code que j'ai indiqué sur la page de discussion (ici, dans la fonction doQuotes) va jeter un oeil. L'idée est d'utiliser un split qui fournit un tableau de la forme : 

[morceau 1, séparateur 1, morceau 2, séparateur 2, ..., morceau n-1, séparateur n-1, morceau n]

Après, les indices pairs font référence à des morceaux, les impairs à des séparateurs.

Ca serait utile pour la détection des modèles qui, à la lecture du code, semble avoir un problème. Ton programme entre dans la fonction dfnBot_getTemplate après avoir lu {{. Mais la fin du modèle n'est pas forcément le premier }} trouvé, voir par exemple : 

{{modèle {{modèle imbriqué}} }}

En divisant une telle chaîne en une liste : 

["", "{{", "modèle ", "{{", modèle imbriqué, "}}", " ", "}}", ""]

on peut facilement suivre les imbrications de modèles (je le fais en pseudo-code, sinon je vais faire plein de fautes de syntaxe) : 

 rec = 0
 on garde le premier texte (i=0)
 pour tous les indices i impairs :
     si tab[i] = "{{" :
        rec++
        on passe le texte dans l'indice suivant
     si tab[i] = "}}" :
        rec--
        si rec>0 :
            on passe le texte dans l'indice suivant
        sinon : on le garde dans le tableau hors modèle.
si rec<=0:
    on garde le dernier texte

Avec un algorithme comme ça, tu es (à mon avis) totalement tranquille. Je vais essayer de coder un équivalent de la fonction preg_split avec flag PREG_SPLIT_DELIM_CAPTURE pour javascript. Ce sera utile pour récupérer directement l'algorithme de doQuotes.--Juju2004 (d) 14 avril 2011 à 11:24 (CEST)[répondre]

Mmh, tu n'a pas bien lu le code apparemment.
Lors du premier appel à dfnBot_getTemplate, je recherche effectivement le premier "}}" (ce premier appel se déroule lorsque le texte commence par le début du modèle "{{").
Mais ensuite, je matche les occurrences de "{{" dans le résultat obtenu. Pour chaque occurrence trouvée (sauf la toute première de ce premier appel), je relance dfnBot_getTemplate sur ce qui reste du texte pour trouver le prochain "}}" (et si dans une de ces opérations, je trouve à nouveau des "{{", c'est relancé encore).
Au final, je m'assure donc de trouver autant de "}}" qu'il y a de "{{".
A priori, le compte est toujours bon. Il faudrait tester sur une sous-page utilisateur avec différents "pièges" pour s'en assurer (j'ai activé le script dans les NS 0 et 2).
⇨ Dr Brains ∞ Consultation ∞ 14 avril 2011 à 14:00 (CEST)[répondre]
C'est vrai, j'ai mal lu (Smiley oups). Mais même en relisant, ça ne coule pas de source. Et je me garderais bien d'affirmer que tout fonctionne comme souhaité, même si des tests pourraient le prouver. L'inconvénient majeur de ta solution est ailleurs : le code n'a pas le caractère de l'évidence, ce qui risque d'être gênant s'il s'agit d'obtenir un consensus.
L'algorithme que je propose ci-dessus est un grand classique pour ce genre de situation (split du texte excepté). On connaît toujours le niveau d'imbrication dans lequel on est, le niveau 0 étant celui hors de tout bloc. Je t'encourage vraiment à adopter cette solution.
Question d'ignorant : que sont les NS 0 et 2 ?--Juju2004 (d) 14 avril 2011 à 16:46 (CEST)[répondre]
NS ce sont les l'espaces de noms. En l'occurrence, NS 0 c'est l'espace encyclopédique (logique puisqu'il faut intervenir sur les articles), NS 2 c'est l'espace Utilisateur: (pour tester sans risque).
Ta solution est également intéressante. En somme, il s'agirait de passer en revue tout le texte et de le découper en une Array en cherchant les séparateurs ("{{" et "}}"). Ensuite, on passe en revue l'Array ainsi obtenu et on y fait correspondre un "niveau d'imbrication de modèle" (0 pour "Hors modèle" (chaque "{{" provoque un +1, chaque "}}" provoque un -1), pour finalement rechercher les apostrophes que dans ces parties-là.
Je vais essayer de mettre cette idée en pratique dans un script dfnBot.js bis. Probablement ce WE.
Par contre pour la recherche du gras, je ne suis pas sûr que cette méthode soit appropriée, vu que les délimiteurs utilisent le même caractère et sont donc difficiles à différencier. Mais je m'avance peut-être un peu. Ce sera à voir plus tard.
⇨ Dr Brains ∞ Consultation ∞ 14 avril 2011 à 18:49 (CEST)[répondre]
Pour les modèles, c'est exactement ça. Pour le découpage avec conservation des délimiteurs, je t'ai mis une fonction split_with_delim ci-dessous (fonction à valider quand même).
Pour ce qui est du gras, la solution doQuotes de MediaWiki utilise une méthode similaire : découpage avec pour délimiteur la RegExp /''+/. Il y ensuite un traitement des apostrophes à intégrer au texte (et donc à supprimer des délimiteurs), puis on se trouve avec des morceaux de textes séparés par '', ''' et ''''' uniquement. Il suffit de traduire le PHP en JS pour avoir un fonctionnement rigoureusement identique à celui de MediaWiki, ce qui est l'idéal ici. Pour l'insertion des dfn, ce que j'ai mis sur la 3è section de cette page constitue une solution (pas forcément optimale, il est vrai).
Merci pour les NS. Je ne connais pas le fonctionnement des bots en javascript (j'en ai codé un en Python, mais il est en phase de test). Je suppose qu'on doit pouvoir se mettre un bouton qui exécute le script sur une page, mais comment ? Ca reste assez mystérieux pour moi et j'aimerais bien comprendre. Si tu as un peu de temps pour m'expliquer...--Juju2004 (d) 14 avril 2011 à 19:46 (CEST)[répondre]
J'ai testé ta méthode (cf le script, où j'ai mis une fonction BIS). A priori, ça marche.
Pour les quotes, je n'ai par contre pas fait de découpage, je me contente de rechercher les deux premières occurrences de « ''' », que je substitue par le modèle et sa fin, et je gère le cas d'un italique ou d'une apostrophe en remplaçant {{Terme défini|' par '{{Terme défini| autant de fois que nécessaire. L'éventuel italique est donc "en dehors" du modèle, et l'éventuelle apostrophe de début aussi.
Mon script est déjà testable sur la page courante : il ajoute un onglet (clignotant Émoticône) pour lancer le bouzin. Par contre il ne sauvegarde pas. Au moment où j'écris ces lignes, c'est ta méthode qui est employée, que j'ai testée avec succés (cf plus haut).
Pour ajouter un bouton, en js :
Ajout d'un onglet (ou d'un lien dans le menu déroulant pour Vector)
function MaFonction_AddLink(){
     var OngletsCactions = document.getElementById('p-cactions');
     if(OngletsCactions){
          var CactionsUl = OngletsCactions.getElementsByTagName('ul')[0];
          CactionsUl.innerHTML += '<li><a href="javascript:MaFonction_Run();">dfn</a></li>';
          $(OngletsCactions).removeClass("emptyPortlet");
     }
}
 
⇨ Dr Brains ∞ Consultation ∞ 15 avril 2011 à 13:43 (CEST)[répondre]
Un peu plus de travail que prévu (voir section "tests du bot"), mais ça valait la peine : le programme passe bien les tests que j'ai pu inventer. Il gère :
  • modèles typo à neutraliser (ex. {{e}})
  • modèles dont il faut explorer les paramètres (ex. {{japonais}})
  • les tableaux (avec la problématique de l'équilibre : un }} ne doit pas pouvoir fermer un {|
Je vais publier une page de tests (manuels) pour montrer la manière dont ça passe.--Juju2004 (d) 18 avril 2011 à 12:07 (CEST)[répondre]

Gestion des apostrophes[modifier le code]

Les tests ci-dessus montrent que ça avance ! L'article sur les timbres de Mayotte a un vrai problème par rapport aux conventions WP, et donc il est souhaitable que le bot le laisse tel quel.
Pour la partie "gestion des modèles", le code est parfaitement clair (je ne l'aurais pas écrit exactement comme ça, mais c'est du détail Émoticône). Pour la partie apostrophes, il doit être possible d'utiliser une méthode raccourcie, comme tu proposes, mais il faudrait la valider par rapport à doQuotes (j'y reviens toujours !!) pour éviter toute surprise lors du traitement. Sur ce que je lis, j'ai du mal à être sûr que tout est pris en compte. A mon avis, un truc comme :
l'''essai de définition du mot '''bidule''' n'est pas concluant''
(qui donne : l'essai de définition du mot bidule n'est pas concluant) ne marche pas, mais tu va me dire que si !
Pour ce qui est de faire fonctionner le script, je ne demandais pas une explication technique, mais au niveau de base... J'ai bien tenté simplement de faire un 
importScript('Utilisateur:Dr Brains/dfnBot.js');
sans succès. Même après vidage du cache. Autre question qui me vient : est-ce que ce programme va pouvoir travailler automatiquement ou bien servira-t-il à corriger les pages en passant ?--Juju2004 (d) 15 avril 2011 à 15:11 (CEST)[répondre]
Les modèles, c'est OK, mais pour les apostrophes, ça ne fait pas exactement la même chose que doQuotes, effectivement. Dans ton exemple, le résultat serait l{{Terme défini|essai de définition du mot }}bidule''' n'est pas concluant''. Cela dit, une intro (généralement la première phrase) est rarement bâtie comme ton exemple.
Je vais me pencher un peu sur cette question des apostrophes et essayer de faire un truc qui colle au rendu PHP de mediawiki.
Il faudra aussi ajouter des tests au cas où le dfn serait déjà présent (d'une manière ou d'une autre) : si balise, remplacement par le modèle, et si modèle, pas de changement. (Je prends d'ors et déjà le pari que c'est le modèle qui sera choisi par la PDD.)
Pour le js : tu es sous vector ou monobook ? Parce là tu as fait correctement pour vector. Tu devrais avoir le lien dans le menu déroulant. Le plus simple est de la mettre dans Utilisateur:Juju2004/common.js, ce qui règle la question. Précision : l'onglet ne s'affiche que si la page ne comporte pas déjà un <dfn>, et comme je l'ai déjà dit, dans les espaces encyclopédique et Utilisateur:, ce qui est peut-être la raison de son non affichage (tout dépend où tu l'as testé).
Pour le moment, je me concentre sur la partie édition, donc j'ai limité à la page courante. Cela pourrait éventuellement déboucher sur un gadget que chacun pourra utiliser. Mais pour la suite (pour Dr Bot (d · c · b)), je compte ajouter d'autres requêtes sur l'API pour obtenir une liste de pages qui seront toutes modifiées à la suite. Je ne sais pas encore par quelle méthode : via Spécial:Allpages ou en ciblant les pages contenues dans une catégorie. Probablement la première solution, avec des bornes en paramètres évidemment, histoire de ne pas lancer la modif sur un million de pages (plus de 200 requêtes rien que pour toutes les répertorier...) et aussi pour pouvoir agir de concert avec d'autres dresseurs (il ne sert à rien de repasser sur des pages déjà traitées). Mais ça c'est la partie facile, le plus complexe, c'est l'étape de l'édition, qui de doit pas générer d'erreur vu que se sera fait en automatique donc sans surveillance.
⇨ Dr Brains ∞ Consultation ∞ 15 avril 2011 à 16:39 (CEST)[répondre]
Je me doute bien le cas que je t'ai proposé ne se présente pas souvent. En plus, en ajoutant un test pour voir si le texte à mettre en dfn est identique au titre (après avoir tout passé en minuscules), les risques d'erreur sont extrêmement faibles. Cependant, il existe une solide tradition qui veut que les utilisateurs (entre autre nous quand nous sommes rédacteurs) soient capables de tout !
Sur l'opération (non encore décidée), il me semble qu'il faut s'assurer que chaque bot qui passera sur les pages suivra le même alogrithme (par quoi je n'entends évidemment pas le même code ou le même langage). Je vais réfléchir de mon côté à une version Python de l'algo (juste la partie qui traite le texte pas le bot derrière) au cas où. Je suis d'accord avec toi sur le fait que l'algo ne doit pas générer d'erreurs, mais il devrait générer des traces avec tous les échecs. L'idéal serait un algorithme qui ne modifierait l'article que dans le cas le plus évident (titre en gras), et qui génèrerait un log avec tous les échecs et un diagnostic précis associé. Il serait ensuite possible de travailler par séries d'échecs similaires, et répéter la procédure de manière itérative.
En tout cas, il est extrêmement intéressant d'avoir un programme comme le tien, qui peut être lancé à grande échelle ou bien utilisé au cas par cas :
  • rien ne dit que, si la modification est acceptée dans son principe, il ne restera pas une habitude de mettre en gras le titre dans l'intro ;
  • il va ya avoir de nombreux cas à traiter manuellement avant d'appliquer la transformation (type timbres de Mayotte).
A part ça, ça marche sur common.js (merci), et je vais faire quelques tests avec ça.--Juju2004 (d) 15 avril 2011 à 17:07 (CEST)[répondre]
Première version d'un code en Python qui me semble ok : Utilisateur:Juju2004/Brouillons/botdfn.py. Je n'ai utilisé aucune des spécifités de Python, ce qui fait que la traduction en JS ou PHP ne pose pas de problème. J'ai fait quelques tests sur des cas bizarroïdes et tout se passe bien. Dis-moi ce que tu en penses.--Juju2004 (d) 16 avril 2011 à 09:22 (CEST)[répondre]
J'ai créé Utilisateur:Dr Brains/dfnGadget.js avec le code pour modifier une seule page. Ça me permettra de continuer à travailler sur Utilisateur:Dr Brains/dfnBot.js en commençant à intégrer la gestion des erreurs.
Je vais regarder de ton code python avec attention.
⇨ Dr Brains ∞ Consultation ∞ 16 avril 2011 à 09:47 (CEST)[répondre]
Pour le gadget, je suis à nouveau largué : comment utilise-t-on ce truc ? (je suis loin d'être un pro de l'interface WP/js, tu l'auras constaté...)
Pour ce qui est de mes tests sur le dfn en mode lien (qui clignote) et de la lecture du code, je résume ce que je comprends : la modification a lieu si et seulement si le premier texte en gras est bien le titre (comparaison sur le titre normalisé : minuscules et sans apostrophes). J'ai été moins restrictif dans mon code, mais je pense que cette condition plus stricte pourrait être la bonne. Evidemment, le problème de la définition de la condition qui doit être remplie pour procéder à une modification n'est pas un problème de programmation : il faudra voir ce qui se décide sur cette question.
Concernant la gestion des erreurs, elle est assez fine pour que les diagnostic soient exploitables, ce qui est un bon point. Elle balaie l'ensemble des possiblités d'échec de la condition. De ce côté là, ok (de mon côté, je ne suis pas sûr d'avoir bien géré le cas "texte vide").
Maintenant, quelques points qui me déroutent un peu :
  • la sortie des apostrophes du modèle dfn : comme je le comprends, c'est pour les cas de ce genre : 
    '''''titre''''' -> {{dfn|''titre}}'' -> ''{{dfn|titre}}''
    Mais j'ai idée que ça devrait être fait avant.
  • le cas texte vide. J'ai trouvé sur le net le code suivant : 
    txt.replace(/^\s+/g, "").replace(/\s+$/g, "")
    qui permet de faire un trim sur texte : si le résultat est vide, alors le texte ne contient que des espaces (tabs, sauts de lignes, etc.) et peut donc être ignoré. Ca te permet de mieux gérer le cas que les lignes : 
    if(ThisTexte!="\n") Errors[0] = false;
    et 
    ThisTexte = "";
    . La variable FoundTexte ne semble pas utilisée (à vérifier quand même.) De plus, il y a un problème actuellement au niveau de thisTexte="" : voir [1] pour un cas qui pose problème (c'est pourri, j'avoue...)
  • la manière d'arrêter de passer dans la boucle for, lorsque Errors[3] = false (remplacement fait), qui n'est pas évidente. J'aurais plutôt vu un while qu'un for : 
    while (a<l and Errors[3]) { ... ; a++ }
Il faut peaufiner, mais globalement, c'est ok et ça fonctionne.
Autre sujet : il reste un partie que nous n'avons pas traité : il faudrait également tester si la page est déjà en dfn, et si oui, vérifier que le boulot à bien été fait (sortir les italiques du modèle, ou autre) et sinon le signaler.--Juju2004 (d) 16 avril 2011 à 11:05 (CEST)[répondre]
PS. mon cas pourri, je ne le gère pas non plus ! Émoticône Et je ne suis pas sûr de la façon dont il faudrait aborder ce genre de cas. Autre chose : qu'est-ce que tu penses de prévenir Lgd (d · c · b) et Micthev (d · c · b) de l'avancement des travaux ?--Juju2004 (d) 16 avril 2011 à 11:32 (CEST)[répondre]

Le gadget marche de la même manière que l'autre script. pour le tester, il faut ajouter importScript('Utilisateur:Dr Brains/dfnGadget.js'); à ton /commons.js. Il crée le même onglet, mais il est différentiable par le fait qu'il ne clignote pas (je pourrait également mettre un intitulé plus explicite pour différencier les deux mais c'est un détail). Il recherche le premier terme en gras, même si ce terme n'est pas le titre de la page. Je verrai plus tard pour le faire évoluer suivant l'avancée des travaux sur le script "bot".

paragraphes déplacés par Juju2004 dans la section "tests et utilisation du bot"

Pour ton exemple, c'est effectivement problématique. Ce genre de cas doit être extrêmement rare mais peut sans doute arriver avec les siècles ou avec certains modèles typographiques ({{Dr}}). Il y a aussi le cas des modèles avec une traduction de langue (exemple sur Aiki Jinja) qu'il faut pouvoir traiter correctement.

⇨ Dr Brains ∞ Consultation ∞ 16 avril 2011 à 12:07 (CEST)[répondre]

Tests et utilisation du bot[modifier le code]

Concernant le code "bot", j'ai effectivement réduit le champ d'action aux cas où on trouve exactement le titre de la page en gras (à la casse près, le titre prenant toujours une majuscule, ce qui n'est pas forcément le cas de sa répétition dans le texte). On pourrait faire plus simple en cherchant simplement une RegExp « "'''"+wgTitle+"'''" » mais cette méthode ne permettrait pas d'essayer d'autres choses, par exemple vérifier que ce gras comporte un ou plusieurs mots contenus dans le titre (mots de plus de 4 ou 5 lettres pour éviter les pronoms et autres prépositions. Pour ce genre de choses, il est nécessaire d'abord d'extraire les textes en gras avant de les comparer à ce qu'on veut (soit le titre, soit une combinaison de mots issus du titre).

L'idée, c'est donc d'essayer successivement, sur chaque gras, plusieurs méthodes, jusqu'à ce qu'on ait ajouté le modèle. En l'effectuant sur une série de pages prises au hasard, sans sauvegarder, et de reporter le résultat qu'on aurait obtenu sur une page de travail avec des sections de type : 

== [[Page]] ==
* Méthode utilisée avec succès : XXXXX
; Avant
<pre>
'''Wikitexte''' avant passage du bot
</pre>
; Après
<pre>
{{Terme défini|Wikitexte}} après passage du bot
</pre>

Cela permettra d'avoir un premier aperçu du taux d'erreurs et de leur cause, permettant ainsi de les éviter.

Tester si la page a déjà un dfn, c'est déjà fait pour le gadget, car le lien n'est ajouté que si la page n'en a pas (mais c'est testé sur le HTML donc on ne sait pas si c'est via un modèle ou si la balise est en dur dans le wikitexte). Pour le script "bot", il faudra effectivement tester si le modèle est déjà présent (et alors on passe à la page suivante), ou si la balise est en dur (dans ce cas le remplacement de la ou les balise(s) est simple).

Il faut également tester la page pour écarter deux types de contenus : les homonymies (présence d'un modèle listé sur Mediawiki:Disambiguationspage) et les liste (titre commençant par "Liste ").

(Dr Brains, 16 avril 2011 à 12:07) paragraphes sur les tests et l'utilisation du bot déplacés par Juju2004

D'abord, toutes mes excuses pour le découpage de message, mais je crois que c'est nécessaire pour y voir clair.
Pour les tests, je souscris à ton idée : création d'une page de travail qui permet de se faire une idée de ce qui se passe, ce qui marche et ce qui ne marche pas. Pour la balise et les pages à écarter, idem (= tout à fait d'accord).
Sur le process général, je vois deux approches possibles :
  • soit le bot qui traite une page gère à peu près tous les cas (ex. essai de différentes méthodes comme tu proposes) ;
  • soit le bot fait un passage sur les cas les plus simples (titre = premier texte en gras) et met des flags sur les pages qui ont été visitées : un flag "ok" pour celles qui n'ont pas posé de problème, un flag "err X" selon le type de problème. Le bot est ensuite modifié pour gérer une partie des pages flaggées en erreur, et générer une nouvelle série de flags. Ces flags pourraient être des catégories ou bien un commentaire (sur ce point, je n'ai pas vraiment d'idée).
L'avantage de la première méthode est évident : on passe et c'est fini. C'est à mon avis celle qui sera choisie. Mais elle complque le code et risque de ne pas être totalement maîtrisée. C'est l'avantage de la seconde : le résultat obtenu assez simplement est tout de suite valide pour une majorité d'articles, sans vraiment de difficulté, et on a tout loisir de comprendre ce qu'il faut faire (ex. supprimer un modèle type {{Dr}}, etc.) à partir de l'intégralité des échecs.
Quoi qu'il en soit, je ne suis pas sûr qu'il faille modifier un pourcentage maximum d'articles (par rapport aux articles visités) d'un coup. Il faut surtout limiter la casse.--Juju2004 (d) 16 avril 2011 à 15:21 (CEST)[répondre]
Gros boulot effectué sur le bot.
Donc pour résumer, il ne sauvegarde toujours pas la modification, mais enregistre les résultats ICI.
Au clic sur le bouton, le script demande la borne de début, puis la borne de fin. Si on clique sur annuler à la borne de fin, il est possible de choisir un nombre de pages maximum via une troisième pop-up. Après ça marche tout seul jusqu'à la sauvegarde du bilan (qu'il faut confirmer).
Pour info, le détail n'apparaît que si il y a moins de 100 pages, sinon c'est trop lourd.
En moyenne, le cas "titre exact en gras" concerne grosso-modo entre le quart et la moitié des pages (suivant les bornes demandées), le reste est occupé par le cas "premier gras trouvé".
Les non-remplacement sont généralement dus à des modèles typographiques à l'intérieur du gras ({{s}}, {{e}}, etc...), ou à l'utilisation de modèles de langue du type {{Japonais}}. Dans ces cas-là, le danger est qu'il y ait un autre gras dans l'intro et donc un mauvais remplacement.
Il faut trouver un truc pour éviter ce problème, ainsi qu'une approche pour diminuer la portion de "premier gras trouvé" (en recherchant des similitudes avec ce gras et le titre ?).
⇨ Dr Brains ∞ Consultation ∞ 16 avril 2011 à 15:47 (CEST)[répondre]
C'est effectivement impressionnant Émoticône. Les titres qui contiennent des modèles ou liens WP posent en effet (comme prévu) problème. La balise dfn possède un attribut optionnel title à la balise dfn (voir [2]) qui pourrait contenir le titre "propre", alors que tout le fatras typographique resterait en place. Il faudrait faire subir un traitement à ces modèles ({{e}}, etc.) avant de commencer le découpage du texte hors modèle. Je n'ai pas d'idée exacte pour le moment sur la méthode, mais j'y réfléchis et ça doit pouvoir être résolu.
En parcourant le log, j'ai découvert un autre problème plus gênant. Considère cette ligne :
''{{Terme défini|Paris-Dakar}}'' est le quarante-et-unième album de la série de bande dessinée ''[[Michel Vaillant]]'', créée par [[Jean Graton]].
Le paragraphe ne définit pas réellement ce qu'on entend par Paris-Dakar (la course, bien qu'elle ait changé de nom ajourd'hui). On pourrait trouver des cas similaires avec tous les films ou livres qui traitent d'une personnalité (Napoléon, etc.). Faut-il vraiment les faire passer à la moulinette dfn ? Je vais exposer le problème sur la page de discussion générale.--Juju2004 (d) 16 avril 2011 à 17:02 (CEST)[répondre]
J'ai mis au jour un nouveau problème potentiel, dont j'ai eu l'exemple sur Colo Colo de Futebol e Regatas : les tableaux.
Il apparait que pour certains articles, l'infobox est codée en dur dans l'article, avec une syntaxe de tableau donc, et avant l'intro proprement dite. Ainsi il est nécéssaire lors du découpage de tenir compte des tableaux en plus des modèles.
J'ai remanié mon code de split (que j'ai mis dans une fonction à part) pour tenir compte de cette dificulté nouvelle. Ça a l'air de fonctionner.
Il apparaît aussi que le cas "titre exact en gras" est peut-être plus courant que je ne le pensais (ça dépend de beaucoup du type de page apparemment). Aussi, je pense que le premier passage ne devrait peut-être se faire qu'avec cette option et garder le l'option "premier gras trouvé" pour un deuxième passage. J'ai d'ailleurs, pour ces cas-là, mis en place une fonction de comparaison entre le premier gras et le titre, ce qui permettrait éventuellement de définir un seuil de similitude à partir duquel la modif serait effectuée et en-dessous duquel elle serait abandonnée.
⇨ Dr Brains ∞ Consultation ∞ 17 avril 2011 à 13:19 (CEST)[répondre]
J'ai l'oeil sur tes tests, et c'est vraiment intéressant. La vue synthétique est particulièrement bien faite. Une petite demande : pourrais-tu mettre la cause de l'échec (si tu ne l'as pas déjà fait). Le cas où il n'y a pas d'intro ne nécessite pas d'aller voir, alors que les autres échecs peuvent être plus instructifs.
A part ça, la gestion des tableaux est bonne dans ton code. Il faudrait penser générer un avertissement pour ce genre de plaisanteries ! Celle de la comparaison également, même si j'aurais comparé des textes plutôt que des tableaux (question de goût), donc j'aurais mis le split dans la fonction. En effet, il existe dans d'autres langages des fonctions de bibliothèque qui font des comparaisons plus subtiles sur des textes, et qu'on pourrait souhaiter utiliser. Je vais voir ce que je fais de mon côté.
Encore autre chose : j'ai trouvé la solution (du moins je crois) pour les modèles {{e}} et {{japonais}}, mais je n'ai pas eu le temps de coder, car je suis pris (entre autres) par la discussion sur la page Discussion Wikipédia:Prise de décision/Adoption du balisage dfn dans les introductions d'articles.
Sinon, quand tu parles de deuxième passage, tu penses à la solution qui consiste à marquer d'un flag certains articles pour y revenir ensuite ? C'est ce que je comprends, et ça me paraît ok.--Juju2004 (d) 17 avril 2011 à 14:33 (CEST)[répondre]
Pour {{japonais}} et les modèles du même type qui formatent la phrase d'intro, le mieux serait peut-être de ne pas traiter ces pages, et d'ajouter le dfn directement dans le modèle. Ainsi, il faudrait faire quelque part une liste des modèles de ce type de façon à ne pas traiter la page automatiquement si l'un d'entre eux est présent (suivant le même principe que j'utilise pour évacuer les homonymies).
Reste les modèles purement typographiques de type {{e}}, {{Dr}}, {{s}}, etc... Pour ceux-là, il faudrait en faire une liste également, et avant le split remplacer les accolades par un texte défini (par exemple {{ -> DEBUTMODELE, }} -> FINMODELE ), de façon à ce qu'ils ne soient pas pris en compte par le split. Il faut bien sûr faire l'opération inverse lors avant de sauvegarder.
Je vais voir si je peux rajouter un texte d'erreur supplémentaire dans les cas "Texte pas remplacé". A priori, il n'y a que trois cas (dont deux sont définissables immédiatement) :
  1. il n'y a pas d'introduction
  2. il y a une introduction mais il n'y a pas de gras
  3. Il y a du gras mais la similitude avec le texte est trop faible (seuil à définir)
Pour les deux passages, je pensais à
  • un premier passage limité aux cas "Texte exact trouvé en gras",
  • la création d'une liste des articles sans dfn (créée par un bot à partir d'un dump (postérieur au prmier passage, évidemment), comme c'est fait par exemple pour le Projet:Articles sans portail (le bot ayant pris soin d'éliminer les homonymies et les listes) ),
  • un deuxième passage sur les pages de la liste pour traiter le premier terme en gras (avec éventuellement un seuil de similitude avec le titre à définir).
  • création d'une nouvelle liste
  • troisième passage en manuel ou en semi-auto (avec le gadget JS, WPCleaner ou autre).
⇨ Dr Brains ∞ Consultation ∞ 17 avril 2011 à 16:48 (CEST)[répondre]
Pour les modèles typo, comme dit, j'ai une solution qui est à mon avis plus simple et robuste. Je publie ce soir si tout va bien une nouvelle version de mon code, que je vois un peu comme une boîte à idées pour les dresseurs de bots. Si tu veux t'en inspirer, n'hésite pas. Cela dit, ce que tu proposes doit faire l'affaire également. Pour le modèle {{japonais}}, il n'est pas réservé au titre, donc l'introduction d'un dfn dans le modèle même pose un problème par rapport au projet. J'ai également une solution (un peu moins satisfaisante que pour les typo, mais bon, ça doit passer).
Pour ce qui est du déroulement des opérations, je n'avais pas pensé au dump et à tout ça. Ca me paraît parfait.
A part ça, si tu peux ajouter les types d'erreur, c'est super, et si peux venir donner ton avis en page de discussion (et éventuellement me soutenir, quand tu penses que je ne dis pas que des bêtises), ça serait pas mal Émoticône. D'autant qu'une partie des questions que je pose vient directement ou indirectement de nos discussions et de tes tests.--Juju2004 (d) 17 avril 2011 à 22:41 (CEST)[répondre]
PS je viens de voir sur ta page de tests que c'est fait pour les types d'erreur. C'est super. Soit dit en passant, il y a beaucoup de cas où tout fonctionne bien.--Juju2004 (d) 17 avril 2011 à 22:45 (CEST)[répondre]
Après réflexion, pour les modèles de type {{Japonais}}, la solution la plus simple passerait par un paramètre "|dfn=oui" dans le modèle, paramètre qu'il faudrait donc que le bot ajoute si il trouve le modèle dans l'intro.
Donc, soit on fait ce traitement particulier pour ces modèles-là, soit on abandonne la modif. Mais dans tout les cas il faut en faire une liste quelque part afin que le bot soit à même de les reconnaître.
⇨ Dr Brains ∞ Consultation ∞ 21 avril 2011 à 13:48 (CEST)[répondre]
L'idée du paramètre est bonne : il faudrait la soumettre. Je commence à avoir une liste de questions assez longue, à laquelle celle-ci va se rajouter. Je vais les (pro)poser à Lgd (d · c · b) (pas pour qu'il y réponde directement, mais pour qu'il sache qu'elles existent), mais peut-être ailleurs que dans la page de discussion principale.
Par ailleurs, si tu vas voir dans mon code nouvelle version, tu verras comment j'ai traité le cas {{japonais}}. A priori, ça marche, mais la mise en oeuvre est plus compliquée que dans le cas du paramètre.
Je rajoute un autre problème que j'ai rencontré : le mot magique DISPLAYTITLE et les modèles {{Titre mis en forme}} et {{Titre incorrect}} qui modifient le titre de la page. En général, c'est le titre modifié (typo) qui est repris dans le première paragraphe. C'est donc sur lui, je pense, que la comparaison devrait se faire en priorité. J'ai aussi traité ce problème.--Juju2004 (d) 21 avril 2011 à 14:41 (CEST)[répondre]
PS. J'ai rajouté une page de tests ici qui peut être vue comme une énumération des cas problématiques que j'ai rencontrés. Mon programme passe tous les tests sans problème.--Juju2004 (d) 21 avril 2011 à 14:48 (CEST)[répondre]
En vrac :
  • j'arrive maintenant à gérer le modèle {{lang}} selon le principe suivant : le modèle est neutralisé dans un premier passage (considéré comme identique à du texte, exactement comme les modèles typo) ; quand on considère le texte en gras, on redéploie le modèle lang et on compare le terme en langue étrangère (un des paramètres du modèle) au titre ; s'il y a égalité, on substitue un modèle {{dfn}} au modèle initial.
  • il y a un autre cas spécial : celui des parenthèses d'homonymie
  • j'ai posé quelques questions sur la page Discussion utilisateur:Lgd/Déploiement dfn parce que trop de points restent dans le flou. Si tu veux intervenir...
  • Est-ce que tu continues à faire des tests ? Si oui, quels sont les résultats ?--Juju2004 (d) 25 avril 2011 à 22:20 (CEST)[répondre]
Je reviens à la charge : je te mets un copier-coller d'un message que j'ai mis à Lgd et qui s'adresse aussi à toi : « comme mon bout de code ne semble pas soulever l'enthousiasme (mais peut-être plutôt une indigestion), j'ai publié non seulement un code de test mais des résultats sous forme lisible (problème des lignes de trois kilomètre excepté). J'ai intégré la règle des italiques dans la balise (c'est désactivable pour le modèle lang par ex.). J'ai aussi opté pour un modèle, mais ce choix est confiné dans un bout de code qui peut facilement être modifié en cas de choix différent. Est-ce que tu vois des cas non conformes qui sont mis en conforme ? Est-ce que tu vois d'autres cas à tester ? D'autres améliorations ? Cordialement. » Si tu as idées, des réponses ou du nouveau...--Juju2004 (d) 3 mai 2011 à 20:22 (CEST)[répondre]


Liste des modèles de langue ayant un impact sur la mise en place des dfn[modifier le code]

  1. {{Hongrois}}
  2. {{Japonais}}

A priori, il n'y a que ces deux qui incluent le texte d'origine dans le modèle. Pour tous les autres modèles de langue, la syntaxe est « '''Texte''' {{Langue|''Traduction''}}, est un truc-bidule... », ce qui ne pose pas de problème.

⇨ Dr Brains ∞ Consultation ∞ 21 avril 2011 à 14:01 (CEST)[répondre]

Et le modèle {{lang}}, tout simplement ? D'après ce que j'ai pu voir, il n'a pas d'influence sur l'affichage, mais il met un truc du genre (dans le cas simple) : 
<span class="lang-en" lang="en">texte</span>
Ce qu'on devrait essayer de transformer en 
<dfn class="lang-en" lang="en">texte</dfn>
dans le cas où le texte est le titre. Et laisser le span ailleurs. De nombreux modèles se fondent sur ce modèle et seraient à traiter également, soit par voie de paramètre dfn, soit par un modèle dfn avec les bons paramètres.--Juju2004 (d) 21 avril 2011 à 14:32 (CEST)[répondre]

split avec conservation des délmiteurs[modifier le code]

En bricolant, voici ce qui est sorti : 

//<pre><nowiki>
function split_with_delim(pattern, str)
{
	var s = str;
	var arr = new Array();
	var templateDelimIndex = s.search(pattern);
	while (templateDelimIndex != -1) 
	{
		var block = s.substring(0, templateDelimIndex); 	// le morceau précédant le délimiteurr
		var delim = RegExp.lastMatch;								// le délimiteur
		arr.push(block);											// qu'on stocke dans le tableau
		arr.push(delim);
		s = s.substring(block.length+delim.length);					// on enlève le morceau et le délimiteur...
		templateDelimIndex = s.search(pattern);
	}
	arr.push(s);													// le dernier morceau
	return arr;
}
//</pre></nowiki>

Le test avec Rhino donne ceci : 

//<pre><nowiki>
var str = "blabla {{modèle {{modèle imbriqué}} }} blabla";
print (split_with_delim(/(\{\{|\}\})/, str))

// sortie (avec un petit problème d'encodage sur mon dos) :
// blabla ,{{,modÞle ,{{,modÞle imbriquÚ,}}, ,}}, blabla
//</pre></nowiki>

On a bien ce qui est souhaité. Maintenant il ne reste plus qu'à :

  • adapter le code de doQuotes ;
  • modifier la sortie pour intégrer un dfn à la place d'un b le cas échéant.

--Juju2004 (d) 14 avril 2011 à 12:17 (CEST)[répondre]

La fin du code (en PHP !)[modifier le code]

Encore un peu de code, cette fois-ci en PHP, puisque j'étais sur une fonction PHP. Il s'agit de la modification de doQuotes. Je ne l'ai pas testée. Il faudrait remplacer les lignes 1418 à 1486 du fichier [3] qui mettent les balises HTML par quelque chose comme ceci : 

//<pre><nowiki>

// $arr : le split par doQuotes du bout de texte hors modèle dans lequel on veut insérer les dfn
// $title : le titre à mettre entre balises
// $dfnBegin et $dfnEnd : les chaînes (soit balise, soit modèle)

// bout de code ...
	$i = array_seach($title, $arr); // trouve l'indice du titre
	if ($i>0 and $i<count($arr)-1)
	{
		$prevDelim = $arr[$i-1];
		$nextDelim = $arr[$i+1];
		if (strlen($prevDelim)==3)
			$arr[i-1] = $dfnBegin;
		else if (strlen($prevDelim)==5)
			$arr[i-1] = "''".$dfnBegin; // pour l'italique
	
		if (strlen($nextDelim)==3)
			$arr[i+1] = $dfnEnd;
		else if (strlen($nextDelim)==5)
			$arr[i+1] = $dfnEnd."''"; // pour l'italique
	}
	$str = implode($arr); // il faudra ensuite reconstituer le texte avec les modèles supprimés
//</nowiki></pre>

C'est perfectible, mais l'idée y est. La traduction js ne doit pas poser trop de problèmes.--Juju2004 (d) 14 avril 2011 à 12:44 (CEST)[répondre]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Dr_Brains/dfnBot.js&oldid=137177638 ».