Wikipedia

Wikipedia:Bots/Requests for approval

< Wikipedia:Bots

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
I Before applying for approval
  • Read the bot policy, and check the list of frequently denied bot requests.
  • If your task could be controversial (e.g. most bots making non-maintenance edits to articles and most bots posting messages on user talk pages), seek consensus for the task. Common places to start include WP:Village pump (proposals) and the talk pages of the relevant policies, guidelines, templates, and/or WikiProjects. Link to this discussion in your request for approval.
  • You will need to create an account for your bot if you haven't already done so. Click here when logged in to create the account, linking it to yours. (If you do not create the bot account while logged in, it is likely to be blocked as a possible sockpuppet or unauthorised bot until you verify ownership)
  • Create a userpage for your bot, linking to your userpage (this is commonly done using the {{bot}} template) and describing its functions. You may also include an 'emergency shutoff button'.
II Filing the application
  • Enter your bot's user name in the box below and click the button. If this is a request for an additional task, put a task number as well (e.g. BotName 2).
  • Complete the questions on the resulting page and save it.

  • Your request must now be added to the correct section of the main approvals page: Click here and add {{BRFA}} to the top of the list, directly below the comment line.
    • For a first request: use {{BRFA|bot name||Open}}
    • For an additional task request: use {{BRFA|bot name|task number|Open}}
III During the approvals process
  • During the process, an approvals group member may approve a trial for your bot (typically after allowing time for community input), and AnomieBOT will move the request to this section.
  • Run the bot for the specified number of edits/time period, then add {{Bot trial complete}} to the request page. It helps if you also link to the bot's contributions, and comment on any errors that may have occurred.
  • AnomieBOT will move the request to the 'trial complete' section by moving the {{BRFA}} template that applies to your bot
  • If you feel that your request is being overlooked (no BAG attention for ~1 week) you can add {{BAG assistance needed}} to the page. However, please do not use it after every comment!
  • At any time during the approvals process, you may withdraw your request by adding {{BotWithdrawn}} to your bot's approval page.
IV After the approvals process
  • After the trial edits have been reviewed and enough time has passed for any more discussion, a BAG member will approve or deny the request appropriately.
    • For approved requests: The request will be listed here. If necessary, a bureaucrat will flag the bot within a couple of days and you can then run the task fully (it's best to wait for the flag, to avoid cluttering recent changes). If the bot already has a flag, or is to run without one, you may start the task when ready.
    • For denied/expired/withdrawn requests: The request will be listed at the bottom of the main BRFA page in the relevant section.
Bot-related archives
Noticeboard
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
Bots (talk)
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
21, 22
Newer discussions at WP:BOTN since April 2021
Bot policy (talk)
19, 20, 21, 22, 23, 24, 25, 26, 27, 28
29, 30
Pre-2007 archived under Bots (talk)
Bot requests
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
21, 22, 23, 24, 25, 26, 27, 28, 29, 30
31, 32, 33, 34, 35, 36, 37, 38, 39, 40
41, 42, 43, 44, 45, 46, 47, 48, 49, 50
51, 52, 53, 54, 55, 56, 57, 58, 59, 60
61, 62, 63, 64, 65, 66, 67, 68, 69, 70
71, 72, 73, 74, 75, 76, 77, 78, 79, 80
81, 82, 83, 84, 85, 86, 87
Bot requests (talk)
1, 2
Newer discussions at WP:BOTN since April 2021
BRFA
Old format: 1, 2, 3, 4
New format: Categorized Archive (All subpages)
BRFA (talk)
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15
Newer discussions at WP:BOTN since April 2021
Bot Approvals Group (talk)
1, 2, 3, 4, 5, 6, 7, 8, 9
BAG Nominations


Bot Name Status Created Last editor Date/Time Last BAG editor Date/Time
IUCNStatusBot (T|C|B|F) Open 2025-03-25, 05:46:08 AidenD 2025-07-03, 06:17:58 TheSandDoctor 2025-07-02, 22:46:23
AussieBot 2 (T|C|B|F) In trial 2025-06-18, 11:00:52 Hawkeye7 2025-07-09, 02:34:46 DreamRimmer 2025-07-08, 10:37:27
GraphBot 2 (T|C|B|F) In trial 2025-07-02, 21:00:07 DreamRimmer 2025-07-08, 06:35:57 DreamRimmer 2025-07-08, 06:35:07
CX Zoom AWB 2 (T|C|B|F) In trial 2025-06-24, 12:55:26 DreamRimmer 2025-07-03, 16:54:49 DreamRimmer 2025-07-03, 16:54:49
SodiumBot 3 (T|C|B|F) In trial 2025-06-18, 18:16:08 Sohom Datta 2025-07-02, 15:18:13 ProcrastinatingReader 2025-06-29, 10:48:39
VWF bot 2 (T|C|B|F) In trial 2025-05-28, 16:11:04 Primefac 2025-06-08, 13:32:41 Primefac 2025-06-08, 13:32:24
DeadbeefBot II (T|C|B|F) In trial 2025-05-23, 02:10:50 Dbeef 2025-07-04, 05:54:54 Anomie 2025-07-02, 12:14:42
CFA (bot) (T|C|B|F) In trial: User response needed! 2024-12-31, 05:00:34 DreamRimmer 2025-07-08, 06:53:40 DreamRimmer 2025-07-08, 06:53:40
SodiumBot 2 (T|C|B|F) In trial: User response needed! 2024-07-16, 20:03:26 Sohom Datta 2025-07-02, 15:09:45 DreamRimmer 2025-01-26, 08:10:11
Bot1058 10 (T|C|B|F) Trial complete 2025-03-07, 17:49:45 Pppery 2025-07-01, 16:37:17 Primefac 2025-06-08, 13:12:35
CanonNiBot 1 (T|C|B|F) Trial complete 2024-12-17, 12:50:01 Primefac 2025-06-23, 23:24:21 Primefac 2025-06-23, 23:24:21

Current requests for approval

IUCNStatusBot

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

Time filed: 05:45, Tuesday, March 25, 2025 (UTC)

Function overview:

A bot that updates the IUCN Red List status of Wikipedia pages.

Automatic, Supervised, or Manual:

Automatic

Programming language(s):

Python

Source code available: https://github.com/DartAiden/IUCN_Status_Bot/tree/main

Links to relevant discussions (where appropriate): No discussion really applicable. I briefly made a request to see if anything was existing, only to receive little reply. https://en.wikipedia.org/wiki/Wikipedia:Bot_requests#IUCN_Status_Bot

Edit period(s):

Run once

Estimated number of pages affected:

Around 11,000.

Namespace(s): Wikipedia pages for species.

Exclusion compliant (Yes/No): Not really relevant.

Function details:

This is a simple script to update the IUCN Red List status of Wikipedia pages for birds, though the functionality can most likely be extended elsewhere. The IUCN Red List status is a measure of conservation status included in the species box of most birds. This bot extracts the name of the citation to ensure contiguity of editing, updates the status itself, and then updates the reference. This bot would be run once now, to standardize the citations, and once every time the Red List is updated, though it is necessary only to run it with those species that are being updated. I may add other functionality in the future, such as updating the actual pages that list statuses (List of critically endangered birds).

Discussion

Would it be worth doing this on Wikidata instead, and then have the template pull from there? — Qwerfjkltalk 12:41, 27 May 2025 (UTC)[reply]
I wrote a bot once that did sommat similar updates by querying the IUCN API. There was sufficient adverse editor pushback that I retired the bot.
—Trappist the monk (talk) 13:49, 27 May 2025 (UTC)[reply]
What was the nature of the pushback? ꧁Zanahary꧂ 21:16, 27 May 2025 (UTC)[reply]
Convenience links: Wikipedia:Bots/Requests for approval/Monkbot 19, User talk:Trappist the monk/Archive 23#Monkbot Task 19 - IUCN status –Novem Linguae (talk) 21:23, 27 May 2025 (UTC)[reply]
Thanks. Looks like it was really a content dispute about whether "Critically Endangered (Possibly Extinct)" is a valid IUCN designation. ꧁Zanahary꧂ 21:34, 27 May 2025 (UTC)[reply]
AidenD, Edit period: Runce on? Primefac (talk) 13:29, 8 June 2025 (UTC)[reply]
What? AidenD (talk) 20:15, 8 June 2025 (UTC)[reply]
That is what you have listed in the edit period for this bot. I was looking for clarification because I have never heard of that sort of time frame. Primefac (talk) 20:36, 8 June 2025 (UTC)[reply]
I think they mean "Run once". – SD0001 (talk) 21:28, 8 June 2025 (UTC)[reply]
That would make sense. Incidentally, that's about the only option I didn't think of. Primefac (talk) 22:50, 8 June 2025 (UTC)[reply]
Whoops, that is what I meant. My apologies. AidenD (talk) 04:42, 9 June 2025 (UTC)[reply]
{{BAG assistance needed}} * Pppery * it has begun... 16:37, 1 July 2025 (UTC)[reply]
AFAICS, this bot would run into the same concern raised with Monkbot 19 - that it doesn't consider "PE" as a valid designation, although Template:Taxobox/species does, and therefore would overwrite the classifications of species currently denoted with a status of "PE". Is that a correct understanding? If so, probably that should be settled as a content decision in some other venue first. ProcrastinatingReader (talk) 19:02, 1 July 2025 (UTC)[reply]
It might also be possible to work around the content dispute. For example, programming the bot not to touch anything that is already PE onwiki. –Novem Linguae (talk) 23:19, 1 July 2025 (UTC)[reply]
It may also comment out new PE designations, which could then be automatically removed or uncommented on resolution of the dispute. ꧁Zanahary꧂ 02:29, 2 July 2025 (UTC)[reply]
That is a very good point. @AidenD: Would it be possible to integrate that from above before we consider any sort of trial? TheSandDoctor Talk 22:46, 2 July 2025 (UTC)[reply]
They can be manually added, the unfortunate problem is that the IUCN API does not discern between those - I can always manually add them, however. AidenD (talk) 06:17, 3 July 2025 (UTC)[reply]

Bots in a trial period

AussieBot 2

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

Time filed: 11:00, Wednesday, June 18, 2025 (UTC)

Function overview: The Bot will go through:

and resolve conflicting quality ratings, setting it to stub or start depending on its rating in Liftwing.


Automatic, Supervised, or Manual: Automatic

Programming language(s): C#

Source code available: [1]

Links to relevant discussions (where appropriate): Template talk:WikiProject banner shell#Conflicting quality ratings

Edit period(s): Daily until all are resolved.

Estimated number of pages affected: ~ 35,000

Namespace(s): Talk

Exclusion compliant (Yes/No): Yes

Function details: Bot goes through each article in the category, clears the current ratings and applies the Liftwing rating of start or stub as appropriate.

Discussion

Thanks for filing this. I think we discussed running this for all Stub/Start/C classes? So that would include the following categories:

— Martin (MSGJ · talk) 12:06, 18 June 2025 (UTC)[reply]

Yes, the bot can handle this. Hawkeye7 (discuss) 12:33, 18 June 2025 (UTC)[reply]
@MSGJ: In testing, I have found that some of the C-class articles would be eligible for a B-class rating. Should they be rated B or C? Hawkeye7 (discuss) 20:28, 22 June 2025 (UTC)[reply]
I think the bot should rate according to its algorithm. Could it produce a log so that we can spot check a sample manually? — Martin (MSGJ · talk) 07:58, 23 June 2025 (UTC)[reply]
Yes, it can. Normally on WikiProject:Military History we double-check all the articles that have been Bot-rated as B-class. Hawkeye7 (discuss) 19:24, 25 June 2025 (UTC)[reply]
Hmmm. Maybe I cannot. The Bot requires the createpage right to be able to do this. Hawkeye7 (discuss) 04:28, 2 July 2025 (UTC)[reply]
All registered users have the right. You likely need to adjust the BotPassword grants to include it. – SD0001 (talk) 15:48, 4 July 2025 (UTC)[reply]
All users should have this right, but AussieBot does not and I do not know how to grant it. Hawkeye7 (discuss) 20:11, 4 July 2025 (UTC)[reply]
Go to Special:BotPasswords, open the botpassword you're using in the bot, tick the "Create, edit, and move pages" grant. Update. – SD0001 (talk) 07:14, 5 July 2025 (UTC)[reply]
  Done Hawkeye7 (discuss) 18:48, 5 July 2025 (UTC)[reply]

If you plan to cover all the mentioned categories, please update the function details to reflect them, and adjust the estimated number of pages affected and the function overview accordingly. – DreamRimmer ■ 06:05, 8 July 2025 (UTC)[reply]

  Done Hawkeye7 (discuss) 07:12, 8 July 2025 (UTC)[reply]
Since LiftWing may rate some of them as B or C class, please update the task details to reflect that. The lines that say "rating of start or stub as appropriate" and "stub or start depending on its rating in LiftWing" should be updated to include B and C as well. – DreamRimmer ■ 10:32, 8 July 2025 (UTC)[reply]

  Approved for trial (120 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Please process 20 pages from each category. – DreamRimmer ■ 10:37, 8 July 2025 (UTC)[reply]

  Done The report can be found here Hawkeye7 (discuss) 02:34, 9 July 2025 (UTC)[reply]

GraphBot 2

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

Time filed: 21:00, Wednesday, July 2, 2025 (UTC)

Function overview:

Automatic, Supervised, or Manual: Automatic

Programming language(s): Rust/Python

Source code available: Uses mwbot

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Redirects_related_to_those_nominated_at_RfD and Wikipedia talk:Redirects for discussion#Avoided double redirects of nominated redirects

Edit period(s): Continous

Page: Wikipedia:Redirects_for_discussion

Exclusion compliant (Yes/No): Yes (but N/A)

Adminbot (Yes/No): No

Function details:

  • Look at each RFD on each RFD Page
  • Determines whether there are any other redirects, in any namespace, that meet one or more of the following criteria:
    • Are marked as an avoided-double redirect of a nominated redirect
    • Are redirects to the nominated redirect
    • Redirect to the same target as the nominated redirect and differ only in the presence or absence of non-alphanumeric characters, and/or differ only in case
  • If the bot finds any redirects that match and which are not currently nominated at RfD, then it should post a message in the discussion (final details about the message are TBD, but the bot request outline the general point). The bot limits the length of it's message, ensuring that the RfD is not over-cluttered.

Discussion

Thanks for working on this GalStar, but it's not clear whether it is checking for redirects that differ only in the presence/absence of diacritics? Thryduulf (talk) 23:41, 2 July 2025 (UTC)[reply]

Diacritics fall under non-alphanumeric characters. GalStar (talk) (contribs) 16:48, 3 July 2025 (UTC)[reply]

  Approved for trial (30 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. – DreamRimmer ■ 06:35, 8 July 2025 (UTC)[reply]

CX Zoom AWB 2

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

Time filed: 12:55, Tuesday, June 24, 2025 (UTC)

Function overview: Implementing behavior change for {{PresFoot}}, compliance with MOS:CHRONO

Automatic, Supervised, or Manual: Manual

Programming language(s): AWB, Python

Source code available: Yes, see User:CX Zoom AWB/Task 2

Links to relevant discussions (where appropriate): Special:Permalink/1296419942#Behavior change for {{PresFoot}}

Edit period(s): One-time run

Estimated number of pages affected: 2950

Namespace(s): Mainspace (mostly), few Userspace and Projectspace pages too

Exclusion compliant (Yes/No): No; templates will have erroneous output if all uses are not resolved

Function details: This task will find uses of {{PresFoot}} and replace them with {{PresRow}} followed by {{PresFoot}} (with no parameters; new behaviour for this template). It will then reorder all the {{PresRow}} in the article in chronological order. It will also check for potential stray table closer |} and remove them.

Discussion

  Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. – DreamRimmer ■ 16:54, 3 July 2025 (UTC)[reply]

SodiumBot 3

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

Time filed: 18:15, Wednesday, June 18, 2025 (UTC)

Function overview: Taking over the functions of User:Yapperbot (frs, pruner, uncurrenter, not wikidatatable), the maintainer has been inactive for 3 years and API changes have caused the bot to become brittle, keep stopping and requiring frequent restarts that require upkeep and/or Toolforge admin intervention. I intend to keep the same code and actions but include maintaince fixes to make it less brittle. The primary reason to take over the task is so that we don't need to bother Toolforge admins for every outage.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Golang

Source code available: Yes, (forked repos: [2], [3], [4])

Links to relevant discussions (where appropriate): User talk:Yapperbot (the three discussions on the page are all about failures of the bot)

Edit period(s): Continous

Estimated number of pages affected: FRS and Pruner are opt-in, so as many users and pages opt-in, uncurrenter depends on the number of {{current}} templates placed

Namespace(s): Mainspace, Talk, Userspace

Exclusion compliant (Yes/No): No, uncurrenter is article-facing, and frs and pruner are explicitly opt-in

Function details:

  • FRS - Running the Feedback request service
  • Pruner - Removes inactive members from WP:FRS and other Wikiproject lists
  • Uncurrenter - Removes {{current}} from pages where it has been around for a long time.

For everything except FRS the original un-modified code will be used, for FRS, minor maintainence fixes will be made. If this bot is trialed or approved, Yapperbot should be blocked to only operate in userspace

Discussion

Original BRFAs for reference:
– SD0001 (talk) 14:50, 19 June 2025 (UTC)[reply]
Can you email the botop to stop the tasks being taken over? We could partial-block if necessary but that's more of a last resort. – SD0001 (talk) 14:51, 19 June 2025 (UTC)[reply]
Sent! Sohom (talk) 15:34, 19 June 2025 (UTC)[reply]
SD0001, do you have any thoughts about this being three tasks in one? Obviously FRS and pruner are related so I could see those combined, but uncurrenter seems rather unrelated. I'd rather split that off into a separate task. Primefac (talk) 01:23, 21 June 2025 (UTC)[reply]
I think it's fine as these are previously approved tasks and the same code is being reused, so there's probably not much chance of things breaking. – SD0001 (talk) 06:46, 21 June 2025 (UTC)[reply]

  Approved for trial (30 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. The FRS job is stuck again, and since the current operator has not responded, we should consider other ways to stop it. There is a switch page at User:Yapperbot/kill/FRS that can be used to stop the job, which is a better option than blocking it. I am approving a 30-day trial so that we can monitor for any errors and give you time to adjust the code for long-term stability. This trial is limited to the FRS and pruner tasks. Since there is no control page for the pruner task, partially blocking it from the Wikipedia and User talk namespaces should be a suitable workaround. – DreamRimmer ■ 17:15, 28 June 2025 (UTC)[reply]

Do we still need uncurrenter? Does Wikipedia:Bots/Requests for approval/ProcBot 10 not cover that area sufficiently? * Pppery * it has begun... 04:09, 29 June 2025 (UTC)[reply]

I did some looking through the code, there was/is a kill switch in the form of User:Yapperbot/kill/Pruner for pruner. I've gone and activated it alongside the FRS kill switch. Sohom (talk) 19:59, 28 June 2025 (UTC)[reply]
(For the period of 30 days) Sohom (talk) 19:59, 28 June 2025 (UTC)[reply]
Noting that the pruner job appears to be broken, I'll throw some time into fixing it and run a manual run (the typical schedule appears to be once a month). Sohom (talk) 13:47, 1 July 2025 (UTC)[reply]
Pruner's manual run is complete this is a list of all edits made for the task. Sohom (talk) 15:18, 2 July 2025 (UTC)[reply]
@Pppery ProcBot says that the task is inactive and [5] says that the uncurrenter job is active. I'm honestly not sure what is going on and who is doing it. (cc @ProcrastinatingReader who might be answer this more cleanly -- I'm happy to drop it completely if the task has already been supersed -- though we should kill the task from User:Yapperbot's side then) Sohom (talk) 04:24, 29 June 2025 (UTC)[reply]
Yapperbot was intermittently crashing when I filed ProcBot 10, but was working again sometime after approval, so I run ProcBot 10 (which is active atm on Toolforge) to deal with current-related templates (like {{current related}}, which Yapperbot didn't cover). I don't know if Yapperbot has broken on {{current}} since then. I can extend ProcBot 10 to cover regular {{current}} in any case.
I'm not opposed to the approval of this task as-is, including uncurrenter, though. Doesn't hurt to improve reliability (especially as I am around a bit less these days). ProcrastinatingReader (talk) 10:48, 29 June 2025 (UTC)[reply]

VWF bot 2

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

Time filed: 16:11, Wednesday, May 28, 2025 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available:

Function overview: Automatically remove transclusions of closed RfD discussions (see example) for convenience regular upkeep.

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Removing_fully_completed_daily_RfD_list_pages_from_the_main_RfD_page

Edit period(s): Continuous

Estimated number of pages affected: 1

Exclusion compliant (Yes/No): No

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

Function details: The bot will remove transclusions of closed RfD discussions (see example) for convenience regular upkeep. More examples at Special:History/Wikipedia:Redirects for discussion.

Discussion

What is being proposed is not quite what the description implies. The bot would actually remove transclusions of daily log pages on the main RfD when all discussions on that day have been closed or relisted, rather than removing the transclusion of individual discussions (which are not typically transcluded anywhere). Thryduulf (talk) 16:46, 28 May 2025 (UTC)[reply]

@Thryduulf from my overview and details above, I clearly mentioned “closed RfD discussions” and from what you just said, it’s only “relist” I didn’t mention (which this process will obviously cover), so I do not think I clearly get what you mean by “not quite what the description implies”. Vanderwaalforces (talk) 18:47, 28 May 2025 (UTC)[reply]
The description implies the bot will be working at the level of individual RfD discussions, rather than what it will be doing which is working at the level of a day's worth of RfD discussions. For example the bot will take no action in relation to Wikipedia:Redirects for discussion/Log/2025 May 27 until all the discussions on that page on that page have been closed or relisted, at which point it will untransclude the page from Wikipedia:Redirects for discussion. I should clarify that I do support the proposal, I just think it's important that the description of what it does clearly matches what it will actually do. Thryduulf (talk) 20:18, 28 May 2025 (UTC)[reply]

It says that the source is available, where can it be viewed? GalStar (talk) 05:31, 6 June 2025 (UTC)[reply]

  Approved for trial (20 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. It's a single page being edited, but I'd like to make sure (since it's a very visible one) that everything's working as intended. Primefac (talk) 13:32, 8 June 2025 (UTC)[reply]

DeadbeefBot II

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

Time filed: 02:10, Friday, May 23, 2025 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Rust

Source code available: https://github.com/fee1-dead/usync

Function overview: Sync userscripts from Git(Hub/Lab) to Wikipedia.

Links to relevant discussions (where appropriate): Wikipedia:Village pump (technical)/Archive 220#Syncing user scripts from an external Git repository to Wikipedia, Wikipedia:Bots/Requests for approval/DeltaQuadBot 9, User:Novem Linguae/Essays/Linking GitHub to MediaWiki

Edit period(s): Continuous

Estimated number of pages affected: All pages that transclude Wikipedia:USync

Exclusion compliant (Yes/No): No

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

Function details: The bot scans and parses the list of user scripts at this list, and they must start with the following header format: 

// {{Wikipedia:USync|repo=REPO_LINK|ref=REPO_REF|path=FILE_PATH}}

so for example: 

// {{Wikipedia:USync |repo=https://github.com/fee1-dead/cplus |ref=refs/heads/production |path=main.js}}

And will start syncing from the Git file to the on-wiki script.

Any user script author intending to use the bot must (1) insert the header both on-wiki, and on the Git file themselves, serving as an authorization for the bot to operate. (2) Create an application/json webhook in their Git repository pointing to https://deadbeefbot-two.toolforge.org/webhook to notify the bot of new commits that have occured on the file.

The bot will then make edits using the commit message and author information to update the user scripts.

Currently, it only supports js files in the User namespace, but its scope could be trivial expanded to cover more formats (CSS/plain wikitext) depending on usage.

This is an improvement upon the previous DeltaQuadBot task: Auditability is achieved through linking on-wiki edits to GitHub/GitLab URLs that tell you who made what changes. Webhooks are used instead of a periodic sync. Authorization must be given on-wiki to allow syncs to happen.

The code is currently a working demo. I'm planning on expanding its functionality to allow Wikimedia GitLab's webhooks, and actually deploying it. I will also apply for Interface Administrator perms as this bot requires IA permissions. Will also request 2FA on the bot when I get to it.

Discussion

  • Just so we are aware of the alternatives here: bd808 suggested on Discord of an alternative solution to this problem which does not involve an IntAdmin bot, where script developers can create OAuth tokens and submit those tokens to a Toolforge service, and the Toolforge service would use those OAuth tokens to make edits as the script author (0xDeadbeef/GeneralNotability/etc.) instead of having the edits coming from a single bot account. There are different trade offs. I think if we're okay with a bot having IA permissions, then this solution is more convenient to setup, as the OAuth one requires going through the extra steps of creating a token. This bot also makes those edits in a centralized place when people want to inspect which scripts are maintained using this way. beef [talk] 02:34, 23 May 2025 (UTC)[reply]

I see a risk here in having a bot blindly copy from the github without any human verification. Interface editor rights are restricted for very good reason, as editing the site's js would be very vaulable to a potential attacker. By introducing this bot, we now also have to be concerned about the security of the github repo's the bot is copying from. Something which is external to Wikipedia. We have no control over who might be granted access to those repos, and what they might do.

In fact, it may actually hinder development of tools/scripts. Currently, as a maintainer, one can be fairly liberal in who you add to your github repo, knowing that you can review any changes when you manually move them from the GitHub to on-wiki. With this change, anyone you add to the repo, realistically should be someone the community would trust with interface admin rights. --Chris 09:49, 23 May 2025 (UTC)[reply]

I think the bot task is more aimed at user scripts than gadgets. You don't need to be an interface admin to edit your own scripts. Being an opt-in system, script maintainers who don't wish to take on the risk can choose not to use the system. As for security, it should be the responsibility of the script author to ensure that they, and others who have been added to the repo, have taken adequate measures (like enabling 2FA) to secure their github/gitlab accounts. – SD0001 (talk) 10:14, 23 May 2025 (UTC)[reply]
For what it's worth, there are already people doing this kind of things to their own userscripts, such as User:GeneralNotability/spihelper-dev.js. However, they were never done with a bot because the bot would need to be interface admin. So they just store BotPasswords/OAuth tokens in GitHub and write a CI job that uses that to edit on-wiki.
Being someone with some fair bit of the open source process, I don't see why someone who wants to personally review any changes themselves should choose to add people liberally to the GitHub repo, and then choose to use this bot if it gets approved. They should try to move the development/approval cycle onto GitHub, appropriately using pull requests and protected branches, or just keep doing what they are doing. beef [talk] 10:22, 23 May 2025 (UTC)[reply]
Script maintainers might be happy to take the risk of automatically copying scripts from an external site to become active client-side scripts at Wikipedia, and they might be happy with the increased vulnerability surface area. The question here is whether the Wikipedia community thinks the risk–benefit ratio means the procedure should be adopted. Johnuniq (talk) 10:36, 23 May 2025 (UTC)[reply]
User scripts are an "install at your own risk" already, so feel free to avoid installing user scripts that do any automatic syncing. If the community doesn't like a bot that does this for whatever reason, I can also be fine with a "store OAuth tokens that give a toolforge service access to my account" approach which requires no community approval and no bots to run, just slightly less convenient to setup.
All I am saying is that the increased vulnerability surface area remains to be proven. WP:ULTRAVIOLET and WP:REDWARN have been doing this for years. Whether approval for code occurs on-wiki or off-wiki shouldn't matter. beef [talk] 11:00, 23 May 2025 (UTC)[reply]
The bot as proposed crosses a pretty major security boundary by taking arbitrary untrusted user input into something that can theoretically change common.js for all users on Wikipedia.
Has anyone looked at the security of the bot itself? Chess (talk) (please mention me on reply) 01:44, 9 June 2025 (UTC)[reply]
@Chess: theoretically change common.js for all users on Wikipedia - no, only common.js that link to the specified page/transclude the specified page would be in scope for the bot. dbeef [talk] 01:47, 9 June 2025 (UTC)[reply]
@Dbeef: I understand what's in scope, but is the authorization token actually that granular? If there's a vulnerability in the bot, I could exploit that to edit anything. Chess (talk) (please mention me on reply) 02:04, 9 June 2025 (UTC)[reply]
@Chess: I'm not sure what you mean.
I had thought about the security implications long before this BRFA:
  • The only public facing API of the bot is a webhook endpoint. While anyone can send in data that looks plausible, the bot will only update based on source code returned from api.github.com. So malicious actors have to be able to modify the contents of api.github.com to attack that.
  • The credentials are stored on Toolforge, standard for a majority of Wikipedia bots. Root access is only given to highly trusted users and I don't think it will be abused to obtain the bot's OAuth credentials. If you think otherwise, I can move the bot deployment to my personal server provided by Oracle.
  • The public facing part uses Actix Web, a popular and well-tested Web Framework. Toolforge provides the reverse proxy. Don't think there's anything exploitable to get RCE.
  • The bot always checks the original page for the template with the configured parameters before editing. If the sync template is removed by the original owner or any interface administrator, the bot will not edit the page.
dbeef [talk] 04:51, 9 June 2025 (UTC)[reply]
@Dbeef: To answer Chess about BotPasswords, there is just one checkbox for "Edit sitewide and user CSS/JS" that encompasses both. ~ Amory (u • t • c) 01:06, 10 June 2025 (UTC)[reply]
While anyone can send in data that looks plausible, the bot will only update based on source code returned from api.github.com. So malicious actors have to be able to modify the contents of api.github.com to attack that. How does the bot verify the contents_url field in a request made to the webhook is hosted on api.github.com in the same repository as the .js file it is synching to?
I'd be reassured by OAuth, mainly because it avoids taking untrusted user input into a bot with the permissions to edit MediaWiki:Common.js on one of the top ten most visited websites on Earth. Chess (talk) (please mention me on reply) 01:58, 10 June 2025 (UTC)[reply]
How does the bot verify the contents_url field in a request made to the webhook is hosted on api.github.com in the same repository as the .js file it is synching to? That's a really good point. I need to fix that. dbeef [talk] 02:10, 10 June 2025 (UTC)[reply]
@Dbeef: I'm uncomfortable with interface admin being granted to a bot that hasn't had anyone else do a serious code review.
Not verifying contents_url would've allowed me to modify any of the scripts managed by dbeef onwiki, to give an example.
OAuth limits the impact of any flaws to just making edits under certain user accounts. Chess (talk) (please mention me on reply) 14:34, 13 June 2025 (UTC)[reply]
@Chess: That is a valid concern and an oversight. It was originally not there when I queried raw.githubusercontent, but I noticed that that updated slowly. I then decided to use api.github.com but hadn't realized contents_url was user input.
That was quickly fixed two days ago.
I won't be of much help reviewing my own code, but maybe other people can take a look as well? Maybe we can ping some rust developers.. dbeef [talk] 15:17, 13 June 2025 (UTC)[reply]
I'm a C++ developer unfortunately. I know nothing about Rust and can't even compile the bot right now. Chess (talk) (please mention me on reply) 04:37, 14 June 2025 (UTC)[reply]

Has there been a discussion establishing community consensus for this task, per WP:ADMINBOT? I don't see one linked here, nor one from Wikipedia:Bots/Requests for approval/DeltaQuadBot 9. The community might also decide whether the OAuth route is preferable to the interface-admin route. Anomie⚔ 11:13, 23 May 2025 (UTC)[reply]

Good idea, I'll post a summary to WP:VPT soon. beef [talk] 11:16, 23 May 2025 (UTC)[reply]
See Wikipedia:Village pump (technical)#Syncing user scripts from an external Git repository to Wikipedia beef [talk] 12:18, 23 May 2025 (UTC)[reply]
{{BotOnHold}} This is just until the discussion concludes (feel free to comment out when it has). Primefac (talk) 23:48, 25 May 2025 (UTC)[reply]
The discussion was archived at Wikipedia:Village pump (technical)/Archive 220#Syncing user scripts from an external Git repository to Wikipedia with a rough consensus to implement the bot. dbeef [talk] 03:31, 8 June 2025 (UTC)[reply]
  Approved for trial (30 edits or 30 days, whichever happens first). Please provide a link to the relevant contributions and/or diffs when the trial is complete. I will be cross-posting this to both WP:AN and WP:BN for more eyes. Primefac (talk) 13:23, 8 June 2025 (UTC)[reply]
I will be deploying the bot in a few days and do some deliberate test edits to get this started. If any user script authors are willing to try this for trial please let me know :) dbeef [talk] 13:37, 8 June 2025 (UTC)[reply]
The linked discussion seemed to settle pretty quickly on using OAuth rather than interface editor permissions. Is that still the plan? Anomie⚔ 03:07, 9 June 2025 (UTC)[reply]
That's not how I read it. It was explored as an alternative but to me it looks like more editors expressed support for the interface editor bot. dbeef [talk] 03:37, 9 June 2025 (UTC)[reply]
On reviewing again, it looks like I misremembered and misread. The subdiscussion that concluded in OAuth was about the possible alternative to interface editor. OTOH I'm not seeing much support for the conclusion that interface editor was preferred over (normal) OAuth either; the few supporting statements may have been considering only interface editor versus password sharing. Anomie⚔ 11:31, 9 June 2025 (UTC)[reply]
It isn't necessarily an either/or thing. Both solutions can co-exist. If some people prefer the OAuth-based approach, they can of course implement that – it doesn't even need a BRFA. What's relevant is whether the discussion had a consensus against the interface editor approach – I don't think it does. – SD0001 (talk) 11:39, 9 June 2025 (UTC)[reply]
What's relevant is whether the discussion had a consensus against the interface editor approach – I don't think it does. As I said, I misremembered and misread. OTOH, dbeef claimed but to me it looks like more editors expressed support for the interface editor bot which I don't unambiguously see in the discussion either.
If some people prefer the OAuth-based approach, they can of course implement that – it doesn't even need a BRFA. I don't see any exception in WP:BOTPOL for fully automated bots using OAuth from the requirement for a BRFA. WP:BOTEXEMPT applies to the owner's userspace, not anyone who authorizes the bot via OAuth. WP:ASSISTED requires human interaction for each edit. WP:BOTMULTIOP does not contain any exemption from a BRFA. Anomie⚔ 12:00, 9 June 2025 (UTC)[reply]
That's a fair observation. I do see support for an interface admin bot and I believe there are no substantial concerns that would make a blocker. I continue to think of interface admin bot as the easier solution but I am not opposed to figuring out the OAuth piece also at a later time. It is just that I don't have truckloads of time to focus on stuff that seems on its surface a bit redundant. dbeef [talk] 12:46, 9 June 2025 (UTC)[reply]
With OAuth, the edits would be from the users' own accounts. No bot account is involved as edits are WP:SEMIAUTOMATED with each push/merge to the external repo being the required human interaction. – SD0001 (talk) 13:43, 9 June 2025 (UTC)[reply]
I look at WP:SEMIAUTOMATED as having the user approve the actual edit, not just do something external to Wikipedia that results in an edit that they've not looked at. But this discussion is getting offtopic for this BRFA; if you think this is worth pursuing, WP:BON or WT:BOTPOL would probably be better places. Anomie⚔ 12:01, 10 June 2025 (UTC)[reply]
Instead of requiring it to be linked and followed by some text in an arbitrary sequence, I'd suggest to use a transclusion for clarity, like: {{Wikipedia:AutoScriptSync|repo=<>|branch=<>|path=<>}} (perhaps also better to put the page in project space). – SD0001 (talk) 15:52, 8 June 2025 (UTC)[reply]
that's a little harder to parse but I suppose not too hard to implement, if parsoid can do it (hand-parsing is an option too). I'll take a look in the next few days. dbeef [talk] 16:02, 8 June 2025 (UTC)[reply]

After reading comments here, I'm unsure. (1) Why do we need a bot for this? Is there a need to perform this task repeatedly over a significant period of time? (Probably this is answered in the VPT discussion linked above, but it's more technical than I can understand.) (2) Imagine that a normal bot copies content from github to a normal userspace page, and then a human moves it to the appropriate page, e.g. first the bot puts a script at User:Nyttend/pagefordumping, and then I move it to User:Nyttend/script. This should avoid the security issue, since there's no need for the bot to have any rights beyond autoconfirmed. Would this work, or is this bot's point to avoid the work involved in all those pagemoves? (3) On the other hand, before interface admin rights were created, and normal admins could handle this kind of thing, do we know of any adminbots that were working with scripts of any sort, and if so, how did the security process work out? Nyttend (talk) 10:17, 9 June 2025 (UTC)[reply]

(1) Yes, because platforms like GitHub give better experiences when developing user scripts, instead of having people copy from their local code editor and paste to Wikipedia each time. This includes CI and allowing transpiled languages such as TypeScript to work. (2) is this bot's point to avoid the work involved in all those pagemoves - Yeah. (3) I don't think there was any bot that did this. dbeef [talk] 10:34, 9 June 2025 (UTC)[reply]
  • How are you handling licensing? When you, via your bot, publish a revision here you are doing so under CCBYSA4 and GFDL. What are you doing to ensure that the source content you are publishing is available under those licenses? — xaosflux Talk 10:07, 13 June 2025 (UTC)[reply]
    I think I could put a section on WP:USync that says "by inserting the header you assert that any code you submit through the Git repository is licensed under CCBYSA4/GFDL or another compatible license", but that's the best I can do.
    Would you want me to parse SPDX licenses or something? I think the responsibility is largely on the people who use the bot and not the bot itself when it comes to introducing potential copyvios. dbeef [talk] 15:09, 13 June 2025 (UTC)[reply]
    Is a compatible license even common on that upstream? You can't delegate authority, whoever publishes a revision is the one issuing the license on the derivative work. — xaosflux Talk 18:31, 13 June 2025 (UTC)[reply]
    This appears that it may end up whitewashing licenses. Anyone that reads any page from our project should be able to confidentially trust the CCBYSA license we present, including required elements such as the list of authors. — xaosflux Talk 00:56, 14 June 2025 (UTC)[reply]
    SPDX is an industry standard and is meant for automatically verifying the licence of a source file. Would that be inappropriate here? Chess (talk) (please mention me on reply) 04:36, 14 June 2025 (UTC)[reply]
    I was just wondering how exactly we should be doing it.
    For example, we can require that one must use something like {{Wikipedia:USync|authors=Foo|license=MIT}}, with license being a manually approved list. dbeef [talk] 04:39, 14 June 2025 (UTC)[reply]
    Including it in a template in the userscript makes sense, since then the list of authors' preferred attribution can be maintained on the repo instead of onwiki, while still being replicated onwiki.
    The "license" field should probably be SPDX if that makes it easier to parse.
    Specifically, the "licence" field should contain CC-BY-SA-4.0 OR GFDL-1.3-or-later since that matches the requirements for contributing to Wikipedia, which is that all content must be available under both licences. I don't think allowing MIT-only (or other arbitrary permissive licences) makes sense right now under the assumption it's compatible with CC-BY-SA/GFDL. We might have to maintain the MIT licence text, and the only people using this bot would be those writing userscripts specifically for Wikipedia. Multiply that by the many variants of licences that exist.
    I think it's a good idea to keep the amount of parsing in the bot as small as possible given its permissions and impact. Chess (talk) (please mention me on reply) 02:30, 15 June 2025 (UTC)[reply]
    We can't take content in incompatible licenses and copy them to Wikipedia. Any page published needs to be available to those reading it CCBYSA and GFDL. Additionally, if the remote site uses a -BY- license, we need to ensure that the remote authors continue to be properly attributed when republishing here. — xaosflux Talk 12:59, 17 June 2025 (UTC)[reply]
    I don't see a problem. All edits are implicitly released under those licenses, whether done from the UI or through some script. All you've to do is to declare in the bot documentation that "you agree to release all code you deploy to the wiki via the bot under CC-BY-SA and GFDL". – SD0001 (talk) 13:45, 17 June 2025 (UTC)[reply]
    this scheme is what i had in mind as well. I am not entirely sure whether a mandatory license field is needed. The assertion that content is compatibly licensed should ideally come from the very edit that inserts the WP:USync header (and we should assume such), and it's not that inserting a license field will be any different from it. dbeef [talk] 10:58, 18 June 2025 (UTC)[reply]
    I've added a note for licensing at Wikipedia:USync#Licensing note. dbeef [talk] 05:54, 4 July 2025 (UTC)[reply]
If it matters, I can vouch that CI/CD is a basic requirement now for much of software development, so I'm generally supportive of the intent of this proposal. It's better because it creates a single source of truth for what is currently deployed to the Wiki. Chess (talk) (please mention me on reply) 16:35, 13 June 2025 (UTC)[reply]

CFA (bot)

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

Time filed: 19:59, Tuesday, December 31, 2024 (UTC)

Function overview: Removes articles from Category:Wikipedia requested images of biota if they have an image

Automatic, Supervised, or Manual: Automatic

Programming language(s): Python

Source code available: No, but it can be if necessary

Links to relevant discussions (where appropriate): Uncontroversial

Edit period(s): Weekly

Estimated number of pages affected: ~3-6k first run; likely no more than 10/week afterwards

Namespace(s): Talk

Exclusion compliant (Yes/No): Yes

Function details:

Discussion

  Approved for trial (100 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 13:24, 1 January 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) Status of trial? – DreamRimmer (talk) 17:06, 14 February 2025 (UTC)[reply]

SodiumBot 2

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

Time filed: 20:03, Tuesday, July 16, 2024 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: https://github.com/sohomdatta1/npp-notifier-bot

Function overview: Notify previous reviewers of a article at AFD about the nomination

Links to relevant discussions (where appropriate): Initial discussions on NPP Discord + previous BRFAs surrounding AFD notifications

Edit period(s): Continuous

Estimated number of pages affected: 1-2 per day (guessimate?)

Exclusion compliant (Yes/No): Yes

Already has a bot flag (Yes/No): No, on enwiki, yes, for other wikis on other tasks

Function details:

  • Use the eventstream API to listen for new AfDs
  • Extract page name by parsing the AfD wikitext
  • Identify previous reviewers of page at AFD
  • Notify said reviewers on their talk pages with a customised version of the existing AfD notification message

Discussion

Bots that have completed the trial period

Bot1058 10

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

Time filed: 17:49, Friday, March 7, 2025 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): PHP

Source code available: User:Bot1058/mishyphenation.php

Function overview: Bypass mishyphenated links, to remove pages from User:Wbm1058/Reports/Linked mishyphenations

Links to relevant discussions (where appropriate): User talk:wbm1058#R from incorrect hyphenation, Wikipedia talk:WikiProject Redirect#Wiped/reinstated template?

Edit period(s): Daily

Estimated number of pages affected: ~2,100 on the initial run; varies on subsequent runs

Exclusion compliant (Yes/No): No

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

Function details: This is the second in a series of tasks for this bot, which will run on the Toolforge and use a database report as the basis for its edits to correct errors in links on mainspace pages. Task 9 bypasses bad piped links to link directly to the title displayed to readers; this task will bypass mishyphenated links. I view edits to add or remove a horizontal line, or adjust the length of a horizontal line, as sufficiently cosmetic to be safely made in automated fashion by a bot.

I created Category:Redirects from incorrect hyphenation on 5 November 2023, to separate incorrect hyphenations from misspellings, as a lower priority for gnomes to fix than actual a–z misspellings. Misspellings need more scrutiny, as vandals can replace correctly-spelled words with a different, misspelled word. We need to avoid endorsing vandalism by correcting the spelling of the incorrect word rather than reverting back to the correct word. We continue to have an imbalance between "executive editors" declaring words to be misspelled or mishyphenated, and gnomes following their directives to correct these errors; my bot tasks are an effort to restore more balance between the executives and the gnomes.

I've built in a safeguard to ensure that this task's edits have community approval. The bot won't make edits when the redirect page triggering the edit has been edited within the past seven days. This will stop edit-warring over what the "correct" form of hyphenation should be, from causing the bot to edit war with itself over a short term. Editors may watchlist User:Bot1058/mishyphenation pending fixes if they want to monitor these pending edits before they're made.

Examples of edits that this task will make:

For consistency, the bot will make similar changes outside of wikilinks when it determines it's safe to do so:

  • the term is in plain text
    • surrounded by spaces
    • leading space and ending period, comma, or semicolon
    • in (parenthesis)
    • in "quotes"
    • leading space, followed by an "s" (plural form)
    • led by a pipe (|), assumed to be a table element
    • led by an equal sign (=), assumed to be a parameter

The bot will explicitly avoid changing filenames, to avoid breaking image links.

It will also avoid changing links when the link is part of a longer linked title. This will avoid the bot creating red links; these will be left for human review.

The bot will leave anything not explicitly determined to be "safe" for human review. The initial run of this task is expected to leave about 120 pages for human review.

The bot will not make changes when more than two characters in a link are changed, leaving these for human review as well. One of the changes will be to a hyphen, dash, or space. A second accepted change may be to uppercase a character or put a diacritic on a character.


Discussion

I'm concerned that the "changes outside of wikitext" would get into WP:CONTEXTBOT territory. You seem to be explicitly stating that you're going to alter direct quotes, which we usually take pains not to modify, and may not be able to correctly identify things like hyphenated compound modifiers. Anomie⚔ 13:48, 8 March 2025 (UTC)[reply]

Yes, regarding this:
Generally, a compound modifier is hyphenated if the hyphen helps the reader differentiate a compound modifier from two adjacent modifiers that modify the noun independently. Compare the following examples:
  • "small appliance industry": a small industry producing appliances
  • "small-appliance industry": an industry producing small appliances
Redirects should only be tagged as "incorrect" if they are always incorrect under all contexts. If there are contexts where they are correct, then they should be tagged as valid alternatives. My bot only edits to correct things that are incorrect in all contexts. Some editors have been over-prescriptive, tagging things are incorrect when there are contexts where they are correct. When I find these mislabeled redirects, I correct them, e.g. age-of-consent laws, where I corrected TARDIS Builder. This is why I created User:Bot1058/mishyphenation pending fixes – to allow time for reversions of mislabeled redirects. – wbm1058 (talk) 16:40, 8 March 2025 (UTC)[reply]
You're relying on every editor to use your definition of "incorrect", or at least some human reacting to every other definition quickly. That does not seem like a very reliable assumption to me. Anomie⚔ 00:12, 9 March 2025 (UTC)[reply]
Speaking only about that example, I tagged it as incorrect because someone searching "age of consent" is almost certainly looking for it as a term (noun) rather than as an adjective. As well, the article it points to talks about the concept as a concept, not as a descriptor.
I disagree with your assertion that redirects need to be incorrect under all contexts to use that template; I could probably comb through my own history and find examples where that's not true and you would still agree that the choice of template was appropriate.
I think nuance & judgment matter. Correct category depends on the redirect and the target article.
Thanks for creating it, I'm glad it's there.   — TARDIS builder✉     ★       06:33, 9 March 2025 (UTC)[reply]
This is all about linked misspellings, not searched terms. From the article Adolescent sexuality,
"Sexual interest among adolescents, as among adults, can vary greatly, and is influenced by cultural norms and mores, sex education, as well as comprehensive sexuality education provided, sexual orientation, and social controls such as age-of-consent laws."
@TARDIS Builder: You were requiring the link to be piped [[age of consent|age-of-consent]] laws to avoid the "mishyphenation". This is bad, especially in the future, if someone were to write a separate article about the adjective, as a distinctly different concept from the noun. You can also tag age-of-consentage-of-consent with {{R from adjective}}, which I just did. – wbm1058 (talk) 12:30, 9 March 2025 (UTC)[reply]
Okay, I understand what you're getting at with this example. I can see that it is an alternative hyphenation in some cases.   — TARDIS builder✉     ★       01:33, 10 March 2025 (UTC)[reply]
Noting that you did correctly tag Age of consent reformAge of consent reform, Age of consent reform in CanadaAge of consent reform in Canada, and Age of consent reform in the United KingdomAge of consent reform in the United Kingdom. – wbm1058 (talk) 16:24, 9 March 2025 (UTC)[reply]
MOS:SIC states that "insignificant spelling and typographic errors should simply be silently corrected." I'm assuming that shortening or lengthening a hyphen/dash would be an acceptable silent correction. – wbm1058 (talk) 17:02, 8 March 2025 (UTC)[reply]

Anomie, i created User:Wbm1058/Reports/Linked mishyphenations/by changes, manually organizing the pages listed on User:Wbm1058/Reports/Linked mishyphenations based on my bot's console output.

I believe the context issues are limited to those that call for replacing a hyphen with a space – specifically where the redirect consists of one word (no embedded spaces) which is not a proper noun (the letter following the hyphen is lower case). I've highlighted the four that meet these criteria – showing examples here where the hyphen is appropriate in context:

Not sure about African-AmericansAfrican-Americans, which has over 500 links. African-AmericanAfrican-American was tagged as an adjective, and then as alternative hyphenation, but it's hard to imagine the plural form being used as an adjective, so this is probably OK to go ahead with the bypass-corrections.

I can modify my algorithm to skip the pages that meet these criteria and report them on the console as likely-valid alternatives in some contexts.

I'm OK with running this on an as-needed or on demand basis rather than daily, in a hybrid between automatic and supervised, where I make a dry run with the $objwiki->edit commented out, and review User:Wbm1058/Reports/Linked mishyphenations and the console report for any issues needing to be addressed before running it in automated mode. – wbm1058 (talk) 17:56, 12 March 2025 (UTC)[reply]

@Hyphenation Expert: any help you might contribute with determining the algorithm for deciding whether a hyphenated form is correct in some contexts (and thus automated correction should be avoided) versus always incorrect (and thus automated correction is safe) would be appreciated. – wbm1058 (talk) 13:58, 14 March 2025 (UTC)[reply]

For compound modifiers, determining "hyphenation correctness" is very case-by-case basis; per Hyphenated compound modifier: Major style guides advise consulting a dictionary to determine whether a compound modifier should be hyphenated ... Not normally hyphenated: Compound modifiers that are not hyphenated in the relevant dictionary or that are unambiguous without a hyphen. So for example, Fatty-acid could be appropriately {{R from incorrect hyphenation}}: Fatty acid synthesis, Fatty acid metabolism are unambiguous.
Only with proper names do I see straightforward "100% incorrect" scenarios: Aaron Taylor JohnsonAaron Taylor Johnson, Hewlett-Packard EnterpriseHewlett-Packard Enterprise. Hyphenation Expert (talk) 18:21, 14 March 2025 (UTC)[reply]
Right, "case-by-case" is precisely what {{R from alternative hyphenation}} is for, and I do not intend for my bot to make any case-by-case determinations.
Mrakia frigida §Membrane lipid composition: There is a positive correlation between the growth temperature and the degree of fatty-acid unsaturation of the cell lipids of Mrakia frigida.
The need for a hyphen, or not, is a judgement determination individual editors may make – not this bot. – wbm1058 (talk) 18:33, 15 March 2025 (UTC)[reply]
In the rare event that this bot might get the context wrong, the solution is easy. Change the offending redirect's Rcat from {{R from incorrect hyphenation}} to {{R from alternative hyphenation}}, and revert the bot. We don't expect perfection from human editors, who all make occasional mistakes, nor should we expect 100% perfection from bots, as long as their mistakes are not too frequent or cause intolerable harm. – wbm1058 (talk) 15:40, 27 March 2025 (UTC)[reply]

A previously approved bot, Wikipedia:Bots/Requests for approval/BattyBot 54, handled the related task of correcting links to Full rigged shipFull rigged ship. I just tagged that as an {{R from incorrect hyphenation}} so that this bot will handle new cases of this usage. – wbm1058 (talk) 15:40, 27 March 2025 (UTC)[reply]

{{BAG assistance needed}} * Pppery * it has begun... 16:03, 20 May 2025 (UTC)[reply]

The above discussion seems to have stalled, but I'm not sure wbm has necessarily made a strong enough argument to bring this to a trial. That being said, all discussions I'm seeing on this matter seem to stall out, so the only way to prod people into getting us to a consensus may be to have a trial. That's my thinking on the matter, will circle back around in a few days and see if anyone has any significant issue with this line of thinking. Primefac (talk) 23:54, 25 May 2025 (UTC)[reply]
Seeing what's happening at WP:VPR#On redirect from mis/other capitalization tags makes me even less confident in the "people will always correctly tag the redirects" plan. But 🤷. Anomie⚔ 01:09, 26 May 2025 (UTC)[reply]
  Approved for trial (100 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. I am still concerned about context issues and edit-warring over bot edits (it is one thing to just say "revert the bot" but if a change to a redirect template results in hundreds of reverts, people will obviously not be happy), and the VPR discussion linked by Anomie strengthens that concern, but I think we're still at the point where we won't get enough people to care about the matter until edits start being made. Primefac (talk) 13:12, 8 June 2025 (UTC)[reply]
Thank you for the belated approval for a trial. Part of the reason for this stalling is long waits for approval, which I'm used to, as that's been rather typical of my bot requests. Another part of the reason is that my time continues to be oversubscribed and I need to find larger blocks of time to work on more complex tasks like this, while still supporting more routine tasks which should be below my pay grade, but I'm obligated to do them anyway because I haven't been able to recruit gnome trainees to do them for me.   Trial complete., actually a 120-edit trial run on 28 March 2025. An editor brought up an issue with that run on my talk page. I obviously need to patch my code to fix that problem, so I'll need another trial run after I've done that. I've reviewed some, but not all, of the 120 edits made by that 28 March trial. Oh, and regarding a particular editor's idea of "miscapitalization", see User talk:wbm1058#Re Wikipedia:Database reports/Linked miscapitalizations. I've abandoned my work on Wikipedia:Database reports/Linked miscapitalizations, as that report's become a massive pile of low-priority or no-priority work due to that editor's activities. The point of this bot request is that I need to do something to continue working my way out from under the piles of work that "executive editors without tools" and "hyphenation experts" are piling on me. This was my idea of a relatively "safe" way to grow from task 9. – wbm1058 (talk) 16:43, 27 June 2025 (UTC)[reply]

CanonNiBot 1

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

Time filed: 12:49, Tuesday, December 17, 2024 (UTC)

Function overview: A replacement for tasks 1, 2, 7, 8, 9, and 15 of FastilyBot (talk · contribs), whose operator has retired

Automatic, Supervised, or Manual: Automatic

Programming language(s): Rust (mwbot-rs crate)

Source code available: Will push to GitLab later

Links to relevant discussions (where appropriate): See this

Edit period(s): Daily

Estimated number of pages affected: A couple dozen every day

Namespace(s): File:

Exclusion compliant (Yes/No): Yes

Function details: Near identical functionality of the previous bot, just rewritten in a different (and better) language. All are modifying templates on File description pages, so I'm merging this into one task.

Task details (copied from WP:BOTREQ)
Original task Description
1 Replace {{Copy to Wikimedia Commons}}, for local files which are already on Commons, with {{Now Commons}}.
2 Remove {{Copy to Wikimedia Commons}} from ineligible files.
7 Replace {{Now Commons}}, for local files which are nominated for deletion on Commons, with {{Nominated for deletion on Commons}}.
8 Replace {{Nominated for deletion on Commons}}, for local files which have been deleted on Commons, with {{Deleted on Commons}}.
9 Remove {{Nominated for deletion on Commons}} from files which are no longer nominated for deletion on Commons.
15 Remove {{Now Commons}} from file description pages which also translcude {{Keep local}}

Discussion

  • Thanks for stepping up to help! For easier review and tracking, could you please list all these tasks and their descriptions in the "Function details" section? You can use a wikitable for this. – DreamRimmer (talk) 13:51, 17 December 2024 (UTC)[reply]
  Approved for trial (120 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Please perform 20 edits for each task. Primefac (talk) 12:35, 23 December 2024 (UTC)[reply]
{{Operator assistance needed}} Any update? – DreamRimmer (talk) 17:07, 14 February 2025 (UTC)[reply]
Sorry about that - I've been inactive for the past three months or so. (probably should've got this thing done before disappearing, my bad) Will get those trial edits done soon! '''[[User:CanonNi]]''' (talk • contribs) 10:14, 22 May 2025 (UTC)[reply]
  Trial complete. @Primefac and DreamRimmer: alright, I've finally completed the trial edits after procrastinating for uh... five months? See Special:Contributions/CanonNiBot. Some edits (60 or so according xTools) were performed on pages that have since been deleted. No major issues, and the code has been pushed to GitHub. '''[[User:CanonNi]]''' (talk • contribs) 13:20, 8 June 2025 (UTC)[reply]
This seems to have only made edits removing {{Copy to Wikimedia Commons}}. Do the other tasks not require any edits at this time? Primefac (talk) 13:56, 8 June 2025 (UTC)[reply]
@Primefac very sorry for the late reply - I uh, accidentally removed this page from my watchlist a while back. (Aaron Liu thanks for the reminder) I've performed several trial edits for all tasks, some of which were to pages that are now deleted, which is why they're not showing up on Special:Contribs. The tasks that required the most edits were 1, 7, 8, and 9. [​[User:CanonNi]​] (💬 • ✍️) 09:51, 23 June 2025 (UTC)[reply]
Please do at least a few edits for each of the other tasks. Feel free to post individual diff links, I'll keep an eye on this page (and of course, I can see deleted revisions). Primefac (talk) 23:24, 23 June 2025 (UTC)[reply]
{{Operator assistance needed|D}} Primefac (talk) 00:16, 21 June 2025 (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.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bots/Requests_for_approval&oldid=1299432441"