Jump to content

Wikipedia:Bots/Requests for approval

From Wikipedia, the free encyclopedia

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: Bunnypranav (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 15:35, Saturday, February 28, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): AutoWikiBrowaer

Source code available: AWB

Function overview: MOS:HEADCAPS fix for Iranian village capitalization

Links to relevant discussions (where appropriate): Wikipedia:Bot requests#Iranian village capitalization

Edit period(s): One time run

Estimated number of pages affected: ~35000, per this search, unless I have miscalculated antything

Exclusion compliant (Yes/No): No

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

Function details: Update

|settlement_type        = village

to

|settlement_type        = Village

in the pages in this search

The policy regarding this fix is MOS:HEADCAPS, per the discussion at Wikipedia:Bot requests#Iranian village capitalization

Discussion

Operator: Dušan Kreheľ (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 21:00, Thursday, February 26, 2026 (UTC)

Function overview: Edit the page about Slovak Italian places.

Automatic, Supervised, or Manual: Semi-manual or automatic

Programming language(s): Wikimate, own code in PHP.

Source code available: no for own code

Links to relevant discussions (where appropriate):

Edit period(s): one time, then only occasionally

Estimated number of pages affected: into 8000

Namespace(s): Mainspace

Exclusion compliant (Yes/No): No

Function details:

  • Actual:
    • Adding statistics and information's about Ethnicity and Population (as the content in actual section Aritzo#Population),
    • Adding section "Geography" (Ex. as Fintice#Geography).

Discussion

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

Time filed: 08:57, Thursday, February 26, 2026 (UTC)

Function overview: Update articles of US counties and municipalities (cities, towns, CDPs, boroughs and villages) to contain the latest census data. Data includes the 2020 decennial census, 2024 American Community Survey, and the 2023 population estimates.

Automatic, Supervised, or Manual: Supervised

Programming language(s): Python

Source code available: https://github.com/StuartMcClintock/wikipedia-census-cyrus/blob/main/poster.py

Links to relevant discussions (where appropriate):

Edit period(s): Periodic continuous runs to update certain chunks of data

Estimated number of pages affected: ~3000 county pages ~25000 municipality pages

Namespace(s): Articles

Exclusion compliant (Yes/No):

Function details: 1. Add 2020 census data to counties and municipalities that are missing it

2. Add 2024 ACS data to counties and municipalities that are missing it

3. Add 2023 or more recent population estimates to historical population tables (plus direction indicators such as Increase)

4. Update ledes of articles that still mention a population older than the 2020 census (eg 2010 census)

Discussion

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: 82,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]

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

Time filed: 05:40, Saturday, January 3, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): R

Source code available:

Function overview: Reviews images in articles to see if they have an alternative text parameter. This is useful for people who use screen readers, use browsers that do not support images, or are visually impaired. MOS:ALT does a good job at explaining what alternative text is important. The bot will then add a hidden maintenance category to the article noting that it has images without alt text. Additionally the bot will create a report and post it in it's userspace with how many images each pages has and how many of them contain alt text.

Links to relevant discussions (where appropriate):

Edit period(s): Continuous

Estimated number of pages affected: Many

Exclusion compliant (Yes/No): No

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

Function details: Selects articles either at random, by a predefined category, or from a list provided by the user.

Using the API the bot will request the page and then search looking for images that either does not have the alt parameter or or has an alt parameter that is blank. To prevent non-images from being selected (audio or video) only files with an image extension will be processed.

Records the results with the article name, image filename, and whether the image has alt text.

After it has completed that it then will also add up the total images found, how many have alt text, how many do not have alt text, and the percentage missing.

If there are images that do not have alt text then the article is added to a hidden maintenance category noting that the page has images that do not have alt text.

Discussion

This might be a silly question, but if the bot is already creating a list of pages that have images without alt text in its own userspace, why do we need a hidden maintenance category that will essentially just duplicate that list? Seems like it would make more sense to have this as a database report or similar. Primefac (talk) 11:19, 3 January 2026 (UTC)[reply]

I figured if it was going to be a large number of pages then it might be easier to navigate in some sort of structured category system. But I could also automate that into the report system instead without much additional work. Dr vulpes (Talk) 11:22, 3 January 2026 (UTC)[reply]
I'm indifferent to the idea of adding a hidden maintenance category, but I'd suggest it be added via a maintenance template like {{Alternative text missing}} or {{No alt text}} rather than adding a bare category as seems implied here. Anomie 16:13, 3 January 2026 (UTC)[reply]
Give me a day to work out the code to make sure I can do this in R. Dr vulpes (Talk) 05:03, 5 January 2026 (UTC)[reply]

Has this been discussed anywhere? The MOS is not binding. While we all agree that alt text is useful, there are probably hundreds of thousands of articles which don't use it. I don't see the benefit of doing a gazillion edits to populate a maintenance category when it's not clear if there are editors willing to work through such a backlog. As Primefac says, creating lists in userspace or project space seems like a better approach. – SD0001 (talk) 12:33, 3 January 2026 (UTC)[reply]

  • Questions: How will the bot deal with images that deliberately have no alt text, per MOS:EMPTYALT? Will the bot differentiate between a completely missing |alt= and a present but empty |alt=? Have you considered using a database report to query for the Linter id "missing-image-alt-text" (id 23)? If someone subsequently adds alt text to all images on a page but does not remove the tracking category, will the bot return to the page to remove the category? I think a process to identify missing alt text that should be present is valuable, but this seems like something that might be better to start as a database report that could be refined for a while to eliminate false positives. – Jonesey95 (talk) 15:52, 3 January 2026 (UTC)[reply]
    That’s a really good point @Jonesey95 and wasn’t something I had thought of. I kind of got tunnel visioned into solving the technical problem and didn’t think of pulling from the database.
    The way I wrote the code is it looks for both an empty alt field or an alt field that is blank.
    Dr vulpes (Talk) 21:46, 3 January 2026 (UTC)[reply]
@SD0001 how about limiting its run to articles with a certain amount of traffic or the top X articles? I don’t really want to add a ton of pages to a list if there’s no chance that the issue will be addressed. But keeping the range tight will kind of work towards making articles that are read more often will be more accessible. Dr vulpes (Talk) 21:44, 3 January 2026 (UTC)[reply]
That seems like a good idea for a place to start. A database query or database dump query might be able to test for a category like "Good articles" or for the presence of a Featured article indicator. – Jonesey95 (talk) 00:13, 4 January 2026 (UTC)[reply]
Yeah that works, it would be impactful enough to matter and small enough to be manageable. Dr vulpes (Talk) 01:25, 4 January 2026 (UTC)[reply]

Wouldn't it be much better if alt text was stored at the file level (here or at Commons), instead of in the articles? We already have a caption for article-specific descriptions, but repeating the normally same alt text on every article that uses an image is overkill. Tagging probably hundreds of thousands of articles for something better solved elsewhere (with a technical improvement that not only displays the image but includes the alt text for screen readers) seems the better long-term solution. List of paintings by Claude Monet is a 300K article already, adding alt texts will not only be a massive task but expand the page size and code dramatically. I don't think this task should be done without wider discussion and a clear consensus. Fram (talk) 12:28, 7 January 2026 (UTC)[reply]

I like this idea. The image itself should be the place where the alt text is provided as that shouldn't change regardless of the article it is placed on. This change can then also be part of the WP:FP criteria. Unsure if the system is set up for this to work though. Gonnym (talk) 11:21, 16 January 2026 (UTC)[reply]
There would at least need to be an ability to override for special cases. MOS:ALTCON disagrees with the assertion that the alt text should always be the same for every use, MOS:ALTINCAPTION suggests that in particular the alt text should not be redundant to the adjacent text, and for icons MOS:PDI suggests some cases should have no alt text and some should be functional (e.g. "next page") rather than descriptive (e.g. "arrow pointing right"). Anomie 12:58, 16 January 2026 (UTC)[reply]
Well an alt text describing that picture as an elderly woman wearing a black hat is horrible. That does a complete disservice to people that are using screen readers. That's why I said that it should tie to the FP criteria, where editors can flesh out a good alt text. If a person wants a picture of a random old woman wearing a black hat, then they should use any other image other then the Queen of England (or celebrity). If a famous person is used, it should be described. For the second part, I agree with you. A simple override should exist for those situations where the guideline says not to use an alt.--Gonnym (talk) 17:33, 19 January 2026 (UTC)[reply]

Bots in a trial period

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

Time filed: 00:02, Wednesday, February 25, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): AWB

Source code available: AWB

Function overview: Update deprecated parameters on {{Infobox mountain}}

Links to relevant discussions (where appropriate): Unopposed deprecation discussion of photo param

Edit period(s): One time run

Estimated number of pages affected: ~27,800

Exclusion compliant (Yes/No): Yes

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

Function details: This is a fairly simple parameter replacement run. The pages are in Category:Pages using infobox mountain with deprecated parameters. The vast majority of the parameters that will be replaced are {{{photo}}}, but this will cover all of the deprecated parameters. I am aware that @OpalYosutebito: appears to be chipping away at this manually, but at 28K pages, I figure a bot run might be a little more appropriate. Also going to ping @Zackmann08: who brought this to my attention. Happy to answer any questions!

Discussion

That sounds great! Just be sure to watch for duplicate parameters. :) - OpalYosutebitotalk』 『articles I want to eat15:21, 25 February 2026 (UTC)[reply]

Approved for trial (100 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete.DreamRimmer 06:10, 26 February 2026 (UTC)[reply]
Edits as requested. I did catch one instance of the bot adding a duplicate parameter (but I fixed it immediately), so I'll be keeping a close eye on when this runs. phuzion (talk) 04:37, 28 February 2026 (UTC)[reply]
On hold, as we figure out some things with the template. phuzion (talk) 17:34, 28 February 2026 (UTC)[reply]
I object to the bot run. This BRFA was submitted only 4 days after a misleading summary of the proposed edits was posted to Template talk:Infobox mountain. This needs to get consensus before it can even start. Any edits done so far should be reverted. — hike395 (talk) 18:50, 28 February 2026 (UTC)[reply]

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

Time filed: 01:29, Tuesday, February 10, 2026 (UTC)

Function overview: Maintain the participants list of a MilHist task force (e.g. Wikipedia:WikiProject Military history/Military aviation task force).

Automatic, Supervised, or Manual: Automatic

Programming language(s): C#

Source code available: https://gitlab.wikimedia.org/toolforge-repos/milhistbot-membership

Links to relevant discussions (where appropriate): Wikipedia talk:WikiProject Military history/Coordinators#Wikipedia:WikiProject Military history/Military aviation task force

Edit period(s): daily

Estimated number of pages affected: 57

Namespace(s): Wikipedia

Exclusion compliant (Yes/No): Yes

Function details: Go through the membership of a MilHist task force (e.g. Wikipedia:WikiProject Military history/Military aviation task force) and comment out members inactive for more than 365 days. Uncomment members who were inactive but have now resumed activity.

Discussion

Which are the 20 pages that this affects? – SD0001 (talk) 09:46, 10 February 2026 (UTC)[reply]
The pages in Category:WikiProject Military history task forces. Actually, there are 57 pages. Hawkeye7 (discuss) 19:55, 25 February 2026 (UTC)[reply]
Approved for trial (2 weeks). Please provide a link to the relevant contributions and/or diffs when the trial is complete.SD0001 (talk) 03:57, 26 February 2026 (UTC)[reply]

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

Time filed: 12:58, Tuesday, September 16, 2025 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: GitHub

Function overview: Update US settlement census data

Links to relevant discussions (where appropriate): Request 1 · Request 2

Edit period(s): Yearly; new estimates released yearly

Estimated number of pages affected: Unknown, likely low 10 thousands

Exclusion compliant (Yes/No): Yes

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

Function details:

  • Doesn't add to a template if it sees there are multiple of it on the same page
  • Doesn't overwrite info if it is same age or newer

Discussion

Supervised Test 1 & Supervised Test 2 Scaledish! Talkish? Statish. 13:06, 16 September 2025 (UTC)[reply]

Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Since this is your first bot task, I am treating this as a one-off task. For future years, a new BRFA will be needed, and then we can see if it can be approved to run annually. – DreamRimmer 13:58, 24 September 2025 (UTC)[reply]

{{Operator assistance needed}} Anything on the trial? Tenshi! (Talk page) 11:52, 7 October 2025 (UTC)[reply]

Hi, the trial is not yet concluded.
As part of the trial, the bot was ran twice, both times being stopped due to eventually forming a false association between the database and the article. This lead to the conclusion that the match script needs to be improved significantly, which I will do but haven't yet had the time. I still believe a reasonable fix is possible. Likely, as part of this, a semi-supervised confidence approach will be adopted where, if confidence isn't overwhelmingly high, the association is sent for manual review.
Also as part of the trial, an additional issue was identified. If the infobox population is from <2010, is cited using a named reference, and elsewhere in the body that reference is referenced, a cite error is caused because those references are now dangling. This may be a simple fix, but needs to be implemented.
When both of these fixes are implemented, I plan to resume the bot for the remaining ~25 trial edits. Afterwards, I will request an additional 50 trial edits. Scaledish! Talkish? Statish. 17:16, 7 October 2025 (UTC)[reply]

{{Operator assistance needed}} Any progress on the fixes? Tenshi! (Talk page) 12:32, 7 November 2025 (UTC)[reply]

I apologize for the delay, my real life workload is roughly cyclical—you can see that reflected in my xtools stats. I expect to be able to work on it again within a week or two. Scaledish! Talkish? Statish. 19:55, 7 November 2025 (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? – DreamRimmer 13:49, 8 February 2026 (UTC)[reply]

Bots that have completed the trial period

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

Time filed: 23:04, Monday, February 9, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s):

Source code available:

Function overview: Fixes a botched historical substitution of {{W-shout}} on user and user talk pages by converting it to the modern, intended wikitext/HTML structure without removing any content.

Links to relevant discussions (where appropriate): User talk:Vanderwaalforces#Another bot run fix hopefully

Edit period(s): One-time run

Estimated number of pages affected: 2975 from search

Exclusion compliant (Yes/No): Yes

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

Function details: The bot performs the following actions:

  • Identifies user and user talk pages containing a known malformed substitution of {{W-shout}}.
  • Converts the broken output into the modern intended format by:
    • Moving the “Welcome!” heading outside of the styled
    • Removing obsolete {{#if}} and {{#ifeq}} parser-function wrappers left behind
    • Removing stray opening and closing <p> tags introduced
    • Preserving all user-facing content, signatures, links, and formatting
    • Appending <!--Template:W-shout--> as a tracking comment
  • The bot does not modify pages unless the exact broken pattern is detected.

Discussion

I've requested this task as it clears some issues that I've encountered when fixing lint errors, including missing talk page headings and everything stated above. --Gonnym (talk) 06:40, 10 February 2026 (UTC)[reply]

The messages that were posted incorrectly to the user page instead of the talk page should either be deleted or moved. I don't really think there is reason to move them to the talk page at this point (but that isn't something I'm opposed if this is what needs to happen). Gonnym (talk) 06:43, 10 February 2026 (UTC)[reply]
@Gonnym I am as well surprised, like I said earlier. It's a little bit complicated; some messages were posted on both the user and user talk pages, some where only the user page, some of the users who have the message on their user page do not have a talk page at all, while some have a talk page but the welcome message was not posted to their user talk. Vanderwaalforces (talk) 07:57, 12 February 2026 (UTC)[reply]
@Gonnym Just to be sure (because this is programmatic, there have to be something specific to do), regarding the notices posted to the main user pages, should they just be deleted? I also do not see any reason to move them to the talk page, also, moving them to the talk page will be pretty unrealistic IMO. Vanderwaalforces (talk) 17:49, 15 February 2026 (UTC)[reply]
I think they should be deleted. They never belonged on non-talk pages and I don't know what they are worth now moving to talk pages. Gonnym (talk) 09:05, 16 February 2026 (UTC)[reply]

Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 17:44, 15 February 2026 (UTC)[reply]

@Primefac Tysm! Trial complete. See contributions.
In the earliest 27 or so edits, I realised that some of these notices initially had a "Welcome" heading, and that after the fixes we then had two headers, I later fixed that by using regex to remove the duplicating header. Vanderwaalforces (talk) 09:35, 16 February 2026 (UTC)[reply]
@Vanderwaalforces in this edit a closing p tag was left which should also be removed (or the opening p kept). Gonnym (talk) 09:45, 16 February 2026 (UTC)[reply]
Also, can the if parser functions be removed in the "We're so glad you're here!" paragraph? Gonnym (talk) 09:47, 16 February 2026 (UTC)[reply]
@Gonnym Ah, I didn’t observe that particular closing p tag. Also, it is weird to find out that some of the We’re so glad paragraph has if parser functions, while some do not have.
I’ll tend to these rn. Vanderwaalforces (talk) 09:52, 16 February 2026 (UTC)[reply]
Yeah I noticed that also. The parser functions were probably fixed at some point in the template. Gonnym (talk) 09:58, 16 February 2026 (UTC)[reply]
@Gonnym After reviewing the edit you mentioned above properly, it becomes obvious that the if parser functions at the last paragraph is not hardcoded in the welcome template; it came from the user's signature. So, I am not sure I should be programming that sort of removal when that occurrence might just be singular. Vanderwaalforces (talk) 16:35, 16 February 2026 (UTC)[reply]
Sure np, any usages that left and I find, I'll just remove manually. Gonnym (talk) 16:47, 16 February 2026 (UTC)[reply]
Okay, we're good to go; everything is in order. @Primefac. Vanderwaalforces (talk) 17:12, 16 February 2026 (UTC)[reply]
A user has requested the attention of a member of the Bot Approvals Group. Once assistance has been rendered, please deactivate this tag by replacing it with {{t|BAG assistance needed}}. Vanderwaalforces (talk) 15:36, 24 February 2026 (UTC)[reply]

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

Time filed: 16:19, Thursday, January 29, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s):

Source code available:

Function overview: Automatically delinks the "Country" value in the "subdivision_type" parameter of {{Infobox settlement}} templates across articles, replacing any instance of [[List of sovereign states|Country]] with plain "Country"

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Infobox_settlement_country_label_easter_egg/overlink_delinking

Edit period(s): Continuous

Estimated number of pages affected: 152,399 from search on mainspace pages

Exclusion compliant (Yes/No): Yes

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

Function details: So, it will perform a precise, text-only replacement within {{Infobox settlement}} templates:

  • Scans only the article namespace for the presence of the target pattern.
  • Identifies the "subdivision_type" parameter inside each Infobox settlement template.
  • Detects any occurrence of the value [[List of sovereign states|Country]].
  • Replaces the value with "Country".
  • Does not affect templates outside {{Infobox settlement}} or any other content in articles.
  • Then save with an edit summary: "Delink 'Country' in Infobox settlement subdivision_type".

Discussion

{{BAG assistance needed}}Vanderwaalforces (talk) 16:02, 15 February 2026 (UTC)[reply]

Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 18:29, 15 February 2026 (UTC)[reply]
Trial complete. See contributions. Vanderwaalforces (talk) 19:22, 15 February 2026 (UTC)[reply]
A user has requested the attention of a member of the Bot Approvals Group. Once assistance has been rendered, please deactivate this tag by replacing it with {{t|BAG assistance needed}}. Vanderwaalforces (talk) 15:13, 24 February 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.