Wikipedia talk:Linter

Archives

This page has archives. Sections older than 60 days may be auto-archived by if there are more than 4.

Empty headings

Empty headings lint errors persist plentifully in Article, Talk, User, User talk, and Wikipedia namespaces. There's one left in Template and I've started a discussion about it at User talk:James Hare (NIOSH)#Avoid empty headings. There remain a few in the Portal namespace, some attributable to a bot I have notified at User talk:ListeriaBot#No empty headings please and some attributable to a bad coding style, and I've started a discussion about that at Portal talk:China#Incorrect markup: empty heading. If someone fixes that one, it will show how to fix the others. I have wiped out empty headings from all other namespaces, for now, and the official count is 5,879. This has ticked up at least 4 in just the few minutes I've been working on this note, so I expect the linter to discover more, both old undiscovered ones and truly new ones. —Anomalocaris (talk) 09:27, 16 May 2025 (UTC)[reply]

Hopefully the Firefly Tools table can be updated to include this error to make it easier to fix. Gonnym (talk) 09:37, 16 May 2025 (UTC)[reply]

Regarding the Portal:China issue, images should never be used instead of text to mimic text. Screen readers can't read it and editors can't select the text and copy it. If the text size needs to be bigger, then that can be adjusted as needed. Gonnym (talk) 09:48, 16 May 2025 (UTC)[reply]

Contrary to what I wrote on 16 May, empty headings were already eradicated or nearly eradicated from the Article namespace. Following Gonnym's work, I fixed the last 5 from Portal namespace. There was some resistance on two of them but I reverted and hopefully it will hold. There are 2 remaining in Template namespace, one of which is a sandbox of the other, which has the empty heading only when the argument is missing or invalid. I also cleaned out the Wikipedia namespace, which had over 100 Wiki Ed pages that could be automatically recreated but probably won't. There are 2 left in Wikipedia space, both of which relate to a discussion on my talk page at User talk:Anomalocaris#Host landing, and will go away after that issues is resolved.

That leaves Talk: 3,427; User: 3,147; User Talk: 1,522; Wikipedia: 2; Template: 2; total: 8,100. The linter is still finding new empty heading errors on pages that haven't been recently edited. —Anomalocaris (talk) 20:26, 6 July 2025 (UTC)[reply]

And sometimes the headers are clean and it's a wonky ref error above them: (line 664). Cleared 9 with that (those sections were also not appearing on the page). Zinnober9 (talk) 21:06, 6 July 2025 (UTC)[reply]

Zinnober9: Good work on Talk:Dementia/Archive 1! I further tweaked Talk:Investigation Committee on the Accident at the Fukushima Nuclear Power Stations of Tokyo Electric Power Company. —Anomalocaris (talk) 22:17, 6 July 2025 (UTC)[reply]

The linter is still finding new empty heading errors on pages that haven't been recently edited. For example, in the last day, it newly found User talk:Awan1110, which was edited only once, 22 July 2022. I regularly follow the last page of Lint errors: Empty headings, and I regularly see new items not recently edited. The total is 8,438, including 2 ~~Template~~ Wikipedia and all the rest are Talk, User, and User Talk. —Anomalocaris (talk) 23:15, 21 August 2025 (UTC)[reply]

This fun experience is sponsored by T157670, from 2017 (see also the earlier T132467, from 2016), for which there is a straightforward fix that the WMF does not appear interested in implementing system-wide. The English Wikipedia is currently working around it with a bot task that refreshes old pages. According to this report, there is currently a backlog of a little over four months, so any MediaWiki code change could result in incremental changes to categories and Linter tracking for over four months. This new code change went live on 6 May 2025, so I would expect new errors to continue arriving until sometime in September, as long as the bot keeps working. – Jonesey95 (talk) 23:40, 21 August 2025 (UTC)[reply]

Jonesey95: Thank you for the explanation. I will continue to post on this topic from time to time, and if things go well, by the end of September I'll be able to say that it's been a bunch of days since the last new ~~one~~ finding of an old error was added. Of course, if other editors fix these errors from the end, I might never see new ones as they come in. —Anomalocaris (talk) 00:47, 22 August 2025 (UTC)[reply]

Is there a reason this lint error isn't in the Firefly report? Gonnym (talk) 08:27, 22 August 2025 (UTC)[reply]

Firefly hasn't edited on en.WP since November 2024 and does not appear to have edited anywhere in the last 90 days. – Jonesey95 (talk) 13:01, 22 August 2025 (UTC)[reply]

This was **just** added moments ago. Was worried for a moment, as the site had an internal server error/went down, but refreshed after a few minutes to find a new column (right end after stripped). Thank you Firefly for this invaluable tool and Tenshi! for adding the empty header error column today! Zinnober9 (talk) 19:11, 10 September 2025 (UTC)[reply]

Was going to say that I did this after phab:T403814 went through, but Zinnober9 found out already it seems. Tenshi! (Talk page) 19:17, 10 September 2025 (UTC)[reply]

Oh, my apologies, I hadn't realized others had access to updating fireflytools. I've amended my comment above. Thank you for adding this, it will be of great help in targeting these errors! Cheers, Zinnober9 (talk) 19:41, 10 September 2025 (UTC)[reply]

I have recently tidied 150+ empty headings, but wonder if I am doing the right thing. Many have been sandbox pages with test edits or graffiti, often many years old. The error was nearly always heading tags around the  comment line. I simply removed the heading tags. Several others were promotional (non-English) spam pages with the same sort of heading coding error. Those I reported using the {{delete}} template. I am wondering if many of the other test edit type sandbox pages should be similarly reported. Many are that user's only edit ever on the site. Several other pages had ONLY an empty heading, and are now empty pages. -- 92.23.57.149 (talk) 19:19, 29 August 2025 (UTC)[reply]

I don't know if it's strictly allowed, but when I come across very stale sandbox pages where the editor has not edited in many years, I will sometimes simply blank the page with the edit summary "Blank stale page instead of fixing Linter errors. Feel free to restore, preferably if errors are fixed." I have had two or three of them restored out of some reasonably large number that I have blanked. It's easier than bothering an admin with a deletion template, and it's easier for the editor to recover the content. – Jonesey95 (talk) 04:11, 30 August 2025 (UTC)[reply]

Agreed, if it's just "beginner test junk or graffiti" from a little used account who hasn't edited in 5+ years, I'd just blank it. I've been blanking and replacing with the
{{userpage blanked}} template, and stating in the edit summary something along the lines of "Blanked. Error filled syntax tests. Inactive user (2014)" or similar. Jonesey95's comment of Feel free to restore, preferably if errors are fixed. is a good idea and probably where my edit summary could be better.

I'm generally most comfortable blanking rather than fixing in the cases where both: A) the user hasn't edited in 5+ years and B) also made little to no edits outside of that one test page.

It's really amazing how many of these bungled beginner tag test pages with bold/sub/sup errors, test galleries, This is in green! etc color statements (using font) there are and how similar they start to look after clearing a few. Zinnober9 (talk) 05:44, 30 August 2025 (UTC)[reply]

Do you completely clear the sandbox page, or do you leave the {{User sandbox}} template and  comment line in place? I agree on seeing what seems to be the exact same thing posted over and over again. -- 92.18.76.185 (talk) 06:24, 30 August 2025 (UTC)[reply]

That's a good question. They are valid, reasonably expected finds in user sandboxes and aren't problematic, so I think I'd leave those in place and tuck the blanked template below that. Zinnober9 (talk) 21:07, 30 August 2025 (UTC)[reply]

I also blank sandboxes of users who haven't edited in years, or sandboxes of indef blocked editors. No reason to waste time in fixing stuff no one cares for. Gonnym (talk) 09:16, 31 August 2025 (UTC)[reply]

Empty heading now appear in the Firefly report. Thanks, Firefly! Also, linter may have stopped finding new empty heading errors in non-recently-edited pages. —Anomalocaris (talk) 03:39, 11 September 2025 (UTC)[reply]

It was actually added by Tenshi!, see indented comments a paragraph or so above. I whacked a few of the 21s last night and dropped User below 3k remaining. Zinnober9 (talk) 14:30, 11 September 2025 (UTC)[reply]

Someone could do about 630 pages by changing ==  == to  WOSlinker (talk) 17:04, 11 September 2025 (UTC)[reply]

I have fixed a few hundred of those among the many other fixes. Keeping going. Total empty headings count was >8600 when I started but is now <5000. I have been through the last 50+ pages of that list and fixed many things. The current last 8 pages of that list lists the stuff I skipped over. -- 92.18.76.185 (talk) 07:09, 3 October 2025 (UTC)[reply]

The "630" above is now zero. -- 92.18.76.185 (talk) 16:59, 3 October 2025 (UTC)[reply]

I have now also cleaned out this other pattern. Total "empty headings" now <4750. -- -- 92.18.76.185 (talk) 23:20, 5 October 2025 (UTC)[reply]

Small milestone

We are now below 900,000 for every error by namespace combination-- Missing end tags in User talk just fell this morning.

Also worth noting, Missing end tags in Main are steadily dropping by about 1k a week, so we will probably be relatively error free in Main by the end of February or so. Well done everyone, and looking forward to that! Zinnober9 (talk) 13:59, 14 August 2025 (UTC)[reply]

I feel like we could get article space done faster with a little focus. I've been working daily in article space, but it is so tedious and there are almost no patterns left, just one-by-one fixes. My current motivation technique is to limit the search to the first two characters of the title and try to get that list to zero (that link shows "Ro"; here's "St" (386 pages), and I previously made a big dent in "Al" (222 pages)). Does anyone else have any tricks that make working on article space easier? – Jonesey95 (talk) 14:35, 14 August 2025 (UTC)[reply]

I have had a similar motivational idea for pages 0-9, but took it from Most by article rather than the Lint search. I have also tried going after just the bolds. The vast majority of those remaining are still italics though, so limited return on that method. By letter combo is a fun way to think about doing it. Zinnober9 (talk) 15:22, 14 August 2025 (UTC)[reply]

We had all of the bolds fixed at one point, but editors keep adding new errors. I expect that will continue to be a problem until either there is some sort of filter that warns about new errors, or the MediaWiki developers remove the workaround that automatically closes some unclosed tags. – Jonesey95 (talk) 19:18, 14 August 2025 (UTC)[reply]

The idea of going at it by completing two letter sets is growing on me. Y and V won't last too long from that. All articles starting with Q and X are done, Z has one remaining (some wonky nowiki div mess of a gradient table that I'm not making heads or tails out of at the moment). Zinnober9 (talk) 05:30, 27 August 2025 (UTC)[reply]

Finding a fair number of cases where the italics are fine, but are broken from the remains of a wikilink incorrectly delinked with the square brackets missing and the delimiter remaining. I doubt there's a way to have a bot search for and repair these cases, but sure would be nice. Most I've come across though are nonexistant redlinks, so I suspect in the articles' histories, someone came along saw they were red and delinked, but did it wrong.

QVXYZ are "zeroed", barring a few stragglers that weren't self evident. Zinnober9 (talk) 01:31, 6 September 2025 (UTC)[reply]

Yes, I've seen a bunch of those, typically in tables of film names or performances. Things like ''Movie Name (film)|Movie Name''. I have never dug through the article history to figure them out, but I have always suspected that a bot or someone with AWB ran a process that incorrectly de-wikilinked this text. – Jonesey95 (talk) 01:38, 6 September 2025 (UTC)[reply]

How do I list all articles with missing end tags in a particular infobox, for example, {{Infobox book}} or {{Infobox person}}? Finding missing end tags in some infoboxes in articles is often very easy. I can see no way to do it via the standard interfaces. —Bruce1ee ^talk 17:23, 14 August 2025 (UTC)[reply]

There may be a clever way to do it with SQL, but an easy way is to search for articles with errors inside templates, then sort by the template name. Having a syntax highlighter enabled helps a lot with locating those tags, since LintHint usually highlights the whole template. I get just four pages of results (3,000 to 4,000 errors) from that search, so that's not too much to scroll through. I see a lot of easy fixes for quote templates. – Jonesey95 (talk) 19:18, 14 August 2025 (UTC)[reply]

Thanks. I tried that a while back, but there were too many pages. My current log length is set to 250. Pushing it up to 1000 will reduce the number of pages, so I'll try it again. —Bruce1ee ^talk 00:22, 15 August 2025 (UTC)[reply]

Looks like the count is finally down under 1000 for these as of today. Still nearly 10K out there without templates, but it's encouraging to see progress. – SirOlgen (talk) 20:07, 19 November 2025 (UTC)[reply]

Yup, coming down nicely these days. Last two weeks the overall total count in main has been dropping by around 3k, before it had been about 1k a week (for a good long while), so might?? be done by the end of the year maybe?

I have a breakdown of the remaining by letter on my userpage at the moment, and have been tracking this since Sept 4th with updates once a week on Thursdays. Since last Thursday, T and R have been cleared, A is going today/tomorrow. Most of the remaining 14 letters have fewer than 1k each with only L, C, and S over 1k. Zinnober9 (talk) 22:01, 19 November 2025 (UTC)[reply]

Just to satisfy my curiosity, do have any non-Latin starting characters with lints? Gonnym (talk) 22:54, 19 November 2025 (UTC)[reply]

Happily, it's only about ten pages, so you can just scroll through and sort by title to find pages like Țipala. – Jonesey95 (talk) 23:43, 19 November 2025 (UTC)[reply]

Sub 20k (mainspace)

As of today, Missing end tags in article space are below 20k. Nine letters are "zeroed", nine letters are under 1k, and the other eight are under 2k. Number pages in total are roughly 90 or fewer. Zinnober9 (talk) 16:51, 19 October 2025 (UTC)[reply]

A little over two years ago, missing end tags in the article space was sitting at 104k. That's roughly two years to clear 80k. At this rate, we'll probably have this category cleared in six months. —Bruce1ee ^talk 06:46, 20 October 2025 (UTC)[reply]

Congrats, everyone working on this. I used to do whole chunks of the Articles by Lint Errors report, but I haven't been able to do any work on that because of IRL reasons (new job, much less downtime). I can recommend all of you to regularly check the top of that list, it's a good way to catch newly added lint errors (or vandalism) early. --rchard2scout (talk) 07:08, 20 October 2025 (UTC)[reply]

Template: Spotify

Two related things on my mind this evening. I suspect part of this might go to templates for discussion, but I'm starting here since others here have likely encountered similar before, and while not directly related to Lint, it in a way, has a tangential relation to delinting when this is incorrectly used.

I'm regularly seeing the misuse of the navbox template {{Spotify}} with people treating it as they would the {{Spotify artist}} linking template (which needs documentation, but that's another story) for linking to a music artist's profile on Spotify with |id= or a wrong parameter "|artist=" filled out and such. This is with such regularity that I'm wondering if there's a way to add a flagged edit warning to editors that when they add any parameter (besides |state= for collapse/expand) and try to save, it warns them that it might not be the template they intend? A "do you mean Spotify artist instead?" notice if you will.

The other question I have is would it be easy to, and how would I add, a tracking category for pages with this navbox such that any pages containing this navbox with unrecognized parameters would be tracked? I highly suspect that there's some unknown pages incorrectly using the navbox, but aren't coming up in our sights since this template misuse only comes into view for us when the navbox template is bulleted (thus reporting the Multiline HTML table in list error in those cases).

I believe I'd add

== Tracking categories ==
* {{clc|Pages using Spotify with unknown parameters}}

to the navbox page, and then create and add {{Unknown params category|Spotify}} to the Category:Pages using Spotify with unknown parameters page, but is there more to it than this? And how would I get it to populate? Is there also a way to determine how many pages have this issue before plan of action? (a "is this worth creating?" check if you will). Zinnober9 (talk) 04:56, 11 October 2025 (UTC)[reply]

I see this error frequently as well. I have enhanced the documentation and added the category, which is unusual for a navbox but may be worthwhile in this case. As for showing an error message, I would think that the giant navbox would provide a clue to editors that they are using the wrong template, but apparently it's not helping them find the correct template. – Jonesey95 (talk) 05:26, 11 October 2025 (UTC)[reply]

Beat me to it Jonesy! I've adjusted the category title slightly to capitalize the S in Spotify (proper noun and all that) Harryboyles 05:32, 11 October 2025 (UTC)[reply]

Great! Thank you both. Knew I typically saw this kind of tracking category on infoboxes, but hadn't realized navboxes didn't typically have this. Hopefully this proves beneficial in finding and reducing the unbulleted of these and in people using the correct template from the added documentation. Zinnober9 (talk) 06:33, 11 October 2025 (UTC)[reply]

Going up

Special:LintErrors/misc-tidy-replacement-issues was <2000 a short while ago, now >2200 and climbing. 92.18.76.185 (talk) 06:48, 11 October 2025 (UTC)[reply]

It's due to this template being marked for discussion. Usually there's a fix with adding noinclude tags to surround the right spot on the template, but this one's odd it seems from Jonesey's attempt. Worst case it'll linger for a week or two and go away after the discussion's reached conclusion, but no action is required. (the current Paragraph wrapping workaround and Tidy whitespace bug errors are also from this) Zinnober9 (talk) 07:00, 11 October 2025 (UTC)[reply]

Some stuff is just too complicated for it's own good it seems. Thanks for the pointers. -- 92.18.76.185 (talk) 08:25, 11 October 2025 (UTC)[reply]

Some things just are a little particular. Seems Taavi got it with a template parameter fix rather than nowiki tags.

Last few pages are from Template:Country data Congo it seems, so hopefully the same gets added there too. Zinnober9 (talk) 21:44, 11 October 2025 (UTC)[reply]

Template:IndyLB issue, ul tags

Template:IndyLB roster was updated today, and while the changes were fine barring a stray </ul>, which I removed and cleared the stripped tag error population, the removal somehow prompted misnested and missing end tags to populate populating for an unclosed ul and misnested div. Linthint agrees when viewing the template, but not when editing the template (clean). I've reverted my removal, but there's still something needed/incorrect, and removing the </ul> is not the full story. What am I overlooking? Zinnober9 (talk) 15:24, 27 October 2025 (UTC)[reply]

I fixed an indented div-based ubl template that User:Sapphaline inserted without testing anything in the sandbox first. Please test changes to templates in the sandbox and on the testcases page, User:Sapphaline. – Jonesey95 (talk) 18:18, 27 October 2025 (UTC)[reply]

LintHint Duplicate ID error

Hi! I am just getting back into editing after a long absence. I have LintHint enabled and I do want to identify and fix Lint errors where I can, but I am getting a lot of pages with duplicate ID errors and I don't quite remember the best way to fix them.

First, is LintHint the best tool for this? Second, what is the best way to fix these errors? Previously I crawled through the source and manually edited any errors I could find, but that no longer seems to work. Is there a better way?

For example, the page Naomi Wu shows one error that looks like this:

lintHint@PerfektesChaos (links to https://en.wikipedia.org/wiki/Special:Blankpage/lintHint)

Duplicate IDs (links to https://en.wikipedia.org/wiki/Special:LintErrors/duplicate-ids)

There is also an option button that links to (User:PerfektesChaos/js/lintHint).

When I click on the Duplicate IDs link it eventually leads me to a page (https://en.wikipedia.org/wiki/Special:LintErrors/duplicate-ids?wpNamespaceRestrictions=&titlecategorysearch=Naomi+Wu&exactmatch=&tag=all&template=all) that says the duplicate id is CITEREFWu2019, but a search does not find the strings "CITEREFWu2019" or "Wu2019" in the source of that page.

Somehow I get the feeling that I am using the wrong tool or that I am using it wrong...

--Guy Macon (talk) 17:20, 27 October 2025 (UTC)[reply]

You can safely ignore these "errors". The CITEREF duplicates are caused by citation templates, can't be fixed by normal editing, and do not appear to cause any problems. Per the help page linked from the Linter error list: "This error is currently listed as 'high-priority', but in many cases, such as citation templates on the English Wikipedia, the IDs are not used and cannot create any problems."

I encourage you to work on any of the other issues listed on the Linter table. In general, the rows from "Template" down to the bottom of the table are either unfixable or not worth worrying about. The main focus is the first six rows, where 99+% of the fixable errors remain. Welcome back! – Jonesey95 (talk) 18:25, 27 October 2025 (UTC)[reply]

Responding to myself to add: If you go to Special:BlankPage/preferencesGadgetOptions#lintHint and replace * with duplicate-ids at the bottom of the options, LintHint will hide duplicate IDs from the list of Linter errors that it shows when the yellow button is pressed. Press the green + to save your settings. – Jonesey95 (talk) 21:53, 13 November 2025 (UTC)[reply]

How is the background color error written for this exclusion? I tried "duplicate-ids background-color-inline-style-rule-exists-without-a-corresponding-text-color" for both the IDs and the background colors, but it didn't work for the latter. Zinnober9 (talk) 01:17, 14 November 2025 (UTC)[reply]

You can copy the wording from the URL. My exception list reads duplicate-ids night-mode-unaware-background-color (note the space between the two items). – Jonesey95 (talk) 01:43, 14 November 2025 (UTC)[reply]

Ah, I was copying from the phrasing LintHint displays on pages with the background error (and what's at Special:Lint), and didn't think to check the url. Felt like it was likely something simple and shorter like that. Thank you very much! Zinnober9 (talk) 02:03, 14 November 2025 (UTC)[reply]

A template change causing old archives to become too large to display templates

Any idea what caused MediaWiki talk:Spam-blacklist/archives/February 2008 to become too large it's now too large for templates to display, which causes lint errors to appear? Gonnym (talk) 12:46, 31 October 2025 (UTC)[reply]

I suspect the recent small changes to {{IP summary}} and {{User summary}} are what ultimately put it over the limit, since those templates are heavily used on that page and have been edited to add content in the last ten days. Aidan9382 _(talk) 13:30, 31 October 2025 (UTC)[reply]

Enabling a new lint category template-arg-in-extension-tag

Please see mw:Help_talk:Extension:Linter#Enabling_a_new_lint_category_template-arg-in-extension-tag ABreault (WMF) (talk) 15:06, 31 October 2025 (UTC)[reply]

I read that page and did not understand it. Will wait until a real world example pops up in the shiny new error category and go from there. -- ~2025-31117-12 (talk) 21:24, 6 November 2025 (UTC)[reply]

From reading mw:Help:Lint errors/template-arg-in-extension-tag, its faster to call something in the parser function format than to use tags? Tenshi! (Talk page) 21:31, 6 November 2025 (UTC)[reply]

@ABreault (WMF), the new lint error is missing from Special:LintErrors, can you add it? Gonnym (talk) 20:02, 10 November 2025 (UTC)[reply]

Ah it's there, it's just written differently from how it was added to this page and in a different place. Gonnym (talk) 20:04, 10 November 2025 (UTC)[reply]

Noting that I've added this to Firefly's linter report, albeit it seems to have no hits anywhere on any (tracked) wiki that I could find. Tenshi! (Talk page) 22:38, 15 November 2025 (UTC)[reply]

Excerpt table error?

New England Revolution has a table issue from an excerpt. The excerpt call appears to be fine, though granted I've rarely needed to examine or edit them. So I then went digging to List of New England Revolution seasons, and found it was fine over there, barring there was a missing section end tag, so added it at a reasonable spot. That didn't fix it. Neither page has had any updates to the relevant excerpt/table content in the past year, so what gives? Zinnober9 (talk) 05:14, 3 November 2025 (UTC)[reply]

I suspect this is the same issue as was found at Module talk:Excerpt § Regression: Excerpt doesn't pick up discontiguous labeled sections with the same name, in which the repeated sections aren't correctly being picked up and combined with the first section. Aidan9382 _(talk) 08:13, 3 November 2025 (UTC)[reply]

Priorities.

We are told that the Duplicate IDs errors cannot be fixed by editing. Why are they listed as high priority?

Also, the error counts for Duplicate IDs and for Background color inline style rule exists without a corresponding text color are both reporting the exact same number, at just over 22 million. Seems unlikely that the two numbers would be consistently identical.

-- ~2025-31117-12 (talk) 20:19, 7 November 2025 (UTC)[reply]

We at the English Wikipedia do not control the priority. The Wikimedia developers say that they are a high priority, so that's where they are listed.

As for the 22 million number on the Linter page, those numbers have never been accurate when they are high (above a few thousand). You may notice that refreshing the page will change the number almost every time, which makes no sense. That's why the top of the page says "The counts for categories are estimated, not exact." In short, neither of these issues is under our control. – Jonesey95 (talk) 00:20, 8 November 2025 (UTC)[reply]

WP:EIS caption equals parameter issue

When a file has a caption that is equivalent to a command word parameter, (present or not), it reports a bogus image parameter error, despite not necessarily being an error.
For example, if we had [[File:thumb.jpg|thumb|thumb]], the first is the file display Type command "thumb", the second, the caption stating the plaintext of "thumb". However, linter thinks, if this example were to display, that I've doubled the Type parameter (I assume Type has a higher priority parameter, otherwise it would think this is two captions), and is flagging it as an error, despite technically being correct. This probable bug was brought to my attention today when @Redrose64 correctly discovered and reverted my error the other day when I removed what I had originally thought was a human error of having two captions (I don't often see vertical-alignments present, so my mind read it as two captions). HOWEVER, when the caption is placed within "quotes", the errors go away. Is having the caption be identical to a parameter's command word a known bug, is there phab ticket on this, anything known or previously discussed on this situation? Currently I've left an edit comment on WP:EIS above that section stating there's an error and the captions are quoted for that reason. Since these are frameless, the captions wouldn't be displaying when reading the article, so it won't be influencing the public to start "quoting" their captions. Zinnober9 (talk) 00:57, 13 November 2025 (UTC)[reply]

I'll also note that I'm not sure I want this issue fixed, since I've seen from the months of clearing the image error backlog a few years back an enormous mess of people doubling up the usage of (typically the thumb) parameters in cases where the command word was not a caption usage, so I'd rather deal with the small unlikelihood of a few cases where caption IS the same as another parameter than miss a slew of doubled cases (though possible if doubled and there's a different caption, it would still think double captions and still report). Just trying to state the possibilities and not start an accidental "falls through the cracks" issue. Zinnober9 (talk) 00:57, 13 November 2025 (UTC)[reply]

This looks like a continuation of T275074, which I reported in 2021. A few similar bugs have been fixed, like T216566, T335538, T179605, so there is hope that these bugs will be fixed. I have long advocated for an explicit |caption= option for images for this reason, just as we sometimes have to use |1= for unnamed parameters that contain equals signs. Working around it for now using quotation marks seems like a reasonable compromise to me. – Jonesey95 (talk) 02:49, 13 November 2025 (UTC)[reply]

Adding a nowiki tag to workaround also works. -- WOSlinker (talk) 06:41, 13 November 2025 (UTC)[reply]

Is there a real word example of when a valid caption will have a single world that is the same as the command word? Gonnym (talk) 07:32, 13 November 2025 (UTC)[reply]

A picture of a thumb. A picture of a town center. A picture of a frame. A gallery of views showing the left and right sides of an object. I linked to various examples, many found in articles, from the phab tasks above. – Jonesey95 (talk) 16:31, 13 November 2025 (UTC)[reply]

Ok, I looked at your error examples. The bug is real, but every single example was awful caption. This bug is more of a feature to fix horrible captions in my eyes. Gonnym (talk) 17:23, 15 November 2025 (UTC)[reply]

Keep in mind that MediaWiki software exists on sites other than the English Wikipedia. This bug applies to every installation. On many of those installations, captions like these that are mistakenly flagged as errors may be perfectly acceptable. – Jonesey95 (talk) 18:41, 15 November 2025 (UTC)[reply]

Transclude files as random slideshow image errors

Just noting for anyone interested, or if someone later needs to remember, found some issues with gallery image parameters that, while aren't reported as erroneous at the source, become reported as a linter error after being transcribed through the {{Transclude files as random slideshow}} template. To track down which article the error might be occurring, you'll want to copy the template and its contents to your sandbox and do some batch testing (saving your sandbox edits) to narrow it down as linthint was not able to preview this. Then once you identify the article(s) triggering this, you'll find within a gallery section of that article some invalid and ignored, but not error reporting (at the source), issues of |left=, |right=, etc that gallery doesn't use at the individual file level (all gallery command parameters should be in the header, with only file/caption as contents following {file/alt/caption also acceptable)). I Just figured out and fixed the month long error on User:Kolventra/sandbox from this edit on trampoline. Zinnober9 (talk) 23:17, 20 November 2025 (UTC) (updated for a slight clarity rewrite, 20:12, 21 November 2025 (UTC))[reply]

So here's the real question: File:Trampoline with enclosure.jpg|right| With safety nets, the risk of falling off the trampoline is reduced. contains an invalid (aka bogus) file option for a gallery entry. The Linter doesn't detect it, and I haven't wanted to report it as a bug, because I haven't seen it cause any problems and it would have just flooded our Linter queue with make-work. Now we have evidence that it causes a problem in some obscure circumstances, so it might be worth filing a bug. What should we do? – Jonesey95 (talk) 23:26, 20 November 2025 (UTC)[reply]

I have created a rogues' gallery (pun intended) of gallery options. Feel free to add to it if I missed anything. – Jonesey95 (talk) 23:41, 20 November 2025 (UTC)[reply]

Not that difficult to search for them. -- WOSlinker (talk) 00:13, 21 November 2025 (UTC)[reply]

Indeed. What do people think about me submitting a bug report, which will take a few weeks or months to be addressed, and some kind gnome simultaneously clearing up the existing undetected errors? – Jonesey95 (talk) 02:39, 21 November 2025 (UTC)[reply]

I've found another way to fool the linter if you want to file another bug report. The following below with a : prefix does not show as an error. -- WOSlinker (talk) 07:56, 21 November 2025 (UTC)[reply]

Thuringian Red

OK, submitted as T410736. – Jonesey95 (talk) 13:29, 21 November 2025 (UTC)[reply]

Thanks. Zinnober9 (talk) 20:25, 21 November 2025 (UTC)[reply]

I don't believe in hiding issues, which I think you know, so that's my position here. It's also something a bot can fix pretty easy and fast so that isn't a factor either. Gonnym (talk) 09:38, 21 November 2025 (UTC)[reply]

Most of us weren't I think. If the linter doesn't report it, I usually don't know there is an issue. Gonnym (talk) 16:16, 21 November 2025 (UTC)[reply]

Caution to editors: If you're going through and fixing these before the bug is fixed, watch out for false positives from search results. File: invocations inside <imagemap>...</imagemap> tags are formatted just like images in gallery tags, but the center/550px/etc. options do work and are valid. – Jonesey95 (talk) 22:21, 21 November 2025 (UTC)[reply]

No worries, we're all pretty much "fix what you know, leave behind what you don't" about fixing things, so you are fine. And also this is brand newly discovered that these actually are an error rather than just extraneous syntax that is "extra" but not erroneous as I(we?) had been thinking they were. Zinnober9 (talk) 20:25, 21 November 2025 (UTC)[reply]

Galleries

I went to a page listed in the bogus-image-options error list solely to change || to | but when I got there I also removed erroneous |thumb| parameters which were not reported by the linter. Edit here. Is this a part of the issue discussed above? -- ~2025-31117-12 (talk) 16:08, 21 November 2025 (UTC)[reply]

|thumb| parameters will be reported by the linter. However, when a single gallery contains multiple lint issues across different files, only the lint issues on the first file with issues would be reported. If you just removed updated the ||, then checked the lint again, the |thumb| would then get reported. -- WOSlinker (talk) 17:18, 21 November 2025 (UTC)[reply]

No redirect

GTrang edited {{No redirect}}, and now it's generating Multi colon escape lint errors. The errors attributed to {{Wikipedia:Administrator intervention against vandalism}} and its aliases are actually {{No redirect}}. —Anomalocaris (talk) 21:33, 25 November 2025 (UTC)[reply]

It might be due to Special:Diff/1324151390 where {{No redirect}} was invoked like this: {{No redirect|:Geothermal energy}}. Tenshi! (Talk page) 21:42, 25 November 2025 (UTC)[reply]

I have edited Template:No redirect to fix an issue that an IP user reported at Template talk:No redirect#Link text is initial caps if target is not a redirect seven years ago. My subsequent edit to the template should hopefully fix both that old issue and the one Anomalocaris has just reported. An alternative would be to instead replace every instance of {{no redirect|: with {{no redirect| (and likewise for transclusions of redirects to the template). GTrang (talk) 21:58, 25 November 2025 (UTC)[reply]

I would be supportive of a self purging of : when {{no redirect|:page}} is used, since it lights up a few hundred admin dashboard pages with the one error every time someone writes it at AIV. Most times it's cleared in a few minutes, but some linger.

The one caveat I feel I need to mention is that I've seen some reports use a leading : within the no redirect, and come away clean, so not sure why most are linty but a few aren't. If someone knows and the automatic removal of a leading : is a problem, then it isn't too big a deal since this error is 90% of the time from AIV reports and self clear after the report's removal. Zinnober9 (talk) 22:45, 25 November 2025 (UTC)[reply]

Portal misnest

Fixed a misnested bold tag in Template:Transclude excerpts as random slideshow/testcases/Portal:Reptiles by editing Ivory Coast mud turtle, changing ''Pelusios''' records to ''Pelusios''{{'}} records. To find it, I broke the list of articles into groups of 25, used Expand Templates 25 articles at a time, found the offending article (there was only one), and fixed it. Lint errors of this sort are usually in Portal space directly, but this one happened to be in Template space. —Anomalocaris (talk) 07:47, 1 December 2025 (UTC)[reply]

Nice work. Was the article itself reporting a Linter error? I find that the above error is detected by the syntax highlighter gadget, but not by LintHint. The above formatting renders as italics with an apostrophe in most cases, but if there is other bold or italics in the same paragraph, LintHint will sometimes report an error. I always fix it when I find it so that the syntax highlighter calms down, but it looks like there is another benefit when that section is transcluded elsewhere. – Jonesey95 (talk) 13:24, 1 December 2025 (UTC)[reply]

Jonesey95, the old version looks clean. — Qwerfjkl talk 17:52, 1 December 2025 (UTC)[reply]

Shortly before fixing Ivory Coast mud turtle, I fixed a misnested bold tag in Portal:Liquor by editing Erguotou, changing ''qingxiang baijiu'''s to ''qingxiang baijius''. I didn't check any other transcluded articles that time. There were no lint errors visible in Ivory Coast mud turtle before I fixed it. —Anomalocaris (talk) 20:30, 1 December 2025 (UTC)[reply]

Now I have fixed a misnested li tag in Portal:Marine life that came from {{Transclude list item excerpts as random slideshow}} messing up some markup in Cnidaria. I changed

{{Automatic taxobox
...
| image = Cnidaria.png
...
| image_caption = Four examples of cnidaria (''clockwise, from top left''):
* A jellyfish ''[[Chrysaora melanaster]]''
* A gorgonian ''[[Annella mollis]]''
* A sea anemone ''[[Nemanthus annamensis]]''
* A stony coral ''[[Acropora cervicornis]]''
...
}}

to

{{Automatic taxobox
...
| image = Cnidaria.png
...
| image_caption = Four examples of cnidaria (''clockwise, from top left''): {{Unbulleted list
  | A jellyfish ''[[Chrysaora melanaster]]''
  | A gorgonian ''[[Annella mollis]]''
  | A sea anemone ''[[Nemanthus annamensis]]''
  | A stony coral ''[[Acropora cervicornis]]''
}}
...
}}

This moved the final </li></ul> inside four closing </div> tags, where it belongs, as it changed the translation by {{Transclude list item excerpts as random slideshow}} from

<div style="text-align:left;"><div class= "thumb tleft" style = "style = overflow: hidden; max-width: 310px; "><div class = "thumbinner" ><div class="thumbimage noresize" style="width: auto; "><br>[[File:Cnidaria.png|frameless|none]] </div><div class = "thumbcaption"><div class="center">Four examples of cnidaria (''clockwise, from top left''): <ul><li> A jellyfish ''[[Chrysaora melanaster]]'' </li><li> A gorgonian ''[[Annella mollis]]'' </li><li> A sea anemone ''[[Nemanthus annamensis]]''</li><li> A stony coral ''[[Acropora cervicornis]]''</div></div></div></div></li></ul>...</div>

to

<div style="text-align:left;"><div class= "thumb tleft" style = "style = overflow: hidden; max-width: 310px; "><div class = "thumbinner" ><div class="thumbimage noresize" style="width: auto; "><br>[[File:Cnidaria.png|frameless|none]] </div><div class = "thumbcaption"><div class="center">Four examples of cnidaria (''clockwise, from top left''): <div class="plainlist"><ul><li>A jellyfish ''[[Chrysaora melanaster]]''</li><li>A gorgonian ''[[Annella mollis]]''</li><li>A sea anemone ''[[Nemanthus annamensis]]''</li><li>A stony coral ''[[Acropora cervicornis]]''</li></ul></div></div></div></div></div>...</div>

I didn't know in advance that this would fix the problem, but I guessed correctly.

It's probably a good idea to replace bulleted lists in infoboxes with {{Bulleted list}} or {{Unbulleted list}}, even if bulleted lists seem to work. —Anomalocaris (talk) 22:02, 1 December 2025 (UTC)[reply]

Sometimes. Watch out for parameters that are wrapped in span tags; the list templates contain div tags. Always run LintHint again before saving. – Jonesey95 (talk) 01:42, 2 December 2025 (UTC)[reply]

Yes, always run lintHint again before saving, and also look at the preview to make sure it looks good. Of course, when fixing a transclusion, you won't know how it looks and what lint errors it might fix or cause in a page that transcludes it until after saving. —Anomalocaris (talk) 03:42, 2 December 2025 (UTC)[reply]

Latent two-three apostrophe errors

It is going to be a lot of work to get to the end of markup of the form ''____'''. I just did a regex search on insource:/'''s / in Article space and there are 12,718 results before timeout. Of the first 20 results, all 20 had the error. (This is what I expected, but visual confirmation is a good idea.) —Anomalocaris (talk) 07:19, 3 December 2025 (UTC)[reply]

Many of them linter hasn't found yet, for example Wanda Jackson, so they won't show up in lint error reports. But sooner or later they will, probably when someone, or a bot, touches them. —Bruce1ee ^talk 07:31, 3 December 2025 (UTC)[reply]

Is this including 'single quoted statement of ''italics''' that returns with no error but not ideal, or is this exclusively italics possessive cases? Zinnober9 (talk) 08:07, 3 December 2025 (UTC)[reply]

I don't think the problem is that the linter hasn't found them, I think the problem is the linter cannot detect them. Here are the first four hits from my latest regex search, plus ~~Zinnober9~~ Bruce1ee's example:

Article	Markup	lintHint error?
Variety (magazine)	`''Variety'''s`	no
Entertainment Weekly	`''EW'''s`	no
The Globe and Mail	`''Globe'''s`	no
Star Trek	`''Star Trek'''s`	no
Wanda Jackson	`''[[Rolling Stone]]'''s`	no

Cheers, Anomalocaris (talk) 08:05, 3 December 2025 (UTC)[reply]

@Anomalocaris: You're right. I removed an extra linefeed from Boing Boing, and linter still isn't reporting ''[[The Washington Post]]'''s as an error. But I've fixed many errors like this in the past that linter has reported. So I don't understand why it's not detecting these ones. —Bruce1ee ^talk 08:21, 3 December 2025 (UTC)[reply]

Here are some insource results for the above Variety, EW, Globe, Rolling Stone, Star Trek. While each one doesn't have extreme numbers, together they make quite a lot. Since these are simple fixes, maybe we can get a bot to fix a list of this? Gonnym (talk) 08:52, 3 December 2025 (UTC)[reply]

Gonnym, my bot is approved for find-and-replace lint fixes, so I think I could run it without need for a new BRFA. — Qwerfjkl talk 11:55, 3 December 2025 (UTC)[reply]

The parser correctly detects these instances as italics followed by 's so there is no error to detect unless there is other bold or italic markup in the same paragraph (I have seen this edge case but I'm unable to replicate it right now). The syntax highlighter gadget flags them as unbalanced markup, and replacing the 's with a template is the right thing to do. In the meantime, I created T411640 just for fun. It will probably be rejected as "works as designed" and "changing this rendering would break a bunch of stuff", but I thought I would give it a try. – Jonesey95 (talk) 15:45, 3 December 2025 (UTC)[reply]

Here are some insource results similar to Gonnym's:

Search	Hits
`insource:/''Post'''s/`	87
`insource:/''The Washington Post'''s/`	41 (25)
`insource:/''Washington Post'''s/`	55
`insource:/''New York Post'''s/`	17
`insource:/''Times'''s/`	27
`insource:/''New York Times'''s/`	20
`insource:/''The New York Times'''s/`	28 (20)
`insource:/''Tribune'''s/`	40
`insource:/''Chicago Tribune'''s/`	27
`insource:/''Los Angeles Times'''s/`	6
`insource:/''Journal'''s/`	54
`insource:/''Wall Street Journal'''s/`	21
`insource:/''The Wall Street Journal'''s/`	29
`insource:/''Chronicle'''s/`	34
`insource:/''Houston Chronicle'''s/`	1
`insource:/''Metro'''s/`	9
`insource:/''Mail'''s/`	21
`insource:/''Daily Mail'''s/`	38
`insource:/''Guardian'''s/`	56
`insource:/''The Guardian'''s/`	244 (155)

When there is one number listed, it is the number of hits in all namespaces without timeout.
When there are two numbers listed like 41 (25), the first number is hits in all namespaces with timeout, and the second number is hits in article space only, without timeout.

—Anomalocaris (talk) 21:10, 3 December 2025 (UTC)[reply]

Some of the names above that are the full name of the article, like Rolling Stone also have the issues when linked. Gonnym (talk) 21:13, 3 December 2025 (UTC)[reply]

Strange quirk in an article

In the article Fake news right before the text "People got vastly more misinformation from Dona, the text News is colored bold blue in the text editor. I can't see any lint errors on the page and I've never encountred something like this before. Modifying the text removes this, but returning the text exactly to "News" restores it. Any idea? Gonnym (talk) 18:28, 3 December 2025 (UTC)[reply]

It's activating because of the trailing colon for News:, and the capitalization (of any letter) makes no difference. I'm assuming it's marked up as though it thinks it's a language keyword, but I don't know what "news as a keyword" means. It seems to be displaying fine on the article though, and that's important. Zinnober9 (talk) 19:07, 3 December 2025 (UTC)[reply]

Zinnober9, @Gonnym, which editor are you using? I see nothing using the 2010 wikitext editor with syntax highlighting. — Qwerfjkl talk 21:33, 3 December 2025 (UTC)[reply]

I think I have the 2010 one also. I have the "enable the editing toolbar" checked and under it it says it's the 2010 one. I also have syntax highlighting on. Gonnym (talk) 21:53, 3 December 2025 (UTC)[reply]

does this look like an external link to you [1]? Gonnym (talk) 21:56, 3 December 2025 (UTC)[reply]

Gonnym, it displays as [1], yes. — Qwerfjkl talk 21:58, 3 December 2025 (UTC)[reply]

Gonnym, it looks like this to me: File:En.wikipedia.org Fake news 2025-12-03.png — Qwerfjkl talk 21:57, 3 December 2025 (UTC)[reply]

This is how it looks for me File:Strange highlighted text.png. And that external links that does nothing is even stranger. Gonnym (talk) 22:02, 3 December 2025 (UTC)[reply]

Gonnym, oh, you meant in the editor. It displays the same for me. — Qwerfjkl talk 22:04, 3 December 2025 (UTC)[reply]

Vector legacy (2010) (but also Vector 2022 it seems), syntax highlighter on, Firefox (uptodate). It doesn't matter if I'm in light mode, dark mode (gadget here or with my browser add-on). Screenshot: File:En.wikipedia.org keyword highlighting 2025-12-03.png Does not appear this way If I'm logged out and view it in editor. Zinnober9 (talk) 22:05, 3 December 2025 (UTC)[reply]

Zinnober9, the article is semi-protected, so the editor shouldn't work when logged out. I also use Firefox, and I use Vector 2022. No difference light mode / dark mode, and nothing in safemode. (Imgur images are blocked here in the UK, so please share images via some other means.) — Qwerfjkl talk 22:14, 3 December 2025 (UTC)[reply]

Apologies, I'm aware of that geopolitical issue, but hadn't ever uploaded something to commons until now and assumed it would work for all present here, I assumed incorrectly. Here you go: File:En.wikipedia.org keyword highlighting 2025-12-03.png. True, when logged out it's view only, so doesn't highlight since editor is not active. Zinnober9 (talk) 22:35, 3 December 2025 (UTC)[reply]

Is it something (legacy code or functions) to do with NNTP and Usenet? -- ~2025-31117-12 (talk) 01:03, 4 December 2025 (UTC)[reply]

Yes. I'm just guessing here, but it probably has something to do with List of URI schemes. More links that will probably behave in the same way on Wikipedia:

[news:Hypertext Transfer Protocol Secure] → Transfer Protocol Secure

[mailto:mailto for email addresses] → for email addresses

[tel:for telephone numbers] → telephone numbers

[geo:25.245470718844146,51.45400942457904] → [2]

There are probably more. – Jonesey95 (talk) 02:05, 4 December 2025 (UTC)[reply]

New report: IP user talk pages by Linter error count

See Wikipedia:Linter/reports/IP user talk pages by Lint Errors for a new report that I created. I'm working on ways to get at least some of these pages blanked by a bot that blanks stale IP user talk pages, so that we don't have to fix all of the errors. – Jonesey95 (talk) 23:57, 4 December 2025 (UTC)[reply]

Unbalanced bold votes

If anyone is interested here are search results for unbalanced bold votes (which aren't detected by lint):

[Kk]eep: ~500
[Dd]elete: ~700
[Mm]erge: ~200
[Ss]upport: ~270
[Oo]ppose: ~210
[Mm]ove: ~10
[Rr]edirect: ~80

--Gonnym (talk) 15:48, 5 December 2025 (UTC)[reply]