Help:Extension:Linter/fr

L'extension  identifie les éléments dans le wikitexte qui devraient ou pourraient être corrigés dans les pages, ainsi que quelques consignes sur les problèmes que forment ces patterns, et sur la manière de les résoudre.

La page Special:LintErrors rassemble les erreurs par type. Plusieurs de ces problèmes seront peut-être plus facile à identifier avec Special:Expandtemplates. Sur cette page, vous trouverez les problèmes de lint classés selon la dangerosité des problèmes en regard aux buts qui ne sont pas atteints à cause de ces problèmes. Les informations et la discussion sur ces points seront développés plus bas.

Une nouvelle fonctionnalité "Montrer toutes les erreurs de lint pour une page spécifique" est disponible en base de la page Special:LintErrors, et permet aux éditeurs d'obtenir un rapport de toutes les erreurs d'une page. 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 la configuration de votre éditeur de source a activé le surlignage, alors le surlignage peut ne pas fonctionner). En travaillant depuis la fin de la liste et en remontant, les changement faits sur la page ne modifieront pas le décalage par rapport aux erreurs précédents, et il s'agit de 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 bugs et à rendre le résultat de l'outil plus facile à utiliser, mais le rendu actuel est déjà prêt à l'emploi et utilisable.

Pourquoi et comment corriger
Par la suite, l'équipe chargée du parseur prévoit d'améliorer l'extension Linter pour qu'elle identifie les éléments de wikitexte :


 * qui sont faux (ex : les options d'image fausse - souvent à cause d'une typo ou parce que l'interprétation des options d'image dans MediaWiki est fragile)
 * qui sont obsolètes (ex : balises auto-fermantes)
 * qui peuvent être brisés à cause de changements dans les tubes (ex : replacement de Tidy par RemexHTML)
 * qui ne sont plus valides en HTML5 (ex : balises obsolètes telles que center, font, tt)
 * qui sont potentiellement cassés et pourraient être mal interprétés par le parseur vis à vis de ce que l'éditeur souhaitait (ex: balises HTML non-fermées, mauvaise inclusion de 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 visés à travers les différentes sous-types de problèmes de lint détaillés ci-dessus. Nous (l'équipe chargée du parseur) essayerons d'être transparents à propos de ces objectifs et nous proposerons des conseils sur les objectifs qui correspondent à la résolution chaque problème.

Des instructions simplifiées sont proposées sur la page de FAQ.

Objectif : Remplacer Tidy
As part of addressing technical debt in the parsing pipeline of MediaWiki, we replaced Tidy with a HTML5-based tool. However, doing so would have broken the rendering of a small subset of pages unless certain wikitext patterns were fixed. Specifically, issues found in the,  ,  ,  ,  , and   categories. In order to do a timely replacement of Tidy, we classified all these issues as high priority.

But : Améliorer la conformité du rendu entre l'analyseur PHP et Parsoid
Right now, the HTML generated by the PHP parser is used for read views and the HTML generated by Parsoid is used by editing tools and the Android app among others. The parsing team, as one of its long-term objectives, wants to enable the use of Parsoid's output for both read views as well as for editing. Since Parsoid and RemexHTML are both HTML5-based tools, the lint categories that affect RemexHTML's rendering also affect Parsoid's rendering. We haven't yet identified any newer lint issues that affect Parsoid's rendering at this time, but will update this list as we identify any such.

Objectif : respecter le standard HTML5
This is a somewhat complex goal and we haven't yet arrived at an understanding about how important it is to pursue this goal or how far we should go with this. Additionally, it is not yet clear what mechanisms we wish to leverage towards this goal. For example, based on a bunch of discussions in different venues, User:Legoktm/HTML+MediaWiki outlines a proposal for handling the html5-deprecated big tag. In any case, fixing issues in the,   categories advance this goal. Given lack of clarity around this goal, we have accordingly marked the obsolete-tag category as a low-priority goal.

Objectif : Clarifier les intentions des éditeurs
Il est difficile d'obtenir un balisage correct. Errors inadvertently creep through. While the parser does its best in recovering from these errors, in many cases, what the parser does might not truly reflect the editor's original intent. Given that, we recommend that it is best to fix the issues identified here to clarify the editor's intention. Les problèmes avec les catégories,  ,  ,   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. However, we have marked the missing-end-tag category with a low priority since in a vast majority of cases, the parser does seem to recover fairly accurately. Nevertheless, we recommend fixing whatever can be fixed without too much effort, if only to assist comprehension by other human editors and tools.

But : nettoyer le balisage
Getting markup right is hard. Even in the presence of errors, the parser does a fairly decent job in most cases in figuring out accurately how that piece of markup is supposed to render. But, in much the same way that typos, punctuation and minor grammatical errors can feel unsettling, some editors or those with a developer-mindset might find lint issues in these categories unsettling. We don't recommend spending an inordinate amount of time fixing these issues and, in many scenarios, bots might be able to fix these up as well. ,,   lint categories affect this goal.

Quand fait-on la mise à jour des erreurs de Lint d'une page donnée ?
Currently, all lint categories are populated by errors identified by Parsoid while parsing a page. When a page (or, template transcluded on a page) is edited, ChangeProp requests a re-parse of that page from Parsoid, which will send the fresh results to the Linter extension.

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 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).

Voir aussi

 * Parsoid/API#Wikitext to lint
 * Parsing/Remplacer Tidy
 * w:Wikipedia:Linter
 * w:Wikipedia:Linter