Wikipedia talk:Linter

Archives

Archive 1	Archive 2	Archive 3
Archive 4	Archive 5	Archive 6

This page has archives. Sections older than 60 days may be automatically archived by when more than 4 sections are present.

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]

Disambiguation warnings vs editing toolbar vs lint error links

I noticed that the editor popup that warns that I've entered a disambiguation wikilink had stopped working. I opened a discussion on this topic at Wikipedia:Help desk#disambiguation warning/help in the editor. PrimeHunter thought the editor dab detector might be connected to the editing toolbar and suggested I check the preference box for this item. I did that, and this caused the editor dab detector to work again, but I didn't want the editing toolbar, so Primehunter gave me a snip of code for my Common.css to make the toolbar not display even when the preference box is checked for the toolbar. That worked, but then lint error links opened with the editor immediately scrolling to the top and removing the lint error highlighting, unless the lint error happens to be in the first screenful. Also, Suntooooth reported the editor dab detector not working even with the toolbar. I am wondering if other editors have these problems. Please reply saying if the dab link detector is working, if you have the preference box checked "Enable the editing toolbar", and if the lint error links open with the highlightedlint error displayed. —Anomalocaris (talk) 10:17, 11 June 2025 (UTC)[reply]

As you said, the dab detector (the one that comes up with a box in the corner saying "do you want to make this link more specific") isn't working for me even with the editor toolbar enabled. I'm not sure exactly what you mean with the lint error links, so I can't test that in my case. Would it be worth taking to WP:VPT too? Suntooooth, it/he (talk/contribs) 11:10, 11 June 2025 (UTC)[reply]

Suntooooth: Welcome to the Linter discussion page. Lint errors are errors in Wiki markup such as tags that open but don't close, or close but don't open, or stuff in tables but not in table cell, or various other things. Stripped tags are closing tags without the corresponding opening tag, such as </div> without <div>. Here is an edit link to User:Pufferfish101/Edit to fix a stripped </div> tag, which hopefully nobody will fix right away. Click that link. If you see the stripped </div> highlighted in blue, that's good. If the page scrolls to the top, that's bad. —Anomalocaris (talk) 18:50, 11 June 2025 (UTC)[reply]

It highlights the </div> and doesn't scroll to the top of the page. Suntooooth, it/he (talk/contribs) 18:58, 11 June 2025 (UTC)[reply]

Suntooooth: Thanks. I filled in the survey for you. —Anomalocaris (talk) 20:01, 11 June 2025 (UTC)[reply]

Folks, for me this is a Red Alert. When I click on a lint error edit link, it now scrolls to the top immediately, whether or not I check "Enable the editing toolbar". —Anomalocaris (talk) 19:50, 13 June 2025 (UTC)[reply]

This also appears to be happening for me as well, except for me it doesn't do it with the editing toolbar disabled? (Both tests were done with the dab link detector working) Tenshi! (Talk page) 20:30, 13 June 2025 (UTC)[reply]

Now it's flipped around the other way. Now, lint error edit links open and scroll to the top when I have the editing toolbar checked, but they open normally when the editing toolbar is unchecked. Perhaps someone is tweaking the internals today. —Anomalocaris (talk) 20:30, 13 June 2025 (UTC)[reply]

To clarify, it's not a red alert now, because with the editing toolbar unchecked, I have both the editor dab link detector working and lint error edit links opening with the lint error highlighted in blue. I'm going off Wikipedia for about 48 hours, so don't expect any any replies until I'm back. —21:30, 13 June 2025 (UTC)Anomalocaris (talk)

At this point it's maybe a Yellow Alert.

With the editing toolbar unchecked, I have the editor dab link detector not working (bad), and lint error edit links open with the lint error highlighted in blue (good).
With the editing toolbar checked, I have the editor dab link detector working (good), and lint error edit links open and immediately scroll to the top (bad).

This is how it was on 11 June 2025. It would be nice to hear from those who are trying to solve this problem and from other editors how these tools are working for them. —Anomalocaris (talk) 06:33, 24 June 2025 (UTC)[reply]

Another week has gone by and the problem remains as it was on 11 June 2025. I am surprised that nobody has responded since June 13. —Anomalocaris (talk) 22:09, 1 July 2025 (UTC)[reply]

It seems I was able to reciprocate your 24 June 2025 results today, albeit I don't think I was able to on the 13th? (I've added my prior and current testing to the survey below). Tenshi! (Talk page) 15:28, 2 July 2025 (UTC)[reply]

@Anomalocaris: Are you still having the same issue or has it changed? Tenshi! (Talk page) 23:16, 21 July 2025 (UTC)[reply]

Tenshi Hinanawi: Same as 11 June 2025. I leave the editing toolbar unchecked so that lint error links work, but I don't get Dab link detection in the editor. ——Anomalocaris (talk) 01:55, 22 July 2025 (UTC)[reply]

Survey

User	Editor Dab link detector works	Enable the editing toolbar	lint error links open with highlighted error visible	Date
Anomalocaris	No	unchecked	yes	11 June 2025
Anomalocaris	Yes	checked	no, scrolls to top	11 June 2025
Anomalocaris	No	unchecked	no, scrolls to top	13 June 2025
Anomalocaris	Yes	checked	no, scrolls to top	13 June 2025
Suntooooth	No	checked	yes	11 June 2025
Tenshi Hinanawi	Yes	unchecked	yes	13 June 2025
Tenshi Hinanawi	Yes	checked	no, scrolls to top	13 June 2025
Tenshi Hinanawi	No	unchecked	yes	2 July 2025
Tenshi Hinanawi	Yes	checked	no, scrolls to top	2 July 2025

Made a userscript to help locating lint errors

Hello. I made a userscript to display and locate Lint errors on a page. If you wish to try it, install the script and head over to some random article in the mainspace (or find one at Special:LintErrors): User:DVRTed/lintHelper.js. Let me know if you've any suggestions or if there are certain errors that should be (ex/in)cluded. Regards, — DVRTed (Talk) 00:37, 28 June 2025 (UTC)[reply]

Special stripped error

Does anyone happen to know why the word "Special" within "Yu-Gi-Oh! Arc-V Tag Force Special" from the nihongo footer entry {{nihongo foot|'''Yu-Gi-Oh! Arc-V Tag Force Special'''|遊☆戯☆王アーク・ファイブＴＡＧＦＯＲＣＥＳＰＥＣＩＡＬ|Yū-Gi-Ō! Āku Faibu: Taggu Fōsu Supesharu|lead=yes|group=lower-alpha}} is triggering a stripped span error on List of Yu-Gi-Oh! video games? The use of this foot template within the template {{Video game titles}} appears to be connected since the above code is clean outside of the VG titles template. This feels like a template bug rather than a thought out command. Zinnober9 (talk) 01:55, 30 June 2025 (UTC)[reply]

Using that template inside {{Video game titles/item}}'s |title= parameter causes invalid characters to be placed in the id tag. See the documentation at {{Video game titles}}; supplemental information should be placed in |notes=. – Jonesey95 (talk) 02:34, 30 June 2025 (UTC)[reply]

With how many times that was placed at the title in other entries and not causing errors, I fell off the "why is a footer used in a title" theory too quickly. It's always the weird ones... Thanks. Zinnober9 (talk) 12:52, 30 June 2025 (UTC)[reply]

Internally nested HTML??

Due to a misunderstanding of another editor's intentions on my part yesterday, I've come to realize with their help that the <pre> with <includeonly></includeonly> example shown at Help:Wikitext#Pre both exists and is also reporting stripped pre tag errors when used in the wild. I say in the wild, as it is oddly not reporting errors ON Help:Wikitext#Pre (despite being identical to my sandbox test which is reporting a stripped error).

Any idea what this is, why this is a thing, if this is a valid thing, and how to proceed in not having these report errors IF this is a valid intentional case? I'm at a lost right now since putting tags inside of other tags in this fashion feels immensely verboten. One example article. While I get the end goal of display desired from the example stated at the Help page, it feels like to wrong way to go about doing it. Zinnober9 (talk) 00:07, 12 July 2025 (UTC)[reply]

Missing bogus file options error

Wikipedia:Extended image syntax#Brief syntax says that image options "can be placed in any order, except for Caption that has to be the last parameter." I have seen numerous images declared on numerous pages where Caption is not the last parameter. When I see this, I usually move the caption to last place. But the linter fails to detect captions out of place, viz:

Either the extended image syntax page is wrong, or the linter needs to be brought into compliance with it. —Anomalocaris (talk) 06:17, 14 July 2025 (UTC)[reply]

I've also seen this quite often. My feeling is that the extended image syntax is correct and that linter needs to be changed to report out-of-place captions. —Bruce1ee ^talk 06:38, 14 July 2025 (UTC)[reply]

When there are two captions, I think the one in last place is the one reported as an error. Maybe this is a clue to this issue? -- 92.21.137.132 (talk) 08:37, 14 July 2025 (UTC)[reply]

That guidance was inserted in December 2024 and was incorrect. Nobody reverted it until today. – Jonesey95 (talk) 12:14, 14 July 2025 (UTC)[reply]

A good place to check is mw:Help:Images, which is the most comprehensive page that I know of for image syntax. One fun note is that in galleries, the caption sometimes doesn't work when it is last. – Jonesey95 (talk) 12:24, 14 July 2025 (UTC)[reply]

Jonesey95: You've left Wikipedia:Extended image syntax#Brief syntax with: image options "can be placed in any order, except for Caption." This implies that there are limitations on the placement of Caption. There don't seem to be any limitations on the placement of Caption ... except in gallery, where Caption has to go before |link=. If there are other limitations, they should be explained somewhere. If that's the only limitation, maybe clarify that point. I updated Wikipedia:Extended image syntax#See also, standardizing the style and adding links to Help:Gallery tag and mw:Help:Images. —Anomalocaris (talk) 20:58, 14 July 2025 (UTC)[reply]

Thanks for that. I missed that addition, which looks like it happened earlier. I have tidied that section. – Jonesey95 (talk) 22:15, 14 July 2025 (UTC)[reply]

Pesky portal bogus file options

I solved pesky portal bogus file options in Portal:Video games generated from {{Transclude list item excerpts as random slideshow}} not dealing well with perhaps nonstandard usage of {{Nihongo foot}}. I fixed two pages:

Super Mario Bros.: The Lost Levels changed

'''''Super Mario Bros. 2''''',{{nihongo foot||スーパーマリオブラザーズ2|Sūpā Mario Burazāzu Tsū|lead=yes|group=lower-alpha}}

to

{{nihongo foot|'''''Super Mario Bros. 2'''''|スーパーマリオブラザーズ2|Sūpā Mario Burazāzu Tsū|lead=yes|group=lower-alpha}},

Persona (series): changed

'''''Persona''''',{{Nihongo foot||ペルソナ|Perusona|group=Jp.}}

to

{{Nihongo foot|'''''Persona'''''|ペルソナ|Perusona|group=Jp.}},

I believe I fixed a bunch of these a long time ago, and I don't remember if the error happens when any English parameter is pulled out of {{Nihongo foot}}, or only if the English parameter that's pulled out has bold or italics. Either way, moving the English parameter inside (with bold or italics if any) fixes the problem. —Anomalocaris (talk) 21:40, 17 July 2025 (UTC)[reply]

html5-misnesting

The error count at Special:LintErrors/html5-misnesting has gone from single digit to 3000+ in an hour or two (and is still going up). What's changed? -- 92.21.137.132 (talk) 23:38, 20 July 2025 (UTC)[reply]

I'm guessing it's due to JPxG doing things with Template:Signpost/item? JPxG, whenever you're done with your work, can you make sure to leave it in such a state that it doesn't emit a linter error? --rchard2scout (talk) 00:21, 21 July 2025 (UTC)[reply]

Here's hoping "oopsie" means it's fixed. Primefac (talk) 00:23, 21 July 2025 (UTC)[reply]

How long does it take to depopulate the special page after the error's fixed? Or does it happen instantly? I believe that I fixed it a bit ago, but I will check again and see if not. jp×g 🗯️ 00:28, 21 July 2025 (UTC)[reply]

@JPxG This misnested error seems to now be fixed as of this edit, and I'm now seeing depopulation.

(Following was composed before that edit)

It varies. Sometimes it takes a pageview to the complaining page, others require a purge, and the really curmudgeony pages require a null edit. (I should clarify that they will depopulate over time without any user assistance, so no actions are really needed to when they are depopulating, these three methods are only needed to force check if the error is addressed or still remains, or later on if a few pages just won't clear after everything else cleared up)

A more minor issue I see, as these are not reporting on transcluded pages, so not something that has to be resolved now, but I also see that Template:Signpost/item is claiming two div errors at this moment, a missing div and a stripped div. I suspect the logic is "hiding" the divs from each other and not "actually" missing and stripped, but template logic/syntax is not my forte at this time, so I can only report what I'm seeing reported. Since I don't see div tags directly on that page, I'm guessing they are buried in a subpage of logic. Jonesey95 probably would know the solutions here, as I'm most aware of their past template error solutions, but I doubt they are the only other delinter well-versed in template logic who might know. Zinnober9 (talk) 01:26, 21 July 2025 (UTC)[reply]

Indeed, thanks. For reference, I just (today) split out the main logic of that template to a subpage ({{Signpost/item/core}}). jp×g 🗯️ 01:34, 21 July 2025 (UTC)[reply]

Normal service has resumed. Back down to just 5 reported errors. -- 92.21.137.132 (talk) 08:11, 21 July 2025 (UTC)[reply]

I fixed the misnesting in /core but did not check if it broke anything. The div was preceded by a br tag, so it *should* be fine. – Jonesey95 (talk) 13:18, 21 July 2025 (UTC)[reply]

User talk:Nehrams2020/Archive 15 and Wikipedia:WikiProject Good articles/Recruitment Centre/Shell

I'm not sure where the error is with User talk:Nehrams2020/Archive 15 and Wikipedia:WikiProject Good articles/Recruitment Centre/Shell. If anyone finds up, please post here. Gonnym (talk) 11:09, 23 July 2025 (UTC)[reply]

I think the problem may be that the table close tag in Wikipedia:WikiProject Good articles/Recruitment Centre/Shell and Wikipedia:WikiProject Good articles/Shell is not on its own line.

That is:

</onlyinclude>|}

should be:

</onlyinclude>
|}

If you look in User talk:Nehrams2020/Archive 15 there are three instances of table close tags not on their own line, and if you put them on their own line, the lint errors go away. They appear to come from the two GA shells listed above. —Bruce1ee ^talk 12:02, 23 July 2025 (UTC)[reply]

I agree. I have found and fixed many of these }}|} errors on User talk pages. Add a new line before the pipe. – Jonesey95 (talk) 13:47, 23 July 2025 (UTC)[reply]

Ah, thanks both. I looked and couldn't see what was missing. It seems that if all else fails, check the newline. Gonnym (talk) 17:30, 23 July 2025 (UTC)[reply]

Misbehaving magic word

Anyone know why the "magic word" {{!}} template is bogusing the file syntax on multiple files within User:V!MA EDIT/sandbox? It should be an "inert/logically ignored display only vertical bar", but it seems to be interacting logically here. I retyped them thinking maybe it was a lookalike ! character, but no luck, and they wrote/used the template as I understood it to work correctly for that displaying vertical bar purpose, so I'm lost. Zinnober9 (talk) 02:05, 27 July 2025 (UTC)[reply]

Ah. That's why. Thanks! Zinnober9 (talk) 06:34, 27 July 2025 (UTC)[reply]

You can also use {{pipe}} -- WOSlinker (talk) 06:48, 27 July 2025 (UTC)[reply]