The example code has an error in it. Erroneous output, as shown in both examples, is to be expected when there is erroneous input.

In T200517#11819750, @SyntaxTerror wrote:

@ihurbain The only thing I want to know is why is this lint error detected, and what is it useful for?

@Izno talked about a discussion on enwiki without giving a link to it, and he says that he wants to fix duplicate IDs, but we don't know what for.
I would like to know if detecting this supposed error really helped him and what for.

It is always possible to detect something, but why doing so if it is useless ?

Anyway, having to look into millions of pages cannot be the solution.

I don’t really care whether this error is detected or not, but I try to sort out issues whenever I can on frwiki, and all these false positives are probably masking a real problem.

Perhaps there aren’t any true positives because the problem hasn’t been properly identified, and there’s another way to solve it that doesn’t involve checking every ID on every page.

By the way, we have a whole project on frwiki ( Projet:Restauration des ancres brisées/Références Harvard) that involves correcting around 20,000 articles with Harvard ref not working.
These errors can be detected without that 8 million pages list.

This is still happening. Today I found it at https://en.wikipedia.org/wiki/User:Uhai/Pages_without_short_descriptions_by_view_count (two stripped span tags reported via LintHint, but nothing on Page Information). Expanding the code that LintHint identifies shows no Linter errors.

This bug has either not been fixed or has returned due to a regression. See T422021.

It looks like this bug was previously reported in T326898, which was closed without a patch being applied, apparently.

Here's one on Commons where LintHint shows no errors, the rendering is clearly broken, and Page information correctly shows the Linter errors:

Here's an opposite situation: LintHint reports no errors, either in Preview or on the rendered page, but Page information appear to correctly show a stripped /th tag:

In T170874#11730076, @ABreault-WMF wrote:

In T170874#11700304, @ABreault-WMF wrote:

In T170874#11609358, @Jonesey95 wrote:

I'm looking at https://www.mediawiki.org/wiki/Special:LintTemplateErrors/missing-end-tag which is populated. How do I get from "36. Template:Cquote (1)" to the list of affected pages? The template itself has no Linter errors, according to "Page information", so one of the 83 transclusions presumably has an error in it. But which one?

Right, I put up a patch for that in T170874#11700296

Here's the newly deployed report
https://www.mediawiki.org/w/index.php?title=Special:LintTemplateErrors/missing-end-tag&template=Template%3ACquote

which shows
https://www.mediawiki.org/w/index.php?title=Talk:Specs/HTML/2.8.0/Extensions/Cite/Announcement&action=edit&lintid=1940684

You can get to that on https://www.mediawiki.org/wiki/Special:LintTemplateErrors/missing-end-tag by clicking on the pages link (1, pages) of the list item

Here's an incorrect finding of a "Link in Link" error by LintHint (checking the API):

I have made a simplified example here:

Note that if you go to the File page and click on the image, it is sharp and looks normal. The problem happens when the image is rendered as part of a page.

Another example: At https://en.wikipedia.org/wiki/User_talk:Samuel_Blanning/February2006 LintHint shows an "empty heading" Linter error but Page information does not.

In T419596#11700686, @Bhsd wrote:

In T419596#11700628, @Jonesey95 wrote:

Have you actually tried that beta feature for fixing Linter errors? It has many problems that I identified with just a few clicks, making it essentially unusable for that purpose, at least for me.

Of course I use it all the time. You should really try the linting feature and will see a status bar at the bottom of the editor. You can easily scroll to the next issue by clicking on the error/warning icons or pressing F8. There is no need to use lintHint any more with CodeMirror.

We have already submitted patches for all the issues you mention (T407203 and T418329).

We are all volunteers. Please be more polite.

In T419596#11698377, @Bhsd wrote:

One workaround is to enable the improved syntax highlighting beta feature (CodeMirror 6) and enable the linting feature in CodeMirror preference dialog. It reports Parsoid lint errors consistent with the page information in my tests.

Here's example output for one of the images that Linter thinks has a misnested s tag:

In T403931#11304858, @ABreault-WMF wrote:

Post-deploy, Parsoid now renders the intended output, the legacy parser does not,
https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1310145580&useparsoid=0
https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1310145580&useparsoid=1

Also, the output https://om.wikipedia.org/wiki/Template%3AWikipediaTOC?useparsoid=1 is fixed

The new wording is much better, thank you.

In T170874#11592636, @Ladsgroup wrote:

For tech news:

There is a new special page listing templates that trigger the largest number of lint errors. For example: [[Special:LintTemplateErrors/night-mode-unaware-background-color]]

Edit mercilessly.

In T170874#11592789, @ssastry wrote:

It is worth noting on help pages (or on the special page listing itself) that the reason some template might repeatedly show up is not because of the template source but because of the args passed into the template. Even in those cases, it is is still an useful signal to focus on its uses on article pages.

Still happening:

Further details on Anomalocaris's post:

Removal of sorting is a misfeature. Sorting by expiry, labels, and other columns is useful. Please add/restore it.

I need to be able to show my whole watchlist on one page so that I can use my browser's Find command. Is there a secret switch for power users to go above 1,000 items per page? Please add an "All" option, or at least a "5,000" option, which is the secret limit on most other pages that list things (e.g. What links here, Contributions)

In T412630#11553654, @Ladsgroup wrote:

In T412630#11553524, @Jonesey95 wrote:

I would also support removal or refinement of the dark mode Linter issue, since it has so many false positives. If it can be refined to highlight only issues that actually cause problems in dark mode, I think the table would be a lot smaller.

It would be great if you share some examples of false positives to help the dev teams on refining the rule. I'd appreciate it.

Sure. Here's one at random from the first page of results: https://en.wikipedia.org/wiki/Template:Footer_Pan_Pacific_Champions_100m_Breaststroke_Men

It would be great if everyone could stop referring to these Linter issue lists and tables using the word "category", since that word has a specific technical meaning on Wikipedia. Linter does not cause any sort of categorization.

It looks like a patch is being added to exclude the Template namespace due to the parser interpreting plain-text values like {{{1}}} as template parameter code.

I was not sent a link to the commit. I had written an e-mail to noc@wikimedia.org, the address shown in the error message. I had no expectation that I would get anything useful in return, but my problem was acknowledged and fixed right away.

I corresponded with the e-mail address listed on the error page, and I received a response from Giuseppe Lavagetto that this was a bug. It was fixed immediately, on 12 January 2026. If this issue can no longer be reproduced, it may have been fixed at that time. I would tag Giuseppe but I do not know their username here. Possibly @Joe

I corresponded with the e-mail address listed on the error page, and I received a response from Giuseppe Lavagetto that this was a bug. It was fixed immediately, on 12 January 2026. If this issue can no longer be reproduced, it may have been fixed at that time. I would tag Giuseppe but I do not know their username here. Possibly @Joe

This bug is still happening and causing Linter errors. See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AWikiProject_Football&diff=1332222385&oldid=1332221864 (10 January 2026).

In T315893#11530676, @Novem_Linguae wrote:

Would recommend reverting to no space everywhere. 1) It was fine that way for many decades. 2) Adding a space in some places (displayed page title) and not others (mw.config.get('wgPageName')) introduces unnecessary complexity / inconsistencies / technical debt. It's likely to result in people writing it both the old way and the new way forever, which is confusing. Right now everyone writes it (e.g. creating wikilinks on talk pages, creating wikilinks in projectspace, etc.) without a space and this is simple and elegant and consistent.

Now that this feature is halfway rolled out and the sky has not fallen, it's time to finish the job and make this spacing consistent. As it stands right now, the spacing is different from page to page, and from page view to page view, with no apparent logic. The spacing should be added to every page view where a page title with a colon is shown.

Here's a permalink to the discussion.

See the recent merged bug for examples of this problem affecting templates that contain manual line breaks. The bug causes Linter errors.

This can be closed. This need is met by commonly used template code like this that deprecates parameters bar and bar2:

As many Wikipedias come closer to fixing the remaining existing Linter errors (some, like de.WP, are already done), it becomes increasingly disruptive when new ones are added, especially at scale. This issue still needs attention. The wikitext of this mass message was apparently in a page, and so the Linter check was not run, causing three Linter errors to be delivered to 179 pages on en.WP. Here's the message diff:

Still happening.

Please fix this bug. It is actively causing confusion among editors:

In T396155#11461397, @AAlhazwani-WMF wrote:

In T396155#11456353, @Jonesey95 wrote:

"Your Wikipedia account is almost complete" seems like it is missing a word or two. One does not "complete" a Wikipedia account. How about "Creation of your Wikipedia account is almost complete"?

thanks for sharing this! as part of this project, we've looked into other websites, platforms, and services that offer email verification _after_ account creation to learn more about are common patterns and framings. based on what we've observed, for the initial release we've decided to lean towards brevity over precision.

A different set of Linter errors inside Template:Pre popped up at https://en.wikipedia.org/w/index.php?title=Wikipedia:Press_coverage&oldid=1326593225

Please see T412577, which may have been caused by changes related to this bug report at en.WP.

"Your Wikipedia account is almost complete" seems like it is missing a word or two. One does not "complete" a Wikipedia account. How about "Creation of your Wikipedia account is almost complete"?

This Linter problem is still happening. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1325855942 for an example found in the wild today.

I don't think we need to hide the graph. Please just add the word "maximum" before the number "1,000". That provides enough information.

Done at T410345. You can close this ticket. Thanks.

That editor has 66 contributions in the last four years, so I suspect that the WMF might have to take responsibility for that supported gadget. I left a message on the author's talk page on the off chance that they are watching.

Item #1 in the initial bug report is not fixed.

A new version of this bug has been found. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1321865922 where the option "super" and the caption "super" are used for an image, and the second "super" is both (a) detected as a bogus option and (b) not displayed as hover text.

I can replicate this problem by zooming in and out.

Is there a reason that this minor inconsistency has not been fixed? I clicked on the link above and muddled my way through to https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/pull/4/commits/162527e0526ae6e6dce309e743dd31f679e9aada but then I got a link telling me that I needed to install a command-line program on my Mac and do some SSH stuff, which is beyond what I am willing to try right now just to fix what is essentially a copy editing error. Maybe someone here can use my diff above to submit an actual patch.

The page at https://en.wikipedia.org/w/index.php?title=User_talk:Nishidani/Index&oldid=1263003121 contains multiple ! characters inside a "display:none" span. They appear to be interpreted as table markup. I don't know if that is a bug, and if so, if it is the same bug as this one. It's something to look at, anyway.

What's happening on this task? These info cards still provide significant amounts of misleading information. Please at least add a disclaimer.

In T162291#11049378, @Esanders wrote:

Hey Erik. Yes - pasting external links is configurable since T129546 and enabled on mediawiki.org, metawiki, officewiki etc.

$wgVisualEditorAllowExternalLinkPaste = true;

In T403653#11148121, @cscott wrote:

If the Parsoid behavior is correct, I'm inclined to resolve this as 'Declined' since the legacy parser is already being deprecated. Parsoid is expected to be the default within a year.

In T396789#11137475, @Novem_Linguae wrote:

Saw this in tech news. Thanks for your work on this. My watchlist already groups by pages and I like the feature.

Can you clarify exactly what you're changing? Are you just pulling this already existing setting out of a menu, for increased visibility?

On the English Wikipedia, https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/Bot1058_8 has been running for over three years to work around this issue, and as far as I know, there has been no negative impact on performance, with the positive impact of providing more accurate category populations and Linter tracking information to editors.

I have removed all instances of "cx-segment" from en.WP article space as of this date stamp. (link to search). That search link can be used to see if any new instances arrive (excluding "new" instances via reverts or page moves).

I think that I already have that kind of grouping on en.WP, by enabling "Expand watchlist to show all changes, not just the most recent".

Is there a place other than Phabricator where we can see this in action? The screen shot, with grouping enabled, looks just like my regular watchlist at en.WP.

I had this problem at https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Templates&oldid=1305235543 when trying to edit the last section.

This task might want to be linked to T208072.

Possibly related: T348149.

This task might want to be linked to T208072.

At least in the English and German Wikipedias, all of the fostered content errors have been fixed for a while. Making such pages uneditable in VE should be fine; to make them editable, editors just need to fix the fostering using a source editor.

The fundamental problem is that the top-of-page header is different from the sticky header, which is very confusing from a UX perspective.

This works for me:

If there is a 1,000-item limit for some of the data, that should be clearly stated somewhere. It causes many issues; some are listed at https://www.mediawiki.org/wiki/Talk:Product_Safety_and_Integrity/Anti-abuse_signals/User_Info#Data_is_wrong_for_reverted_edits,_edits_in_last_60_days,_and_probably_more

Since T213258 was closed as a duplicate, here's my recent comment from that task:

This is still happening:

This is still happening, six years later. See https://en.wikipedia.org/w/index.php?title=Abdourahamane_Soli&oldid=1303063596

This bug is still present. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1303358064

This may be related to T132467.

I don't see Diff pages mentioned here. This page is missing the spacing between the namespace and the title:

Well done. Thanks for addressing this bug.

Thanks for these answers, even though they are dissatisfying. I would hope that the parser could check the actual output for compliance with having both a color: and a background-color: specified, since that is the underlying concern.

Still happening.

Thank you for asking about this at en.WP. A brief discussion, linked from a couple relevant notice boards, has not surfaced any potential negatives regarding this new Linter "category".