Sujet sur Discussion utilisateur:Jurbop

Résumé: sur 2 échantillons d'articles créés initialement aux environs de 2010 et 2014 (représentant environ 6% des 2,2 millions d'articles de wikipédia) du dump de mai 2020 de fr.wikipedia.org (comportant tous les derniers articles de l'encyclopédie disponibles), il y a environ 12% des articles avec des guillemets informatique (soit environ 264 000 articles). Ainsi dans un peu plus d'1 cas sur 10 les conventions typographiques de wikipédia concernant les guillemets (lien) ne sont pas respectées. Ce qui donne pour un lecteur d'article, un manque de sérieux (amha surtout lorsque l'article mélange les deux formes de guillemets soit dans environ 1/3 des cas) ! Merci de garder en mémoire que 88% est quand même un très bon score (toutefois il faudrait connaître le nombre d'articles qui ne comporte aucun guillemets !).

Préambule: Attention j'ai essayé d'obtenir ces résultats de façon sérieuse mais je ne suis pas un informaticien ! Merci d'avance de me signaler d'éventuelles erreurs. ;) J'ai passé plusieurs jours à essayer de comprendre comment les obtenir, ce qui est dorénavant plus rapide ! ;) Toutefois vous pouvez vous même faire vos essais (cf. mes explications ci-dessous et même avec d'autres outils si vous le souhaitez ex: https://www.mediawiki.org/wiki/Alternative_parsers) !

Dump de mai 2020: J'ai téléchargé le dernier dump de Wikipédia FR (les historiques ne sont pas inclus à part bien sûr la dernière modif qui représente l'état de l'article) datant de mai 2020 (4 Go zippé soit 20 Go dézippé). Il y a au total 338 Millions de lignes ! https://dumps.wikimedia.org/frwiki/20200501/ (frwiki-20200501-pages-articles-multistream.xml.bz2 4.5 GB et frwiki-20200501-pages-articles-multistream-index.txt.bz2 47.8 MB)

Pour mon ordi qui commence à dater (>5 ans ; Processeur : Intel Core i5 3570 ; 16GB ram ; disque ssd; windows 8.1 64 bits) j'arrive à ouvrir le dump de mai 2020 en environ 1m30s avec le puissant programme Emeditor (Payant. En anglais. J'ai la dernière version. Pour info on peut trouver des coupons sur le web. Je n'ai pas d'action chez eux!). Du coup j'arrive facilement à faire des recherches par mot clef dans toutes les 338 Millions de ligne du dump. Ce qu'hélas ne peut pas faire le logiciel gratuit Notepad++. Je mets 1min30s pour ouvrir le fichier de 20Go et autant de temps pour faire une recherche par mot clef dedans ce qui est une performance sans avoir un ordi de folie amha!

https://www.cjoint.com/doc/20_05/JEvlcWHm0DD_2020-05-21-130219.png

C'est pratique pour retrouver par exemple des doublons, qui sont difficilement trouvables en utilisant la boîte de recherche de wikipedia (même pour les dresseurs! cf ici), du genre "par par" ..etc.). Donc trouver le nombre de lignes comportants une sorte de guillemet ou une autre est facile : il y a 58,5 millions de guillemets informatique répartis sur 18,2 millions de lignes.

Toutefois afin de trouver uniquement les articles comportants des guillemets informatiques, là c'est beaucoup ...beaucoup plus long (je dirais qu'il faudrait à mon pc au moins 3 jours entier 24h/24h !).

En essayant de passer de nombreuses heures à ne garder que les lignes comportant au moins un guillemet informatique en enlevant du code html interne, je me suis rendu compte des problèmes suivants :

a) le dump ne comporte pas que juste le titre des articles et le texte enrichi façon ligne de code html ; et hop du coup on pourrait chercher dedans mais en fait le dump regroupe aussi des namespaces (_espaces_de_noms). Au lieu d'avoir uniquement les 2 218 263 Millions d'articles (le 21/05/2020 cf. à droite de la la page d'accueil de wikipédia), on se retrouve avec 4 797 340 d'articles qui commence avec le tag : <page> (et un chiffre plus proche du nombre d'articles : 2 142 744 avec le tag : {{Infobox )!

b) les guillemets informatiques " sont hélas utilisés à d'autres fin dans le code wikitexte (ex: <text bytes="21648" ou xml:space="preserve" ...).

En voulant éviter de détruire mon ordi, j'ai donc été forcé de procéder par extraction d'échantillons : un gros échantillon pour des articles créés environ en 2014 et un petit pour 2010. nb: dans le fichier dump les lignes sont classées par ordre de création des articles sur l'encyclopédie.

Voici le détail de comment j'ai procédé (merci à https://stackoverflow.com/questions/61857069/regex-keep-text-between-2-keywords-but-only-if-another-keyword-exists-inside-t) avec les résultats :

(Désolé je mets un lien vers le fichier texte explicatif ci-dessous car je n'ai pas envie de passer trop de temps à refaire le formattage spécialement pour cette page (ça bug un peu trop) !)

https://www.cjoint.com/doc/20_05/JEvlhQlljgD_explications.txt

Voici le fichier (frwiki-20200501-pages-articles-multistream_8-p01_que_infobox-04 que guillemet_infor-01.xml) qui correspond aux résultats du gros échantillon A :

( fichier .7z de 32MB) https://www.transfernow.net/VILL45052020

ps: J'ai corrigé 38 fautes de frappe ("par par") sur les 146 présentes dans la base entière de wikipédia (les autres ayant : - soit été corrigés entre début mai -date du dump- et ce jour 21/05/2020 ; - soit c'était un faux positif comme Par_Par_Lay par exemple. Sur les 2,2 millions d'articles au total de wikipédia FR cela représente quand même pas grand chose ! ;) )

Bonjour Jurbop.

Voici ce que je ferais si on veut passer tout un dump en revue. Traiter les pages une à une :

• récupérer l'élément du dump.
• si son numéro d'espace de nom ne correspond pas à ce que l'on souhaite, passer au suivant. En général, peuvent être intéressants les namespace 0 (articles), 10 (modèles, attention aux syntaxes particulières, éléments de programmation, accolades triples...) et 14 (catégories).
• charger le wikicode de la page. Avec des regex simples, retirer les éléments de texte qui sont perturbateurs ou ne présentent pas d'intérêt. Plusieurs possibilités :
  • par exemple les balises <ref …> peuvent être remplacées par des <ref> afin d'éviter les « name="…" ». Idem sur une liste de balises valides <gallery>, <div>, <span>, <syntaxhighlight>, etc. Ou par défaut sur toutes les balises.
  • ou alors complètement retirer des éléments par exemple les <timeline>...</timeline>. Attention à bien faire des recherches lazy (non greedy) pour ne pas retirer trop de texte.
  • Dans tous les cas, examiner quels pourraient être les sources de faux positifs. En traitant ce code source, on n'a plus les limitations mentionnées précédemment et relatives au moteur de recherche en ligne proposé dans Wikipedia. Les assertions vers l'avant ou l'arrière et l'utilisation de variables (pour les répétitions) sont possibles. Cela peut permettre d'éviter tous les style="…" ou class="…" fréquents dans les tableaux.
• Si on détecte, dans ce qui reste du texte, les motifs recherchés, on ajoute à la liste des articles concernés le titre de la présente page testée.

Cette étape de listage est un préalable à une éventuelle automatisation de modifications.

Remarques annexes :

• Le temps de traitement peut effectivement être de plusieurs heures (24h ?)
• Il n'existe pas que les guillemets "mot" et « mot » mais aussi d'autres formes (cf Guillemet) qui sont parfois utilisés à bon escient.
• Il est probable que l'on trouve parfois des espaces insécables « … »

Bonjour Ideawipik,

Merci pour ces explications. Je bute toutefois dès le début car je ne peux pas choisir les espaces de noms que je souhaite car ils sont inclus d'office dans le dump ! D'où mon raccourci un peu abusif de ne garder que les articles avec infobox.

Merci pour les autres précisions qui correspondent (évidemment de loin) à ce que j'ai essayé de faire. Avez-vous pu jeter un coup d'oeil aux résultats de l'échantillon A (cf. https://www.transfernow.net/VILL45052020) ?

Merci d'avance ;)

Bonjour. Pour être franc, je n'avais pas ouvert les fichiers joints. Mais je viens de lire intégralement la procédure que vous aviez suivie (dans le fichier explications.txt)

Cela me semble correct, même si c'est incomplet et sommaire. Je ne manipule pas fréquemment les dumps bruts. Pourriez vous m'expliquer l'étape suivante :

« Puis je supprime les lignes suivantes qui n'apparaissent pas dans le corps de l'article (bookmark +sup ligne bookmark)

"preserve">{{

="preserve

<comment> =" »

En regardant la fin du fichier final (tail -1000) je me rends compte qu'il n'y a plus les en-têtes des tableaux, est-ce lié à cette étape ?

Sur un plan plus général, à quoi sert cette détection ? S'il s'agit de lister les fichiers potentiellement à corriger, se contenter d'extraire les titres <title>...</title> serait suffisant au final.

Je veux bien faire une analyse similaire et plus fiable, pour les statistiques, mais je ne vois pas bien l'intérêt de déployer tant d’énergie (pour nos machines) et de stocker, selon vos estimations plus de 4% (36% des 12%, hypothèse basse) des titres d'articles de frwiki, sans savoir où l'on va.

NB1 dans le xml, le numéro d'espace de nom namespace de la page considérée se trouve entre <ns>...</ns>

NB2 Si on analyse directement le wikicode, les modèles (dont les infobox peuvent s'écrire indifféremment avec une initiale en lettre capitale ou minuscule donc une regex {{ *[Ii]nfobox capturerait mieux les infobox. Mais je ne pense pas que cela soit la meilleure méthode pour déceler les articles. L'espace principal ns=0 auquel on soustrait les pages de redirections et éventuellement les pages d'homonymie me semble plus fiable.

NB3, en relation avec explication.txt. En langue française, outre la nuance de distance physique, ceci ou voici se réfère à ce qui suit, cela ou voilà à ce qui est antérieur. Autant les utiliser à bon escient.

Cordialement.

Bonjour.

Tout d'abord merci pour votre réponse. ;)

• (...)Pourriez vous m'expliquer l'étape suivante (...)

Je vais essayer: en fait je cherche (CTRL+F) le mot clef "preserve">{{ (en cliquant sur "bookmark"), ça met en surbrillance toutes les lignes qui contiennent le mot clef. Ensuite il y a une option pour supprimer toutes les lignes correspondantes.

• Sur un plan plus général, à quoi sert cette détection ? En fait j'avais commencé à créer un article il y plusieurs jours et je viens juste de le poster aujourd'hui. Il est ici .
• Merci pour le NB1. C'est incroyable que je ne l'ai pas vu !
• Merci aussi pour les NB2 et 3.

Cordialement

OK, je comprends, il y a dans les dumps des <text bytes="..." xml:space="preserve">{{ au début de chaque wikicode d'article. Mais c'est un coup de rabot trop gros car cela supprime aussi la première ligne dudit wikicode. Inversement, cela ne retire pas d'autres types de guillemets.

Avec l'outil que j'utilise régulièrement basé sur Pywikibot et le parseur mwparserfromhell, je peux réaliser ce que j'ai mentionné dans ma première réponse, sur un dump. Mais quel est l'intérêt de repérer seulement les articles qui incluent simultanément les deux types de guillemets, s'il faut aussi corriger des articles qui ne contiendraient que des guillemets informatiques. Ce serait juste pour commencer quelquepart ?

Pour m'aider pourrais-tu lister grossièrement les types de guillemets informatiques (principalement dans des balises) qui sont présents de façon normale dans le wikicode mais ne font pas partie du texte de la page ?

Bonsoir, Merci pour les explications. ;)

Oui le plus simple est de ne chercher que les guillemets informatiques.

Est-ce que ceci t'irais (il faut que je refasse mes extraits à partir des namespaces. Merci encore) ? J'ai extrait les lignes qui comportent des " (à partir du fichier : frwiki-20200501-pages-articles-multistream_8-p01_que_infobox.xml (cf. fichier texte dans l'article principal ci dessus) qui est un extrait du dump de 753MB des articles ayant une infobox. cad avant que je ne commence à enlever des guillemets! ). Le fichier s'appelle frwiki-20200501-pages-articles-multistream_8-p01_que_infobox_extrait_des_lignes_avec_quote_pour_20200526.xml Il est disponible ici (25MB .7z / 134MB brut) : https://www.transfernow.net/gjhG8c052020

Souhaiterais-tu autre chose (je ne sais pas du genre xMB de tel fichier...) ? En revanche probablement pas avant demain. Bonne soirée ;)

ps: Peut être que ce fichier https://www.cjoint.com/c/JEAsb6mnH6Dserait interessant car il comporte les 100 lignes les plus utilisées du fichier frwiki-20200501-pages-articles-multistream_8-p01_que_infobox_extrait_des_lignes_avec_quote_pour_20200526.xml ?

À vue de nez, dans les exemples que tu donnes, il s'agit dans plus de 95% des cas d'attributs de tableaux mais il peut aussi s'agir de balises ref ou gallery, principalement.

Pour la détection : voici ma proposition pour chaque article :

1. retrait des commentaire présents dans la page ;
2. remplacement des balises <tag...> par des <tag>, pour s'affranchir de ces attributs, surtout qu'en pratique, si des " étaient présents dans du texte, il y aurait déjà des conflits avec les " des attributs. Une liste exhaustive des noms de balises valides sur Wikipédia serait utile. Liste commencée dans la première réponse.
3. traitement des balises particulières (par exemple entre des <timeline>, on peut avoir des text:"...") ;
4. pour les tableaux comme pour le cas précédent, deux options s'offrent à nous, selon que l'on s'intéresse à tout le texte ou uniquement le texte rédigé :
   • soit on omet entièrement tout leur contenu,
   • soit on retire uniquement les attribut="..." avec la liste des attributs valides à définir (class, style, scope et des attribut légèrement obsolètes mais encore largement présents et fonctionnels : width, align, bgcolor, cellspacing, cellpadding, border, etc.
5. enfin, on cherche les guillemets dans le texte restant.
6. on vérifie que l'on n'a pas trop de faux positifs et le cas échéant, on modifie les filtres définis lors d'étapes précédentes.

En réalité, c'est le programme qui fera tout sauf établir les listes initiales de tags et d'attributs et vérifier les faux-positifs.

Quelques pistes d'améliorations :

• il me semble inutile de prendre le dump complet (quel importance que la version de 2004 de l'article contienne ou non des guillemets ?) et il serait bien plus léger d'utiliser le dump avec la version actuelle des articles (All pages, current versions only)
• il existe Wikipédia:AutoWikiBrowser qui est gratuit et dispose d'un outil spécifiquement prévu pour analyser les dumps MediaWiki Aide:AutoWikiBrowser/Database Scanner (et où l'on peut facilement choisir l'espace de nom par exemple).
• attention, il y a énormément de faux-positifs où les guillemets droits sont nécessaires (et pas juste le wikicode, il y a les exemples dans l'article Guillemet comme exemple trivial mais aussi tout les articles comprenant des exemples de code informatiques, dont les articles dans la catégorie Catégorie:Langage de programmation)

Bonjour VIGNERON. Merci pour ces remarques pertinentes.

• Juste un détail. Il ne s'agit pas de la version de 2004 d'un article mais de la version actuelle d'un article créé en 2004 puisque Jurbop a analysé le début du dump qui correspond aux articles les plus anciens. Si j'ai bien compris, il a bien utilisé un dump récent avec les dernières versions.
• AWB est effectivement un exemple d'outil, parmi d'autres, étant donné l'existence d'autres « parseur ».
• Les codes informatiques sont souvent compris entre des balises <syntaxhighlight> ou <code> que l'on peut exclure, ce qui réduirait le nombre de faux positifs qui sont malgré tout inévitables.

Ce n'est effectivement pas la version de 2004 mais c'est le dump complet avec toutes les versions des articles, donc autant la version actuelle de l'article que les versions anciennes (y compris 2004 que j'ai pris comme exemple arbitraire).

AWB est un outil parmi d'autres mais c'est le seul que je connaisses spécifiquement prévu pour Mediawiki.

Effectivement, les balises (quand elles sont utilisées) permettent d'exclure certaines faux-positifs mais pas tous, voir aussi Guillemet#Double ou triple niveau de citation.

VIGNERON, Non, sauf erreur de ma part, il s'agit bien de la dernière version des pages articles, modèles, portails, projets, pages de catégories, Aide et Wikipédia, Fichier (à vérifier), redirections incluses, en gros tout sauf les discussions et les pages utilisateur (All pages, current versions only, without meta). L'ensemble des pages avec les historiques fait bien davantage que les 4,3 Go des fichiers du types frwiki-20200501-pages-articles.xml.bz2 (ou guère plus gros, leurs [:en:Wikipedia:Database download#Should I get multistream? homologues pages-articles-multistream.xml.bz2]). Cf les fichiers contenant history dans leur nom dans https://dumps.wikimedia.org/frwiki/20200501/ dont la taille cumulée monte à plusieurs centaines de Go.

Il me semble qu'il est aussi possible de créer ses propres dépôts personnalisés, en ajoutant des restrictions ou filtres, pour manipuler des fichiers adaptés à l'utilisation qui en sera faite.

Mais c'est un détail par rapport au sujet.

@VIGNERON @Ideawipik

• Il ne s'agit pas "dump complet avec toutes les versions des articles" mais bien du dump de Mai 2020 avec uniquement la dernière version des articles de wikipédia fr. cf. les fichiers en verts : https://www.cjoint.com/doc/20_05/JEAnNRCdVoD_2020-05-26-153900.png https://dumps.wikimedia.org/frwiki/20200501/ . Par ex si je cherche l'article sur le "Lac Rakshastal" (mot clef : <title>Lac Rakshastal</title>), il n'y a qu'un seul résultat qui est bien le dernier en date : <timestamp>2019-01-09T11:52:35Z</timestamp>. Cf. https://fr.wikipedia.org/w/index.php?title=Lac_Rakshastal&oldid=155646876. https://www.cjoint.com/doc/20_05/JEAnWErY1RD_2020-05-26-154737.png

• Merci d'avoir partagé les infos sur AWB : sa partie Scanner m'avait échappé (de plus, il n'y a pas besoin de s'inscrire pour traiter un dump local). ;) Je viens de tester. Et surprise ! Je dois mal m'y prendre car j'ai au final une liste de 958 997 résultats qui contiennent un guillemet informatique sur un total d'environ 2,2 millions d'articles. Les réglages que j'ai utilisé : https://www.cjoint.com/doc/20_05/JEAnFHEvpnD_001.png et https://www.cjoint.com/doc/20_05/JEAnFXAMePD_002.png . Lien vers la liste des résultats AWB (réalisé en seulement 6 minutes - ne contient que les titres des articles concernés - je n'ai pas trouvé comment extraire les articles en entier!) : https://www.cjoint.com/c/JEAn0gWhzYD . Par ex le "Lac Rakshastal" est bien présent dans ces résultats. Toutefois dans l'article en ligne https://fr.wikipedia.org/wiki/Lac_Rakshastal je n'arrive pas à trouver un guillemet informatique " ! (nb:je pense avoir trouver avec Emeditor la ligne en cause : &lt;gallery widths=&quot;250px&quot; heights=&quot;166px&quot;&gt; )

Merci d'avance ;)

Pour le dump, ok il n'y a qu'un seul <title>Lac Rakshastal</title> mais dans cette balise title n'y a-t-il qu'une seule balise fille <revision><id> ?

Là je ne peux pas tester moi-même mais pourquoi les 958 997 résultats serait mauvais ? (cela me semble plutôt être correct). Et oui, le scanner ne donne que les titres mais on peut prendre ces titres pour la partie principale d'AWB (où l'on peut faire des remplacements automatiques).

Enfin, dans le code de l'article Lac Rakshastal, je vois bien widths="250px" et non pas widths="250px".

« Ahah, bonne blague mais non, absolument pas. Les hypothèses comme les conclusions ne sont même pas fausses. Cdlt, » Désolé mais c'était trop tentant pour la question du contenu des dumps. Pour la seconde partie, en lisant le premier message, et la question typographique posée par l'utilisateur, on comprend que ce ne sont pas ces types de guillemets techniques dont il est question mais des guillemets présents dans le corps du texte ou du moins ceux qui s'affichent dans le rendu de l'article.

Mea culpa, sans pouvoir regarder les dumps j'ai fait un peu à l'aveugle et il semblerait que j'ai confondu Dump complete et dumps with complete edit history). Dans ce cas, effectivement c'est bon.

Pour la seconde question, pas sûr de ce dont il s'agit ; mais effectivement, ce n'est pas la question ici.

@VIGNERON

• Pour la balise <revision><id> il y en a bien qu'une : https://www.cjoint.com/doc/20_05/JEApxJ0qHuD_2020-05-26-172220.png et https://www.cjoint.com/doc/20_05/JEApx7UkqED_2020-05-26-172223.png. La version texte : https://www.cjoint.com/doc/20_05/JEApzKtN38D_extrait-complet-lac-from-dump.txt
• Pour les 958 997 résultats, ce que j'ai en tête : sur la page de l'article, un CTRL+F pour trouver un guillemet ". Du coup AWB trouve les guillemets qui apparaissent dans le code (c'est ok), mais je pensais qu'il me trouverait les guillemets qui apparaissent uniquement dans le texte lu par un lecteur. Dommage qu'il n'extrait pas les articles en local ça permettrait de se rendre compte de la réalité des articles visés. Bon là ça devrait être aussi plus long pour tout le dump !
• Je ne comprends pas bien ! Vous regardez le code source html c'est bien ça ? et je ne vois pas de différences entre vos 2 codes. Merci d'avance ;)

• Ok, très bien
• Il doit être possible de trier cela, à l'aide d'une regex ou autre, je regarderais dès que j'aurais le temps
• ooups, l'éditeur visuel avait converti les entités HTML, mais de toute façon, ce n'est pas important puisque c'est des guillemets dans le code

&quot; est l'équivalent HTML du caractère guillemet informatique « " », comme tu peux t'en convaincre en éditant le présent message : &quot; donne "

Dans le dump, il s'agit effectivement d'un comportement souhaité, comme pour les chevrons de balises HTML, afin d'éviter les conflits avec les éléments de la base de donnée/fichier XML, et d'une question d'éditeur, comme cela est expliqué sur cette aide. Ce n'est pas problématique à la lecture, mais il ne faudrait pas utiliser ce texte brut pour réalimenter directement Wikipédia.

Voir aussi ma proposition plus haut. Salutations à tous les deux.

Bonjour Jurbop.

Es-tu encore sur cette question ?

Je n' ai pas fait des statistiques détaillées mais quelques chiffres approximatifs.

Parmi les pages crées avant le 6 août 2006 (id<350 000, ce qui correspond à beaucoup moins de pages en considérant la restriction à quelques espaces encyclopédiques et les pages supprimées depuis) :

• 31000 pages contenant des "..." et «...» et encore, sans considérer les guillemets français introduits par le modèle {{Citation}} ou les modèles bibliographiques comme {{Lien web}}

• 8000 pages contenant des "..." uniquement, même remarque.

En regardant ces chiffres, il s’avérerait qu'une grande majorité des pages contenant des guillemets contiennent des guillemets français. Une bonne partie des guillemets informatiques droits se trouve dans les références. Dans le texte/wikicode, il s'agit parfois de guillemets utilisés à la place des doubles apostrophes utilisées pour la mise en italique. Cela amènerait à confirmer les avis plutôt unanimes sur le fond dans Discussion Wikipédia:Conventions typographiques à savoir que ni les conventions, ni l'état actuel de l'encyclopédie ne justifierait un remplacement des chevrons par une autre forme de guillemets

Cependant, en poursuivant une analyse plus poussée sur le reste du dépôt du 20 mai 2020, le chiffre s'équilibre.

Attention il est nécessaire de garder à l'esprit qu'il y a des faux négatifs de chevrons (insérés par un modèle mais non répertoriés) et des faux positifs, avec la détection indue de guillemets droits informatiques, notamment sur des articles contenant des balises <mapframe> non exclues et à prendre en compte pour la suite. Les chiffres sont donc à prendre avec des pincettes, car inexacts.

Parmi les pages créées après août 2006, sur un peu plus de 13 000 000 identifiants, il y a 4 517 553 pages en excluant les espace de discussion, pages utilisateur, modules et fichiers dont:

• 3 653 708 pages dans l'espace principal : article ou page d'homonymie ou redirection. Étant donné qu'il y a dans les 2,22 millions de pages de contenu (articles ou homonymie), des dernières représentent 60 % de ces pages du « namespace 0 ». (Pas vérifié dans le dump.)
  • 153 861 pages contenant dans leur code "..." et «...» soit 7% des pages de contenu
  • 163 198 pages contenant dans leur code "..." sans «...» soit 7,3% des pages de contenu
• 863 845 autre pages dont modèles, catégories (potentiellement davantage de faux positifs :
  • 15 358 pages contenant dans leur code "..." et «...» : 1,8 % de ces pages
  • 56 139 pages contenant dans leur code "..." sans «...» : 6,5 % de ces pages

J'espère ne pas avoir trop de mauvaises détections (dans les deux sens). Tes estimations 12-14% semblent correctes.

Si cela t'intéresse, je peux te transmettre les fichiers que j'ai stockés et qui contiennent les noms des pages concernées avec quelques extraits entre guillemets. Le total des fichiers, textes bruts, fait dans les 80 Mo (un tiers si compressé).

Pour ce genre de maintenances dignes du mythe de Sisyphe, il vaut mieux y aller petit à petit et à plusieurs. Une autre du même genre : des liens internes dans des articles, qui apparaissent bleu mais qui renvoient sur le même article. Projet:Correction syntaxique/Lien vers une redirection ramenant sur l'article initial. Parfois cela est complètement inapproprié. Parfois, cela se discute, en fonction des potentiels intérêt encyclopédique et admissibilité d'un article connexe. Parfois la syntaxe est améliorable/simplifiable pour des Liens internes ancrés.

Bonsoir Ideawipik,

Merci pour le suivi. ;) Oui je vais essayer de m'y remettre dès que possible (avec le dump de juin 2020) mais il ne faudra pas être trop pressé. ;)

Je veux bien voir ton fichier.

Par ailleurs il est possible que ces liens t'intéressent :

• dump en .json (ex https://dumps.wikimedia.org/other/cirrussearch/current/frwiki-20200525-cirrussearch-content.json.gz source: https://github.com/attardi/wikiextractor

• Kiwix nice's library (dump sous format .zim) https://news.ycombinator.com/item?id=19401679

• https://spark-in.me/post/parsing-wikipedia-in-four-commands-for-nlp

A bientôt,

Salutations ;)

Salut @Ideawipik,

Je suis tombé par hasard sur ce lien qui permet d'extraire des articles d'un dump d'en-wiki. C'est à première vue trop complexe pour moi, mais j'imagine que cela pourrait éventuellement te servir un jour. Salutations ;)