Wikipedia:Bots/Requests for approval/ParamBot

ParamBot

• (BRFA
• Approved BRFAs
• talk
• contribs
• count
• SUL
• logs
• page moves
• block log
• rights log
• flag)

Operators: Phuzion (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search) & Zackmann08 (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 03:05, Thursday, October 1, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python, Pywikibot, mwparserfromhell

Source code available: https://github.com/phuzion/ParamBot

Function overview: Automatically renames deprecated infobox parameters that have come back into articles to their current names, using approved rules

Links to relevant discussions (where appropriate): Wikipedia:Bot requests#Bot to regularly check for restored deprecated parameters

Edit period(s): Daily

Estimated number of pages affected: Varies, likely 5-100/day

Exclusion compliant (Yes/No): Yes

Already has a bot flag (Yes/No): No

Function details: This request is for the approval of a new bot, ParamBot, that @Zackmann08 and I have been working on for the past few days.

Before describing what this bot does, allow me to paint a picture of a relatively common issue that we see in the parameter cleanup world.

1. An infobox template has a parameter deprecated and replaced with a new parameter, e.g. |imagesize= → |image_size=, using a "Deprecated Parameters" category for tracking purposes. The old parameter is still supported, but throws an in-preview warning to editors.
2. The "Deprecated Parameters" category is cleaned out by bots such as User:PrimeBOT, User:ZackBot and User:PhuzBot, as well as manual work by users with WP:AWB and other tools.
3. Once the "Deprecated Parameters" category is cleaned up, the deprecated parameters code is removed from the infobox template, and the old parameter no longer works. Uses of the old parameter will result in the article getting placed into an "Unknown Parameters" category (assuming it exists), separate from the "Deprecated Parameters" category.
4. Well-intentioned editors make changes to the articles with said infobox, not realizing that |imagesize= is now |image_size=. Their edit does not actually do what they expect it to do, and puts the page into an “Unknown Parameters” maintenance category.

Some of the legitimate reasons that an editor might insert a parameter name that is not valid include:

• Reverting vandalism/LLM/Socks
• Copying Infoboxes from other Wikipedia languages
• Old-hat editors that have 20 years of experience writing |imagesize= rather than |image_size=

All of these are useful contributions that shouldn’t just be reverted. This is where ParamBot comes in.

ParamBot is a Pywikibot bot that runs on Toolforge. It is given a curated list of parameter replacements, most frequently pulled from historical uses of {{#invoke:Check for deprecated parameters}} in the infobox template’s edit history. This list tells the bot a list of unknown parameter categories to check, and what changes to make. As it scans through each category, it compares its list of “old parameters” to the list of parameters in the infobox at the time of the run. If it finds any of the “old parameters” that it is supposed to replace, it replaces it with the new parameter. The list of replacements is human-curated. We are not blindly pulling from the history of the template.

Additionally, a rule can be written to completely delete a parameter, for instance removing |nationality= from an infobox where that parameter was entirely deprecated with no replacement.

Once it makes the edits, a report is generated at User:ParamBot/Report that gives a summary of what it did, and any configuration errors it found. Included in this report are a list of articles that need human review, articles it skipped and the reason for the skip, a list of rules pages that have issues, and notes such as rules waiting for a template to drop an old name.

The rules are located at User:ParamBot/Rules. This page is template editor protected, and in order to have a rule take effect, the rule must be listed on the page, as well as its revision ID. While anyone can contribute to the project by creating a rules file (as subpages of the Rules page can be edited and created by anyone), this requirement to list the rule with its revision keeps the bot from being potentially abused by vandals and ne’er do wells. Further edits to the approved rules will not automatically take place, the appropriate revision ID needs to be inserted for the bot to use the updated copy. If the revision on the Rules page is out of date, the bot will continue to use the old revision until the revision ID is updated.

The bot will not edit an article it has edited in the past 30 days; it checks its own recent edits before every run.

Some of the checks that the bot does include:

• If the "old parameter" is still accepted in the template, that particular parameter of that rule is ignored.
• If the "new parameter" is not yet accepted in the template, that particular parameter of the rule is ignored.
• If both the old and new parameter are present in the article's infobox, the bot intelligently handles the scenario according to this table.
• The bot waits at least 10 seconds between edits, and sends maxlag=5 so it backs off when servers are lagging. We have a --max-edits N argument that we can use to limit the number of edits we will perform in a single run.
• It never makes an edit that only changes empty parameters.
• It never edits pages outside of Article namespace (except for its own Report page). It does not touch drafts, sandboxes, user pages, etc.
• The bot links to its FAQ in every article edit summary, as well as the rule and revision that triggered the edit.
• It abides by {{nobots}} and {{bots}}, and has an Emergency Stop button that anyone can trigger.
• Any time the bot edits more than 500 pages in a single run, it leaves a note on the Report page to alert the bot operators.

During development, I have been running the bot locally, and copy-pasting the output of the reports to User:ParamBot/Report, but I have recently turned on "Report Only" mode, which does not edit articles, but does update the Report page. This is permitted under WP:BOTUSERSPACE, as the bot only edits a subpage of its own userpage.

As I mentioned in my original comment announcing this bot over at WP:BOTREQ, this was coded with the assistance of an AI model, particularly Claude Opus 5.5. I have thoroughly reviewed every single hypothetical edit this bot would have made and any mistakes that were found were immediately addressed. As of the filing of this BRFA, I know of no outstanding bugs in the code.

As for edit volume, this is going to vary depending on the number of rules we write. There may be some days where the bot makes zero edits. There may be days where the bot has hundreds or even thousands of edits to perform. Currently, the bot is limited to 1 edit per 10 seconds, and a run will time out after 20 hours. But as of right now, I don't think that we will even come remotely close to that time limit. In testing with 87 pages comprising 1800+ rules, we are seeing 5-10 hypothetical edits per run. For a trial, we would suggest 50 edits, at 5-10 per run. This will take approximately a week at the current pace.

As always, please let us know if there are any questions!

Discussion

Just want to build on what Phuzion has said. This bot has been one I've been kicking around in my head for months. A number of users (some of whom I'll ping below) have expressed interest in this type of bot being created. The need is absolutely there. Phuzion has done a killer job over the last few days building this code base. Together we have been thoroughly testing this with dozens and dozens of data sets. More testing is absolutely needed and will be performed, but I am highly confident that this bot will perform to everyone's expecations! We both stand ready to address any questions or concerns that anyone may have.

Courtesy pings: ChompyTheGogoat, grapesurgeon, Gnomingstuff, Chipmunkdavis, Dionysodorus, DraconicDark, Kowal2701, M kuhner, Knypster, gurkubondinn, Johnuniq, Drmies -Zackmann (^{Talk to me}/_{What I been doing}) 03:13, 1 October 2026 (UTC)

So happy. Just had to repair another "alma_mater"; would love to stop doing that. Thank you both. M kuhner (talk) 03:18, 1 October 2026 (UTC)

Full disclosure... |alma_mater= will take some time to fully be deprecated, that merge with |education= is a complicated one as the 2 fields often co-exist in a way that makes a bot-run very difficult to achieve. But ultimately that will absolutely be handled here by ParamBot! Zackmann (^{Talk to me}/_{What I been doing}) 03:25, 1 October 2026 (UTC)

thank you so much, I look forward to never having to type custom data or whatever it is again Gnomingstuff (talk) 03:56, 1 October 2026 (UTC)

Fixing these sorts of things is the type of task a bot would be helpful for. There are other reasons old params might appear, like code being copied from an old revision (or a current revision with old code). I have some caution from past discussions around the accessdate->access-date conversion, so a month between hitting the same article seems sensible. There is the larger question of how outdated code should be before we expect it to break. Viewing very old revisions, you expect to see a bunch of broken templates, but more recent revisions may be more regularly checked for various reasons. The bot report sounds like it can help identify a time when a deprecated parameter stopped being used, and thus inform later removals from code. CMD (talk) 03:57, 1 October 2026 (UTC)

actually I do have a question -- when you say It never makes an edit that only changes empty parameters does that mean that if the deprecated parameters were already empty, then those still need to be manually changed? Gnomingstuff (talk) 03:58, 1 October 2026 (UTC)

@Gnomingstuff: This is a great question. So the important thing to remember is that the actual deprecation of parameters and what this bot does are 2 separate tasks. During the deprecation (mostly being done these days by ZackBot) I do take on empty parameters. However, there is an ongoing debate about whether this is considered a WP:COSMETICEDIT. So, the way we have setup ParamBot is that it will only change parameters that have a value assigned to them, with one exception! If there are (For example) 2 bad parameters on the page. One with a value and one without, the bot will change both (I.E. fix the blank while it is fixing the other). It will not, however, fix a page that only has a blank bad parameter. What is more, this is unlikely to show up anywhere anyway as Check for unknown parameters almost universally ignores blank params. Zackmann (^{Talk to me}/_{What I been doing}) 04:08, 1 October 2026 (UTC)

yeah, and I assume that if someone comes along and populates a previously-empty deprecated parameter, the bot will deal with it in its next run. Are there going to be lots of unknown parameters that aren't currently at /Rules that will get added once they're found in the wild, and will there still be the odd unknown parameter that will need to be done manually (like, how many times does one need to pop up to necessitate adding it to /Rules, or will it be all ones that aren't clearly nonsense)? (also, just making sure, does this basically make WP:RDP defunct and mean editors can ignore the Preview warnings when this goes live? If so, is it worth removing the Preview warnings for old parameters in Rules so people don't spend time manually doing it?) Kowal2701 (talk, contribs) 12:46, 1 October 2026 (UTC)

The purpose of this bot is to handle deprecated parameters after the deprecation process is complete. WP:RDP depends on {{#invoke:Check for deprecated parameters}} being present in the template. Eventually, after some time, the support for old parameters is removed, as is the deprecation code. Once this happens, a rule is written, and ParamBot will begin monitoring that template's unknown parameters category.

WP:RDP will remain useful, as there is still plenty of work to be done during the deprecation period. phuzion (talk) 17:01, 1 October 2026 (UTC)

This looks like a great solution. I do have a few questions/comments though:

The restriction on the bot re-editing a page within 30 days seems a little long, in my opinion. One of the main purposes listed in the initial proposal was to fix removed parameters that were re-added to a page from reverting a LLM/vandal/sock. Assuming the initial parameter fix and the revert happen within 24 hours, the bot will wait nearly 30 days to fix the broken parameter, if I am understanding this right.

Also, I was just wondering why the bot begins editing after the initial parameter fixes, versus allowing it to first take care of any basic parameter replacements it could before any AWB runs are set up. I’d personally rather see as many of the edits as possible come from a single standardized bot, instead of coming from various AWB runs.

Anyways, I am excited to see this in action! FlammablePizza (talk / contrib) 04:01, 1 October 2026 (UTC)

@FlammablePizza: valid points.

1. The 30 day restriction is something we have gone back and forth on. 30 is where we are at right now, but that is absolutely NOT set in stone and can easily be changed as part of this BRFA. Perhaps 15 days is better? We just want to make sure we avoid a bot editwaring....
2. As to your second question about why the bot begins editing after the initial parameter fixes. The reason for this is that there are currently 3 approved bots taking on deprecated parameters.... So there is less of an urgent need for that at present. That being said, there is absolutely the possibility of a task 2 for ParamBot down the road! Something Phuzion and I have already discussed. BUT, one thing at a time.... Currently no bots are taking on regressions the way this task for ParamBot would, so that is the primary focus at present!

- Zackmann (^{Talk to me}/_{What I been doing}) 04:12, 1 October 2026 (UTC)

Maybe it could keep the 30-day restriction to prevent edit warring while providing an exception (or shorter cooldown) for instances where both:

1. The bot’s previous edit was reverted

2. The edit immediately preceding that one was reverted AND was not created by the bot.

Honestly, I doubt this would be worth the time and technical resources though.

Also, perfectly understandable that this task is the focus for now anyways. As I said earlier, I look forward to seeing it at work! FlammablePizza (talk / contrib) 05:04, 1 October 2026 (UTC)

Right now, if the bot were to make an edit, and it were to be reverted, that article would show up on the Report page under the "Not edited" section. The fix could then be handled by a human editor. The idea with the 30-day restriction is to eliminate the possibility that the bot could get into an edit war. I do recognize that this might be a touch overkill, but I wanted to err on the side of caution here.

The cooloff period and a bunch of other decisions are all configurable, as can be seen in the config file. If we decide to make changes to the edit frequency or the cooloff period, that can be done with minimal needed changes. But I think we're talking about a hypothetical that might, maybe, possibly happen a handful of times a month. If it becomes necessary to revisit this, we can. phuzion (talk) 13:27, 1 October 2026 (UTC)

Support! My nudge would be to have it run weekly and skip the same page restriction. For CutlassBot (ATODAY removal) there were 100s of redo’s from slop-reverts and only 1 targeted revert (after 89,000 edits). For the edit war case, where the parameter really should be removed from the target list, it’s better to get that sorted early rather than wait 30 days. So if you’ve already built the 30 day feature, I’d recommend changing to 7. You want to get the edit in soon after the slop revert so it’s part of the new baseline. Cheers and thanks for your work on this! Dw31415 (talk) 08:43, 1 October 2026 (UTC)

Based on our dry runs, we're seeing about 5-20 hypothetical edits per run, and the number is rising as we add rules. As the list grows, I think we can expect to see dozens to low-hundreds of edits per run, with skips and cooldowns likely being in the single digits for the foreseeable future. If the number of skipped edits or articles in cooldown increases, we can look at lowering the cooldown period. The bot is meant to handle the unambiguous, obvious cases that need to be fixed. Anything that's contentious (aka, it has been reverted) or not obvious should be handled by a human. Zackmann08 and I will be perusing the Report page on a daily basis, and other interested editors are welcome to do so as well. When we spot skips, we will likely handle them manually, rather than waiting for the bot to come back and take care of it in 30 days (or whatever we set the cooldown period to be).

Running weekly would mean that more articles get missed for longer. If anything, I'd like to eventually increase the frequency that the bot runs, not decrease it. phuzion (talk) 00:03, 3 October 2026 (UTC)

Note: The work Phuzion has done really is incredible... User:ParamBot/Report even highlights issues with the rules that have been implemented and has already identified a number of things that needed fixing. Mostly typos, but a few were params that were deprecated but then not properly removed from the Infobox in question. Likely never would have been caught without this... Zackmann (^{Talk to me}/_{What I been doing}) 04:02, 2 October 2026 (UTC)