Archives

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

This page has archives. Topics inactive for 60 days are automatically archived 2 or more at a time by Lowercase sigmabot III if there are more than 4.

All of a sudden, I'm noticing a lot of empty headings errors that are caused by markup like this:

Fact.<ref name="Yes">{{cite web|title=Yes |url=http://yes.com}}</ref> Another thing.<ref name="Yes"> This content doesn't appear because somebody forgot to self-close a named reference.

==Bogus empty heading==
Another fact.<ref name="No">{{cite web|title=No |url=http://no.com}}</ref> <!-- we've finally closed <ref name="Yes"> above -->

You can remove the <pre>...</pre> markup to see the error, but I didn't want to create it on this page. The real problem is the missing slash to self-close the reference after "Another thing." It's possible that nothing has changed other than one or more editors who are all of a sudden carelessly using this markup. —Anomalocaris (talk) 20:13, 28 April 2026 (UTC)Reply

I've been seeing these daily ever since we eliminated their backlog a few months back. I haven't noticed any upswing in frequency, but it's possible we're tuning in at different times. I think it's just careless markup and/or editors forgetting that they are calling a named ref (selfclosed) and not defining a new one (open) since there's been a steady stream of a few every few hours and rarely by the same editors. When it isn't these, it's been copyeditors sticking the "Use MDY dates" type of templates, or other "top of article" templates, into header notation when they have no business being in section header notation.

Zinnober9 (talk) 20:45, 28 April 2026 (UTC)Reply

I'm guessing this reported empty header is a Thursday issue as there aren't any actual empties or any ref tags present. It also disappears from linthint when the Afd top/old template is deactivated.

Also curious on the explosion of 500+ div-span-flip errors on various unedited pages. Zinnober9 (talk) 01:03, 1 May 2026 (UTC)Reply

I'm curious why there's a little bit of a cropping up of templates of the webaddress.com/{{{1}}} format reporting empty headings. They shouldn't, they are webaddress templates and don't use or produce headers. First one to appear was Template:Magyar Elektronikus Könyvtár link and now today is Template:YouTube, Template:Labsquery, and a few others and their sandboxes are reporting. I'm suspecting this isn't an error at the template level but some other weirdness since all? haven't been edited recently.
Similar issue for User talk:Godlord2/Archive 1, [{{SERVER}}{{Wikipedia:WikiProject My Chemical Romance|action=edit}} Edit] is causing all of the empty heading issues on the page due to the {{SERVER}} call. Something is interfering with these address type templates. Zinnober9 (talk) 09:47, 10 May 2026 (UTC)Reply

This edit, which put {{documentation}} on a new line, appears to fix the strange empty heading issue. This format, which can fix other Linter errors, is recommended in the how-to guide. – Jonesey95 (talk) 03:01, 24 May 2026 (UTC)Reply

Ah, should have thought of that given how many other templates have issues when they share the same line (or are bulleted/indented/etc.) Thank you very much! Zinnober9 (talk) 11:36, 24 May 2026 (UTC)Reply

I think an unclosed <ref> tag should be a new high-priority lint error. It causes everything up to the next </ref> not to display, and causes otherwise valid markup to have bogus lint errors. —Anomalocaris (talk) 01:43, 30 June 2026 (UTC)Reply

Found an issue on four pages I haven't figured out. Within a ref, an ordered list appears, but the combination doesn't seem to display at all. Anyone know if these are incompatible or how to fix?

Pages affected:
Talk:Banu_Ifran at Problem_2 (I fixed the lint errors, but not displaying at all)
Talk:Annexation of Tibet by the People's Republic of China/Archive 1 at Incorrect move II (not fixed)
Talk:Death Cab for Cutie/Archive 1 at Weird code (not fixed)
Talk:History of antisemitism/Archive 2 at "2006 February" (not fixed)

Thanks, Zinnober9 (talk) 15:04, 10 June 2026 (UTC)Reply

Re Talk:Banu Ifran § Problem 2, the problem was the malformed ref close </<ref> — SirOlgen (talk) 20:13, 10 June 2026 (UTC)Reply

Oops, and all the things Gonnym adjusted (only just saw that now). It takes a village, apparently. — SirOlgen (talk) 20:24, 10 June 2026 (UTC)Reply

Re Talk:Annexation of Tibet by the People's Republic of China/Archive 1 § Incorrect move II, it looks like the ref with the ordered list is nested within another ref. If I close the first ref before opening the second, everything appears. Assuming <ref>something<ref>something else</ref></ref> isn't a thing, maybe the solution here would be to convert the initial ref to a sfn?

The ordered list is also has an extra </li> where the <ol> should be. — SirOlgen (talk) 20:50, 10 June 2026 (UTC)Reply

Or maybe that second <ref> tag was intended to be <ol><li> ? Not great for the reference numbering, but it makes things visible. SirOlgen (talk) 21:07, 10 June 2026 (UTC)Reply

Thank you both. I got focused on the ol errors and overlooked what it was containing, and the li ref ^ markup seems unnecessary and complicated. Since the intent is a list of refs, and the li ref ^ markup appear on these other pages also, I've followed Gonnym's lead and just simplified everything rather than ponder the OP's intentions of what and where, and since ref nesting isn't appearing to work for you or me. On Death Cab, since it was calling out the broken markup, I wrapped that in pre tags to preserve the intended example. Zinnober9 (talk) 22:01, 10 June 2026 (UTC)Reply

Need help with a lint error on three userpages: User:DankJae, User:Swanyay, and User:Evilrh104.
Template:Collapsed infobox section begin seems to be an enigma ripe for triggering misnested or missing/stripped div errors and I'm not seeing how these pages' usage differs from the example on the template's page or how to get these pages cleared. The two I "fixed" (Swan, Evil) changed the misnested div error to become a missing and stripped div error pair. Past discussions of delinting this template did not provide any insight on a solution, just that we hate how particular this template is and also looked into an error within the template, not errors with using the template. It's quite likely I've been staring at these too long and am overlooking something obvious. Otherwise, misnested divs are addressed. Thanks, Zinnober9 (talk) 16:15, 22 June 2026 (UTC)Reply

I remove this template from article pages when it causes Linter errors, per MOS:HIDE. In many cases, it is a hack that is too difficult to troubleshoot. User pages are a different story; I usually check the page history and the user's contributions, and if they haven't been around for a while, I edit the page to fix the Linter errors with an edit summary of "Fix Linter errors. I hope you don't mind this minor cleanup edit in your user space." – Jonesey95 (talk) 14:58, 23 June 2026 (UTC)Reply

Thanks. All three users have edited this year, so removing the template outright without a better reason doesn't feel appropriate at this point and since the sections function correctly when viewed. Will set them aside until something changes I guess. Zinnober9 (talk) 17:53, 24 June 2026 (UTC)Reply

I commented at Template talk:Collapsed infobox section begin#LintHint errors on 3 October 2021 that this template is fundamentally illogical. Nobody replied, but I believe I was correct then, and I think this template should be abolished. —Anomalocaris (talk) 02:33, 25 June 2026 (UTC)Reply

I'd be supportive of that, but I'm not speaking from a neutral point of view due to my frustration with it. I will note though that all the articles in mainspace (roughly 3800 of the total 4230 transclusions) that are using this template are all clean which is more than a bit frustrating from the "how and why did that work there but not here?" standpoint, but a good thing in the "we don't have to clean them up" standpoint. Zinnober9 (talk) 04:03, 25 June 2026 (UTC)Reply

We could really use a bot to finish off the font tags. It's really bizarre that such an easy bot fix is still around. Gonnym (talk) 19:06, 24 June 2026 (UTC)Reply

I thought Legobot was chipping away at these, but it doesn't seem to be currently. Tenshi! (Talk page) 19:07, 24 June 2026 (UTC)Reply

User:Legoktm, who runs that bot, is not around very much. The last time I checked, their bot was designed such that if it can't fix every Linter issue on a page, it won't perform any edit on that page. That means that a page with 50 font errors and one missing end tag that the bot can't fix will remain unedited. That is one reason why I often perform Linter fixes of non-font issues with the edit summary "Fix Linter errors. More needed. Leaving obsolete tags for bots."

When I do this, I hope that Legobot will be able to tidy up after me, which it last did on June 4, fixing 230 pages and 6,400 Linter errors, by my calculations. If you look at the history of one of those pages, you will see that User:Bruce1ee fixed some Linter errors on that page, leaving only obsolete tags, which Legobot was able to fix.

All of this is to say that we need bots and editors to focus on the non-font Linter errors, and Legobot will be able to take care of most of the font errors once we have those sorted. – Jonesey95 (talk) 19:50, 24 June 2026 (UTC)Reply

But it's a bit silly that in order to not have multiple edits by the bot, we preform multiple edits by everyone else, isn't it? Also, by first fixing the majority of the errors on a page and then leaving humans 1-2 errors to fix, it makes the editing process much easier as there isn't so much noise to ignore.

We just need a bot that can fix the font errors and get rid of them from the system. Gonnym (talk) 21:25, 24 June 2026 (UTC)Reply

I understand your viewpoint and would also love to see the half million fonts disappear at a quicker rate, but if the bot clears all of the fonts and leaves behind unclosed/stripped/misnested errors for a human editor, it'll still be a net minimum of two edits on pages with multiple error types. Zinnober9 (talk) 22:06, 24 June 2026 (UTC)Reply

The bot is programmed in this "silly" way deliberately. It was discussed in the BRFA: The main reason it doesn't edit if there are remaining lint errors is that some times those issues cause bugs in the fixes ... – Jonesey95 (talk) 22:09, 24 June 2026 (UTC)Reply

I know why. I was in those conversation. I'm just saying the rational behind that is failing. This should ensure that Legobot does not edit a page more than once, which was the main issue in the above-linked BOTN discussion. which is fine, but then we have at the minimum 2 edits, a human editor and Legobot. In practice, sometimes more than 2. And those other edits can't be hidden as they aren't bot made. So in general the community gets more watchlist noise. Gonnym (talk) 05:18, 25 June 2026 (UTC)Reply

What Jonesey said; in short Legobot mostly operates on the Parsoid HTML representation of page, which means that those misnested tags tend to screw up the fixes themselves.

I did implement a few regexes that operate on wikitext, and are able to fix those issues using the high-value items on the Signature submissions page that Jonesey and others had flagged. If there are more of those patterns or cases I can work on implementing them. (And if someone wants to contribute code, that would be incredible!) Legoktm (talk) 23:37, 24 June 2026 (UTC)Reply

On that signature submissions page, there is still a link to pages with Template:Welcomeg. Many of those pages have been fixed, but others, like User talk:A Knight Who Says Ni, have just one missing end /div tag, so there are still bot-fixable pages out there. If you go to the signature submissions page, you'll see multiple links to affected pages. I have patterns for fixing many of those welcome messages at User:Jonesey95/AutoEd/linter.js, starting at line 1396 and going for about 10 lines. I'll list a few more large batches that Legobot might be able to take on:

• As Gonnym said in that linked discussion, the work of Wikipedia:Bots/Requests for approval/SheepLinterBot 2 is almost done, and after some Legobot work, there are about 380 pages left to edit. There appear to be maybe 17,000 more of a different variety.
• 600 pages with a stripped center tag; the regex for this Mediation message is on the signature submissions page.
• A few thousand pages with a substed AFC decline template.
• User:Flat Out's signature; 1,800 pages.
• AnimWIKISTAR-laurier-WT.gif; 3,000 pages
• Get adopted; 1,500 pages
• Article wizard: 1,000 pages
• Question "What would you like to change about that?"; 850 pages

If Legobot could work on any of these, that would be helpful. If you need regexes, I can probably provide them (I have a regex for AnimWIKISTAR-laurier-WT.gif in my linter.js file, for example). I don't know what other kind of code you might need. – Jonesey95 (talk) 01:38, 25 June 2026 (UTC)Reply

Jonesey95, my bot can do these, if they're as simple as the past fixes. — Qwerfjkltalk 17:10, 26 June 2026 (UTC)Reply

Except for the SheepLinter div tag "TWA Earth" pages, they are simple; I excluded more complex examples from the list above. I believe that I have regexes for most of them in my linter.js file, linked above. Other replacement strings are on the signature submissions page. Some of them will need to include newline characters or at least detection of the end of a line (regex $). I don't have time to create specially-formatted replacement strings for you at the moment, but I'll be happy to look at test replacements if you want to have a go at them. – Jonesey95 (talk) 17:49, 26 June 2026 (UTC)Reply

Jonesey95, I can't see the line numbers on your linter.js page, so it would seem tricky to locate them. Because they're regexes and not simple replacements I'd need to modify my code somewhat. I might have a go at them later, but no promises. — Qwerfjkltalk 10:30, 28 June 2026 (UTC)Reply

Is there an example of a page that you'd have expected Legobot to fix (i.e. all the other issues are fixed) that it didn't? I checked the logs and it's still running weekly, but in the last run on June 19, it didn't find any pages it could actually fix. Legoktm (talk) 23:27, 24 June 2026 (UTC)Reply

Here are some pages where I fixed some Linter errors before June 18, leaving only font tags. I wonder what might be tripping up Legobot. Talk:Germany/Archive 18, Wikipedia talk:Pending changes/Straw poll/Archive 1, User talk:Sjakkalle, Wikipedia:Administrators' noticeboard/Archive192 (one tt tag), User talk:Academic Recorder (no font tags, but two possibly easy center tags), Wikipedia:Peer review/4X/archive1, Wikipedia talk:Peer review/Archive 4, Wikipedia:WikiProject Aviation/Peer review/Rolls-Royce Merlin, Wikipedia:Peer review/Islamic architecture/archive1. – Jonesey95 (talk) 01:42, 25 June 2026 (UTC)Reply

Going back a month, I have eight pages that I left for the bot that haven't been cleared yet, with only font tags remaining: User talk:Arbitrarily0/Archive/2009, User talk:Daniel/Archive/28, User talk:Georgia guy/Archive 1, User talk:Bmedick, User talk:28421u2232nfenfcenc/Archive 2, User talk:5 albert square/Archive 16, User talk:Tamzin/Archive/Old/6, and Talk:2006–07 Southern Hemisphere tropical cyclone season/February. Also curious what might be tripping these. It did follow me and clear four pages though, so some progress, and pages I tend to leave leftovers on tend to be long or robustly fonty pages with elaborate signatures that I don't want to bother with so potentially more prone to some unknown (to me) hangup. Zinnober9 (talk) 03:06, 25 June 2026 (UTC)Reply

Same for me with the leftover font tags. I have regexes that fix the easy ones, so anything that is left is necessarily at least a bit complex. – Jonesey95 (talk) 04:32, 25 June 2026 (UTC)Reply

I was trying to see if I could make a regex search for the IAbot dead link templates that appear in external links but haven't been detected by Linter yet so I can either clean it up with my bot or with my alt account that I have for scripts, though the search function keeps timing out and only giving partial matches, saying that I should simplify the regex to get complete search results, but I don't see any way of simplifying what I have now ([1]). Any ideas? — Tenshi! (Talk page) 12:12, 1 July 2026 (UTC)Reply

This more specific search may work better. It still times out, but it gave me more results. Adding the word "is" sometimes helps, but that one also times out for me. Here's a third one with a more limited regex that, frustratingly, still times out. I would fix the 100 pages that show up in that search and then search again. – Jonesey95 (talk) 13:01, 1 July 2026 (UTC)Reply

I finished going through the third one, will see later how much it's done. Tenshi! (Talk page) 17:32, 1 July 2026 (UTC)Reply

Greatly reduced (from 100 to 30 when my search times out). One of the searches is also finding unclosed brackets, which is useful but a different kind of error. You could also work on the actual Linter error list, which has been populating slowly since last week. I have fixed a few dozen errors from that list. – Jonesey95 (talk) 20:49, 1 July 2026 (UTC)Reply

I'm using searches because I'm using the simple find and replace script rather than the main one TenshiBot uses, since it's not very cooperative if I take it out of it's repo without everything else, that and it would lead to weird things such as my alt account editing User:TenshiBot/Errors if there's an error or other inconvenience, and using the bot edit summaries. Tenshi! (Talk page) 22:42, 1 July 2026 (UTC)Reply

In any case, the wikilinks in external links category is now clear again. Tenshi! (Talk page) 00:48, 2 July 2026 (UTC)Reply

Anyone know why (within the code) the transliteration template is breaking the Template:Ruby line case on Ruby character? The Ruby line template was updated today, and I fixed the unclosed ruby tag issue, but it didn't solve this part of the issue. Zinnober9 (talk) 19:35, 2 July 2026 (UTC)Reply

I posted a note to the template's talk page. – Jonesey95 (talk) 00:42, 3 July 2026 (UTC)Reply

About once a year since 2019, I have looked at the error count in Template space and thought "Will we ever get to zero? Probably not. All of these errors are difficult to fix." I poke through the existing errors, as many of you have probably done multiple times, and I revisit the frustrating, enigmatic cases that I couldn't figure out the previous year, or that have cropped up in the previous year. I am usually able to fix or work around some of them.

In 2021, there were 800 errors in Template space, and I despaired of going lower. In 2022, we had somehow gotten down to 272 errors. A year later, we were down to 152. And in March 2026, after a few more yearly battles with painful code interpretation and deliberate error cases, we were down to 17.

I had something important to do today, so instead of doing it, I looked at Linter errors in Template space, with no real hope of fixing them. My creative juices must have been flowing, though, because I was able to get the entire list knocked off. We have ZERO Linter errors in Template space, as of this writing. Enjoy it, if only temporarily! – Jonesey95 (talk) 20:59, 11 July 2026 (UTC)Reply

That is awesome. Well done Jonesey. Let's keep it that way! Primefac (talk) 21:19, 11 July 2026 (UTC)Reply

Is there any template or functional method on here that would intelligently append a table or div tag closer to the end of a page in the fashion of

{{table opener}}
{{magic footer}}
...
page content

so that it displays as

... page content ... [end of page]

without physically placing something at the end so that pages are clear of unclosed errors, but doesn't interfere with people adding new content at the end of a page?

I'm seeing a pattern of people in Wikiprojects and User talk pages who have some page decoration added that are unclosed. While it looks nice, it's also going to be an unsolvable unclosed tables/div tags situation since sticking a "edit above this line comment with a [table footer]" at the end of the page is impracticable with active pages.

Logic-wise it would be something like a checkloop of "Determine line magic footer is placed on. Set value as X. Check if content exists after line X. If yes, increment X=X+1 and check again (loop). If no (exit condition), add table at currently evaluated line."

Does this idea exist or is this something that would be possible to create if not? Or is there a way with if functions to achieve this?

Just thinking out loud. Zinnober9 (talk) 21:12, 16 July 2026 (UTC)Reply

No such thing exists, as far as I know. I think there was a previous discussion here or on Mediawiki or Phabricator about how to work around this issue, and there is no current way to do it. – Jonesey95 (talk) 21:17, 16 July 2026 (UTC)Reply

Missed this reply somehow. That's disappointing that there isn't something since people seem to enjoy creating these situations. Hopefully later on this changes and something can be figured out so these can be cleared. Thanks for the reply. Zinnober9 (talk) 01:00, 28 July 2026 (UTC)Reply

Links in links reports a problem with User talk:Porterjoh/Archive 1. But, there's nothing locally wrong with the spot identified. This seems to be one of those Real-problem-is-elsewhere issues. If you delete everything up to this table:

{| cellspacing="20" width=90% style="margin:auto; background-color:transparent;"
|<!-- -->
{{Signpost/item|2|1|2008-04-07|April Fools'|April Fools' pranks result in temporary blocks for six admins}}
{{Signpost/item|2|2|2008-04-07|WikiWorld|WikiWorld: "Apples and oranges"}}
{{Signpost/item|2|3|2008-04-07|News and notes|News and notes: 100 x 5,000, milestones}}
{{Signpost/item|2|4|2008-04-07|In the news|Wikipedia in the News}}
{{Signpost/item|2|5|2008-04-07|Dispatches|Dispatches: Reviewers achieving excellence}}
{{Signpost/item|2|6|2008-04-07|Features and admins|Features and admins}}
{{Signpost/item|2|7|2008-04-07|Technology report|Bugs, Repairs, and Internal Operational News}}
{{Signpost/item|2|8|2008-04-07|Arbitration report|The Report on Lengthy Litigation}}
<!-- -->
|}

the Links in links error is still there. If you delete that table too, the links in links error goes away. If you copy the entire page into ExpandTemplates, the links in links error is not there. That's what I have so far, and others can take it from there. —Anomalocaris (talk) 22:09, 23 July 2026 (UTC)Reply

I'm almost certain that it's due to the postsize exceeded issue, as the offending section was clean on the user's talk page prior to the move, and was clean in my sandbox preview. I think that after the point of exceeding postsize, it defaults to showing the template's wikilink. I've also seen this error occur on other pages that have tripped into postsize territory*. I looked at this briefly earlier, and almost made changes to make an archive 2, move about 10k over (roughly the last three edits by Lowercase sigmabot III), and adjust their archivebot settings from 300k to 250k to keep this from reoccuring, but I wasn't confident that I'd get it right in one go. The reasons I hesitated and have not were that today's bot edit was the only one to create this issue, so wasn't sure if going back three edits worth was too invasive, and I wasn't 100% sure I'd get the archiving script to connect with an archive 2 on the first go since I haven't created or used it. A "knowing what it does and telling it to do what it does" hesitancy.

 *Wikipedia:Selected anniversaries/All regularly trips the wikilink error randomly due to the overflow and breakage of templates after Sept 18th. I've been considering how much WP:BOLD I want to step into from possibly going ahead and splitting it into a Jan-Jun and Jul-Dec (the WP:OTD/A shortcut link is mainly why I haven't), or if that needs to go to a discussion, but that's for another day). Zinnober9 (talk) 23:19, 23 July 2026 (UTC)Reply

I boldly split User talk:Porterjoh/Archive 1 to Archive 2 and left a note on the editor's talk page. PEIS is a PITA and, in my experience, is non-deterministic. Pages sometimes seem to save OK and sometimes exceed the limit. – Jonesey95 (talk) 05:07, 24 July 2026 (UTC)Reply

Excellent, thanks! And yes, I didn't mean to say PEIS always causes the wikilink error, just that it can cause it and was likely in this case. Zinnober9 (talk) 15:11, 24 July 2026 (UTC)Reply

Any hunches regarding the div-span-flip errors that appeared this afternoon and appear related to {{Maplink}}? I don't see any obvious changes to the template or underlying module, and I believe the files being fed into the Maplink templates still exist despite the warnings to the contrary. Just another Thursday? — SirOlgen (talk) 03:37, 24 July 2026 (UTC)Reply

Regarding the warnings I mentioned (e.g. the District line article reflects maplink: Title "District line.map" is not a valid map data page), I now realize I misinterpreted that to suggest the file didn't exist (which it does). Perhaps the format expectations for the .map files has changed? SirOlgen (talk) 03:56, 24 July 2026 (UTC)Reply

I posted on WP:VPT to see if anyone has insight into these error messages, which are present in 900+ articles. I think they are new. The ones on the "Line" articles appear to come from Module:Mapframe's |display=title option, which appears to wrap its output in span tags. This new error message, which may come from the MediaWiki software itself, may be wrapped in div tags, which would cause a span/div Linter issue.

Let's see if VPT gives us any insight. This may be a MediaWiki bug introduced in a code update. Code updates show up at the English Wikipedia on Thursdays. [Update: I found T433008, a bug filed by someone from the German Wikipedia. The de.WP folks do not tolerate Linter errors, so I think we'll see it fixed soon.] – Jonesey95 (talk) 05:35, 24 July 2026 (UTC)Reply

Noticed an interesting tidbit on this week's Tech News:

• From now on, wikis can restrict editing in the "User" namespace to only the page owner and certain user groups. Read the configuration documentation to learn more.

If en.wikipedia were to implement this restriction, is it safe to assume there would need to be a Lint-related user group created in order to clear errors from the User space? — SirOlgen (talk) 19:44, 27 July 2026 (UTC)Reply

Yes, although consensus to implement the config and the group would be required. I imagine it would operate like .css/.js pages with interface admins, though I believe it'd do more damage than good in our case, since it's an extra hoop for anyone who wants to fix lint errors in userspace. Tenshi! (Talk page) 19:53, 27 July 2026 (UTC)Reply

I have posted a note on WP:VPT to ask anyone who sees a proposal to do this on the English Wikipedia to post on VPT about that discussion. I imagine that there will be pushback of various kinds to creating yet another user group, but restricting such editing to e.g. extended confirmed users might get support. – Jonesey95 (talk) 22:22, 27 July 2026 (UTC)Reply

Considering 17% of remaining countable errors are in User namespace, certainly something to keep an eye one. EC's a decent level if this is enabled and doesn't become a separate group. If it is enabled as a separate group, I would certainly look into applying. Zinnober9 (talk) 00:55, 28 July 2026 (UTC)Reply

Implementing this on enwiki will also impact other maintenance activities, for example the removal of spam from user pages. —Bruce1ee^talk 08:33, 28 July 2026 (UTC)Reply

... and user pages not adhering to WP:UP in general. —Bruce1ee^talk 11:18, 28 July 2026 (UTC)Reply

Likely we'd set a very low bar for that -- perhaps as low as extendedconfirmed... 13:36, 28 July 2026 (UTC) — xaosflux ^Talk 13:36, 28 July 2026 (UTC)Reply

Thanks, that will help. —Bruce1ee^talk 13:39, 28 July 2026 (UTC)Reply

Multiline table in list lint used to cause an indent leak. For this reason, I often used an edit summary like {{db-reason}} unindented to avoid Multiline table in list lint error and indent leak to end of page. For awhile now, I've noticed that Multiline table in list lint lint errors don't always cause an indent leak, and now I believe they never cause an indent leak. See, for example, Old revision of User talk:SoniaAmerica, which I fixed 14 minutes later in an edit with the above edit summary, but now the old version doesn't have an indent leak. So, does Multiline table in list still need to be a lint error? —Anomalocaris (talk) 18:39, 3 August 2026 (UTC)Reply

100% keep this error category. Navboxes and most div based templates that are on a bulleted line trigger this error, and I clear a few of these each day. Zinnober9 (talk) 19:51, 3 August 2026 (UTC)Reply

I know we're still seeing several of these errors every day. The question is, does this error cause any actual problem? —Anomalocaris (talk) 04:04, 4 August 2026 (UTC)Reply

Display issues. Causes the show/hide button to move and appear above the navbox title text (and forcing the title text to a new line) with both to be oddly not quite centered. And causes the box to be a bulleted indent width narrower, which is an inconsistent display to the others. In this example, I bulleted the 2007 season (collapsed in the Championship box) and MLB's boxes in the second grouping, and while they function, they don't don't display identically to their companions. Zinnober9 (talk) 04:48, 4 August 2026 (UTC)Reply

Okay, it's still an error! —Anomalocaris (talk) 05:50, 4 August 2026 (UTC)Reply

I keep seeing users turning {{Use dmy dates}} / {{Use mdy dates}} into section headers, like this, which generates an "Empty headings" lint error. I don't believe the user did this deliberately. In this case VisualEditor was used, is that the problem? —Bruce1ee^talk 10:28, 12 August 2026 (UTC)Reply

I would have just reverted that very poorly formatted edit and let them come back and redo it. And yes, the Visual Editor is probably in part to blame; it allows editors to make all sorts of mistakes that non-VE editors do not make. – Jonesey95 (talk) 19:57, 12 August 2026 (UTC)Reply