Aide:Extension:Linter
L'extension Linter identifie les motifs du wikicode qui doivent ou peuvent être corrigés dans les pages, et donne quelques conseils sur les problèmes causés par ces motifs, et la manière de les résoudre.
La page Erreurs d’analyse Lint rassemble les erreurs par type. Certains de ces problèmes seront peut-être plus facile à identifier avec Expansion des modèles. Sur cette page, vous trouverez les problèmes de Lint classés selon leur dangerosité au regard des buts non atteints de par leur présence. Les informations et la discussion de ces points seront développées plus bas.
Une nouvelle fonctionnalité Montrer toutes les erreurs de lint pour une page spécifique est disponible en bas de la page Erreurs d’analyse Lint et permet aux éditeurs d'obtenir un rapport de toutes les erreurs d'une page donnée. Ce rapport contient la catégorie ainsi que d'autres informations utiles, et chaque erreur dispose d'un lien cliquable qui charge la page et surligne l'erreur. (Note : si votre éditeur de source gère lui-même la mise en valeur de la syntaxe, il est possible que celle-ci ne fonctionne pas). En corrigeant depuis la fin de la liste et tout en la remontant, les changements faits sur la page ne modifient pas le décalage en nombre de caractères des erreurs qui précèdent, et ceci est la manière de faire recommandée si vous souhaitez corriger toutes les erreurs d'une page.
Nous allons continuer à améliorer les fonctionnalités d'élimination du bruit, à résoudre les bogues et à rendre le résultat de l'outil plus facile à utiliser, mais le rendu actuel est déjà prêt à l'emploi et utilisable.
Documentation des erreurs de lint
Quoi corriger et pourquoi
Par la suite, l'équipe chargée de l'analyseur prévoit d'améliorer l'extension Linter pour identifier les motifs du wikicode :
- qui sont faux (ex : les bogues dans les options d'image - souvent à cause d'erreurs d'orthographe ou parce que l'interprétation des options d'image dans MediaWiki est fragile).
- qui sont obsolètes (ex : balises auto-fermantes)
- qui peuvent casser à cause des modifications dans les pipes (ex : replacement de Tidy par RemexHTML)
- qui ne sont plus valides en HTML5 (ex : balises obsolètes telles que center, font)
- qui sont potentiellement cassés et pourraient être mal interprétés par l'analyseur vis à vis de ce que le contributeur souhaitait (ex: balises HTML non-fermées, mauvaise indentation des balises HTML)
Toutes ces erreurs ne nécessitent pas d'être réglées rapidement, sinon jamais (selon votre tolérance au lint). Différents objectifs sont signalés à travers les différentes sous-types de problèmes de lint détaillés ci-dessus. Nous (l'équipe de l'analyseur) essayerons d'être transparents à propos de ces objectifs et nous proposerons des conseils sur les objectifs correspondant aux corrections de chaque problème.
Des instructions simplifiées sont proposées sur la page de FAQ.
But : Remplacer Tidy
Dans le cadre de la résolution de la dette technique dans le pipeline d'analyse de MediaWiki, nous avons remplacé Tidy par un outil basé sur HTML5.
Cependant, cela aurait cassé le rendu d'un petit sous-ensemble de pages à moins que certains modèles de texte wiki n'aient été corrigés.
Particulièrement les problèmes trouvés dans les catégories : deletable-table-tag, pwrap-bug-workaround, self-closed-tag, tidy-whitespace-bug, html5-misnesting et tidy-font-bug.
Afin de procéder à un remplacement rapide de Tidy, nous avons mis tous ces problèmes en priorité haute.
À l'heure actuelle, le code HTML généré par l'analyseur PHP est utilisé pour les vues en lecture et le code HTML généré par Parsoid est utilisé par les outils d'édition et l'application Android entre autres. L'équipe d'analyse, comme l'un de ses objectifs à long terme, souhaite permettre l'utilisation de la sortie de Parsoid à la fois pour les vues de lecture et pour l'édition. Étant donné que Parsoid et RemexHTML sont tous deux des outils basés sur HTML5, les catégories Lint qui affectent le rendu de RemexHTML affectent également le rendu Parsoid. Nous n'avons pas encore identifié de nouveaux problèmes Lint qui affectent le rendu Parsoid pour le moment, mais nous mettrons à jour cette liste au fur et à mesure que nous en trouverons.
Il s'agit d'un objectif quelque peu complexe et nous ne sommes pas encore parvenus à comprendre à quel point il est important de poursuivre cet objectif, ou jusqu'où nous devrions aller avec cela.
De plus, nous ne savons pas encore quels mécanismes nous souhaiterions exploiter pour atteindre cet objectif.
Par exemple, sur la base d'une série de discussions dans différents endroits, User:Legoktm/HTML+MediaWiki a présenté une proposition pour gérer la grande balise obsolète html5.
Dans tous les cas, corriger les erreurs dans les catégories obsolete-tag, self-closed-tag devance cet objectif.
Etant donné le manque de clarification autour du sujet, nous avons en conséquence marqué la catégorie des balises optionnelles (obsolete-tag) comme étant de priorité basse.
But : Clarifier les intentions des contributeurs
Il est difficile d'obtenir un balisage correct.
Les erreurs se glissent par inadvertance.
Bien que l'analyseur syntaxique fasse de son mieux pour se récupérer de ces erreurs, dans plusieurs cas, ce que l'analyseur fournit peut ne pas refléter exactement l'intention orignelle du contributeur.
Ceci étant dit, nous recommandons de corriger les problèmes identifiés ici pour clarifier l'intention du contributeur.
Les problèmes avec les catégories bogus-image-options, fostered-content, misnested-tag, missing-end-tag semblent pénaliser cet objectif.
Etant donné que c'est une chose importante, nous avons marqué la plupart d'entre eux avec une priorité moyennne.
Néanmoins pour la catégorie que regroupe les balises de fin absentes (missing-end-tag) nous lui avons assigné une priorité basse parce que dans la plupart des cas, il semble que l'analyseur syntaxique n'arrive pas à se resynchroniser correctement.
Néanmoins, nous recommandons de corriger tout ce qui peut être corrigé facilement, ne serait-ce que pour faciliter la compréhension des autres contributeurs humains et des outils.
But : nettoyer le balisage
Il est difficile d'obtenir un balisage correct.
Même si des erreurs sont présentes, l'analyseur syntaxique fait un travail tout à fait remarquable dans la majorité des cas en montrant comment l'élément balisé sera rendu.
Mais tout comme les fautes d'orthographe, la ponctuation, et les erreurs grammaticales mineures peuvent indisposer; certains contributeurs ou ceux qui ont un esprit de développeur peuvent trouver déstabilisants les problèmes Lint dans ces catégories.
Nous ne recommandons pas de passer un temps démesuré à corriger ces problèmes et dans beaucoup de scénarios, les robots seront en mesure de corriger cela.
Les catégories Lint misnested-tag, missing-end-tag, stripped-tag servent pour cela.
Goal: Improve content portability and presentation
Writing templates for content that works across different devices, different browser resolutions, different skins (and their themes e.g. dark mode), different websites (e.g. Wikiwand, Kiwix, Wikimedia Apps) is tricky. While skins do their best to adapt to content, they are restricted in what they can do given the myriad of templates used across our sites. Where we can, issues are flagged for editors to assist. night-mode-unaware-background-color, large-tables, lint categories affect this goal.
FAQ
Quand fait-on la mise à jour des erreurs de Lint d'une page donnée ?
Actuellement, toutes les catégories Lint sont remplies par des erreurs identifiées par Parsoid lors de l'analyse des pages. Lorsqu'une page (ou un modèle transclus sur une page) est modifiée, ChangeProp demande une nouvelle analyse de cette page à Parsoid, qui envoie le nouveau résultat à l'extension Linter.
Cela signifie que lorsqu'une nouvelle catégorie est introduite (ou une correction est faite sur une catégorie existante), un certain temps peut s'écouler avant que l'ensemble des résultats ne soit mis à jour (même pour des pages rarement accédées). En faisant une modification nulle sur le résultat on accélère le processus individuel. Néanmoins dans la tâche phab:T161556 nous évaluons différentes manières de traiter à nouveau l'ensemble des pages.
Faut-il corriger les pages de l'espace de noms XX (ex : Talk) ?
La priorité concerne les espaces de noms de contenu. Le reste dépend largement du wiki. Beaucoup de pages servent de bac à sable et comportent naturellement des erreurs.
Outils
- w:User:PerfektesChaos/js/lintHint – gadget JavaScript qui affiche une liste de LintErrors (messages Parsoid) au fil de l'eau
- WPCleaner – programme Java qui s'interface avec Linter et peut détecter aussi certaines erreurs
- ShowPageLintError.js – script utilisateur de User:MawaruNeko affichant les erreurs Lint d'une page.
- Robot de User:星耀晨曦 pouvant corriger les erreurs de balise fermante absente (multiple-unclosed-formatting-tags).