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). High-priority Linter issues require fixing as they may display in undesirable fashion. The MediaWiki wiki help page describes 17 specific types of lint errors.
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: it 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. Further reasons can be found 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 the order of the most recently edited being 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 details how many errors of each type of lint error that 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 is OK to fix a missing end tag, such as 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 bolded or italicized or in a different font, you should insert the missing end tag, even if the page has "always" been wrong.
- Fixing such errors has become more urgent; after MediaWiki's July 2018 switch to a new linter package, many pages that used to look fine despite errors in them now show terrible appearance and accessibility problems, such as fonts becoming smaller and smaller (or larger and larger) the further down the page you scroll, due to successive unclosed sizing elements.
- In a discussion about wiki or HTML markup, unclosed tags are sometimes used. For example, in a discussion about the
<div>tag, the tag might not be surrounded by
<nowiki>markup, so the
<div>tag will be taken as markup with a missing end tag instead of simply displaying the tag. In cases like this, it is helpful to insert
<nowiki>...</nowiki>around the unescaped markup, which changes the display, shows the intent of the original comment, and fixes the missing end tag or other errors resulting from the unescaped markup.
- It is OK to fix a missing end tag, such as a
- 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, since 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. "Show preview" is your friend.
- See also WP:HTML 5 § Obsolete elements and attributes for a list of invalid tags and attributes, which you can detect with CSS. See below.
- The Firefly Tools table, Outstanding linter errors on enwiki, is a chart with rows for the namespaces and columns for the type of lint error, with each cell in the chart listing the number of errors (maxed at 20 for each error type per article). This chart can help find a project of manageable size, or quickly check the number of lint errors of a certain type in a namespace, such as the Article namespace. This page is updated several times per hour.
- User:Galobot/report/Articles by Lint Errors is a report of articles (i.e. pages in the article namespace) that have the most lint errors (excluding obsolete HTML tags).
You can run lintHint repeatedly in the same edit session to see if you fixed the errors and to relocalize 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 rechecked 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.
User CSS tool: lint.css
You can easily employ user CSS to detect a lot of "linty" old HTML 4 code in pages as you read, if you're a WikiGnome who likes to do cleanup. See meta:User:SMcCandlish/lint.css
for a sample CSS declaration that makes various deprecated cruft – like
<strike> – turn pink so it sticks out like a sore thumb. You can customize as you like for your own Special:MyPage/common.css or meta:Special:MyPage/global.css, or follow the instructions at lint.css to
@import (transclude) lint.css directly into your own user CSS at this or any other WMF wiki.
This CSS only detects no-longer-valid markup; it has no means of detecting other coding errors.
See here for another example.