Wikipedia:Linter

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 9cfilorux (talk | contribs) at 20:07, 10 July 2018 (problematic). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Cleaning up the lint

The Linter extension is a MediaWiki extension that aims to identify broken and problematic markup on all wiki pages which cannot be fixed automatically by MediaWiki. Linter lists them by severity of the code issues for editors and bots to clean up (Special:LintErrors). Linter issues in the high priority categories require fixing as they may display in undesirable fashion. The MediaWiki wiki help page describes 17 specific types of lint errors.

Background

A linter is software that helps an author or editor of a document (such as a wiki page or a programming file) see if there may be errors in the document. The extension does this for wiki pages. The extension helps identify whether a page displays as the author intended yesterday in some cases (for example, some image options are "linted" for), and helps identify whether a page displays as the author intended today, due to changes in how the MediaWiki system creates HTML from wikitext. (Other reasons at mw:Help:Extension:Linter#Why and what to fix.)

How you can help

Editors (mostly wikignomes) are going around Wikipedia working to clean up lint errors, which are sorted by severity into one of three priority levels: high, medium, and low, which relate to how badly the displayed page will change when MediaWiki parsing is changed. You are welcome to join in this effort. Here are some hints:

  • Each lint error page has a help link in the upper right corner that links to a page with more information about that type of error.
  • Lint error pages are sorted approximately in order of most recently edited listed last. Some error pages are sorted better than others.
  • Lint error pages are not necessarily complete. When a new lint error type is discovered and a page is made for it, or when the definition of a type of lint error is changed, that lint error page starts empty and is gradually filled by a process that can take several weeks or months.
  • Every page's page information provides a page that tells how many errors of each type of lint error the page has. This section is near the end, and is omitted if there are no lint errors.
  • For each lint error, the count maxes out at 20.
  • It is OK to edit other people's User and User talk pages, and other people's comments on talk pages, but if you do, please see Wikipedia:Talk page guidelines#Editing others' comments for guidance.
    • Don't change the words of other editors.
    • Try to preserve the appearance.
    • It is OK to change the appearance in some cases if it preserves the original intent.
      • It's OK to fix a missing end tag, for example, a <small> tag improperly closed with another <small> tag instead of </small>, even if this changes the appearance. This is especially true if the missing end tag affects anything beyond the scope of the comment in which it appears. If a user's comment in the middle of the page causes subsequent comments or sections to be indented wrong, or be bold or italic or in a different font, you should insert the missing end tag, even if the page has "always" been wrong.
      • In a discussion about wiki or HTML markup, for example, in a discussion about the <div> tag, if the wikitext didn't bracket it as <nowiki><div></nowiki>, the <div> tag will be taken as markup (with a missing end tag) instead of simply displaying. In cases like this, it is helpful to insert <nowiki>...</nowiki> around the unescaped markup, changing the display, showing the plain intent of the original comment, and fixing the missing end tag or other errors resulting from the unescaped markup.
    • In a discussion about errors, for example, "Why does the display get messed up when I use [some bad markup]", it's often best to leave the bad markup in place, otherwise the discussion won't make any sense.
    • Especially on User and User talk pages, try to minimize disruption by getting your fix right on the first try. Preview is your friend.
      • By default, editing a base user talk page will trigger notification to the user, which can be annoying and should not be done in large batches. To avoid this, use a flagged bot account, and also flag the edit as minor, which will bypass the "You have new messages" process.
  • User:PerfektesChaos/js/lintHint has instructions for installing and using LintHint, a javascript gadget that identifies lint errors in a document in the Wiki editor.
    • You can run LintHint repeatedly in the same edit session to see if you fixed the errors and to re-localize the error pointers.
    • Error pointers are relative to the top of the article, so if you correct errors from the bottom up, you won't need to run LintHint again to relocalize error pointers.
  • After editing, pages are re-checked for lint errors, but the delay can take from seconds to hours. If LintHint says you fixed one or more lint errors, you almost certainly did fix them, even if page information and the specific lint errors page aren't updated yet.

How to check a page

You can compare the old and new systems side by side. Navigate to the page and add ?action=parsermigration-edit to the end of the URL. If the two sides match, then it's likely that all of the problems have been fixed. If the two sides don't match, but the second side looks acceptable, then you can probably ignore any errors present on the page.

You can add an easy link to this in the sidebar. Go to Special:Preferences#mw-prefsection-editing and choose "Enable parser migration tool" from the list. Save your changes. Then, when you read a page, there will be a link in the sidebar that says "Edit with migration tool". When you click that link, the side-by-side comparison will appear, above a wikitext editing window.

See also