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 auto-archived by Lowercase sigmabot III if there are more than 4.

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]

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 <!-- EDIT BELOW THIS LINE --> 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 <!-- EDIT BELOW THIS LINE --> 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]

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]

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]

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]

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]

I solved another one in Portal:Baseball caused by Mark Murphy (American football executive) having this markup: <sub><!-- Subscript text --></sub>{{good article}}. I removed <sub><!-- Subscript text --></sub>. To solve this sort of error, I click the link on the lint error page, copy the highlighted text into Special:ExpandTemplates, and do repeated cycles of clicking OK and using lintHint to see if there is an error. When there is an error, I find out what page causes it and look for markup on the same line as templates that are usually on lines by themselves. —Anomalocaris (talk) 19:34, 4 August 2025 (UTC)[reply]

The following is a similar bogey image issue reappearing on Portal:Japan:

<span class="switcher-label" style="display:none"><span class="randomSlideshow-sr-only">Image 15</span></span><div class="center"><div class="thumb <br />'"`UNIQ--nowiki-00000018-QINU`"'<br />tnone" style="width:282px;"><br /><div class="thumbinner"><div class="thumbimage overflowbugy" style="height:350px;overflow:auto;">[[File:Shoki2.jpg|250px|alt=|Use the scrollbar to see the full image.]]<br /></div><div class="thumbcaption"><div class="magnify">[[:File:Shoki2.jpg| ]]</div>''Shōki-zu'' (Shōki striding), c. 1741–1751</div><br /></div></div></div><br />{, width="33%",  <small>Credit: [[Okumura Masanobu]]</small><br />, }<br />''Shōki-zu'' (Shōki striding), c. 1741–1751, a ''[[ukiyo-e]]'' print in the [[Woodblock_printing_in_Japan#Paper_sizes|pillar print]] format created by [[Okumura Masanobu]].<br />{,  class="noprint" width="100%"  border="0" style="padding: 0; margin: 0; background-color:transparent", -<br />,  width="33%",  '''[[Portal:Japan/Selected picture|More selected pictures]]'''<br />,  style="text-align:right;margin-right:10px;margin-bottom:4px;",  '''[[Okumura Masanobu|Read more...]]'''<br />, -<br />

I gave the extend template tool a try, but beyond expanding and seeing it state there's "an extra /div", I haven't made any real headway or spotted a probable culprit page yet. Sharing in case you or others have an idea. Zinnober9 (talk) 02:33, 11 August 2025 (UTC)[reply]

The problem page appears to be Portal:Japan/Selected picture/42, which is using non-standard formatting because the selected picture is very tall. My recommendation would be to somehow exclude this image and select a different one that fits in the Portal format. More pictures are at Portal:Japan/Selected_picture. – Jonesey95 (talk) 05:24, 11 August 2025 (UTC)[reply]

Sounding a bit like User:Begoon/POTD custom all for days where a past year's picture's format is different and causes display issues to occur (entire post showing instead of only the file: problematic, fine). Zinnober9 (talk) 14:29, 11 August 2025 (UTC)[reply]

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]

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]

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]

Resolved

At User:Discographer/Various–Music, I'm seeing link-in-link errors that were not being reported yesterday.

An example error is [https://www.billboard.com/charts/hot-100/1990-03-10 {{mono|05}}], which renders as 05 and expands to this HTML:

<div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr"><p><a rel="nofollow" class="external text" href="https://www.billboard.com/charts/hot-100/1990-03-10"><style data-mw-deduplicate="TemplateStyles:r886049734">.mw-parser-output .monospaced{font-family:monospace,monospace}</style><span class="monospaced">05</span></a>
</p></div>

I'm not seeing a problem here. I'm guessing that because WP:ITSTHURSDAY, a code change has surfaced this newly reported error. Changes have been made to the page in the past day or two, but the link above does not appear to be part of those changes (I could be wrong). Does anyone have any insight into this one? I am thinking of reporting it on Phabricator as a false positive. I note also that the link above – Jonesey95 (talk) 17:36, 7 August 2025 (UTC)[reply]

I'm more confused after saving this post, because the link above is not reported by Linter on this page. Insight is requested. – Jonesey95 (talk) 17:39, 7 August 2025 (UTC)[reply]

Never mind. I noticed that the page is in Category:Pages where post-expand include size is exceeded, which causes some of the wikitext to be ignored. This can cause all sorts of imbalanced code and Linter errors. – Jonesey95 (talk) 17:43, 7 August 2025 (UTC)[reply]

The system is mostly working, but I can't get some Multi colon escape lint errors to highlight.

• The lint error in User:CanonNi/To do: When I open the edit link, the page does not highlight the markup {{Dashboard}} that has the lint error. lintHint identifies that there is a Multi colon escape, but when I click on the down arrow (↓), nothing happens.
• The lint error in Wikipedia:Deletion review/Log/2019 December 3: When I open the edit link, the page does not highlight the markup {{noredirect|:Template:Old Afd multi}} that has the lint error. lintHint identifies that there is a Multi colon escape, but when I click on the down arrow (↓), nothing happens. If someone fixes this error, I challenge you to re-insert the colon in the editor and then try to find the error with lintHint.

But the crazy thing is, lintHint is working fine in the basic case. Edit this section and remove the nowiki markup around this multicolon escape, and lintHint will give a working link to it:

• [[::Water]]

I haven't found similar no-highlight problems with any other lint error. The problem is not "lintHint can't highlight templates". Misnested tag with different rendering in HTML5 and HTML4 lists a lint error in Wikipedia:Village pump (technical)/Archive 83 through Template:Nowrap. When I open the edit link, it highlights {{nowrap|"{{padright:|5|:*mmnn}}"}} as it should, and lintHint generates a working pointer to this same wikitext. The problem may be related to templates, but there's more to it than that. —Anomalocaris (talk) 08:17, 13 August 2025 (UTC)[reply]

User:CanonNi/To do is in Category:Pages with too many expensive parser function calls. I believe that can cause incomplete and unpredictable rendering, which may be causing a Linter false positive. As for the Deletion review page, I can't explain LintHint's behavior, but as often happens, copying the whole page to Special:ExpandTemplates reveals the actual location of the error. – Jonesey95 (talk) 13:05, 13 August 2025 (UTC)[reply]

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]

You may notice an increase in missing end tags and other Linter errors, especially inside <ref>...</ref> and {{efn}} tags/templates, fixable in the usual way. I believe that the increase is due to the fixing of the two-year-old bug at T348149, which fixed the Linter's missing of some errors. You're welcome, I guess. No rest for the bug reporter .... – Jonesey95 (talk) 00:31, 15 August 2025 (UTC)[reply]

Wikipedia:Village_pump_(miscellaneous)#Indenting_fmboxes. This topic will be of interest to this community. Zinnober9 (talk) 20:44, 18 August 2025 (UTC)[reply]

Killed with fire. – Jonesey95 (talk) 23:21, 18 August 2025 (UTC)[reply]

The question that remains on my mind is: Why is indenting <div> (or div-based templates such as {{fmbox}} in my case) considered a type of Linter error? What other problems arise (even from intentional cases within discussion threads) that make it necessary to designate indented divs as Linter errors in the first place? – MrPersonHumanGuy (talk) 16:09, 27 August 2025 (UTC)[reply]

MrPersonHumanGuy, because the indentation uses an inline tag. Placing a div inside an inline tag is illegal in html. — Qwerfjkltalk 16:18, 27 August 2025 (UTC)[reply]

Special:LintErrors/deletable-table-tag: was ~6, now 41, and going up. -- 92.18.76.185 (talk) 22:25, 1 September 2025 (UTC)[reply]

It looks like that is due to Mackensen replacing {{s-rail}}, a template that starts with a table row opening, with {{Disused rail start}}, a template that starts with a table opening. I recommend that Mackensen undo these edits and work on a method that does not introduce invalid syntax. It is unclear what they are attempting to achieve; to me, the output looks the same before and after each edit. – Jonesey95 (talk) 23:59, 1 September 2025 (UTC)[reply]

Yup. It's because of this and/or this being changed. Since I don't know which end is wronger (I see issues at both places to be honest) and the second page requires template editor permission, so I was hanging back and seeing if the editor would clear it up, or if one of the template delinting editors here was going to have a look and sort it out. I don't like the template end being changed from the s-rail templates to a wikitable, that seems improper to move away from a well established template, but I also don't see the vision here. I also don't like how the articles don't have a table closer statement/template. Zinnober9 (talk) 00:07, 2 September 2025 (UTC)[reply]

@Mackensen: We should be moving Ireland's templates to the Adjacent stations Module as well. Cards84664 00:32, 2 September 2025 (UTC)[reply]

@Cards84664 I'm trying to isolate the Australian "disused" lines which have never been organized by system. Mackensen (talk) 01:15, 2 September 2025 (UTC)[reply]

I'll deal with the linter issue. @Jonesey95 to answer your broader question, {{s-rail}} shouldn't be used to indicate a disused line when the surrounding templates are for a completely different system. I explained my concerns on Template talk:Disused Rail Start. Is there some css/js I can add for linter issues to be visible while editing? I manually reviewed each edit and as you say they're visually identical (which is intended and in fact desirable). Mackensen (talk) 00:38, 2 September 2025 (UTC)[reply]

Fixed. I've modified {{Disused Rail Start}} with explicit support for this use case via a parameter. Sorry about that. Also added PerfektesChaos's tool. Mackensen (talk) 01:14, 2 September 2025 (UTC)[reply]

All good. You didn't send off a massmailer with a misnested tag error that multiplied into 1600+ errors, or set off a change in a template that broke the visual layout of any page content, so not a big deal in the grand scheme of things to have a small collection of pages with this issue for a little while. Table related syntax issues just happen to be a little more visible to us since we cleared off the backlog of table errors earlier in the year, but we're agreeable people when its a few pages with some errors while something's being tested and figured out. As long as the end result's clean, a little test mess is fine. Linthint's a great tool, I don't go anywhere on Wikipedia without it. Feel free to ask us questions if you have any.

Hope you are having a great long holiday weekend, Zinnober9 (talk) 01:42, 2 September 2025 (UTC)[reply]

On Santa Maria della Catena, Naples, {{Expand language}} is causing missing end tag lint errors because the associated pages linked via Wikidata contain missing end tags in their title (article in Neapolitan). Not really sure on how it can be fixed without moving the Neapolitan Wikipedia page. Any ideas? — Tenshi! (Talk page) 21:21, 2 September 2025 (UTC)[reply]

 Fixed with this edit. It replaces the ' character with HTML encoding. – Jonesey95 (talk) 22:03, 2 September 2025 (UTC)[reply]

Thanks to both of you. I'd attempted a few weeks ago to update the "nap" value in Wikidata:Q719084's "Wikipedia" name table, replacing one of the apostrophes with &#39. I did both the delete/add in one go which appeared to be interpreted as a null update, and I felt that was just as well since I wasn't entirely sure of the impact to the Neapolitan page had it succeeded.

— SirOlgen (talk) 23:15, 2 September 2025 (UTC)[reply]

Is the name in Neapolitan really with two regular apostrophes? Gonnym (talk) 08:30, 3 September 2025 (UTC)[reply]

Gonnym, looks like there are some problems with titles like this on enwiki.
E.g. linking to 2,2',2''-Nitrilotriacetonitrile works fine here, but seems to render as italics on Glossary of chemical formulae. — Qwerfjkltalk 12:30, 3 September 2025 (UTC)[reply]

Though switching to Parsoid (?useparsoid=1) renders correctly. — Qwerfjkltalk 12:32, 3 September 2025 (UTC)[reply]

Parsoid is expected to become the default parser within a year, so we're not likely to try to fix this in the legacy parser. (Commented on phab:T403653.) C. Scott Ananian (he/him) (talk) 14:24, 4 September 2025 (UTC)[reply]

My question is if apostrophes are the correct semantic character or should one of several other similar characters be used instead. Gonnym (talk) 12:36, 3 September 2025 (UTC)[reply]

They are correct, using apostrophes to indicate one or more missing letters. Napolitano has the usual Italian construction d', short for "de" (of), and also has a construction that uses 'e when "le" (the; plural) would usually be present. There is also 'a for "la" (the; feminine) and 'o for "lo" (the; masculine). So then you get "of the" becoming d''e / d''a / d''o. Fun! See this Reddit thread. – Jonesey95 (talk) 13:41, 3 September 2025 (UTC)[reply]