Jump to content

Wikipedia:Bots/Requests for approval

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:BRFA)

New to bots on Wikipedia? Read these primers!

To run a bot on the English Wikipedia, you must first get it approved. Follow the instructions below to add a request. If you are not familiar with programming, consider asking someone else to run a bot for you.

 Instructions for bot operators

Current requests for approval

Operator: Rusalkii (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 09:08, Tuesday, September 8, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: https://github.com/rusamoss/rfd_watch

Function overview: Maintain a manual RfD pseudo-watchlist for users that have opted in, to work around the fact that there's no way to watchlist individual RfD discussions.

Links to relevant discussions (where appropriate): N/A

Edit period(s): Continuous (every 15 minutes)

Estimated number of pages affected: Single userspace page for each user who opts in

Exclusion compliant (Yes/No): No

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

Function details: For every user that opts in at User:Rusabot/RfD subscribers, maintain a list at User:Username/RfD subscriptions, which is updated whenever that nomination has any changes. Any RfD nominations from your Twinkle log is added automatically, and you can manually add entries as well.

It's been running at User:Rusalkii/RfD subscriptions without any issues. Not entirely sure I need a BRFA for an opt-in userspace-only bot, but filing just in case; I'll unprotect the subscribers page once the bot is approved for other users. Possibly the subscribers page should be permanently ECPed since it controls a bot and non-EC users are pretty unlikely to need it.

Accompanying userscript User:Rusalkii/subscribeToRfDs.js adds some convenience buttons.

Discussion

  • Not entirely sure I need a BRFA for an opt-in userspace-only bot To write anyone else's userspace besides your own and the bot's, you do. WP:BOTUSERSPACE doesn't cover userspace in general, even with opt-in. BTW, I note that an unprotected subscription page may not be completely opt-in, if there's no guard against someone adding other names to the list. Anomie 11:31, 8 September 2026 (UTC)reply
    I'd ECP it, but if that's not sufficient I suppose I could full protect it and add people on request from the talk page. Since the scope of potential damage is pretty low (adding a single page to each editor's user space that they wouldn't notice unless they went looking for it) I think that's excessive, though. Theoretically I could add a check for someone adding more than one username at a time or adding usernames other than their own, but that's a lot of extra code for pretty marginal benefit. Rusalkii (talk) 17:56, 8 September 2026 (UTC)reply
    Mostly I mention it so it can be taken into account when making the decision. You're right the impact is pretty small, so not worrying about it could be a valid choice. If you decide to worry about it anyway, one strategy might be to have people create a particular .js or .css subpage in their userspace to confirm. Anomie 23:43, 8 September 2026 (UTC)reply
    I generally don't see any issue with bots editing user space for the purposes of making life easier when the backend software isn't doing the most ideal job, especially if it's opt-in, but there also needs to be a demonstrated need. I'd be fine with a trial (maybe 30 days?) to gauge interest and get feedback from the community. Primefac (talk) 20:40, 13 September 2026 (UTC)reply
    There's been some complaints about the lack of this feature over the years - the latest I've seen is at Wikipedia talk:Redirects for discussion#Watching RfD discussions. Rusalkii (talk) 20:43, 13 September 2026 (UTC)reply

Operator: Fengrímur (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 17:07, Monday, August 31, 2026 (UTC)

Function overview: A new implementation of ProcBot 5 and ProcBot 6 for cache purges and link refreshes and category/template fan-outs.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Python 3.13, with MariaDB

Source code available: Yes, GitHub.

Links to relevant discussions (where appropriate): Wikipedia:Bot requests#Taking over ProcBot 5 and 6

Edit period(s): Queues are checked every five minutes, requests themselves run once or daily at 0:00 UTC.

Estimated number of pages affected: No (0) edits. One per individual request or up to 1.500 per fan-out (purges!).

Namespace(s): Main, Template and Category

Exclusion compliant (Yes/No): No. Because it does not edit pages.

Function details: FengPurgeBot reads two protected queues: individual requests and fan-out requests. An individual request uses purge-page-cache to purge one page, or refresh-page-links to purge it with forcelinkupdate=1. The fan-out actions apply the link refresh to the direct page members of one category or the direct (non redirect) transclusions of one template. Files and subcategories are excluded, and targets are limited to the Main, Template and Category namespaces. I used the purge API instead of null edits so that the task does not need to save wikitext.

Each nonblank line must contain one request template. Requests run once or daily at 00:00 UTC. Fan-outs also need an English Wikipedia permanent link to the discussion behind them. The bot records the link for logging purposes. I split the queues so individual requests can remain semi-protected while the higher-impact fan-out queue is extended-confirmed protected. A malformed line pauses that queue.

Before a fan-out starts, the bot reads the complete category or transclusion result twice. Both sets must match, and a set over 1,500 pages is rejected in full. The accepted targets are fixed by page ID. Before every effect POST, the bot resolves those IDs again and rereads the queue to confirm its protection and that the request is still present. Removing an entry cancels anything not yet sent.

A MariaDB ledger records dispatches before HTTP and prevents the same one time request or daily slot from running twice, including after a restart. Missed daily slots are coalesced. Ordinary purges use batches of up to 50 and link refreshes use up to 25. POSTs are serial, at least 30 seconds apart, and use maxlag=5. In any rolling 24 hours, the limits are 180 effect POSTs, 3,000 target attempts and 1,500 forced link-update attempts.

A target is accepted only if MediaWiki returns purged, plus linkupdate for a link refresh, and its identity is unchanged after the request. The bot retries temporary errors later using increasing delays. If a POST may have succeeded but cannot be verified, that target gets at most one later retry by itself. A second ambiguous result suspends the request for my review.

Discussion

Apologies if I'm asking a dumb question (I really need to start checking these earlier in the day), but if I wanted to do a fan-out request on all pages calling {{infobox cricketer}} (which has 32k transclusions) it would reject the request? Primefac (talk) 21:50, 7 September 2026 (UTC)reply

+. Each transclusion means a forced link update, and since maxlag alone does not stop one huge request from putting too much load on the servers or tying up the bot, it needs a per-job cap. I chose 1,500 because the discussion mentioned just under 1,200 redlinked categories, giving about 25% headroom, and because 1,500 had already been used for a similar task by Joe's Null Bot. If a higher limit works and is needed, I could raise it. A lower one is probably better for a trial, anyway... Fengrímur (talk) 08:12, 8 September 2026 (UTC)reply
I think I'm good for a trial, but I'd like a second opinion. Would be good to also make sure we have requested purges ready to go (i.e. is the BOTREQ request still ongoing?). Primefac (talk) 20:44, 13 September 2026 (UTC)reply
Not really ongoing. Depending on how much time people are willing to give this, I could continue working on my next planned bot — an updated version of this one — which would shove the problem off Wikipedia entirely. Basically, that means eliminating the human-in-the-loop that FengPurgeBot currently needs and just autonomously purging whenever it's needed and never when it's not supposed to (It's possible, I can confirm!). Naturally, I could also find pages for us that need requests specifically for this trial... Orrr we pause this for a bit until I publish the update for iFengPurgeBotPro. If it's up to me to decide, that's what I'd recommend, unless there’s a specific need for the bot in the next 1–2 weeks. Fengrímur (talk) 12:48, 14 September 2026 (UTC)reply

Operator: Electricmaster (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 12:46, Tuesday, July 21, 2026 (UTC)

Function overview: Synchronizes AFL player statistics (games and goals) from AFL Tables to Wikipedia player infoboxes.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Python (using Pywikibot)

Source code available: Custom Python script using Pywikibot and requests.

Links to relevant discussions (where appropriate):

Edit period(s): Daily during the AFL season.

Estimated number of pages affected: ~600 pages checked daily; edits only occur when a player's stats have actively changed.

Namespace(s): Mainspace (Articles)

Exclusion compliant (Yes/No): Yes

Adminbot (Yes/No): No

Function details: The bot scrapes active player statistics (total games and goals) from AFL Tables (e.g., https://afltables.com/afl/stats/2026.html). It then iterates through the corresponding Wikipedia articles for those active players.

The bot targets the {{Infobox AFL biography}} template to update:

  • The `games_goalsX` parameter corresponding to the player's current active club.
  • The `games_goalstotal` parameter if the player has played for multiple clubs.
  • The `statsend` parameter, advancing it to the most recently completed round (e.g., "round 19, 2026").

The script strictly parses the wikitext, updating the stats inline while meticulously preserving existing references, comments, and other infobox data. It runs as a "dry run" first to calculate diffs and will only perform a live edit if the AFL Tables data represents an actual advancement of the player's Wikipedia statistics.

Discussion

  • Information Note: This bot appears to have edited since this BRFA was filed. Bots may not edit outside their own or their operator's userspace unless approved or approved for trial. AnomieBOT 22:46, 30 July 2026 (UTC)reply
  • Related ANI thread. —ClaudineChionh (she/her · talk · email) 04:22, 15 August 2026 (UTC)reply
  • If having the latest stats is that important, wouldn't a central data page be a better option? The bot could update that one page, and a module could pull the data from there and be invoked in the infobox. We don't usually update stats this way, and I'm not sure having a bot check around 600 pages every day and edit them just to keep the stats up to date is a good approach. I also read the ANI thread, and it gives me the impression that you don't have full control over the scripts you use, so I'd also like to see the source code for this task if you're comfortable sharing it. – DreamRimmer 16:03, 15 August 2026 (UTC)reply
    I would second this. If it were 6 thousand pages it might be different, but having one module (and/or a .json page) storing the data would mean a lot less editing. I would also note that "daily" is excessive for stats when the matches are played what, at most two times a week for any given team? A weekly update is more than sufficient (regardless of if one page or every article is edited). Primefac (talk) 16:16, 15 August 2026 (UTC)reply
    I'm not a BRFA regular so I don't know what's appropriate here, but I've found references to two GitHub repos scattered on different talk pages – is it OK to link them here? —ClaudineChionh (she/her · talk · email) 00:47, 16 August 2026 (UTC)reply
    I'm not sure I understand the relevance; the issue right now is not "does the code work" (which, according to the ANI, seems to be "most of the time") but rather if there is consensus (at all?) for this task, or if there is a better/more efficient way to get the same results. Primefac (talk) 22:52, 16 August 2026 (UTC)reply
    Oh, that was in response to DreamRimmer's question about the source code. —ClaudineChionh (she/her · talk · email) 03:58, 17 August 2026 (UTC)reply
    ClaudineChionh, you are more than welcome to add constructive comments in the BRFA space. Primefac, the reason I asked for the source is, as I said above, they made multiple claims about their code being reliable, but there were still mistakes as mentioned in the ANI thread, so I was curious to see how reliable the code actually was. After checking their GitHub repo, I found the table scraping and template manipulation logic pretty unreliable. There were also quite a few unnecessary functions in the code that I'm not really sure why they were using. That gave me a better idea of what they were actually doing. With our suggested version, though, it won't make any edits outside the single data page, so that shouldn't really be an issue if they're ready to go with this. Max (talk) 18:28, 19 August 2026 (UTC)reply

Operator: Blippy1998 (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 05:41, Tuesday, July 14, 2026 (UTC)

Function overview: updating a draft set of data modules, hopefully with permissions to also edit what would hopefully be a non-draft set of data modules, with new data about legislatures pulled from official/authoritative sources, starting with the United States House of Representatives. btw if i'm allowed to add my own userspace and my own module sandbox to Special:OAuthConsumerRegistration without asking permission, let me know and i'll just do that for now, but it would be nice to get permission to edit Module:Legislature and its subpages in the near future with my bot also.

Automatic, Supervised, or Manual: automatic

Programming language(s): Python, Scribunto

Source code available: it's just on my computer at the moment

Links to relevant discussions (where appropriate):
Wikipedia:Bots/Requests for approval/Blippy1998Bot
User_talk:Morwen#A_barnstar_for_you! - i describe it a bit here, BELOW the discussion about Module:Legislature diagram, which is wholly unrelated (i probably should have started a new section). i have described it elsewhere, too.

Edit period(s): no more than every hour when my laptop is open, but realistically no more than a few times a month to begin with, scaling with how many legislative chambers are covered

Estimated number of pages affected: for now i think just 3 but probably well under 100 within the next year

Namespace(s): the Module:Sandbox/Blippy1998 namespace and maybe my userspace for now but in the future hopefully Module:Legislature and all its subpages, plus perhaps some templates

Exclusion compliant (Yes/No): yes (it would only edit a short whitelist of pages for now)

Function details:

the goal of this bot is to automate updates for data on legislatures - current seats, current members, current committees, and whatever else people see fit to add. there is to be a module with functions that parses that data in useful ways, computing the list of members belonging to a certain party, the balance of power, etc. this is not meant to replace user editing of highly-trafficked pages, but rather to serve as centralized, standardized database-like storage for information that infrequently-edited articles and sections of articles can pull from so that they stay up to date automatically. (this can be seen as a major expansion of my previous work, which can be read about at my previous bot request.)

this bot would, initially, edit Module:Sandbox/Blippy1998/Legislature/US/lower/committees, Module:Sandbox/Blippy1998/Legislature/US/lower/members, and Module:Sandbox/Blippy1998/Legislature/US/lower/seats only, i think, but i would love to see it grow to cover other legislative chambers, and of course to migrate to Module:Legislature once i think it's ready. i may have it edit various templates - within my userspace to start - automatically to update citations automatically as it downloads new data, for example.

basically, what it would do is use a number of python scripts to download the xml file, check it against the local copy, and update it if it's new. then, if it did that, it would parse the new one and update the committees, seats, and members jsons i have locally before simply converting those to lua data modules and uploading them to the pages i listed above. in other words, it would effectively just update the data at each of these data module pages in this formatted, quasi-relational way, parsed directly from the official xml file every time it's updated.

Discussion

it just gets this page using a python script every hour while my laptop is connected to the internet. i haven't written code to pull data for every state legislature - that would be incredibly tedious to do alone - but i've designed the structure of the modules to be easily expandable to other legislatures. for example, if someone wrote a script to download data for Texas's Senate, they could put the data into Module:Legislature/US/TX/upper/members, Module:Legislature/US/TX/upper/seats, and Module:Legislature/US/TX/upper/committees, or other subpages as appropriate, and then use the same functions in Module:Legislature (already written in Module:Sandbox/Blippy1998/Legislature) and templates (not yet written) to create views of the data, like a wikitable of all the members of a certain committee, or just the tally of members of a certain party. the point is to set up a framework that is easily extensible so people can write their own scripts and upload a data module to a sensible location with a standardized format (like Legislature/[ISO country code]/[subnational entity code]/[chamber label]/seats) and then not have to rewrite functions that actually parse that data. but all i'm seeking approval for is the bot that pushes the updates to those pages. seeing as all i have is the US House at the moment, updates would realistically not happen more than a few times a month to just a few pages, but, yes, hopefully more legislatures would be added and the number of pages and frequency of edits would scale with that. Blippy1998 (talk) 16:16, 16 July 2026 (UTC)reply

Operator: Sdkb (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 21:26, Saturday, February 7, 2026 (UTC)

Function overview: Removes erroneously italicized commas at the end of italicized terms.

Automatic, Supervised, or Manual: Automatic

Programming language(s): AutoWikiBrowser

Source code available: The bot will be operated by running through lists of pages from the RegEx search query insource:/''[A-Z a-z\[\]\|]+,'' / with a find and replace for ''([A-Z a-z\[\]\|]+),'' ''$1'', . It will use the edit summary Fix erroneously italicized comma and general fixes (task 5).

Links to relevant discussions (where appropriate): None. Although not explicitly specified in the Manual of Style, it is standard English to italicize only the term itself, not punctuation following it.

Edit period(s): Daily

Estimated number of pages affected: 103,000 per this search

Namespace(s): Mainspace (potentially expanding to other namespaces)

Exclusion compliant (Yes/No): Yes

Function details: Because italics markup looks similar to quotation marks and many editors are used to American-style quotation, many editors erroneously put commas following italicized terms within the italicized term, causing the comma to be erroneously italicized. This bot will fix many of these instances, using the AWB settings described above. I did 50 test edits for a version excluding italicized terms with spaces, manually reviewing each one, and the only instances that gave me any pause were ones within quotations, e.g. here (after "for" in the paragraph beginning "King asked a bookmobile driver"). These could be excluded if an issue, but, per the MOS, Insignificant spelling and typographic errors should simply be silently corrected (for example, correct basicly to basically), so I think it's fine to include them. I reviewed another 60 edits (including terms with spaces) via search and found no issues.

Discussion

Should something similar be done with bold? (10,000 per this search) -- WOSlinker (talk) 21:46, 7 February 2026 (UTC)reply

Likely. It might also be worth requesting this be added to the genfixes for AWB so that when this run is over any new instances will be more likely to be picked up. Primefac (talk) 21:50, 7 February 2026 (UTC)reply
Yeah, I think it'd definitely be nice to do the same thing with erroneously bolded commas. I intentionally kept the query constrained to start off (ignoring any italicized terms with unusual characters, for instance), but it could be expanded after the initial run is over.
And yes, I agree it'd be nice to add this to the GENFIX set. Cheers, Sdkbtalk 22:54, 7 February 2026 (UTC)reply
Are you not wanting to do bold? Primefac (talk) 17:48, 15 February 2026 (UTC)reply
I looked through the first 100 search results for the bold query. I found one niche edge case: On this page, bolding is used to delineate which parts of two passages match. Because manual line breaks are used, some bolded strings end with a comma. You could argue that this is a downstream effect of the article using poor syntax with manual line breaks, or that a passage like that should have been surrounded with {{as written}}. But because bolding is sometimes used for niche purposes like this, I think it's the slightest bit riskier to try to fix it than italics.
I'll defer to whatever the consensus is here about whether, given this, it's worthwhile to include it or not. Sdkbtalk 17:44, 20 February 2026 (UTC)reply

This feels like something so minor that it would be best either ignored or done as part of AWB GENFIXES. I oppose this being done as the sole edit to a page. Thryduulf (talk) 14:28, 20 February 2026 (UTC)reply

It's certainly not the most earth-shattering change to a page, but it is an improvement, and it's clearly in compliance with WP:COSMETICBOT because it changes the output HTML of the page. It is something that I occasionally notice as a reader. Also, because it's an AWB bot, it can be run alongside GENFIXes, so often the comma fix will not be the only change the bot makes. Sdkbtalk 17:20, 20 February 2026 (UTC)reply
I think we'll have to agree to disagree on whether the change is an improvement or neutral, and I have no objection to the change being made alongside changes that are unambiguously improvements, but minor changes like this should never be the sole change made by a bot. Thryduulf (talk) 18:40, 20 February 2026 (UTC)reply
On hold. There is opposition to the task, and with only the implication of consensus to run the task based on existing guidelines I would prefer to see a stronger consensus to specifically target this as a bot run. I know AWB releases updates less frequently than most countries change leadership, but that would be another route to go down to start whittling away at the list. Primefac (talk) 20:17, 8 March 2026 (UTC)reply
@Primefac, where would be an appropriate venue to get additional input on whether there is consensus to run this as a bot task? Thryduulf's view seems to be that WP:COSMETICBOT should be made stricter, and while I know that's a view some editors hold, presumably it's a minority given that editors have not found consensus to change the language of the bot policy. Sdkbtalk 20:34, 8 March 2026 (UTC)reply
Either at the MOS talk or a Village Pump. I wouldn't necessarily say that it's a more strict ruling on COSMETICBOT given that it already says Minor edits are not usually considered cosmetic but still need consensus to be done by bots. Since this is a "barely visible" type of minor edit, I'd like to get at least some measure of support for making it; it's not like you're going to need an RFC, just enough to indicate that Thryduulf is in the minority when it comes to being concerned. Primefac (talk) 20:48, 8 March 2026 (UTC)reply
@Sdkb: Did you start a discussion to gather consensus at all? Tenshi! (Talk page) 14:59, 10 July 2026 (UTC)reply
@Tenshi Hinanawi, yes, see here. I read it as a weak consensus to proceed, although it didn't gather as much input as I would've liked. Sdkbtalk 15:22, 10 July 2026 (UTC)reply
As I said at Wikipedia talk:Manual of Style/Archive 230 § Bot task to remove erroneously italicized commas, I think this would be a useful bot. I always fix those manually as well. However, it should not fix incorrectly "fix" instances of multiple italics separated by a non-italicised space, such as ''The good,'' ''the bad,'' ''and the ugly'', since this is especially common when editing in the VE. Otherwise it might sometimes make the problem worse, not better. FaviFake (talk) 12:54, 10 August 2026 (UTC)reply
How does one person reiterating their comments at a long-archived discussion help anything here? Should every participant just repeated their comments there here? I note that nobody has expressed any opposition to doing this as an AWB-task or alongside some other unambiguously substantive change, and nobody has articulated any reason why that would not be sufficient. Thryduulf (talk) 12:58, 10 August 2026 (UTC)reply
I just wanted to make sure the bot doesn't incorrectly handle this edge case in case it's approved. Do with that what you will. FaviFake (talk) 13:03, 10 August 2026 (UTC)reply
Name-internal commas is an edge case the bot can handle, but name-internal edge cases where also there is a break in italicization is an edge case within an edge case that it cannot. I did not come across any instances of this scenario during the 110 test edits I reviewed, so I believe it is exceptionally rare. Overall, the garbage-in, garbage-out principle applies. Sdkbtalk 14:45, 10 August 2026 (UTC)reply
Wikipedia is written for our WP:READERS. As long as the garbage stays in the editor, it's fine. If your bot would cause the garbage to be displayed to our readers, then I oppose the bot. FaviFake (talk) 14:49, 10 August 2026 (UTC)reply
@FaviFake, can you point me to any article where this would happen (or, better, give me a number of articles affected)? I could ensure all of them are resolved before running the bot. Sdkbtalk 14:53, 10 August 2026 (UTC)reply
I'm not a technical user, so I can't give you any stats. But I've just tested this on the current version of the VE and I was able to italicise three parts of a sentence with commas in them, and the VE outputted this result in the preview: After ''the withdrawal of U.S. troops from Iraq,'' ''ISI,'' ''then-led by John Doe,'' continued
I suspect this is rare. Someone should figure out a way to find a list of the articles that have this issue. Once they're fixed correctly, I guess your bot could go ahead even if it would still produce incorrect results from new edits. I just don't want to introduce the incorrect formatting into the articles that have been edited since Wikipedia was started. FaviFake (talk) 15:01, 10 August 2026 (UTC)reply
@FaviFake, wait, it's actually pretty easy to find these instances by just adding additional quote marks to the search query. There are 6,600 results. I manually reviewed the first 100 (you're welcome to do the same), and found that nearly all were instances of a list of italicized items or improper italicization in a reference, all of which the bot would handle correctly. There was only one instance, here (a comma being erroneously used to separate a title and subtitle), that was at all questionable.
We could modify the find-and-replace to skip all these instances (where an italicized term ending in a comma is immediately followed by another italicized term after a space) by using a negative lookahead. However, based on the sample, it appears that this isn't an issue, so my weak preference would be to leave them in. Which option do you prefer? Sdkbtalk 17:40, 10 August 2026 (UTC)reply
Huh, I didn't think there would be so few false positives. I've reviewed 100 more and they were all incorrect. So now I support the bot based on the data. Even if we assume 1% of 6k articles would cause false positives, that's just 60 articles, which is a great compromise! FaviFake (talk) 17:57, 10 August 2026 (UTC)reply
Doing it as an AWB task would be exponentially slower. Because it is not a cosmetic task as it changes the visible page output, it is eligible to be done by bot. I know you disagree, but if you want to interpret the rules other than as they're written, you need to take that up as a proposed change to WP:COSMETICBOT. Sdkbtalk 14:51, 10 August 2026 (UTC)reply
Why does it need to be done more quickly than AWB would do it? What benefit does a change imperceptible to many (maybe most) readers, with no semantic relevance for readers or screen readers, bring that justifies so many edits? It doesn't meet the letter of COSMETICBOT but it certainly matches the spirit. Thryduulf (talk) 15:59, 10 August 2026 (UTC)reply
You had the opportunity to make that argument at the WT:MOS discussion and were not able to get a consensus supporting your view. It's time to drop the stick. Sdkbtalk 18:07, 10 August 2026 (UTC)reply
No stick needs to be dropped at this point. The MOS discussion was essentially over by the time I was aware of it and your comment here is the first time anybody has actually acknowledged the substance of my comments and even you've just said "I disagree". You're entitled to disagree but that doesn't equate to a consensus. Thryduulf (talk) 00:39, 11 August 2026 (UTC)reply
  • One small update: I've tweaked the query to include wikilinks. Reviewing the results, I'm not seeing any errors being introduced. Sdkbtalk 17:48, 10 August 2026 (UTC)reply
  • @BAG: combining the WT:MOS discussion with FaviFake's additional support above, I'd say this is ready for approval. Are we good to proceed? Sdkbtalk 18:10, 10 August 2026 (UTC)reply
    I'm not going to weigh in on this too much just now, but FaviFake also participated in the MOS discussion, so their support here does not do anything to tip the scales in either direction. Primefac (talk) 22:48, 10 August 2026 (UTC)reply
    Yeah, I wasn't suggesting they be allowed to !vote twice, but just that they had concerns at the MOS discussion which are now resolved per above. Sdkbtalk 23:00, 10 August 2026 (UTC)reply
    Yeah; to clarify, I commented here because I noticed the MOS discussion had been archived but the issue that another editor and I had hadn't been mentioned here. Now that we discussed it a bit more and discovered it's not really an issue, it just validates the MOS consensus. FaviFake (talk) 23:06, 10 August 2026 (UTC)reply
  • I'm leaning towards declining this in its current form. There seems to be reasonable support for the edit itself, but I don't think there's a clear consensus for making potentially ~100,000 standalone edits for such a minor change, especially with the ongoing concern about cluttering watchlists and page histories. I'd be happy to see this added to GENFIX or run alongside more substantive changes. Max (talk) 02:42, 31 August 2026 (UTC)reply
    There is one editor objecting loudly, but overall it looks to me like there is consensus to proceed. And policy-wise the task abides by WP:COSMETICBOT, so the impetus to show otherwise was on those who object to the plain reading of that guideline. Sdkbtalk 18:18, 31 August 2026 (UTC)reply
    And I will continue to object loudly until the substance of my objections are actually engaged with rather than ignored or handwaved away. This does not come remotely close to meeting the spirit of WP:COSMETICBOT, being a tiny change that almost nobody will notice and which has absolutely no semantic or other meaningful impact. Thryduulf (talk) 19:05, 31 August 2026 (UTC)reply
    well i always notice these little things like bolded commas and they often annoy me so much that i fix them on sight, even when I'm on my phone. FaviFake (talk) 19:11, 31 August 2026 (UTC)reply
    Good for you, but that doesn't equate to a consensus to disrupt the encyclopaedia by making only this trivial change, which most people (obviously not everyone) does not notice by bot. Thryduulf (talk) 19:14, 31 August 2026 (UTC)reply
    Making objectively substantial and minor changes to 7k articles does not disrupt the encyclopaedia and there is already consensus for it. Bot edits don't even clutter watchlist-like pages, what exactly would be disrupted in your view? FaviFake (talk) 19:22, 31 August 2026 (UTC)reply
    I don't think watchlist clutter is a valid concern when bots can be hidden in the watchlist, and if they have reason to want to watch problematic bots or something to that effect, the script at WP:HIDEBOT exists to hide specific bots. Tenshi! (Talk page) 19:29, 31 August 2026 (UTC)reply
    Bot edits clogging up watchlists have been a complaint for a long time. Even with the script and CSS rule to hide them, I don't remember the exact discussions, but I've seen people complain about it, so I don't think we can just dismiss it as an invalid concern.
    Sdkb, as I said above, I see consensus to fix the formatting issue, but I don't think everyone is on the same page about doing this as a standalone task, or at least that's how I read the discussion. Maybe the better option would be to unarchive the discussion and leave a notice somewhere more visible to get more people involved. Max (talk) 10:02, 2 September 2026 (UTC)reply
    So you're saying there's consensus to fix those formatting issues but not on whether to do it using a bot. Isn't BRFA the place where new bots are supposed to be discussed? If anything, this request should be made more visible rather than the archived one, imho. FaviFake (talk) 10:09, 2 September 2026 (UTC)reply
    BRFA space isn't really "the place where new bots are discussed" in that broad sense. It's mainly for getting approval for a specific bot task once there's community consensus for the underlying change, rather than being the place to establish that underlying consensus in the first place. That's why the BRFA request is expected to link to the relevant community discussion. Here, the question of whether the incorrectly italicised commas should be fixed at all, and whether a bot is the right way to do it, is something that can be discussed at the relevant venues, or at more visible places like WT:MOS or VPR, and this is where it was discussed. I suggested unarchiving the discussion because I thought it would be better to keep everything in one place and make it easier for people to see the earlier discussion, rather than having the same points repeated across different pages. Max (talk) 11:46, 2 September 2026 (UTC)reply
    Makes sense!  Done, see Wikipedia talk:Manual of Style § Bot task to remove erroneously italicized commas FaviFake (talk) 12:06, 2 September 2026 (UTC)reply
    I'm sure there has been many complaints, but I don't believe they hold any weight when it's 2 clicks and some scrolling for ignoring all bots, and adding a user script for removing specific bots from the watchlist with a bit of configuration. Tenshi! (Talk page) 17:57, 2 September 2026 (UTC)reply
    Firstly you have to know how to do that, and secondly it doesn't address the issue of page histories at all. Thryduulf (talk) 18:21, 2 September 2026 (UTC)reply
    Correct, I haven't said anything about page histories, my contention is with watchlist clutter complaints. It's mentioned at Help:Watchlist#Options, and WP:HIDEBOT is on Wikipedia:Bots, both of these seem pretty easy to understand and on pages which would come to mind when checking how to disable bots in watchlists. Tenshi! (Talk page) 18:38, 2 September 2026 (UTC)reply
    Yeah, I remember disabling bot edits and making other changes even before I read those pages or even understood what exactly bots were. FaviFake (talk) 19:04, 2 September 2026 (UTC)reply
    I mean, sure, the options to hide bot edits are there, and we can definitely suggest them to people who find them useful. But I don't think that means concerns about watchlist clutter don't carry any weight. Just because there's a two-click option to hide bot edits, or a user script to hide a specific bot, doesn't mean everyone affected by the task should have to use them. If we're talking about potentially thousands of standalone edits for a pretty minor change, I think it's fair to consider how that affects people who don't want to change their setup. That's why I'd still prefer to get a bit more input. Of course, I understand you have a different opinion on this. Max (talk) 18:45, 2 September 2026 (UTC)reply
    I agree now that those cases should be considered, as well as the possibility that some people may not be able to (e.g. nojavascript users cannot use the user script), but I still don't think they should be given the same weight. Personally it's not a convincing argument when it's an issue that can be resolved for the majority of people easily. Tenshi! (Talk page) 20:18, 2 September 2026 (UTC)reply
    Let's also keep in mind that "majority of people" here means "majority of editors". The costs of minor edits are borne by editors, whereas the benefits are enjoyed by readers who outnumber editors by an enormous margin and who are the ones we're ultimately creating the encyclopedia for. We should try not to let editor-centric bias influence our calculus. Sdkbtalk 20:59, 2 September 2026 (UTC)reply
    We should not lose sight of the fact that hiding bots is an imperfect solution to a problem that we have the option of not creating in the first place. Thryduulf (talk) 21:01, 2 September 2026 (UTC)reply
  • Oppose per Thryduulf. * Pppery * it has begun... 03:13, 4 September 2026 (UTC)reply

Bots in a trial period

Operator: Solidest (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 08:07, Friday, July 24, 2026 (UTC)

Function overview: One-off runs to correct music charts or infoboxes.

Automatic, Supervised, or Manual: Starting with supervised, then automatic

Programming language(s): Python/Pywikibot

Source code available: -

Links to relevant discussions (where appropriate): Template talk:Single chart#Canadian RPM templates need updated

Edit period(s): Series of one time runs

Estimated number of pages affected: around 8300 articles

Namespace(s): Mainspace

Exclusion compliant (Yes/No): Yes

Function details: The Canadian music charts website was recently updated, and all the IDs have changed. I’ve created a mapping table which I’m going to use to transfer the old entries to the new chart with the new IDs. Moreover, these kinds of charts edit runs happen from time to time; I used to carry them out from my main account, but it would be more convenient for me to do so from the bot's account. To comply with the policy on bulk edits and avoid flooding.

Discussion

Operator: Balance3641 (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 09:58, Monday, August 10, 2026 (UTC)

Function overview: Alerts users to cross-language articles created for articles they have authored. Will watch for new articles linked to the wikidata and alert users on their talk page.

Automatic, Supervised, or Manual: Automatic, can supervise to begin before becoming automatic.

Programming language(s): Typescript

Source code available: Not currently

Links to relevant discussions (where appropriate): Wikipedia:Village_pump_(proposals)#Would_anyone_be_opposed_to_a_bot_that_notifies_you_when_someone_translates_an_article_you_made? Wikipedia:Bot_requests#Bot_that_informs_you_when_someone_translates_your_article

Edit period(s): Continuous

Estimated number of pages affected: Upper bound was ~5 alerts/min measured over the last day.

Namespace(s): User_talk

Exclusion compliant (Yes/No): Yes

Function details: The bot watches the live EventStreams recentchange stream, and detects edits to the wikidata wikipedia entries and if there is an enwiki entry, and another wiki is added a message is added to user talk pages. Users can opt-in with the {{bots}} template. A single message will be sent the first time a user is alerted, if there are any detected messages from the bot, another alert will not be sent without explicit opt-in. The bot adds a comment in the message to detect duplicate messages based on the source article and linked language (so spamming the wikidata with changes won't spam user talk pages, even if the article linked is different). The bot will listen on User:NervousBot/shutoff, and anything except 'running' on the page will force a shutdown. Logs will be written to User:NervousBot/log.

Talk Page Message

A new page Foo on the French Wikipedia has been linked to your page Foo via Wikidata (Q123).

You will not be notified in the future about new articles linked to any of the articles you have created, if you wish to opt-in to receiving these notifications, please follow the opt-in instructions.

Discussion

Operator: Pauliesnug (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 01:57, Thursday, July 23, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Rust

Source code available: https://codeberg.org/pauline/AnnealBot-wp

Function overview: Corrects the invalid IPA symbol ʋ → v inside {{IPA|sh}}/{{IPA|sr}}/{{IPA|hr}}/{{IPA|bs}}/{{IPA|cnr}} transcriptions, per Help:IPA/Serbo-Croatian.

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#IPA_symbol (raised by IvanScrooge98)

Edit period(s): One time run

Estimated number of pages affected: 782 (live CirrusSearch count, 2026-07-22; query: incategory:"Pages with Serbo-Croatian IPA" insource:/ʋ/)

Exclusion compliant (Yes/No): Yes

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

Function details: ʋ hasn't been a listed symbol in Help:IPA/Serbo-Croatian for three years (see Special:Diff/1161939637), so any instance of it inside a Serbo-Croatian-family IPA template is a stray labiodental-approximant symbol that should be the plain /v/.

Workflow:

  1. Searches incategory:"Pages with Serbo-Croatian IPA" insource:/ʋ/ for candidate pages.
  2. On each candidate, replaces ʋ with v only inside {{IPA|sh}}, {{IPA|sr}}, {{IPA|hr}}, {{IPA|bs}}, and {{IPA|cnr}} calls.
  3. Many of these articles also carry a {{IPA|sl}} (Slovenian) transcription right next to the Serbo-Croatian one, and Slovenian distinguishes /ʋ/ from /v/ as a phoneme. The task is scoped to never touch {{IPA|sl}} or any code outside the five named.
  4. ɛ/ɔ occurrences are logged for manual review but not auto-corrected, per the original discussion, whether those should map to e/o is less clear-cut.

Sample diffs from a 15-page dry-run sample (2026-07-22): Yugoslavia, Novi Sad, Vlade Divac, Gavrilo Princip.

The task has an automated test suite (in the linked repository) covering: the five-code scope restriction (including a regression test that Slovenian/Macedonian codes are never matched), that replacement only touches text inside the matched template span, and that ɛ/ɔ are left untouched even inside an otherwise-matched span.

Discussion

Approved for trial (100 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 22:00, 25 July 2026 (UTC)reply

A user has requested the attention of the operator. Once the operator has seen this message and replied, please deactivate this tag. (user notified) Any update on this? Max (talk) 02:48, 31 August 2026 (UTC)reply

Bots that have completed the trial period

Operator: Ow0cast (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 01:50, Thursday, November 14, 2024 (UTC)

Function overview: Replace external links to wikipedia with wikilinks

Automatic, Supervised, or Manual: Supervised during trial, automatic afterwards

Programming language(s): Python (pywikibot)

Source code available: Yes, upon request on github

Links to relevant discussions (where appropriate): I do not believe that discussions are required for this action, as this is the entire point of wikilinks

Edit period(s): Continuous

Estimated number of pages affected: Large burst at approval/during trial, then 25/day at the highest afterwards.

Namespace(s): Mainspace

Exclusion compliant (Yes/No): Yes

Function details: The goal of this task is to replace "external" links to wikipedia pages with the proper wikilinks.

  • Watch Special:RecentChanges for edits containing "https://[*].wikipedia.org/wiki/[*]", then replace the external link with a wikilink.

Example: "Python https://en.wikipedia.org/wiki/Python_(programming_language) is cool" → "Python is cool."

Discussion

Many articles contain external Wikipedia links to templates, policy pages, and discussion, usually added as comments. On average, about 20 of these kinds of links are added per day, with 95% of them as commented-out text. Replacing these links would only lead to cosmetic changes, which should be avoided per WP:COSMETICBOT, as commented-out text are not visible to readers. For the remaining 5%, using a bot isn't a good idea, as these minor edits can be easily handled by a human editor. Currently, over 62,000 pages have these types of commented-out links, and none need replacement based on your criteria. This suggests that these types of external links are fixed regularly. – DreamRimmer (talk) 14:32, 14 November 2024 (UTC)reply
I do not want to pile-on, but for "en.wikipedia" this task wont be much useful like DreamRimmer explained above. However, in case the link is to some other wikipedia eg "de.wikipedia" (german), or "es.wikipedia" (spanish), this task would be useful, but again, the occurrences are extremely low, and they are generally handled/repaired by editors as soon as they are inserted. Also, bot operator is new (not extended confirmed), so this might get denied under WP:BOTNOTNOW. But this is actually a sound request, my first BRFA was outright silly. —usernamekiran (talk) 15:45, 14 November 2024 (UTC)reply
DreamRimmer, I think CheckWiki #90 would probably be more useful for finding the number of pages affected by this; at the moment it's sitting at ~4500 pages so this probably does require some sort of intervention. Primefac (talk) 20:19, 17 November 2024 (UTC)reply
@Ow0cast: Given there are around 4500 pages, this is indeed a useful task. Would you be able to program it to handle the subdomains? Similar to the example I provided above? —usernamekiran (talk) 20:25, 1 December 2024 (UTC)reply
@Usernamekiran: Yes, I should be able to make it handle subdomains. /etc/owuh $ (💬 | she/her) 20:29, 1 December 2024 (UTC)reply
Approved for trial (100 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 20:39, 1 December 2024 (UTC)reply
Should I run it on Special:RecentChanges or the pages listed at checkwiki? /etc/owuh $ (💬 | she/her) 22:26, 1 December 2024 (UTC)reply
@Ow0cast: pages listed at checkwiki would be the optimal choice. —usernamekiran (talk) 00:18, 5 December 2024 (UTC)reply
{{operator assistance needed}} I see the bot made some successful edits, but then stopped. Are you still working on the task? —usernamekiran (talk) 20:18, 24 January 2025 (UTC)reply
To be completely honest, I stopped working on it after getting stumped on people using wikipedia as a ref, then completely forgot about it and wikipedia (lot of family related things happened, plus exams and holidays) until I saw the notification. I probably won't be working on this again, but if I do, I'll just have it modify files on my PC and copy them to wikipedia manually, unless you (or someone) else want my terrible code to implement into another bot. /etc/owuh $ (💬 | she/her) 03:35, 26 January 2025 (UTC)reply
{{BotWithdrawn}} I am marking this as withdrawal for the time being. If you plan to continue, you can either file a new request or reopen this one—whichever works best for you. Just make sure to request a new trial if you decide to reopen it. – DreamRimmer (talk) 06:01, 28 January 2025 (UTC) Reopened at the user's request. – DreamRimmer (talk) 15:42, 19 February 2025 (UTC) reply

Requesting a new trial. /etc/owuh $ (💬 | she/her) 13:59, 20 February 2025 (UTC)reply

Feel free to continue. Primefac (talk) 14:26, 26 February 2025 (UTC)reply
Should I continue with the number of edits from the previous trial? /etc/owuh $ (💬 | she/her) 14:31, 26 February 2025 (UTC)reply
If you have changed your backend code, then yes, please start again. Otherwise, you can continue where you left off. Primefac (talk) 14:33, 26 February 2025 (UTC)reply
{{operator assistance needed}} What is the status of this? * Pppery * it has begun... 16:06, 20 May 2025 (UTC)reply

{{BotExpired}} No issue with re-opening as-is or filing a new task. – DreamRimmer 06:47, 8 July 2025 (UTC)reply

Re-opening as-is per above and requesting a new trial since I re-wrote it from the ground up /usr/bin/owuh $ (💬 | she/they) 00:55, 4 September 2026 (UTC)reply

{{BAG assistance needed}} /usr/bin/owuh $ (💬 | she/they) 03:14, 11 September 2026 (UTC)reply
Approved for trial (100 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. --Zackmann (Talk to me/What I been doing) 04:23, 11 September 2026 (UTC)reply
Trial complete. all edits done, none notable other than the following:
  • Special:Diff/1374444582: created formatting error like [[This|This]], somewhat my fault, somewhat not, bot fixes the ones it creates
  • Special:Diff/1374446375: formatting error (bottom of infobox) fixed, but i blame mediawiki
  • Special:Diff/1374446089: ditto, in "shermans advance" section
  • Special:Diff/1374456971: bad formatting error, it thought that the image size was the title, caused the page to have a bunch of massive flags, fixed
  • Special:Diff/1374543704: after a quick glance i dont think this broke anything but i for some reason i feel like it did, someone who better understands how file links work should take a closer look
  • Special:Diff/1374560974: nothing went wrong with this edit this is the most reasonable way to handle things (decided manually) that don't take wikilinks, i just chop off everything before "/wiki/", probably no problems with it but worth mentioning
/usr/bin/owuh $ (💬 | she/they) 22:07, 12 September 2026 (UTC)reply
Moving forward, how do you plan to fix these types of issues? While I understand they aren't entirely your fault, the edits (if left uncorrected) would cause issues. So if/when the bot becomes unsupervised, what is the plan to check for these issues? Zackmann (Talk to me/What I been doing) 22:38, 12 September 2026 (UTC)reply
since once it goes through the checkwiki #90 backlog, edits wont be very common from it, i will most likely check its edits every now and then (ideally once a week, but i dont know), see if it broke anything, if it did, fix it by hand and then fix it in code.
unfortunately, there are an infinite number of ways to format something that could result in a breakage due to humans being human. i will also implement something like what cluebot has to prevent edit warring, where it only reverts (or in my case) replaces once per article per 24 hours. plus have a link in its edit summary so people can report when it breaks formatting directly on my (or its) talk page. /usr/bin/owuh $ (💬 | she/they) 22:48, 12 September 2026 (UTC)reply

Approved requests

Bots that have been approved for operations after a successful BRFA will be listed here for informational purposes. No other approval action is required for these bots. Recently approved requests can be found here (edit), while old requests can be found in the archives.

Denied requests

Bots that have been denied for operations will be listed here for informational purposes for at least 7 days before being archived. No other action is required for these bots. Older requests can be found in the Archive.

Expired/withdrawn requests

These requests have either expired, as information required by the operator was not provided, or been withdrawn. These tasks are not authorized to run, but such lack of authorization does not necessarily follow from a finding as to merit. A bot that, having been approved for testing, was not tested by an editor, or one for which the results of testing were not posted, for example, would appear here. Bot requests should not be placed here if there is an active discussion ongoing above. Operators whose requests have expired may reactivate their requests at any time. The following list shows recent requests (if any) that have expired, listed here for informational purposes for at least 7 days before being archived. Older requests can be found in the respective archives: Expired, Withdrawn.