Wikipedia talk:Linter

  1. Home
  2. Wiki

Empty headings

[edit]

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 <!-- 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]

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 == <!-- EDIT BELOW THIS LINE --> == to <!-- EDIT BELOW THIS LINE --> WOSlinker (talk) 17:04, 11 September 2025 (UTC)[reply]

Pesky portal bogus file options

[edit]

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. 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''''',{{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:
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]
[edit]
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]

Multi colon escape lint errors not highlighting

[edit]

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]

Small milestone

[edit]

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. —Bruce1eetalk 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. —Bruce1eetalk 00:22, 15 August 2025 (UTC)[reply]

Increase in detected errors inside ref/efn/sfn

[edit]

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]

Errrrggggggghhh

[edit]

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]

Error count going up.

[edit]

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]

Expand language template causing missing end tag lint errors

[edit]
Tracked in Phabricator
Task T403653

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]

Bot task proposed to fix Linter dark mode issues

[edit]

Please see this discussion at VPP regarding a proposed bot task for fix Linter dark mode issues on AFD pages. The technical discussion of the bot task itself is at Wikipedia:Bots/Requests for approval/MatrixBot 2. – Jonesey95 (talk) 19:02, 8 September 2025 (UTC)[reply]

Mystery fostered content errors

[edit]

Wikipedia:Template index/Cleanup, now, and since revision of 04:59, 28 July 2025 (UTC), has mystery fostered content lint errors that lintHint sees in editing this template, but lintHint does not see in Special:ExpandTemplates. The offending markups are in these two tables: 

===Bottom of page===
{| class="wikitable"
|-
{{tlrow|orphan|category=All orphaned articles}}
* Use this for articles that aren't linked to from any other pages.
{{tlrow|uncategorized|category=Uncategorized pages}}
* Place this at the '''bottom''' of an uncategorized article/category if you are unsure of which categories apply.
|}

===Other===
{| class="wikitable"
|-
{{tlrow|cleanup HTML|category=Articles with HTML markup}}
* If the article needs HTML changed into wiki-markup
* Use this if the article has non-English text but lacks {{tl|lang}}, {{tl|transl}}, or other [[:Category:Wikipedia multilingual support templates|multilingual support templates]].
|}

I note that {{tlrow}} emits |- right at the beginning, so all of the tables that have |- followed by {{tlrow}} should probably omit the |-, but that is not the problem here. I am stumped. —Anomalocaris (talk) 20:21, 14 September 2025 (UTC)[reply]

It seems to have hit the PEIS limit, which might be causing it? Tenshi! (Talk page) 20:24, 14 September 2025 (UTC)[reply]
Correct diagnosis. Always look for Category:Pages where post-expand include size is exceeded and unexpanded templates at the bottom of pages like this. – Jonesey95 (talk) 20:38, 14 September 2025 (UTC)[reply]
User:WikiEdita65: Wikipedia:Template index/Cleanup is in Category:Pages where post-expand include size is exceeded. It would be a good idea to remove some templates or split it into two or more pages, so that all of the templates properly expand. While you are about it, you might as well remove the "new table row" lines as noted in this discussion above. —Anomalocaris (talk) 21:29, 14 September 2025 (UTC)[reply]

Bogus file options count spike

[edit]
Resolved

The count for bogus file options is now showing at 123,806. Looking at the pages, the problem parameter given via linthint and Special:LintErrors/bogus-image-options is class=sister-inline-image. — Tenshi! (Talk page) 19:32, 15 September 2025 (UTC)[reply]

Seems to be caused by Special:Diff/1311552111. Tenshi! (Talk page) 19:34, 15 September 2025 (UTC)[reply]
The editor has reverted their error. The list will take a while to clear. – Jonesey95 (talk) 19:38, 15 September 2025 (UTC)[reply]
Don't think I've seen one that big before... geez. At least we know it'll be near zero afterwards! Thankfully they are clearing from just page views and not needing any purging, so best just to ignore and see if any need pushing in a few hours I guess. Dropping quickly so far, 65k at last update. Zinnober9 (talk) 20:07, 15 September 2025 (UTC)[reply]
I cleared the non-article namespace lists semi-automatically so that it will be easier to see real instances appearing on those lists. – Jonesey95 (talk) 20:32, 15 September 2025 (UTC)[reply]
I open Special:LintErrors and refresh the page, and the Bogus file options count changes as follows: 20,308, 20,164, 19,212, 17,888, 20,078, 17,832, 20,055 ... just a few seconds apart. I've never seen it jump around like that. —Anomalocaris (talk) 00:38, 16 September 2025 (UTC)[reply]
It's been doing that for as long as I can remember. Those numbers are unreliable. Take a look at the number for "Background color inline style rule exists without a corresponding text color" when you refresh. – Jonesey95 (talk) 00:48, 16 September 2025 (UTC)[reply]
I regularly see it jump like that on the bigger sets when I refresh S:LE. The bigger the set, the bigger the jumps. Background color jumps anywhere from 20mil to 25mil when I look at it, but Empty Header is almost always a stable 6,165. I don't trust any value over 10k to be very accurate. Zinnober9 (talk) 00:52, 16 September 2025 (UTC)[reply]
Still some remaining, latest updates shows as 1,362. Tenshi! (Talk page) 11:32, 16 September 2025 (UTC)[reply]
I cleared out the last few stragglers. The category is empty at this writing. – Jonesey95 (talk) 13:50, 16 September 2025 (UTC)[reply]

Unstable purge buttons

[edit]

Calmer Waters's page has two 'purge this page' image buttons that seem to be unstable in terms of lint. It's been frequently appearing in the list this week stating "action=purge}}" is bogus, but if you go to the page, it either tells you it's got no errors, one error, or two errors. I don't see anything specifically wrong. I copied both links to my sandboxes 2 and 3 and haven't seen my sandboxes appearing with errors. The only "issue" I see on their page from a brief visual scan is they have a col table with six col-5 separators, but I'm not confident the extra col-5 would cause this. Anyone have any ideas? Zinnober9 (talk) 17:34, 24 September 2025 (UTC)[reply]

The page is in Category:Pages where post-expand include size is exceeded, which causes unpredictable problems because the code on the page is not fully rendered. This may need to be a FAQ; it comes up a few times a year on this page. – Jonesey95 (talk) 17:39, 24 September 2025 (UTC)[reply]
But it seemed so small... Weird. I'm starting to think that the admin dashboard template is far too massive/needs to be on its own page and not transcluded ever for these reasons, but that's probably an unpopular opinion. Ok, glad to know it's correct and not something to fix. Zinnober9 (talk) 17:53, 24 September 2025 (UTC)[reply]

Infoboxes showing up due to improperly embedded child infoboxes

[edit]

A couple of infoboxes have been changed, leading to some of their transclusions showing up on the stripped tag list. I clicked three at random and found that each one was missing the module= parameter. – Jonesey95 (talk) 02:29, 26 September 2025 (UTC)[reply]

I don't know if this is an issue we should be concerned about, but simply prefixing the embedded child infobox with the missing module parameter sometimes upsets the order of the infobox data. For example the above fix places "Cause of death" at the end of the infobox, instead of after "Died" where it was before the fix. One way to fix this is to swap the parent and child infoboxes as I did here – that puts "Cause of death" in the correct position. There are probably other ways to fix this problem. —Bruce1eetalk 09:59, 26 September 2025 (UTC)[reply]
In a perfect world, the infoboxes based on {{Infobox person}} would have the code written like in {{Infobox architect}}, which means that only the unique code to that specific template is added and any existing parameters of {{Infobox person}} is allowed. This means that |module= or parameter order issues are gone. {{Infobox gymnast}} isn't set up like that. Gonnym (talk) 10:08, 26 September 2025 (UTC)[reply]
User:Hike395 good job on converting to the wrapper btw. Gonnym (talk) 10:09, 26 September 2025 (UTC)[reply]
Thanks! I can convert {{Infobox gymnast}} to wrap {{Infobox sportsperson}} (which I believe should be the correct base template). — hike395 (talk) 13:24, 26 September 2025 (UTC)[reply]
I think that would be helpful. Something like {{Infobox sport wrestler}} looks like a good example to copy. – Jonesey95 (talk) 15:30, 26 September 2025 (UTC)[reply]
@Hike395 maybe sportsperson should also be converted to a wrapper of person so all base functions are handled by the base infobox. This discussion should probably be moved elsewhere as to not spam the linter page. Gonnym (talk) 14:15, 28 September 2025 (UTC)[reply]

Adding parameters

[edit]

I have added |death_cause= and |education= to {{Infobox musical artist}}. This change allows us to eliminate child infoboxes in many cases. Zackmann08 might be interested in doing similar additions to templates causing these tag errors due to misplaced child infoboxes as they add the new date-related template to infoboxes. Here are the documentation changes I made to the musical artist template. – Jonesey95 (talk) 12:43, 26 September 2025 (UTC)[reply]

search results for anyone interested. Gonnym (talk) 13:38, 26 September 2025 (UTC)[reply]
That helps, thanks. —Bruce1eetalk 13:42, 26 September 2025 (UTC)[reply]
Template:Infobox ice hockey biography also needs |death_cause= added (per Bert Cadotte). Zinnober9 (talk) 06:13, 27 September 2025 (UTC)[reply]
... and {{Infobox writer}} needs |death_cause= for Joyce Kilmer and others. Thanks. —Bruce1eetalk 07:13, 27 September 2025 (UTC)[reply]
 Done. – Jonesey95 (talk) 13:18, 27 September 2025 (UTC)[reply]
Thanks ... —Bruce1eetalk 13:55, 27 September 2025 (UTC)[reply]

Merging child infoboxes when the parameter is supported

[edit]

{{Infobox military person}} has |death_cause= (it was added sometime in the past few years), so you can simply eliminate the child infobox and use the parameter directly. I assume that people used the child infobox before the parameter was supported. – Jonesey95 (talk) 13:05, 26 September 2025 (UTC)[reply]

Thanks for adjusting the infoboxes, that makes things easier. —Bruce1eetalk 13:41, 26 September 2025 (UTC)[reply]

div span error

[edit]

Got an error of span, an inline tag, wrapping a block template on Template:Infobox religious biography. last item changed here

{{#if:{{{death_place|{{{place of death|}}}}}}|<span class="deathplace">{{{death_place|{{{place of death|}}}}}}</span>}}

I'd replace the span with div, unless there's something better. Zinnober9 (talk) 15:24, 26 September 2025 (UTC)[reply]

Which article? – Jonesey95 (talk) 15:31, 26 September 2025 (UTC)[reply]
Never mind, I found it at Mike Velarde. I think divs will work without breaking anything and have boldly made the change. – Jonesey95 (talk) 15:35, 26 September 2025 (UTC)[reply]
Wilfredo Alarcón, Yasser Al-Habib, Francesco della Penna and a few others with the div span flip error which have since cleared. The template page was claiming the error as well, so articles didn't seem important.
Muhammad's hanging on for some reason though. Oh... Overlooked the other items changed were also spans. nickname and birth place. Oops. Those too please? Zinnober9 (talk) 15:49, 26 September 2025 (UTC)[reply]
Yum, edge cases. Fixed. – Jonesey95 (talk) 16:18, 26 September 2025 (UTC)[reply]
Same issue on Template:Infobox officeholder, unless there's something specific with the flagged articles Edmund Barton, Mindaugas Sinkevičius, François Langelier, and Robert Duchniewicz. Zinnober9 (talk) 23:58, 26 September 2025 (UTC)[reply]
Fixed. – Jonesey95 (talk) 02:56, 27 September 2025 (UTC)[reply]