Extension talk:Linter

History link

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

many time the error are causes by users false edits and finding them needs to check hisdtory. please add history link near edit link 5.161.12.16 (talk) 06:38, 16 March 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Add a basic html validator to the extension

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Problem

It can be quite hard to find these errors in pages full of markup and deeply nested templates.

Proposed solution (some ideas)

Add special page that does basic html validation, e.g.:

1. http://jona.ca/blog/unclosed-tag-finder
2. https://gist.github.com/Munawwar/9353965
3. http://cerebrumcontorquet.debun.nl/brainwaves/tablecheck/index.php
4. https://validator.w3.org/

Add a basic html beautifier to the page, e.g. http://minifycode.com/html-beautifier/.

Special:Expandtemplates works, but it is very hard to discern the exact problem without a linter or a beautifier. 197.218.88.36 (talk) 11:58, 15 April 2017 (UTC)

See [1] for an example. It would have extremely hard to find the exact error if those tools weren't used. The linter was complaining about "<span>" when in reality it was being caused by the abuse of definition lists (<dd>) for indenting. That in turn resulted in unbalanced tags which caused the error. 197.218.88.36 (talk) 13:58, 15 April 2017 (UTC)

@SSastry (WMF), comments? Elitre (WMF) (talk) 15:32, 27 April 2017 (UTC)

Linter is based on Parsoid which uses a HTML5 parser. So, we extract information based on that parse which fixes up all the broken HTML. The linting is part of the regular parsing pipeline and we cannot do additional expensive HTML validation in addition. Unsure of the benefits of a validator on top of the mediawiki output (since it has already gone through Tidy which would have fixed everything).

But, I suppose one option is to look at adding html validation to output of Special:ExpandTemplates ... that is a mixed bag since it might flag a lot of noise as well. So, I am a bit unsure about this just yet. But, the general suggestion of making LInter output more easily actionable is something we will continue to work on.

That said, suggestion to add a HTML5 validator to output of Special:Expandtemplates is worth a phab task. SSastry (WMF) (talk) 15:49, 27 April 2017 (UTC)

It is true for the most part that this is not an easy fit. Although some editors do add the good old html table using html markup to templates (most infoboxes consist of these), so something like the table check tool would certainly detect errors from those, and it fits quite nicely with the fostered table lint type.

The linter could show the full html table, with highlighted errors which wouldn't be a problem as some experienced wikitext editors are familiar with those anyway. 197.218.91.181 (talk) 19:49, 27 April 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Recheck page for lint errors during edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Problem

There is no way to check if all errors have been corrected before saving the page.

Background

Currently, in order to eliminate errors in a page one has to save and check them one by one until they are all removed. This means that for a page containing 50 lint errors one may have to save and edit the page more than 50 times, and then check the Special:linterrors over and over again.

Proposed solution

• Alternative 1: Provide a report of lint errors on demand, somewhere in the preview area.
• Alternative 2: Provide a scribunto-like console / tool indicating lines with error along with updated error count.
• Alternative 3: Set up a special page, e.g. Special:Linter/Pagename, that outputs all page errors, the raw html, and an html validator / linter. 197.218.81.124 (talk) 14:02, 16 April 2017 (UTC)

Thanks. We are considering this. https://phabricator.wikimedia.org/T153055 and https://phabricator.wikimedia.org/T163091 cover this issue. SSastry (WMF) (talk) 14:25, 20 April 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Disable gadgets / site js when using the linter from special:linterrors

Problem

Some users or wikis add javascript that blocks the linter from working by highlighting the changes.

Proposed solution

Append the newly created "?safemode=1" to the linter to prevent sitewide javascript / css from interfering, e.g.:

https://www.mediawiki.org/w/index.php?title=Category_talk:Extensions&action=edit&lintid=1384&safemode=1 197.218.81.52 (talk) 20:28, 16 April 2017 (UTC)

While that works, it's kind of a sledge hammer. What scripts are not compatible with the Linter highlight JS? We should update those scripts to not activate when there is a lintid parameter. Legoktm (talk) 03:02, 17 April 2017 (UTC)

See https://phabricator.wikimedia.org/T163070, [1]. It seems that the syntax highlight script was activated for all users in that wiki or at least for all unregistered users.

It is likely that you'll endlessly play a game of wack a mole if you try to fix all such scripts, users will always create scripts with issues or have their scripts break due to various reasons. Individual scripts may also work perfectly fine on their own, but when combined may cause unpredictable errors. 197.218.88.188 (talk) 11:04, 17 April 2017 (UTC)

Strongly opposing a sledge hammer.

• WSTM is automagically fixing many errors, also a lot but not all linter errors as soon an article is opened by action=edit.
• lintHint provides re-analysis of the current TEXTAREA contents and updates the entire linter table with all problems, not only the current single one; also selecting “dsr” error regions one after the other.
• Also syntax higlighting used for error detection would be thrown out.
• Users might have furnished their editing environment by various helpers, links, tools etc. All of them will be gone. Even VE source mode, I presume.
• Bombs page back to stone age, at a nearly naked state.

Site problem, needs to be helped on that wiki or particular unser scripts.

• Other sites or scripts apparentlynot involved.
• JS programming per site or by users need to be developed and adapted continously, or disabled by default. Not a world wide business. PerfektesChaos (talk) 08:11, 12 October 2017 (UTC)

Errors in not-so-relevant pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi,

Is it in any way useful to correct lint errors in pages that are unlikely to be viewed or edited much?

For example, I found some lint errors in user talk page archives. I'd fix them, but maybe it's not worth the time. On the other hand, their presence in the list of errors makes other errors harder to notice. Amir E. Aharoni {{🌎🌍🌏}} 13:03, 20 April 2017 (UTC)

https://phabricator.wikimedia.org/T162918 has yet to be deployed because of the freeze. Arlolra (talk) 13:07, 20 April 2017 (UTC)

To save other people a click, this suggests Different handling for lint errors in User: and other non-article namespaces, a namespace filter, etc. :)

OK, but still: is it in any way useful? Or completely useless?

If it's in any way useful, then it could be done by people who are bored and can't find something better to do. If not, then filtering them out would indeed be more important. Amir E. Aharoni {{🌎🌍🌏}} 13:41, 20 April 2017 (UTC)

Some of the lint issues must be fixed for rendering to be preserved when Tidy is replaced, for example. Others are not so critical and can be skipped. We are still trying to figure out how best to address this either via the UI, via filters like the one Arlo mentioned, or maybe even suppressing them completely. SSastry (WMF) (talk) 14:20, 20 April 2017 (UTC)

@Amire80, check https://www.mediawiki.org/wiki/Help:Extension:Linter. Feedback appreciated. That still doesn't fully answer your original question, but maybe you have some suggestions based on what you read there? SSastry (WMF) (talk) 21:04, 24 April 2017 (UTC)

Thanks for writing these docs:

So, it says: "fixing issues in the obsolete-tag, self-closed-tag categories advance this goal".

What prompted this question is a "self-closed-tag" issue on a user talk page archive. While far from being an important page, it should probably be displayed as correctly as possible in the future, when parsing is changed.

From this I understand that it is at least a bit useful to fix it, even if not high priority. Amir E. Aharoni {{🌎🌍🌏}} 14:42, 26 April 2017 (UTC)

> From this I understand that it is at least a bit useful to fix it, even if not high priority.

Yes, if it is a self-closed tag. SSastry (WMF) (talk) 22:23, 27 April 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: API for fetching lint errors for a specific revision

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Use cases:

User - interested in finding out on average how many lint errors were added to revisions of a specific article (perhaps because there is complicated markup there).

Researcher - interested in looking at the burden (e.g. cleanup efforts) new or older editor cause other editors.

Tool / script developer - interested in finding out in which revision an error was introduced to revert or to identify the culprit.

Use in extensions - for example, recentchanges could theoretically flag every revision that contains a lint error.

Background

Even in its current state the extension can make it possible to do a lot of analysis on existing data. In addition to the use cases presented above, one could for example look into historical data, e.g. run extra analysis on theResearch:VisualEditor%27s_effect_on_newly_registered_editors/June_2013_study dataset to evaluate the number of errors introduced by VisualEditor vs Wikitext editors on page creation or just wikitext editor errors.

This may also be used in the ORES tool (which works on revisions) by giving extra information that can be used to help identify possible revisions containing vandalism (vandals might generally not know wikitext markup).

One possibility would be for an individual to look at their own contributions, and evaluate whether there are patterns of incorrect markup they leave behind that they can improve on. This could also be used by editors to either see if a newbie needs help, or to identify a possible vandal.

Proposed solution

A new api endpoint , e.g.:

api.php?action=query&revids=478198|54872|54894545&prop=linterrors&leprop=count|type|...

Unlike fetching lint errors for arbitrary text (which is useful by itself), this allows for much more flexibility and analysis, without using database dumps or complex scripts. 197.218.80.192 (talk) 12:52, 22 April 2017 (UTC)

@SSastry (WMF), want me to file this as a suggestion on Phab? Elitre (WMF) (talk) 15:32, 27 April 2017 (UTC)

The specific form of this is a bit harder to support since linter is backed by parsoid right now. So, may be a separate endpoint similar to T163091 ... but this will be a lower priority one. But, sure file the suggestion in Phab. Good to have it there rather than be lost on wiki. Thanks! SSastry (WMF) (talk) 15:39, 27 April 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Add more bogus types to linter

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Problem

There are a huge number of wikitext based errors made everyday, both by visualeditor (see VisualEditor/Feedback/Archive/2017/04#h-Issue:_VisualEditor_allows_insertion_of_extension_tags_with_empty_content_that_l-2017-04-27T19:04:00.000Z) and regular wikitext editors that go unnoticed.

Background

The lint type for file options is great, but it doesn't go far enough. There are plenty more tags that are used and could use use coverage.

Proposed solution

Add basic linting for as many of these as possible:

• Gallery - This is a very complex tool, with many options that are pretty easy to get wrong and mutually exclusive at times.
• Indicator - Though not used as much, linting could possibly be easy and useful to do
• Tables - Tables are by far the most flexible and complex wikitext construct, both for building, and just changing. While tables that contain serious errors just show up as broken markup, it is possible, much like the file options, to have bogus options for tables, e.g. using bogus attributes or stuff such as colgroup (see Help:Tables#Caveats). One pipe dream might be to flag tables that don't render properly on mobile (someday).
• Whitelisted html tags (Everything else ) - Some of these have rigid structure and bogus options will be obvious, e.g. for the <time> tag (see Help:HTML_in_wikitext). Some might not be worth linting, but many such as the full html table syntax will be useful as this might be used in templates.

Having these would offer a huge advantage to various editing tools and editors, and hopefully some of these are easy to do at some point in the future (even if low priority for now).

Notes: Maybe it might be a good idea to make a parent category for bogus options, and have specific sub categories for things such a file markup, tables, and everything else. 197.218.91.181 (talk) 19:43, 27 April 2017 (UTC)

On second thought it might be good to be selective about which white-listed tags to lint, some tags such as the definition list are deliberately abused and broken by editors on a daily basis. It might be better to pick the most useful ones because it others will quickly flood the list with unimportant pages. 197.218.91.181 (talk) 20:08, 27 April 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Add last updated date, and "recheck" or purge to special:linterrors

Issue

The current lint error page is very confusing because it is not possible to know if the errors listed there are current.

Background

If someone is looking at the lint error page and someone else happens to fix the errors or just purges the page the current list will remain the same until the next update. This means that a user can often be confused when they view the page and don't find any errors. In many cases it is also a waste of time to actually review the page because the reported errors have long been fixed and the cache hasn't been refreshed, e.g. if a software update fixes the problem causing the error.

Proposed solutions

1. Add a the last time (date) the page(s) were rechecked
2. Add a link or button to purge (using ajax) a specific page (API:Purge) 197.218.88.184 (talk) 12:31, 6 May 2017 (UTC)

Edited pages are reprocessed pretty quickly. Separately, @Legoktm added the history link so editors can look at the edit history and verify. SSastry (WMF) (talk) 15:35, 8 May 2017 (UTC)

Your view comes from a perspective of a perfect tool always operating perfectly. This is not likely to be the case as there will be times when the tool may be disabled, when it doesn't refresh quickly due to server load, or a bug, or when it is simply showing wrong information because there was a software update and not all pages were refreshed.

A simple example would be this:

• https://en.wikipedia.beta.wmflabs.org/wiki/Special:LintErrors/bogus-image-options
• https://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama

It is currently listing thumbtime as a "bogus" file option. Well, the only bogus thing is the report itself, which seems to have been fixed without refreshing all pages. Such inconsistencies will likely always happen, so having a date somewhere in the special page (e.g. like special:wantedpages) gives users some idea about whether it may still be working or not. 197.218.81.110 (talk) 16:29, 9 May 2017 (UTC)

Issue: Linter is highlighting the wrong string

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Steps to reproduce:

1. Go to https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Barack_Obama&action=edit&lintid=56
2. If the highlighted text is not currently being show, scroll down until you find it
3. Look at the highlighted text

Expected

[[File:20090124 WeeklyAddress.ogv|right|thumbtime=1:10|thumb|Obama presents his first [[commons:Obama Administration weekly video addresses|weekly address]] as President of the United States on January 24, 2009, discussing the [[American Recovery and Reinvestment Act of 2009]]|alt=Photograph]]

Actual

in the general election since the system was created in 1976.<ref name="Bloomberg_Salant_20080619">{{cite news |author = Salant, Jonathan D. |title = Obama Won't Accept Public Money in Election Campaign |url = https://article.wn.com/view/2008/06/19/Obama_Wont_Accept_Public_Money_in_Election_C

Lint error:

Page title	Bogus file option	Through a template?
Barack Obama (edit | history)	thumbtime=1:3	—

Note: This is potentially a temporary error. If someone edits the page it will probably disappear, because the problem is gone and this is a report on the cached document. 197.218.81.110 (talk) 16:35, 9 May 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Add a linter warning / notice to the previewnote and editnotice area

Issues

• The linter doesn't always properly highlight the error (or it isn't visible in the current viewport /visible area).
• When the error has been fixed a user may fruitlessly look for a non-existing error.

Background

While the linter uses lintid to pinpoint the lint error in a page (e.g. https://www.mediawiki.org/w/index.php?title=User:Jtneill&action=edit&lintid=42994), this doesn't always immediately scroll to the exact section. So users need to scroll on their own, and make sure that they to select anything otherwise the previous selection is discarded. Also if a user happens to follow the link to a page that has been recently been fixed, they will not find any errors nor be notified of that fact.

Proposed solutions

• Add a message to the previewnote or editnotice system indicating that there are lint errors, with links (or anchors) that jumps to their positions.
• When there is no lint error:
  • Add a message to the previewnote or editnotice system indicating that there aren't any lint errors. Or alternatively add a simple popup indicating that's the case;
  • When the user clicks the page link (leading to the page containing the error) in the Special:LintErrors page:
    • Recheck if there is a lint error and display a alert dialog box.
    • Update the lint error list and remove the page, if all errors are cleared from it.

Notes:

• The previewnote is a mechanism used by Extension:Scribunto to show editors errors during preview, see Extension:Scribunto/Lua reference manual#mw.addWarning for an example.

• Task T141970 seems relevant. 197.218.80.225 (talk) 14:33, 17 May 2017 (UTC)

Correction:

that they to select anything otherwise the previous selection is discarded.

-> that they do not select ... 197.218.80.225 (talk) 14:36, 17 May 2017 (UTC)

False positives

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In the past days I've been going through Linter errors for nlwiki and now I think I've found a few false positives. Where and how should these be reported? Bdijkstra (talk) 22:44, 29 June 2017 (UTC)

Phabricator bug report ideally. If not, you can report them here, and we'll create bug reports and investigate. Thanks. SSastry (WMF) (talk) 22:45, 29 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Main-NS links where template-NS links expected

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In looking through various LintErrors pages at the Hindi Wiktionary (a language I don't read, unfortunately), I've noticed that all the linked template names at wikt:hi:Special:LintErrors/obsolete-tag seem to lead to (unprefixed) titles in the main namespace rather than to the appropriate template pages. For example, errors caused by a problem in wikt:hi:साँचा:हिन्दी (AKA, wikt:hi:Template:हिन्दी) give links (in the "Through a template?" column) to the main-namespace entry wikt:hi:हिन्दी instead. Is this a known bug? I couldn't find a Phabricator task that seemed to address it — although I admit I didn't spend very long looking. dcljr (talk) 08:53, 6 August 2017 (UTC)

If templates on that pages will be expanded it will result in that error directly on (main) page. You can notice separate column "Through template". wargo (talk) 08:59, 6 August 2017 (UTC)

I don't think you understood me, since you don't appear to be addressing the issue I am raising. dcljr (talk) 09:36, 6 August 2017 (UTC)

The relevant task is https://phabricator.wikimedia.org/T161151.

It seems that the fix wasn't complete or perhaps these pages weren't refreshed after the fix was made. Purging the pages will probably clean it up if the issue is the former.

They will naturally disappear from the list as pages are edited if that's the case. 197.218.89.17 (talk) 10:44, 6 August 2017 (UTC)

Yes, the staleness problem is T165538. The original problem was fixed as our anonymous friend above noted. SSastry (WMF) (talk) 15:09, 6 August 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Implement a filter to avoid a Sisyphean task

Issue:

While some users fix these issues, other users add more.

Background:

Currently the linter has unintentionally introduced a problematic scenario. In fact, it is a common old age wisdom that if you want to tell the characteristic of a group of people, tell them to fill a bucket with water, and come back a few hours later. If they are still doing it, they are fundamentally insane because the bucket has a hole in it, and any sane person would stop doing the Sisyphean task .

This will likely result in one of two scenarios, either users will stop making the effort to clean these up, until D-day or users will waste considerable time redoing the same task pointlessly only to be reverted or added by another ignorant user. In fact, the recent linter reports seem to indicate that such errors are increasing rather than decreasing on English wikipedia and commons.

Possible solutions:

1. Add a notice to the linter page or elsewhere encouraging wikis to opt into the new parser ASAP (or once they reach a very low number of high priority tasks)
2. Add some facility to Abusefilter that prevents new such cases from being added to pages
3. Gradually disable each separate high priority linter category on certain specific dates.

In the long term, the only sustainable approach is probably #2. People work better when they feel the problem closer to home, and also because low priority issues will probably keep piling up, making the report useless because people will likely end up ignoring it.

As long as pages render well enough now most editors won't bother fixing the problems as discussed on this thread (Wikipedia:Village_pump_(technical)/Archive_154#What_problems_occur_by_not_closing_bold_or_italic_markup.3F). 197.218.80.189 (talk) 17:48, 11 August 2017 (UTC)

Actually, the problem is different -- it is not introduction of new errors.

Linter depends on Parsoid and Parsoid gets requests to parse a page only when it is edited. So, we don't yet have a complete baseline run. So, as pages are edited, more of them get linted which is what is causing the addition of new pages.

We are planning to address that in the coming weeks by running a script to request linting on all pages on all wikis. After that, we expect counts to actually keep going down. SSastry (WMF) (talk) 18:23, 11 August 2017 (UTC)

That is true. But it doesn't account for the fact that as noted in the linked thread, some people deliberately add these because it is more convenient and easy to do so, and also because there is no tool preventing it and no warning anywhere in the editing tool against doing it.

The basic idea is that it is important to have a systematic mechanism allowing editors to prevent new occurrences so they focus on only fixing existing cases and be done with it. 197.218.80.189 (talk) 19:02, 11 August 2017 (UTC)

To use another analogy, if one has a leaking broken water pipe, the first thing one should do is fix the pipe to prevent more water from dirtying the floor, instead of first cleaning the floor and then fixing the pipe. 197.218.80.189 (talk) 19:08, 11 August 2017 (UTC)

In theory I think you're right, but at a time when it's hard to retain and keep editors, I'd hate to reject an edit simply because it was syntactically wrong for something that looks fine in their browser. Legoktm (talk) 02:21, 12 August 2017 (UTC)

Well, that's a conflicting view. Some edits are already rejected because they are syntactically wrong, and yet "look fine" in the browser, e.g. in the module namespace, for css related to template styles, and probably many more.

Also just because something looks fine in one browser doesn't necessarily mean it will look fine in another. Just try to view a very long and complex wikitext talk discussion on a mobile device. Or load one of those articles with huge tables. The submitted content will probably also not always look fine if the parser-migration tool is used (e.g.https://en.wikipedia.org/w/index.php?title=Gaston_Essengu%C3%A9&action=parsermigration-edit&oldid=760555126).

One tool that could somewhat reduce syntax errors is the Extension:CodeMirror. For example it could be configured to work in a manner similar to Extension:CodeEditor by asking the user if they want to save the article with syntax errors. While it might considerably affect performance to do a full check because the whole page needs to be parsed, it can easily check basic wikitext and html errors. This would be ~99 % effective for pages that don't contain any templates, parser functions, or tag extensions.

The fact remains that doing nothing means that this extension will either create endless syntax wars or it will simply be ignored by people claiming that the content looks fine in browsers and there is no point to doing anything. 197.218.84.98 (talk) 15:31, 13 August 2017 (UTC)

Possible bogus-image-options bug

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi,

I might be wrong, but I suspect that the page w:he:שיחת משתמש:מרקו is incorrectly reported as having bogus image options.

It has a template as the file caption. The template renders as expected, so I don't understand what is bogus there. It is a slightly weird template, however, so it's possible that I'm missing something.

NB: @SSastry (WMF): , @IKhitron: . Amir E. Aharoni {{🌎🌍🌏}} 14:05, 26 August 2017 (UTC)

The template expansion returns a link [[משתמש:|]] which has no link content (presumably pst normally fills that in). Since that doesn't parse as a link, the pipe remains, and therefore the caption splits on the pipe, half of which becomes the caption text, the other half becoming the bogus option. Arlolra (talk) 14:41, 26 August 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

"Missing end tag" results in numerous extra <code> tags (and rendering issues)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Issue

Paste the following in a wiki page:

<code>A piece of computer code
asdasdasd
<h2> buuu</h2>
zsadsdasd

Expected:

Output html should be similar to above.

Actual:

<p><code>A piece of computer code
asdasdasd
</code></p><code><h2><span class="mw-headline" id="buuu">buuu</span></h2></code><code><p>zsadsdasd
</p></code>

See it in action on this page (https://www.mediawiki.org/w/index.php?title=Project:Sandbox&oldid=2583108)

Possible solutions:

• Increase priority of this lint error - This seems to be creating huge rendering differences, and seems bad enough to either increase the priority of the "misnested" tag
• Set it as a separate high priority category
• Or decide whether this is actually a bug in the parser - and fix that

Notes: I've been seeing this for quite some time in some help pages (e.g. https://www.mediawiki.org/w/index.php?title=Help_talk:Searching&oldid=2475830 scroll down), and couldn't understand where it came from until I tried it in a different wiki, and it became obvious. 197.218.91.45 (talk) 22:49, 11 October 2017 (UTC)

Note that high priority rendering categories are about whether rendering will change when Tidy is replaced with a RemexHTML based tool. It is not about whether the HTML output for a piece of wikitext matches expectations.

In this case, the actual HTML structure is slight different for Tidy, RemexHTML and Parsoid. However, the rendering in the browser is identical.

So, this doesn't belong in the high priority category. Right now, we don't want to confuse editors and add more work to their plate beyond what is required to switch from Tidy to RemexHTML. Once Tidy is replaced, we could change the priority of linter categories based on new desired goals. SSastry (WMF) (talk) 03:27, 12 October 2017 (UTC)

Err, rendering did change. Did you actually look at the url?

Try looking at https://www.mediawiki.org/w/index.php?title=Project:Sandbox&oldid=2583108&action=parsermigration-edit. Maybe you've customized the code tag in your browser or personal css, and you don't see the gray areas.

Anyway, it is up to you. Personally I found it so odd, that I began to think there was something wrong with my browser. 197.218.90.179 (talk) 20:03, 15 October 2017 (UTC)

Ah, sorry, you are right. I looked at output in my browser outside the mediawiki CSS settings where the differences don't show up. This doesn't happen with the small tag (except for the vertical whitespace diff). Parsoid's analysis for linter errors treats all formatting tags identically, and both code and small are formatting tags. But, looks like CSS for the code tag changes how the heading and paragraph render.

We could add a special case for the code tag, but I am inclined to let this be for just now unless there are a lot of code-tag-related issues in practice. SSastry (WMF) (talk) 20:49, 15 October 2017 (UTC)

Hmm, you're right. Those come from the wiki-specific CSS styles. Still, the way the way those code tags are nested results in invalid html, see :

https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.mediawiki.org%2Fw%2Findex.php%3Ftitle%3DProject%3ASandbox%26oldid%3D2583108

That might be a completely separate problem, maybe https://phabricator.wikimedia.org/T134469. I suppose that code tags aren't used that much in articles, and because the linter detects this it might be reasonable to let editors take their time fixing it. 197.218.90.179 (talk) 01:28, 16 October 2017 (UTC)

Output compliance wrt content model constraints is covered in Parsing/Notes/HTML5 Compliance ... that is a separate discussion. SSastry (WMF) (talk) 02:23, 16 October 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Suggest autofixes for simple lint errors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Issue

It can be quite time consuming coming up with fixes to lint errors.

Proposed solution

Use the parser or cleanup tool to suggest fixes to content. This could be a within a triggered fromSpecial:Linterrors.

The simplest solution is to only suggest an autofix when:

There is simple markup (no templates, parser functions / tag extensions within the snippet);

Simple hacky example for lint error found here (https://www.mediawiki.org/w/index.php?title=User:SPage_(WMF)/VE_span_bug&oldid=1163248) :

var sText = '<p style="font-size: 1.2em; margin-top: 1.2em;">When Vagrant is done configuring your machine, browse to <span class=plainlinks>http://127.0.0.1:8080/</span> to find your MediaWiki instance. The admin password is <code>vagrant<code>.</span>';
    disablelimitreport: '1',
    $.post(window.location.origin + '/w/api.php?action=parse', {
        format: 'json',
        text: sText,
        disableeditsection: '1',
        disablelimitreport: '1',
        contentmodel: 'wikitext',
        formatversion: 2,
        wrapoutputclass: ''
    
    }).then(function(data) {
        if (data && data.parse && data.parse.templates.length === 0) {
            $.post(window.location.origin + '/api/rest_v1/transform/html/to/wikitext', {
                html: data.parse.text
            }).then(function(data) {
                console.log("Suggested fix:\n\n" + data);
            });
        }
    });

Output:

When Vagrant is done configuring your machine, browse to <span class="plainlinks">http://127.0.0.1:8080/</span> to find your MediaWiki instance. The admin password is <code>vagrant</code>.

Currently there doesn't seem to be a way to check if the content contains parser functions or tag extensions. It might be possible to strip manually strip these before testing. Or potentially make that into its own feature request for the API.

It might also be interesting to isolate this cleanup tool (tidy, etc) and expose it as a separate API, assuming it doesn't already exist somewhere. 197.218.90.50 (talk) 11:13, 26 October 2017 (UTC)

Interesting idea. Have to ponder that for a bit -- in this form, this will only be usable on a very small set of pages, but wonder if we can build a variant that will work in the presence of templates since pretty much every page will have templates / extensions. SSastry (WMF) (talk) 04:14, 27 October 2017 (UTC)

Extracting "atomic" snippets reliably from a wikitext page is hard -- consider the simplest case where the entire page is wrapped in an unclosed <div> tag -- but there is something here worth experimenting with. SSastry (WMF) (talk) 04:19, 27 October 2017 (UTC)

I'd say start small and build up from there, rather than get stuck in analysis paralysis.

Anyway, considering that parsoid seems to keep track of template parameters, it can probably detect if a particular argument contains a lint error, and if so suggest a localized fix. Of course wikitext in general is very messy and complicated, changing a single token in a template can completely alter the whole page and trigger even more lint errors. That could be detected using a basic diff tool, e.g. if the proposed automated change significantly alters the page rendering, then it can either not suggest the fix, or provide a serious warning.

- consider the simplest case where the entire page is wrapped in an unclosed <div> tag

Well, for the simple case the tool still works. For better or worse the linter highlights the whole page in some of those cases, so it will close the snippet at the end (of the page). It is also prudent to set a limit to the snippet size (in bytes) to reduce destructive "fixes".

It might be worth making the linter smarter by providing the offset of the closest html parent element. For a table cell, that might be the whole table, or the top most table in case it is a nested table.

Generally, the exact solution depends on the exact problem:

• Invalid self-closed - simply to strip it, e.g. <span/>. That's what the parser does anyway and that's what the code above will do.
• Table tag that should be deleted - same as above, do what the parser does (but it needs the topmost parent of the nested table
• Bogus file option - the simplest fix here is to just comment out (e.g.[[File:boo.svg|1|2|3]] ->[[File:boo.svg|<!-- Parameter error here 1|2|-->3]]) the bogus option, and leave a note. In many cases these are typos.
• Misnested- pure wikitext / html cases (stuff like <b>\n * list \n *list </b> can easily be solved by the code above. It might be better to give up when there are templates involved
• Stripped tags - code above fixes that too by removing them from the markup. Although that might not always be the right fix.
• Some of them can be fixed with a reversion, as described here (https://www.mediawiki.org/w/index.php?title=Extension%20talk%3ALinter#h-Suggestion%3A_Store_the_revision_that_introduced_the_lint_error_in_linter_database-2017-10-27T11%3A21%3A00.000Z). s that.

----

In many cases there is no need to reinvent the wheel, editors have created tools to identify and fix some errors automatically with high degrees of accuracy. 197.218.88.106 (talk) 11:39, 27 October 2017 (UTC)

Extracting "atomic" snippets reliably from a wikitext page is hard -- consider the simplest case where the entire page is wrapped in an unclosed <div> tag -- but there is something here worth experimenting with.

Personally, it to seems to me that the parser really facilitates this kind of "misbehaviour". A better approach would be for it to transform the tag into a simple <div/> on output. That would get editors to fix it without any linter, and if they don't they don't cause problems for anyone else who doesn't understand html but still edits the page. 197.218.88.106 (talk) 11:45, 27 October 2017 (UTC)

I am working on automatic syntax fixes by WikiSyntaxTextMod for 8 years now.

I strongly discourage such an approach as automatic means triggered by MediaWiki on all Wikis for all users.

Dealing with the strange things that happen here needs editors who know the Linter methodology and have very good skills in wikisyntax. Less than 1 % of the editors in German Wikipedia could deal with that suggestions. Newbies get entirely smashed.

Error causes are ambiguous. It is necessary to understand the intention of the author first before appropriate remedy can be chosen. It might have been the idea to put some words <small><small>minor into an empty element, or creating an anchor by <span id="here" /> and making a mess of it. An auto-correction will silently remove that and leaves no trace and no hint.

And popping up somewhere a <div/> on output is a very bad idea. That will be presented to all readers on all such pages, while it worked for a decade with that error andlooke pretty. The only problem an unclosed div causes that a validator complains, but it does not affect readability of the page.

Leaving short comments in the syntax would be understood by a few people only. Causing more confusion in a wide majority of editors rather than helping to solve problems. Leave such things to syntax experts. PerfektesChaos (talk) 11:49, 31 October 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Store the revision that introduced the lint error in linter database (or maybe page props)

Issue

It is not always easy to find out how, where and why and error was introduced without context (revision id, edit summary etc)

Proposed solution

Log the revision that introduced the error( ,e.g. for page "Stuff" - linterror-nested-tag = "revid =12346"):

• Store in page props ; or
• Store in lint database

For simple enough errors it may be possible to fix the error by simply reverting the template / page to the last known good revision. 197.218.88.106 (talk) 11:21, 27 October 2017 (UTC)

Storing revid in LinterDB is a pretty good idea.

Naturally for new cases only, 0 for historical issues.

Diff2prev will give the clue in many cases quickly. On large edits with many element changes still some homework.

Reverting is not really a recommendation; that will destroy valuable contents for an ignorable HTML formatting problem. Get the reason and improve as appropriate. PerfektesChaos (talk) 11:28, 31 October 2017 (UTC)

Issue: Different rendering of list not detected

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Steps to reproduce

1. Paste the following code on a page

<ol> uuuu</ol>

Expected output

<ol> uuuu</ol>

Or

<p> uuu</p>

Actual

<div style="margin-left: 2em">uuuu</div>

Worse rendering:

<ol> uuuu
<li> zzz</li>
</ol>

Output

<ol>
<li style="list-style: none">uuuu</li>
<li>zzz</li>
</ol>

That div thing is pretty odd, the newer parser seems to output it in a better way. Although it might be best to simply remove the ol tags in such cases. 197.218.83.254 (talk) 19:30, 1 November 2017 (UTC)

There are probably several edge cases like this which we probably won't try to detect and report exhaustively. The high priority linter categories detect patterns that are in common use on wikis and would break. SSastry (WMF) (talk) 19:47, 1 November 2017 (UTC)

Makes sense, it might be right that it might not be worth the effort. The newer tool handles it quite well.

In general though, it might make sense to have a catch all linter category: "Invalid html". That way every other low priority item that doesn't fit elsewhere might be simply thrown in there. That's probably worth the effort as new html tags may be whitelisted, and a general parser may simply detect them and put them there with lower effort from developers.

Since there will eventually be a need to update the html library / validator. 197.218.83.254 (talk) 20:15, 1 November 2017 (UTC)

P.S. Fun fact:

<ol type=a />

The above renders nothing in the older cleanup tool, but shows a nice "a." in the newer one. 197.218.83.254 (talk) 20:34, 1 November 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Detect unclosed wikitext based tables

Issue

Unclosed tables tend to often cause problems to unsuspecting editors. This is apparently the simplest way to create a table:

{|
|

In general the linter seems to detect such cases in some cases that will cause problems, although there are probably plenty of edge cases it doesn't detect those. It also detects the simple unclosed html table <table> but not the wikitext based table.

Stranger still is the fact that one can more easily create a table with just something like a td tag, e.g. <td style="background-color:red">buu. This causes rendering differences but is already detected by the linter. 197.218.83.254 (talk) 19:48, 1 November 2017 (UTC)

Issue: Parser crash with specific unclosed tags + block type html tag

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Steps to reproduce:

Paste the following wikitext in a page or simply use the parsermigration-edit , and click preview:

 <i> <b>foo<b>k
<b>foo</i>

Output:

[WjpdFQpAICkAAKBp10gAAAAY] 2017-12-20 12:52:37: Fatal exception of type "RemexHtml\TreeBuilder\TreeBuilderError"

Note the space behind the <i> . That's a pre block, it also seems to happen with a div and perhaps other tags. 197.218.81.28 (talk) 12:58, 20 December 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Issue: Undetected fostered content

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Reproduction case:

<table><td><li>First<div>
second
</div>
third
</table>

Expected

Everything is in the table

Actual

Old parser moves content out of the table:

<p>third</p>
<table>
<tbody><tr>
<td>
<ul>
<li>first</li>
</ul>
<p>second</p>
</td>
</tr>
</tbody></table>

New parser keeps it as expected

<table><tbody><tr><td><li>first<div>
<p>second
</p>
</div>
<p>third
</p>
</li></td></tr></tbody></table>

Note: It seems that by closing the td this lint error is detected. Seems like a good reason to keep the missing end tag for td (despite being valid html) because the wild things the browser may do to it may be completely unexpected. 197.218.90.206 (talk) 16:46, 5 January 2018 (UTC)

Also happens with wikitext:

{|
|<li>first<div>
second
</div>
third
|}

197.218.90.206 (talk) 16:49, 5 January 2018 (UTC)

I don't know .. that is pretty convoluted HTML to merit changing default linting strategies.

Fostered content detection is done by Parsoid which is HTML5 based. Given that we are moving to RemexHTML which is alsoHTML5 based, I think it is reasonable not to flag those as fostered content. SSastry (WMF) (talk) 18:10, 5 January 2018 (UTC)

Well this flips content around. There couldn't be a more confusing parser change. Note that this also happens if a wikitext list is used instead of the html based list:

{|
|* first<div>
second
</div>
third
|}

This example came from a discussion here: https://www.mediawiki.org/w/index.php?title=Talk%3AWikimedia%20Audiences/Archive%202/Flow%20export#c-Whatamidoing_%28WMF%29-2016-10-06T20%3A41%3A00.000Z-Alsee-2016-07-30T18%3A45%3A00.000Z . It seems to have been used as an argument that the preview used by flow itself is somewhat flawed.

Having used something like that in the past, it is likely that this probably happens quite a few times because it is utterly impossible to add a list item with multiple lines using just wikitext because it lacks a "wikitext list closing tag". See https://phabricator.wikimedia.org/T3115.

Anyway, who knows, perhaps it doesn't happen enough times to merit any changes or even flagging. 197.218.90.206 (talk) 19:28, 5 January 2018 (UTC)

{|
|
* first<div>
second
</div>
third
|}

197.218.90.206 (talk) 19:31, 5 January 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How to locate linter error

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi, I posted a topic in Wikimedia Developer Support a few days ago. Can someone answer my doubts? 星耀晨曦 (talk) 12:49, 18 March 2018 (UTC)

Location tells you the start and end offset within the wikitext source where the linter error can be found. SSastry (WMF) (talk) 22:56, 18 March 2018 (UTC)

How can I catch the error html? I queried it, the start is 2129 and the end is 2275. When I catch the html in my program, the program returns non-error html. There is my test code (written in PHP):

$start = 2129;
$end = 2275;
$obj = new HclearBot\APIRevisions( 3912458 ); // Where 3912458 is the page error
echo substr( $obj->getContent(), $start, $end - $start );

There is HclearBot\APIRevisions class for used to get revision.[2].

The captured html is completely different from the html seen in the wikicode editor. 星耀晨曦 (talk) 12:57, 19 March 2018 (UTC)

Also, note that the offsets are for wikitext strings in the page, not HTML. SSastry (WMF) (talk) 15:44, 19 March 2018 (UTC)

The offsets are character offsets. So, you need to use a unicode compliant substr operation. Try mb_substr($obj->getContent, $start, $end, "utf-8").

https://zh.wikipedia.org/wiki/%E9%A6%96%E9%9F%B3%E4%BA%92%E6%8F%9B?action=parsermigration-edit shows you the problem visually.

You can see the problem here: ... You have <u>m<u>issed all my ... SSastry (WMF) (talk) 15:42, 19 March 2018 (UTC)

Oh, yes. I just need this answer. Thank you. 星耀晨曦 (talk) 16:01, 19 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

What does "Output not from a single template" mean?

What does this mean? 星耀晨曦 (talk) 14:29, 6 April 2018 (UTC)

I think that Linter wasn't able to pinpoint which template is causing the problem, but only a selection of several templates NicoV (talk) 14:34, 6 April 2018 (UTC)

Indeed. Note that the problem might be caused by the template itself, or by the template call. Bdijkstra (talk) 14:37, 6 April 2018 (UTC)

Look this error. The tagged field contains 21 templates, then I use this URL to query if these templates have linter errors and eventually I don't get anything.

P.S. I noticed Parsoid doesn't recognize the error in Lua modules. 星耀晨曦 (talk) 14:46, 6 April 2018 (UTC)

If a template doesn't have linter errors, that can mean that the linter hasn't seen it yet, or that the errors aren't transcluded in the template itself. In any case you can use Special:ExpandTemplates to look at the generated wikicode. In the first few lines you can already see multiple unclosed font-tags obviously caused by Template:User rainbow. Bdijkstra (talk) 15:07, 6 April 2018 (UTC)

For bot, the difficulty of repairs has increased. :) 星耀晨曦 (talk) 04:45, 7 April 2018 (UTC)

Your IP address has not been whitelisted to report lint errors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I have installed mediawiki with Linter, VisualEditor and Parsoid extensions.

I get "Your IP address has not been whitelisted to report lint errors" error when I want to edit a page using VisualEditor.

Should I white list my IP anywhere? What is this IP, the visitor IP, server public IP or localhost? Niagarafalls (talk) 13:50, 8 April 2018 (UTC)

You need to whitelist IPs of your Parsoid server in your mediawiki config.

See https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/d6ca1267a4680a020630e767c4fedd074c8c521e/wmf-config/InitialiseSettings.php#14844 for the wikimedia production config. SSastry (WMF) (talk) 20:45, 8 April 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Update location of the lint error

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Assuming there are multiple errors on the same page, will the location of other errors be updated after an error is fixed? 星耀晨曦 (talk) 09:23, 30 April 2018 (UTC)

It will get updated once the page is reparsed. SSastry (WMF) (talk) 14:47, 30 April 2018 (UTC)

Will only change the location, other properties (e.g. error id) will not change? 星耀晨曦 (talk) 19:15, 30 April 2018 (UTC)

Error id also changes. SSastry (WMF) (talk) 19:23, 30 April 2018 (UTC)

It's bad news for me. If I query out 1, 2, 3, 4 error id before fix, assuming these errors are on the same page. I fixed No.1 error, after the error fix will wrong, because the location of the errors is based on the previous context (before fixed N0.1). Do you have any good ideas?

Now I think to fix only the first error and give up fixing the errors behind. If the error id is not changes..I can append a API query to update location.. 星耀晨曦 (talk) 14:33, 4 May 2018 (UTC)

Fix it in the reverse order of offsets .. i.e. fix the error with the largest offset first .. that way, offsets for errors earlier in the page won't change. SSastry (WMF) (talk) 15:09, 4 May 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

No lint errors

I've installed the extension and modified the config.yaml for Parsoid as per the instructions. VisualEditor is working fine so I know Parsoid and Restbase are both working. However, I am not getting any lint errors at all. This seems unlikely. I've tried deliberately putting an error on a page but it isn't picked up. Any ideas? Is there anything I can do to test that everything is working correctly? Prh47bridge (talk) 08:42, 24 May 2018 (UTC)

• You can try setting sendAPI: false and rendering exclusively with Parsoid to see if it logs the errors you expect.
• You can check the logs of your MediaWiki API to see if it's rejecting the posted lints
• Maybe you need to whitelist the server Parsoid is running on https://github.com/wikimedia/mediawiki-extensions-Linter/blob/master/extension.json#L166-L169 Arlolra (talk) 16:14, 24 May 2018 (UTC)

Thanks for your advice. I think I've solved it. It seems that the version of Parsoid I'm using is expecting the config variable linterSendAPI rather than the current variable. So lint errors were being detected but were going straight to the log, not to the API. However, when I put "linterSendAPI: true" in the config Parsoid won't work at all! Very frustrating! Would I be correct in thinking that this means I'm using an older version of Parsoid and need to update? Prh47bridge (talk) 09:18, 25 May 2018 (UTC)

I've now established that, for some reason, my server was no longer picking up Parsoid updates from the repository. Fixed that and will be upgrading from the currently installed version (0.7.1) to the latest in the repository. Hopefully that will fix this issue. Prh47bridge (talk) 13:43, 25 May 2018 (UTC)

The config was renamed between versions 0.7.1 and 0.8.0

You might not want to upgrade as high as 0.9.0 though, see the release notes https://www.mediawiki.org/wiki/Parsoid/Releases#0.9.0_(released_Mar_23,_2018) Arlolra (talk) 14:51, 25 May 2018 (UTC)

Thanks for the pointer. I have now upgraded to 0.8.0. However, it still isn't working. I'm getting the following in the Parsoid log on startup:

WARNING: For config property linter, required a value of type: object

Found null; Resetting it to: {"sendAPI":false,"apiSampling":1,"tidyWhitespaceBugMaxLength":100}

A diff comparing my config.yaml with the distribution version comes up with the following (ignoring domain name stuff);

83,87c83,86

<         linting: true

<         # Send lint errors to MW API instead of to the log

<         linter:

<               sendAPI: true

<               apiSampling: 10

---

>         #linting: true

>         #linter:

>         #  sendAPI: false # Send lint errors to MW API instead of to the log

>         #  apiSampling: 10 # Sampling rate (1 / 10)

97,99d95

<

<       # Enable the batch API

<       useBatchAPI: true

Any ideas? I'm assuming there is something I need to change in config.yaml to make this work? Prh47bridge (talk) 12:50, 29 May 2018 (UTC)

Maybe a whitespace issue? Do you have any tabs hanging around? Arlolra (talk) 15:04, 29 May 2018 (UTC)

Yes, it was a whitespace issue. I had tabs rather than spaces on the sendAPI and apiSampling lines of config.yaml. I am no longer getting lint errors in the Parsoid log. I can't see anything relevant in the API debug log but I suspect that is because the page I've been using no longer has any lint errors! I'll have to try and provoke one to make sure it is working. Prh47bridge (talk) 23:18, 3 June 2018 (UTC)

Coming back to this after getting distracted by a problem with subpages...

I'm still not getting any Lint errors. Looking at the Parsoid log, I'm seeing multiple entries saying "Parsoid id found on element without a matching data-parsoid entry". I'm also seeing "Incompatible constraints (merge)" messages. I don't know if the incompatible constraints reports are significant. I know that for a while Parsoid was unable to log errors through the API due to a whitelist problem which I've fixed. Is that the cause of the "element without a matching entry" messages? Is it stopping errors being reported from my test page? If so, what do I do about it? Any advice gratefully received! Prh47bridge (talk) 09:50, 25 June 2019 (UTC)

False errors on transcluded page

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Our special page suggests a missing end-tag on this page we use to access an archive by year. The page is mainly a transclusion of this single archive page, that contains no errors. Using lintHint 0 errors are reported for this original page and 4 for the transcluding page! As far as I can see, 3 error messages are generated by the "{{qtu}}" in section 66.1 and 1 by section 79, a WMF message. As there seems to be no problem rendering the page as intended, might this be a bug in Linter? MarcoSwart (talk) 12:15, 31 May 2018 (UTC)

I have narrowed down the problem to our template: Tl that is used to create a link to a template (description) page, and uses html-entities instead of {}-brackets in order to achieve the desired result. For Linter this is no problem on the page itself, but when the page containing the template is transcluded itself apparently it becomes too much. My question now becomes:

a. Will using the html-entities in the way our template Tl become problematic in future parsers? In that case it would constitute a new error?

b. If the answer to a. is "No!", then isn't this a bug to be fixed in Linter? MarcoSwart (talk) 11:02, 26 September 2018 (UTC)

Chances are that it isn't a false positive. The problem probably comes from the hacky way you're trying to display the templates, since it ends with }}. It means that if there is another template on the page it will complete the transclusion and have unexpected results, e.g.:

{{ecologie|{{Tl|foo}}

A more sensible approach is to either apply nowiki to each side, or replace all curly brackets there with their html entities:

{{templatename}} 197.235.55.13 (talk) 11:47, 26 September 2018 (UTC)

Thanks for the reply and the suggestion. As far as I am concerned my question has been answered and the problem is solved. MarcoSwart (talk) 21:58, 26 September 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Wrong location

See this query. The error location is wrong, because 278-341 are

<code>」字號以利排版，要複製再利用文獻時，不用複製「<code>*<code>」字號。

the error text should be are

<code>*<code>」字號以利排版，要複製再利用文獻時，不用複製「*</code>」字號。

This location caused my bot to make a wrong repair. 星耀晨曦 (talk) 10:44, 2 June 2018 (UTC)

Fostered content

Why is this considered a "Fostered content" error?

{| class="wikitable"
{{{{{subst|}}}!}}<div>a</div>
|} Helder 19:32, 24 July 2018 (UTC)

It's sort of a bug in Parsoid, it's struggling with the templated template name.

The php parser sees this as {{{subst|}}}, a top-level template argument, whose default value is the empty string. So, gets expanded to {{!}}<div>a</div>, which gives the desired wikitext table syntax.

Substitution (subst) is supposed to occur when saving a page, and shouldn't show up in wikitext. Arlolra (talk) 20:38, 24 July 2018 (UTC)

Filed as https://phabricator.wikimedia.org/T200293 Arlolra (talk) 20:44, 24 July 2018 (UTC)

I've responded there, but why is the subst showing up in saved source? Or is the complaint that Parsoid isn't handling PST before saving? SSastry (WMF) (talk) 05:47, 27 July 2018 (UTC)

The author used the wrong syntax, three { instead of two. Arlolra (talk) 14:15, 27 July 2018 (UTC)

three braces are OK for this case use inside a template. It means taking parameter whose name is subst, and if it is not passed by the page transcluding the template, use a default empty text value.

The role of this parameter in any template "X" is to:

• pass either "|subst=" (i.e. empty text, the default value), so that the code {{!}} will be used (and saved under this form on editing and saving the page making the transclusion of "X")
• or pass "|subst=subst:", so that the | will be used (when saving the page using the template "X", and if the template X itself was "subst:'ed" as {{subst:X|...|subst=subst:}}, then that page will not be saved to contain {{subst:!}} or {{!}}, but its expansion (to a pipe character). Verdy p (talk) 19:33, 28 March 2023 (UTC)

But, {{{subst}}} substs .. i just tested ... SSastry (WMF) (talk) 17:05, 27 July 2018 (UTC)

oh .. never mind ... i see what you are saying about top-level argument. SSastry (WMF) (talk) 17:06, 27 July 2018 (UTC)

Suggestion: Improve sorting and change number of results

Issue:

Currently, the special page doesn't provide same type of paging and sorting available in other special pages. The only way to get more results is to keep clicking next.

Proposed solution

Make it possible to :

• Change number of results , e.g.:https://en.wikipedia.org/wiki/Special:LintErrors/misc-tidy-replacement-issues?namespace=0&limit=5000
• Sort results, e.g. by page name / template, and description, like in https://en.wikipedia.org/w/index.php?title=Special:ListFiles&sort=img_name&limit=50

It might be a general problem in most pages that use the "newer" query list design, or simply a switch that wasn't enabled for this one because it exists in listfiles. 197.235.57.129 (talk) 23:17, 1 September 2018 (UTC)

Is the Parsoid requirement accurate?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The page has a note saying "This extension requires Parsoid to be installed". However, Parsoid is part of MediaWiki core since several stable versions ago, so there's no way to "install" it.

And it says "and linting enabled in Parsoid's configuration", but in the Configuration parameters section, it sets "'linting' => false", which is the opposite of what one would expect for "enable linting on Parsoid". Ciencia Al Poder (talk) 23:07, 28 December 2022 (UTC)

Good catch! Those instructions were stale. Fixed. SSastry (WMF) (talk) 16:35, 29 December 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Linter on Third-party Wikis gives no results

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Does Linter work on third-party wikis? I've installed MW 1.39.1 (on Apache, php 8.0.12) added Linter with the recommended settings:

$wgParsoidSettings = [
    'linting' => true
];

I ran update.php, it shows in Special:Version, but all stats are empty in Special:LintErrors. Editing a page with VisualEditor that has obsolete tags doesn't make the page populate into Special:LintErrors/obsolete-tag. The job queue is empty, there's nothing in the debug logs. I've run rebuildall.php in case it's a category link issue, I can't get this extension to work.

I've found one wiki (farm) on 1.38 (Miraheze) where Linter is functioning correctly, and the folks in MediaWiki discord pointed out that the other third-party wikis found via wikiapiary, using Linter, have all zeros for Linter results like I do--this seems unlikely to be because there's no Linter errors on any of their pages.

The notice "this extension requires linting enabled in parsoid's configuration" in combination with the suggested setting above, lead me to think that the bundled parsoid and its corresponding setting should work, but it doesn't. I see Miraheze is using a manual parsoid config with their (working) version of Linter. Perhaps in its current state, Linter requires the separate parsoid setup/config still, which isn't documented?

If it doesn't work with third-party wikis out of the box, it would be great to add a notice of some kind until the documentation is working and complete. FrozenPlum (talk) 04:41, 9 January 2023 (UTC)

I've largely given up on making Linter work at this point, I am mostly leaving this here in hopes it might help someone else get farther than I did. I tried a number of variations in the settings (including some I saw in the extension page's history) and these instructions. I also tried making Linter work by following Miraheze's example who got it working in 1.38, loading it as an extension using:

For me, this resulted in a 404 with "The requested relative path () did not match any known handler".

I tried this with and without the extension page's recommended code:

$wgParsoidSettings = [
    'linting' => true
];

This is where I stopped, as I've already been through this same relative path error and most of the others described in T263928 with manual parsoid/restbase config. I decided I didn't need Linter that badly, but perhaps this info might help someone else. FrozenPlum (talk) 06:21, 9 January 2023 (UTC)

Okay, so working with the folks in MediaWiki Discord, I figured out how to load Parsoid as an extension (the built-in wikimedia/parsoid version), which lead me to looking at Miraheze's mw-config setup on Github. That got me part of the way there, but broke VE editing.

Fortunately, these links and footwork helped Feivel, the smarty pants at Star Citizen wiki to take it over the finish line, which helped me spot where my own (silly) error was (this particular site required the 'www' be added). The config I ended up with, works now for pages parsed by VE/Parsoid

# Parsoid
wfLoadExtension( 'Parsoid', "$IP/vendor/wikimedia/parsoid/extension.json" );
$wgParsoidSettings = [
    'useSelser' => true,
    'linting' => true,
];
$wgVisualEditorParsoidAutoConfig = false; #(for Linter, to make work)
$wgVirtualRestConfig = [
	'paths' => [],
	'modules' => [
		'parsoid' => [
			'url' => 'https://www.mysite.wiki/w/rest.php',
			'domain' => 'www.mysite.wiki',
			'forwardCookies' => true,
			'restbaseCompat' => false,
			'timeout' => 30,
		],
	],
	'global' => [
		'timeout' => 360,
		'forwardCookies' => false,
		'HTTPProxy' => null,
	],
];

FrozenPlum (talk) 22:32, 9 January 2023 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Wikipedia Mobile App: Image Recommendations and New Lint Error

Hello,

This is Amal Ramadan, the Sr. Community Relations Specialist supporting the Wikipedia mobile apps team.

Our Android team is working on Image Recommendations that will enhance accessibility and user engagement within the Wikimedia mobile apps; our engineers are adding a new lint error type, which is planned to match images without alt text and are expected to trigger on a large number of pages.

It is planned to use this lint category to feed both existing linter-based correction workflows and a "microtask" workflow in the Wikipedia mobile app, where small work tasks can be presented to users in a relevant context.

We want to make sure this won’t be disruptive to existing linter system users and that updates to support the new lint type can be coordinated.

Our current technical evaluation doesn't expect performance problems from this, but if it's overloading people's workflows, we want to be sure to accommodate those needs.

Thank you for your understanding and cooperation as we work towards enhancing the Wikipedia mobile app experience. ARamadan-WMF (talk) 08:11, 27 February 2024 (UTC)

I just added a lenghy statement at Talk:Wikimedia Apps/Team/Android/Image Recommendations.

TL;DR: It is honourable to try improvement of accessibility, but pushing uneducated people to create alt= descriptions will make the situation worse and will flood the pages with nonsense, resulting in ignoring all image descriptions since most of them are waste of time. PerfektesChaos (talk) 10:14, 27 February 2024 (UTC)

False bogus image option positives for parameters added by extensions

Tracked in Phabricator
Task T422079

Currently (I mean the current version that runs on MW 1.44) Linter complains about [[File:foo.jpg|layerset=bar]] because it doesn't know the "layerset" parameter added by Extension:Layers. Shouldn't these parameters be added in a registry somewhere, maybe collected automatically by Template:Extension, just like it already does for third-party hooks? I mean I can probably do that if it helps somehow.

I'll risk yet another duplicate on phabricator if I must, but I'd rather have some feedback here first. Tactica (talk) 18:07, 8 January 2026 (UTC)

Thanks, I filed it as phab:T422079 for you. ABreault (WMF) (talk) 20:50, 1 April 2026 (UTC)