帮助:扩展:Linter
Linter扩展可以识别页面内必须或者可以被修复的维基文本样式，并识别这些错误是什么、如何修复。
Lint错误页面会根据类型给错误分组。 一些错误可以借助展开模板很容易地找到。 在此页面上，我们将根据问题的严重性相对于被这些问题阻止的目标对lint问题进行分类。 下面有关于这个的更多信息和讨论。
在Lint错误页面底部有一个新功能“显示特定页面的所有linter错误”，允许编辑器在单个页面上获取所有错误的报告。 该报告包含分类和其他有用信息，每个错误都有一个可点击的链接，用于加载页面并高亮错误。 （注意：如果您的源代码编辑器启用了语法高亮，则高亮可能不起作用）。 如果从列表末尾向前完成，那么对页面的更改不会使前面的错误字符偏移无效，因此如果你要修复页面上的所有错误，最好这么做。
我们将继续改进功能以消除噪音、修复错误并使linter的输出更具可操作性，但当前输出已准备好使用并采取行动。
lint问题的文档
为什么修复，以及如何修复
向前看，解析团队计划让Linter扩展能够识别以下维基文本样式：
- 易出错的（例如：伪造的图像选项——通常由拼写错误或因为 MediaWiki中的媒体选项解析很脆弱）。
- 已弃用的（例如：自我闭合的标签）
- 可能因为解析管线的变化而被破坏的（例如：将Tidy替换为RemexHTML）
- 在HTML5中不再有效的（例如像center、font这样的过时标签）
- 与编辑器预期的内容相比，可能已损坏并且可能被解析器错误解析的（例如：未闭合的HTML标签、错误嵌套的HTML标签）
并非所有这些都需要立即或最终修复（取决于你对Linter的容忍度）。可以修复上述lint问题的不同子集，以完成不同的目标。我们（解析团队）将尝试对这些目标保持透明，并通过修复哪些问题来提供有关推进哪些目标的指导。
FAQ页面提供了简化的指引。
目標：替换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 deletable-table-tag, pwrap-bug-workaround, self-closed-tag, tidy-whitespace-bug, html5-misnesting, and tidy-font-bug categories. In order to do a timely replacement of Tidy, we classified all these issues as high priority.
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.
目标：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 obsolete-tag, self-closed-tag categories advance this goal. Given lack of clarity around this goal, we have accordingly marked the obsolete-tag category as a low-priority goal.
目标：澄清编辑意图
Getting markup right is hard.
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.
Issues in the bogus-image-options, fostered-content, misnested-tag, missing-end-tag categories seem to affect this goal.
Since this is a fairly important goal, we have marked most of them with medium priority.
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.
目标：清理标记
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. misnested-tag, missing-end-tag, stripped-tag lint categories affect this goal.
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.
常见问题
When are lint errors for a page updated?
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.
This means that when a new category is introduced (or a correction is made to a previous category), it may take a while for all the results to be updated (if ever for pages that are rarely touched). Making a null edit would speed up the process individually. However, in phab:T161556, we're exploring ways to reprocess all pages.
Should pages in X namespace (e.g. talk) be fixed
The priority is content namespaces. The rest largely depend on the wiki. A lot of pages are used as a sandbox, and as such deliberately contain errors.
工具
- w:User:PerfektesChaos/js/lintHint – JavaScript小工具，可以实时显示LintError（Parsoid消息）的列表
- WPCleaner – Java程序，与Linter对接，也可以检测一些错误
- ja:User:MawaruNeko/ShowPageLintError.js – 在一个页面内显示所有lint错误的用户脚本
- 由User:星耀晨曦开发的Bot，可用于修复multiple-unclosed-formatting-tags错误。