Update rfcbot with a replacement anchor template

Hi @Legoktm, Happy new year! I created an issue and PR to implement WhatamIdoing's suggested improvement above this comment. I don't have an environment set up to test though. (Posting here for visibility, apologies if it's spam, also completely understand if including this change is not something you are up for, Based on this discussion near the linked comment, we'd like to keep the rfcId in the section text after the rfc template is removed. Dw31415 (talk) 14:28, 1 January 2026 (UTC)

Thanks @Dw31415, I made a small fix and deployed the change. We'll see how it goes when an RFC expires. (fyi @Redrose64) Legoktm (talk) 03:03, 3 January 2026 (UTC)
Thank you! I’ll try to get a PHP environment set up before requesting any more changes. Dw31415 (talk) 03:46, 3 January 2026 (UTC)
Honestly I'm very overdue to port this to Rust. I don't know if that's a better language for you or not. Legoktm (talk) 16:35, 3 January 2026 (UTC)
I’d love to learn Rust so I’d be interested in collaborating on that. I’ve been spending a bunch of time over the holidays on the RfC bot ideas from Marshall and Whatanmidoing. I’ll have to see what’s realistic after normal life resumes. Dw31415 (talk) 17:27, 3 January 2026 (UTC)
Success! --Redrose64 🦌 (talk) 10:09, 3 January 2026 (UTC)
Woot. I made a small change to add a newline after the anchor template so it doesn't get merged onto the same line like in this edit. Legoktm (talk) 16:03, 3 January 2026 (UTC)

RFC database now public

Probably most of interest to @Redrose64 and @Dw31415...the RFC database is now public and named: s51043__rfcbot_p. It can be queried from Quarry (example) or directly on the server by any Toolforge user. Maybe it is interesting to others, but now I'm no longer the only person with access to it.

Possibly more importantly, while moving the database over, I noticed that it was using the latin1 charset, instead of utf8mb4!!! That would be a pretty solid (and slightly embarrassing) explanation for why it couldn't handle unicode characters in titles properly! So I've switched it over to utf8mb4🤞. (If that causes any issues I have a pre-charset conversion backup.) Legoktm (talk) 04:21, 4 January 2026 (UTC)

Aha! Maybe that will eliminate the need to create redirects like Talk:Siege of Neam? Citadel. --Redrose64 🦌 (talk) 17:52, 4 January 2026 (UTC)
Thanks! I downloaded the full list: https://quarry.wmcloud.org/query/100675# Dw31415 (talk) 20:17, 4 January 2026 (UTC)

Looping on page

Is Legobot ignoring certain errors when checking before saving?

If I recall correctly, Legobot checks its proposed revisions before saving to see if there are any remaining Linter errors. Is it still doing that? I support the methodology; I'm asking because of the follow-up question below.

If it is doing that, is it ignoring duplicate id and background color errors? It probably should, since those are basically down-the-road errors that don't need to be fixed right now. They are also often caused by templates, so editing a given page that transcludes one of those templates won't fix the errors on that page. Am I making sense? Basically, if Legobot is checking for remaining errors, it should check only for those currently listed on the Firefly table. – Jonesey95 (talk) 18:10, 31 December 2025 (UTC)

Correct, it does check there are no more lint errors, and doesn't ignore any type. Matrix mentioned the same thing regarding the dark mode/background color ones. I haven't had the chance to fully read up on it but I was also leaning that way.
I think the duplicate ID ones Legobot shouldn't ignore, since it's using an HTML parser and that's invalid HTML. For ones where the duplication isn't via a template, I was wondering if we could just auto-renumber them, e.g. id="Foo", id="Foo2", id="Foo3", etc. Legoktm (talk) 03:15, 2 January 2026 (UTC)
The problem with duplicate ids is that many (most?) of them are caused by CS1 citation templates, and there is no desire at all to change the behavior of those templates to fix what is seen as a non-problem. And the problem with night mode errors, as I said above, is that many of them are caused by templates and can't be resolved in the wikitext of a given page. I'd be curious to know how many "Publish" operations are skipped solely because there are night mode or duplicate id errors remaining on a page. It seems a shame to force humans to perform bot-fixable edits.
Does Legobot at least ignore the "hidden" Linter errors like "large-tables" (id 20) and "missing-image-alt-text" (id 23)? Those are not reported in "Page information", primarily because the WMF developers are still working out the kinks to figure out whether the tracking of those conditions even makes sense to perform. – Jonesey95 (talk) 04:53, 2 January 2026 (UTC)
I agree with Jonesey here, the bot should ignore the duplicate id and background color as those aren't things we can really fix now. They require much more investigation and discussion (and code changes) so holding off on fixing fixable issues for them isn't really helpful to the project (and won't be a spam on watchlist as again, no fix for those two issues is on the current radar). Gonnym (talk) 19:51, 2 January 2026 (UTC)
@Jonesey95, @Gonnym: Yes, the hidden Linter error categories are ignored because they just don't appear in the API output.
As for numbers, I created a new webpage (warning: large page, will take some time to load) that groups all the pending edits by which errors are preventing it. In short: duplicate-ids is blocking 213 pages, night mode is 15k pages, duplicate-ids + night mode is 503 pages.
I do want to look at the duplicate-ids problem a bit more, e.g. this one seems trivially fixable by a bot just adjusting one of the IDs. My spot checking is that the majority are from templates, but I'm guessing there's some minority not from templates and just bad copy-paste issues. Legoktm (talk) 05:25, 4 January 2026 (UTC)
Fascinating list. I find it odd that it lists so many html5 misnesting errors that aren't actually present. We eliminated those errors from all of en.WP long ago. [edited to add: I think I get it, after working on some of the pages in the list: The html5 misnesting errors are present after Legobot applies its fixes. It is happening to me as well. They usually start out as regular misnesting errors, but the parser sees them differently after some wikitext changes are applied.] – Jonesey95 (talk) 14:49, 4 January 2026 (UTC)
Hmm, I need to look at this closer. In e.g. this page it's turning a <font> into a <span> instead of a <div>, which is causing the html5-misnesting issue...but I already have code to check for block elements, which should have it use a div. Legoktm (talk) 20:12, 4 January 2026 (UTC)
Why does it want to change [[Clay Felker]] to [[Clay Felker|<span style="color: yellow;">Clay Felker</span>]]? Gonnym (talk) 10:02, 5 January 2026 (UTC)
There's a <font size="+3" color="yellow" face="Comic Sans MS">...</font> element enclosing the whole of the page. All child elements inherit the size and face, but not all inherit the colour - a notable case being the <a>...</a> element (because clickable links should be distinguishable from plain text by their colours). Some years ago, a previous version of MediaWiki, upon encountering a construct like
<font color="yellow">[[Clay Felker]]</font>
would twist this around and emit HTML like
<a href="/wiki/Clay_Felker" title="Clay Felker"><span style="color:yellow;">Clay Felker</span></a>
MediaWiki no longer does that, which is why we launched the good ship delinter some years back. It's not just for picking up unclosed inline elements. --Redrose64 🦌 (talk) 12:12, 5 January 2026 (UTC)
Filed T415233, which from spot checking will unblock fixes on a thousand-ish pages once resolved. Legoktm (talk) 04:42, 22 January 2026 (UTC)
@Jonesey95, @Gonnym: Legobot is now ignoring dark mode errors. Legoktm (talk) 03:52, 21 January 2026 (UTC)
Super. That should help a lot, especially on discussion pages. – Jonesey95 (talk) 05:31, 21 January 2026 (UTC)
Amazing, thanks! Gonnym (talk) 18:44, 21 January 2026 (UTC)

Should legobot be modifying the User page of an editor?

Legobot modified my user page this morning. This violates the general convention of not modifying an editor's User page unless you are the owner. If my userpage somehow has a catastrophic effect on the functioning of wikipedia by using obsolete html tags - one day taking down the entire site for days because of my malfeasance - then sure. Otherwise, I wear my extraordinarily weak capabilities with html tags as a badge of honor. If my page alone breaks from this gross error, well then, I can live with it, and will likely attend to it within a few years.

But a little more seriously - is there any actual harm that can derive from this, other than my user page someday appearing wonky? cheers. anastrophe, an editor he is. 19:26, 21 February 2026 (UTC)

That is a bit surprising. You can opt out of bots with Template:Nobots Dw31415 (talk) 19:59, 21 February 2026 (UTC)
That’s generally speaking. I can’t promise Legobot respects that or there is something about your previous edit that is potentially harmful Dw31415 (talk) 20:01, 21 February 2026 (UTC)
Thanks! I'll give it a whirl. cheers. anastrophe, an editor he is. 20:08, 21 February 2026 (UTC)
Bots and other editors are allowed to edit pages in User space to fix problems. See WP:UOWN, including except when it is likely edits are expected and/or will be helpful. The bot clearly stated what it was doing and why, and linked to a page with further explanations that explain why such edits are helpful. The bot did not change the appearance of the page, and it fixed an error that appeared in the "Page information" page for your user page. This bot and other bots have cleaned up millions of these errors in every namespace. I hope that explanation helps you understand what may have been a surprising edit. – Jonesey95 (talk) 21:08, 21 February 2026 (UTC)
Yes, I read the edit summary it provided. I linked to WP:UOWN in my first message. I was specifically referencing "Bots and other users may edit pages in your user space or leave messages for you, though by convention others will not usually edit your user page itself, other than (rarely) to address significant concerns or place project-related tags."
'Helpful' is in the eye of the beholder with non-critical changes, in my opinion. But, whatever. I've added nobots, hopefully it will be another twenty years before a bot decides to fix my user page. cheers. anastrophe, an editor he is. 21:35, 21 February 2026 (UTC)
p.s. please don’t trust my answer. I’ve just been following Legobot for a while and don’t know what I’m talking about. Sorry for over stepping Dw31415 (talk) 21:40, 21 February 2026 (UTC)
Hi @Anastrophe. As mentioned, the nobots system will cause Legobot to skip your userpage. Can you explain why you want to keep using <font> tags?
In addition to the links Jonesey provided, I've also written an essay that explains why cleaning this up is a good thing. To answer your point, no, it's unlikely anything bad will happen from continuing to use obsolete HTML tags, but things could be much much better if we got rid of them and could rely on pages being clean of any lint errors. Legoktm (talk) 22:42, 21 February 2026 (UTC)
I think I already explained my rationale; I'm an obstinate bastard! If someday down the road the HTML tags become non-functional and my page (mildly in the exteme) 'breaks', i'll fix them then. This isn't a big deal; it was just a bit of a surprise, because the only previous edits by any entities other than myself had been by vandals, and those who smacked down those vandals. To be absolutely crystal clear, I know this wasn't vandalism and I didn't even slightly consider that it was vandalism. Just a surprise. cheers. anastrophe, an editor he is. 22:52, 21 February 2026 (UTC)
@Anastrophe: that's pretty disappointing to hear. If someone crossed paths with a project you'd been working on for a decade, undid your work and when asked why, merely said "I'm an obstinate bastard!" I think you'd be justifiably upset.
Wikipedia is a collaborative project and we all make compromises for its betterment; I hope you'll reconsider. Legoktm (talk) 23:12, 21 February 2026 (UTC)
I'm unclear how I "undid your work". I did not. My user page is my own. It's my choice to configure it within the limits of policy, which I have done, and it's my choice what changes I allow others to make (which is none). The lack of compliance with what Legobot makes its decisions by is not critical, nor meaningful, to my userpage. I did not "Merely say 'I'm an obstinate bastard!'" (which was supposed to be lighthearted). I said I had already explained it. Please reread my initial post.
I'm sorry you're taking this personally, but legobot's usefulness, in my opinion, is in improving the public encyclopedia. That it does. My user page is irrelevant to the public encyclopedia. It should not matter what I do there, within the constraints of policy. I have opted out of the bot. Everybody should be happy. cheers. anastrophe, an editor he is. 00:29, 22 February 2026 (UTC)
In addition, there was already an RfC on this which validated this process. You reverting a bot, will only cause additional editors to redo this. Gonnym (talk) 08:54, 22 February 2026 (UTC)
Very interesting. Reviewed the deprecated tags page. It seemed a little wishy-washy about HTML5. I’d be interested to read the RfC and would appreciate any tips on finding it. Dw31415 (talk) 09:07, 22 February 2026 (UTC)
@Anastrophe, have you read about the evils of the font tag and the blessings of HTML5? Dw31415 (talk) 09:09, 22 February 2026 (UTC)
I'm uninterested in such matters, so no. cheers. anastrophe, an editor he is. 09:55, 22 February 2026 (UTC)
What do you make of @Gonnym‘s comment that other editors can (and should) clean up your tags? I guess it should be clarified if you have right to your HTML4 or are expecting to get on the 5 train. I’ts an odd hill to defend, especially if it’s not out of a deeply held conviction of the html spec Dw31415 (talk) 10:03, 22 February 2026 (UTC)
Even in HTML 4, the font element was deprecated. Some of the most significant features of HTML 4 as compared to HTML 3.2 were the class=, id= and style= attributes. Alongside these was the full introduction of the <style>...</style> element (having merely been proposed but not implemented in 3.2). Taken together with the existing <link /> element, these features allow CSS styling to be incorporated into HTML documents when rendered by the browser. As stated in the CSS 2.1 spec: By separating the presentation style of documents from the content of documents, CSS 2.1 simplifies Web authoring and site maintenance. --Redrose64 🌹 (talk) 23:12, 22 February 2026 (UTC)
Thanks @Redrose64, do you know if it’s consensus the the OP is entitled to his font tags or if other editors are encouraged to make the same edit Legobot made? Personally, I just ask because I’m curious. Dw31415 (talk) 02:53, 23 February 2026 (UTC)
I might consider buying a T-Shirt with “I already explained my rationale; I'm an obstinate bastard!” Let me know where to send $14.95 and a self-addressed and stamped envelope ;-) Joking aside, I’ll just express gratitude to the folks keeping Wikipedia clean and tidy and allowing us to drop support for IE-9. Dw31415 (talk) 23:50, 21 February 2026 (UTC)

Templates stopped working on a user talk page while clearing lint errors

The bot removed the use of active templates while clearing up lint errors on my user talkpage - this has been reverted. Link to diff Nightfury 22:20, 24 February 2026 (UTC)

(talk page stalker) Nightfury, that is a strange one. I have fixed the bot's edit for you, since the font tags did need to be updated. I believe that the page is working as intended now. I'll leave the explanation of the edit to the bot operator. – Jonesey95 (talk) 00:02, 25 February 2026 (UTC)
@Nightfury: sorry about that, it looks like an edge case that I didn't realize Parsoid treated differently. I've put in a temporary fix to have it skip pages if it finds that condition until I get a proper fix working. Thanks for letting me know! Legoktm (talk) 03:39, 25 February 2026 (UTC)

Another pass at pages with strike tags

It looks like the bot could take another pass at articles with strike tags. I'm seeing Talk:Electoral system/Archive 6, Talk:Diver navigation, Talk:Diving reflex and more that seem like the bot would be able to fix. I'm using this simple query to find them. There are currently 3,686 pages with strike tags; it would be great if the bot could cut that down to the point where we could use User:Jonesey95/Pages with many strike tags to eliminate the rest. – Jonesey95 (talk) 00:21, 25 February 2026 (UTC)

The main limitation Legobot has by using Parsoid HTML to make changes is that it can't edit through templates, because even with VisualEditor, templates are edited as wikitext. So in Electoral system, the strike tag is inside archivetop/archivebottom templates, and then for Diver navigation and Diving reflex, there are raw #if parser functions surrounding the B-class review which is where the strike tag is. :/
At some point I'll need to figure out how to overcome this limitation by editing the wikitext directly but really haven't figured out how I want to go about that. Legoktm (talk) 03:15, 25 February 2026 (UTC)
Oof, that's a big limitation. The LintHint script is subject to a similar issue in that it will highlight a big block (like a block wrapped in atop/abot templates) as having a Linter error, making it more difficult to pinpoint the error. I will probably forget about this limitation on your bot and ask you about it again, for which I ask your forbearance in advance. I hope that you can find a way around it. – Jonesey95 (talk) 04:22, 25 February 2026 (UTC)