Wikipedia:Bot requests

For the policy on bot requirements, see WP:BOTREQUIRE.

This is a page for requesting tasks to be done by bots per the bot policy. This is an appropriate place to put ideas for uncontroversial bot tasks, to get early feedback on ideas for bot tasks (controversial or not), and to seek bot operators for bot tasks. Consensus-building discussions requiring large community input (such as request for comments) should normally be held at WP:VPPROP or other relevant pages (such as a WikiProject's talk page).

You can check the "Commonly Requested Bots" box above to see if a suitable bot already exists for the task you have in mind. If you have a question about a particular bot, contact the bot operator directly via their talk page or the bot's talk page. If a bot is acting improperly, follow the guidance outlined in WP:BOTISSUE. For broader issues and general discussion about bots, see the bot noticeboard.

Before making a request, please see the list of frequently denied bots, either because they are too complicated to program, or do not have consensus from the Wikipedia community. If you are requesting that a template (such as a WikiProject banner) is added to all pages in a particular category, please be careful to check the category tree for any unwanted subcategories. It is best to give a complete list of categories that should be worked through individually, rather than one category to be analyzed recursively (see example difference).

Alternatives to bot requests

• WP:AWBREQ, for simple tasks that involve a handful of articles and/or only needs to be done once (e.g. adding a category to a few articles).
• WP:URLREQ, for tasks involving changing or updating URLs to prevent link rot (specialized bots deal with this).
• WP:SQLREQ, for tasks which might be solved with an SQL query (e.g. compiling a list of articles according to certain criteria).
• WP:TEMPREQ, to request a new template written in wiki code or Lua.
• WP:SCRIPTREQ, to request a new user script. Many useful scripts already exist, see Wikipedia:User scripts/List.
• WP:CITEBOTREQ, to request a new feature for WP:Citation bot, a user-initiated bot that fixes citations.

Note to bot operators: The {{BOTREQ}} template can be used to give common responses, and make it easier to keep track of the task's current status. If you complete a request, note that you did with {{BOTREQ|done}}, and archive the request after a few days (WP:1CA is useful here).

---

Please add your bot requests to the bottom of this page.
Make a new request

#	Bot request	Status	💬	👥	🙋 Last editor	🕒 (UTC)	🤖 Last botop editor	🕒 (UTC)
1	Automatic NOGALLERY keyword for categories containing non-free files (again)		27	11	Anomie	2024-08-04 14:09	Anomie	2024-08-04 14:09
2	Fixing stub tag placement on new articles	Not a good task for a bot.	5	4	Tom.Reding	2024-07-16 08:10	Tom.Reding	2024-07-16 08:10
3	Adding Facility IDs to AM/FM/LPFM station data	Y Done	13	3	HouseBlaster	2024-07-25 12:42	Mdann52	2024-07-25 05:23
4	Tagging women's basketball article talk pages with project tags	Y Done	20	4	Usernamekiran	2024-09-05 16:55	Usernamekiran	2024-09-05 16:55
5	Bot that condenses identical references	Coding...	12	6	ActivelyDisinterested	2024-08-03 20:48	Headbomb	2024-06-18 00:34
6	Bot to remove template from articles it doesn't belong on?		3	3	Thryduulf	2024-08-03 10:22	Primefac	2024-07-24 20:15
7	One-off: Adding all module doc pages to Category:Module documentation pages		7	3	Andrybak	2024-09-01 00:34	Primefac	2024-07-25 12:22
8	Draft Categories		13	6	Bearcat	2024-08-09 04:24	DannyS712	2024-07-27 07:30
9	Remove new article comments		3	2	142.113.140.146	2024-07-28 22:33	Usernamekiran	2024-07-27 07:50
10	Removing Template:midsize from infobox parameters (violation of MOS:SMALLFONT)	Resolved	14	2	Qwerfjkl	2024-07-29 08:15	Qwerfjkl	2024-07-29 08:15
11	Change stadium to somerhing else in the template:Infobox Olympic games	Needs wider discussion.	8	5	Jonesey95	2024-07-29 14:57	Primefac	2024-07-29 13:48
12	Change hyphens to en-dashes		16	7	1ctinus	2024-08-03 15:05	Qwerfjkl	2024-07-31 09:09
13	Consensus: Aldo, Giovanni e Giacomo		17	5	Dicklyon	2024-08-14 14:43	Qwerfjkl	2024-08-02 20:23
14	Cyclones		3	2	OhHaiMark	2024-08-05 22:21	Mdann52	2024-08-05 16:07
15	Substing int message headings on filepages		8	4	Jonteemil	2024-08-07 23:13	Primefac	2024-08-07 14:02
16	Removing redundant FURs on file pages		4	2	Jonteemil	2024-08-12 20:26	Anomie	2024-08-09 14:15
17	Need help with a super widespread typo: Washington, D.C (also U.S.A)		32	10	Jonesey95	2024-08-26 16:55	Qwerfjkl	2024-08-21 15:08
18	Dutch IPA		4	3	IvanScrooge98	2024-08-25 14:11
19	AnandTech shuts down		9	6	GreenC	2024-09-01 18:39	Primefac	2024-09-01 17:28
20	Date formatting on 9/11 biography articles		5	2	Zeke, the Mad Horrorist	2024-09-01 16:27
21	Discussion alert bot		6	4	Headbomb	2024-09-08 12:29	Headbomb	2024-09-08 12:29
22	Regularly removing {{coords missing}} if coordinates are present	BRFA filed	11	2	Usernamekiran	2024-09-07 13:19	Usernamekiran	2024-09-07 13:19
23	Latex: move punctuation to go inside templates		3	2	Yodo9000	2024-09-07 18:59	Anomie	2024-09-07 03:38
24	Removing spurious nobot notice	Resolved	5	2	DreamRimmer	2024-09-11 04:26	DreamRimmer	2024-09-11 04:26
25	de-AMP bot	Resolved	4	3	Primefac	2024-09-09 16:01	Primefac	2024-09-09 16:01

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Mark a lot of pages for microformatting

Could a bot be run to apply {{Start date}} to pages using {{Infobox NRHP}}? I'm envisioning the bot editing every page whose infobox has a single year in the template's |built= parameter to envelop the year in the template, similar to what was done in this diff. According to its documentation, the purpose of the template is to improve microformatting without affecting the appearance of the article. From my experience with this template, I believe that a substantial majority of the template's 40,000 transclusions will have a single date in this parameter, although some will have multiple years or a range of years, and a few will have a blank parameter or no parameter at all. In these cases, nothing should be done. Nyttend (talk) 23:37, 31 December 2012 (UTC)

I support this whole-heartedly; and it could also apply to other templates, and to templates with a year/month date or a full date (see previous discussion); but breaking it into manageable chunks is a good way to get started. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:50, 31 December 2012 (UTC)

So basically if the value in |built= is a 4 digit number, encase it in {{start date}}? I can file a request for that in a few days. Legoktm (talk) 08:36, 2 January 2013 (UTC)

For the first stage, yes. The second would be where the value is only a month and year (e.g. "November 1901" convert to, e.g., {{Start date|1901|11}}. the third and final stage, full dates, is obviously more complex. A list of other affected templates is at User:Pigsonthewing/to-do#Date conversions. Note that Dates before the year 1583 AD (or after 9999) should not be converted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:16, 2 January 2013 (UTC)

I don't fully understand the value of using the startdate template. I have twothree questions or possibly objections to starting with a bot run very quickly:

1. The startdate template could probably be applied within the NRHP infobox template. It does not need to be changed in any of the NRHP articles at all, does it? Assuming that the arguments which appear in NRHP infobox date fields, usually either of format YYYY or of format Month DD, YYYY, are acceptable to the startdate template, the startdate template can be applied by just one central modification of the NRHP infobox code.

If the startdate template is to be applied only to entries of format YYYY, I expect the wikimedia code for the NRHP infobox could handle that, as a conditional application. It would be better to do this in the infobox code, centrally, too, if only for reason of saving all those keystrokes in articles. And the unnecessary edits of new and old editors changing perfectly good info, manually. This comment applies to all the other infoboxes being mentioned above: change the code in their infobox templates, not in all of the articles using the infoboxes. --doncram 19:44, 3 January 2013 (UTC)

2. If it is to be applied by a bot to all the NRHP articles using the NRHP infobox (about 40,000), for some reason, why apply it to just the "built =" field? The built= field is actually not present in every NRHP infobox. The "added=" field is present in nearly 100% of the infoboxes, and is the date of NRHP listing. In most cases it will be filled in with a date like "January 1, 2000", but sometimes it may have just a year, for example in articles that editor Daniel Case created (he happens to think the month and day information is excessive). And also there "designated_nrhp_type = January 1, 2000", "designated_nrhp_type2 = ", "designated_nrhp_type3= ", and "designated_nrhp_type4=" fields that are date fields and that are sometimes present. If a bot is run, it should probably cover them all at once.

3. I also note that the "startdate" is confusing as a term, especially for use in the built= field for the NRHP infobox. In some cases the year-date given there is a start-and-end year-date for construction. In other cases it is a start date while there exists a later completion date, not provided in the infobox. In other cases it is the completion date, and not a start date at all. In other cases it is the date of some significant other event, and is not a built date at all. I wonder, before this is applied by a bot to many thousands of articles, could the term be changed to show something else? Could/should it be called "cssdate" instead? or "mfdate", rather than "startdate"? This has not been used in NRHP articles previously, and I for one do not appreciate its merit yet. Even if it does have merit, then perhaps it could be done better with a different name or changed in some other way to avoid a lot of future confusion.

Thanks, Nyttend, for giving notice about this at wt:NRHP#Recent modification to generator results. I'll comment there too. Perhaps this request should not be implemented without checking there for further discussion, too. --doncram 19:23, 3 January 2013 (UTC)

The previous discussion mentioned above may answer some of your questions; note that it comprised an RfC with overwhelming support. {{Start date}} currently has 104,374 transclusions (including NRHP articles); its name doesn't appear to be a problem. It cannot be applied within the Infobox's code, because of the variety of data formats used, as you mention. I have updated the Infobox's documentation to show examples of its use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:23, 3 January 2013 (UTC)

Hi, thanks for replying. At the NRHP page discussion, you stated that you "answered these questions" here, which you did not, IMHO. The linked previous discussion does not address my 2nd and 3rd points above, at all. Partly addressing 3, you simply state that "its name doesn't appear to be a problem", but that does not fully respond to the situation of the NRHP built date, where editors are focused upon, or should be focused upon, whether a given date is a start of construction date or not. This is quite a sore point, actually, that the commonly used NRHP infobox generator puts the wrong information into infoboxes frequently at this field (some small fraction of the occasions, percentage-wise, but it has generated errors that stand in probably hundreds if not thousands of articles still out uncorrected in mainspace, and the generator is poised with similar incorrect information for many more future articles).

I see you mentioned in the previous discussion that sometimes dates in infoboxes get modifiers like "circa 1920" or get vague dates like "1920-23". These modifiers or date ranges SHOULD be implemented into the built= date in NRHP infoboxes. They are implemented into some good number, probably some few thousands of articles. Unfortunately the NRHP infobox generator commonly used, which works from a copy of the NRIS database, ignores the NRIS database field that indicates "circa" applies, so will show "1920" rather than "c.1920", which is wrong. For a building built during 1920-23, the NRIS infobox generator will put in built=1920, which is wrong. So new articles and many existing articles show assertions that are inaccurate, that are not faithful representations of the NRIS database. Applying the startdate template would make these incorrect assertions seem all the more official, and it will be unclear to editors whether and how they can put in the correctly vague information. I think they would tend to let the official-looking startdate information stand, and only perhaps in the article text state something more accurate.

On point 1., you suggest that the variety in dates is too complicated for mediawiki template software to handle. I don't know that there is much variety in dates, besides the circa and date range issues. I think is is otherwise pretty much just January 31, 2000 format or 2000 format (and not ever 31 January 2000 format), and that infobox code could handle that. Also, from the linked previous discussion, i browsed my way to WikiProject Microformats, where there is a question stated How can we use Microformats on Wikipedia? (and, more generally, in MediaWiki)? which is answered by: "It is easier to apply them to templates rather than individual pages. That also means that individual authors need not know the intricacies of microformat mark-up, only how to use the relevant template. Many of the templates on Wikipedia require minimal changes to use microformats to present their existing content with added meaning. While the functionality may already exist in the Wikipedia template, adding microformat mark-up will make that functionality available to people using the same tools they use when visiting other sites." I interpret that to mean that the Wikiproject which you founded recommends the implementation should be done in the NRHP infobox template, not in all 40,000 or so current articles.

Frankly, I think it is a bad idea to implement this microformat effort, on this particular field of the NRHP infobox. I think that waiting about a year or two would enable the NRHP wikiproject to complete articles on its 87,000 or so NRHP places, and to engage in a cleanup campaign about the accuracy of data in that built= field. I believe the provider of the NRHP infobox tool is not currently willing to make changes to prevent new bad data from being added, so the way to go is to create all the missing articles, then fix them, cutting the infobox generator out of the loop. And I see no immediate need to implement the microformatting. The disadvantages of doing mf now are that it complicates the actual development of articles and the correction of the known-to-be-frequently bad information in the built= field. It also is hardly a service to any potential users of the microformat data, to get convenient access to a field of bad data.

Could you respond to these points? About a previous RFC about the hypothetical of this bot being run having achieved a consensus, that is fine and good, but maybe the participants--none of whom were NRHPers--could not anticipate the complications coming up here. --doncram 23:14, 3 January 2013 (UTC)

Issues with the generator are outwith the scope of this proposal, and this page. By "its name doesn't appear to be a problem", I mean "not a problem to the Wikipedia community. It's unlikely that the template will be renamed to satisfy some editors using one infobox, but feel free to propose that if you wish. The proposed changes in the first and second stages would not touch articles with "circa" or similar qualifiers; or hyphenated vague dates; and the "complications" you say could not have been anticipated have been. I can see no basis for your assertions about "all the more official" data, or "tend to let the official-looking startdate information stand" or "complicating the actual development of articles" - what is your evidence for them? The microformat is applied to the infobox template; this change will mark up the date within the microformat, as explained at the RfC to which I have already referred. If you think you can make the infobox handle the range of date formats used - including circa and vague dates - then by all means do so; but others so challenged have been unable to comply. To reiterate: the RfC - centrally publicised - has already decided that this work can be done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:18, 4 January 2013 (UTC)

Your declaration that it will be "not a problem to the Wikipedia community" omits that it will be, in my estimation, a problem to the NRHP editor community, of current and future editors. It will make the creation and editing of the NRHP infobox a bit more complex, for little/no gain that I can understand, while the NRHP project is right in the middle of its development (at about 40,000/87,000 articles needed).

It's fine that you see "no basis" for concern about editors being intimidated by official-looking but erroneous data. I am sorry, but I have recently been attacked for "ignorance" and worse about a subject area where I have not previously shown expertise, but I was working strictly from sources, and I believe i showed no ignorance. If those who attacked me were consistent, they should attack you personally for gross ignorance too (e.g. your question about Julian dates, below, and your using complete misnomer "HRHP" where NRHP is intended) and should ban you from this area altogether. I don't doubt your good intentions, however, just saying.

My judgment is informed by long experience with the editors of NRHP articles. New editors are quite scared of changing anything that comes from the NRHP article generator. Even very experienced editors are unduly swayed, especially if they don't have access to the NRHP nomination document that was the source for the data entry into NRIS (that was then processed further, and sometimes garbled, by the commonly used NRHP infobox generator). Even very experienced editors WITH access to the NRHP nom document are swayed. It is not a very serious error, but one logical error put in by the NRHP infobox generator is to list architectural styles erroneously as "Greek Revival, Other, Federal", where "Other" is logically out of order. The NRHP infobox generator programmer doesn't care to correct that, but rather accepts the random output of an SQL merge of data that happens to put "Other" in non-logical position. My own programming (not popularly use) corrected that with a few lines of code. A few seconds browsing of new NRHP articles today finds new Ellendale State Forest Picnic Facility, which shows "architecture=Other, Rustic", produced by a fine NRHP editor who was using the NRHP nom document as source for other material, but relied up the generator for that. There are many examples like that. I and others also went through this with the architect= field, which used to be populated with names of persons other than architects, that went straight into mainspace articles. I don't want to condemn any one editor for not exercising more judgment and for not knowing what to doubt out of the NRHP article generator's output. But, I see it with my own eyes, over thousands of articles, that more complicated, more official-looking output simply gets believed. This kind of judgment is corroborated by there being scads of attacks against me, an experienced editor, for using accurately imprecise language in NRHP articles, e.g. that all that is known about a person is that he was an architect and/or a builder, or that a given date was a built date or another date of significance, when full NRHP nomination documents are not available but an article exists already or needs to be created for some reason. I find by experience that if I put in the possibly-incorrect simpler assertions suggested by the generator, that everyone loves it. These are several kinds of evidence, or several ways of explaining that I have relevant experience and focus upon this, Pigsonthewing. --doncram 02:32, 4 January 2013 (UTC)

I have a question and a concern. The question is, does the emitted start date represent the start date of the historic place, or the start date of the construction of the historic place? The concern is that some historic places will have been built when the Julian calendar was in use. It might not be possible to assign a "built" parameter for 13 days to matter, but in cases where that is possible, it would be incorrect to emit a Gregorian date when the input date is Julian. (Emitted dates are always considered to be Gregorian.) Jc3s5h (talk) 23:40, 3 January 2013 (UTC)

You will note that the RfC and documentation for {{Start date}} both explicitly exclude Julian dates. Are there any HRHP entries with explicit Julian years? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:18, 4 January 2013 (UTC)

First, thanks Jc3s5h for being the third person to comment (Nyttend in his comment at wt:NRHP, me, then you) with assumption being that "startdate" means the start date of construction. This documents the likely confusion if this is implemented in the built= field, which is focused on a date of starting and/or completing construction usually (and otherwise is erroneous data). Pigsonthewing's proposal is to use the "startdate" template which has nothing to do with the start of anything.

Second, to answer Pigsonthewing's question, no there never have and never will be any Julian calendar dates in the NRHP infobox, ever. The NRHP listing dates in the "added=" field are all from 1966 on. Some archeological sites that are NRHP-listed may have dates appearing in a built= field that are pre-1500, but the dates given would be from the perspective of U.S. historians and officials of the 1960's and onward. --doncram 02:32, 4 January 2013 (UTC)

Oppose I've raised some concerns that are not addressed. One concern, for one example, that the built= field is especially confusing, could be mitigated by applying the new template to the added= and other fields at the same time. The person who wants to run the bot does not pick up on that, and I perceive wishes to run the bot exactly as proposed, only, dammit. On those terms, and without reasonable discussion and give-and-take perhaps, well, I think it is best not to allow this bot to run. --doncram 02:32, 4 January 2013 (UTC)

Your concerns have been addressed; that you don't accept the answers you have been given does not overturn a properly conducted and well supported RfC. The template should never be used in the |added= field; that's not what it's for. As for calling for people to "attack [me] personally for gross ignorance" and to "ban me from this area altogether" over a single-letter typo... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:59, 4 January 2013 (UTC)

I'm sorry, there is some basic miss-communication here. Is the startdate template meant to indicate start dates of things, or not? I have been understanding it not to be about the start dates of anything like construction, but rather to be a (somewhat misnamed) general date formatting that puts "microformat" into an article, so that the dates can be harvested by some external systems in the future. If it is meant to be about some kind of start date, then the "added=" field should be understood to mean the beginning of a place being NRHP-listed. For most places there is a beginning and no end; for some NRHP places there is an end by delisting sometime after a given building has been demolished or a site has otherwise lost historical integrity. But I do not understand you to want to indicate start and end dates of anything. Instead, the main difference between "startdate" vs. "enddate" templates, that I understand, is that one uses 31 January 2000 format while the other uses January 31, 2000 format, while both provide "benefit" of microformatting. I really really do not understand this bot proposal at all, based on what you say now. Could you please clarify? This is basic to any consideration here.

About calling for people to attack you that was not seriously meant. It was a comment about general stupidity going on that has nothing to do with you. I am sorry for introducing that here.

About your having responded to my concerns, you have not done so. It appears you don't understand my concerns at all, so it makes sense that you cannot respond to them (or if you do understand my concerns, please explain)). Perhaps my concerns are misplaced because of my mis-understanding what you wish to achieve. Please do explain what on earth you wish to achieve. --doncram 15:23, 4 January 2013 (UTC)

(ec) Thank you for your apology. A building constructed in, say 1715 and added to the register in 1959 has a "start" date of 1715, not 1959, just as a soldier born in in 1963 and promoted to general in 2012 has a birth date of 1963, not 2012. The building would have an "end" date if it were demolished, not delisted, the same as the general does not have a death date on retirement. The microformat emitted by the infobox describes the building, not the listing. Your understanding of the difference between {{Start date}} and {{End date}} is wrong; either can display either format of date; it is the meaning of the metadata emitted by them which differs. It is not collegial to block or object to sound and community-approved proposals on the basis that you personally do not understand them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:39, 4 January 2013 (UTC)

You're probably going to encounter a few Julian dates for NRHP places, but (1) they're going to be rare, and (2) it won't really matter. Some places on the East Coast will have been built before 1752, when the British Empire adopted Gregorian, but since I'm asking for the bot to tag only individual year numbers, I doubt that it will have any difference. Nyttend (talk) 16:51, 4 January 2013 (UTC)

Break for convenience

Stop. Think. This is a standardised thing to enable other websites to understand Wikipedia without human guidance. Doncram, consensus has supported its use, so unless you want to file a new request to get that consensus overturned, it's not helpful to object to the concept. Do you have any objections to the concept of adding this template to these dates, and/or do you believe that a bot will be unable to do it? It sounds as if you're objecting to having these dates in the templates in the first place — this information is already there, and the bot won't affect the situation. Nyttend (talk) 16:42, 4 January 2013 (UTC)

Last centralized RfC concluded that microformat deployment should be on a case by case basis. The above discussion addresses such a case, so I don't see a problem with Doncram's comments. His point is valid that the same result could be achieved via infobox or MediaWiki enhancement. Except nobody is taking any steps to do so, instead converting individual article infobox fields to {{start date}}-style templates. —  HELLKNOWZ  ▎TALK 16:54, 4 January 2013 (UTC)

This is not a request to deploy a new microformat, nor indeed to deploy a microformat at all. Please see the more recent RfC, mentioned twice already above, where this is made clear, and which passed with overwhelming support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:02, 4 January 2013 (UTC)

To reiterate, and with consideration of further discussion, I continue to oppose this bot suggestion, I think for good reasons. The several-times-mentioned previous "RFC: Deploying 'Start date' template in infoboxes", seems to be about the merit of using microformats with dates. There was no discussion and no endorsement within that proposal, for applying "startdate" specifically with any type of start date, and especially nothing about NRHP-listed properties, ships, historic districts, objects, other types of items that use the NRHP infobox. I don't know where "Start dates" are relevant in wikipedia, perhaps for articles about wars or other events that actually have known start and end dates. I don't think "startdate" and "enddate" have been defined for NRHP historic districts, or buildings, or other NRHP items.

If they were to be defined, I don't think any bot should be run based off the built= field, because the contents of that field are known to be sometimes erroneous, in existing articles and likely to be erroneous in new articles that include the common NRHP infobox generator's output. It would not be putting forth WikiProject NRHP's best work, to put it mildly, for this field to be emphasized and picked up in hypothetical uses of the microformatted date information, as if this is a useful or correct date for any purpose. I read the microformat and hcard and some other articles, and see no immediate use for anyone of this. I read the template:startdate and template:enddate pages and see no explanation there for what a "start date" is supposed to mean, or for an "end date". I don't see anything useful at all about anything here, and I think it is an especially bad time to run a bot through all the WikiProject NRHP articles that somehow elevates sometimes-incorrect information that is not useful information. The costs of the bot include all the edits and clogging up of watchlists and edit histories for no gain. The costs include increasing the difficulty of editing in NRHP pages, and in overcoming natural reluctance/unsureness of editors to correct bad information that is widely present. The costs include expanding the size and extending the load time of 40,000 articles.

I doubt whether the major advocate for running this bot is aware of running controversy over the use of NRIS built date in articles for historic districts vs. buildings and some other types of listings, where one editor has been, with some justification, systematically adding and subtracting categories that address whether a listing dates from a given year or not. The categorizing of buildings "completed" by a certain date accepted by this editor is often incorrect, keying off the infobox-reported built= field, in asserting that a given property was built in a given year, when in fact frequently that was the year a building's construction was started. The editor has been simply removing date related categories for the historic district items, where in fact it could be possible and useful for date categories to be defined. Maybe advocates of microformat start and end dates could get together with category advocates, and generate microformats using the somewhat-more-verified category fields, somehow.

The very same built= date, subject of category-focused confusions, is now targeted by this bot proposal to be used as start date, when sometimes the contents appearing probably are a completion date and sometimes are a start date. I honestly don't know what date is wanted by the bot-proponeent ideally, nor do I think they are aware of the various options and complications for different types of NRHP items. Again, perhaps for the NRHP wikiproject, the most meaningful start and end dates are probably the dates of listing and delisting (if it has occurred) for a given property. Or to be the beginning and end dates of the period of historical significance for the listed property. Or to be start and end dates of construction. If start and enddate were to be defined in any given way, then surely the current contents of the built= field are not correct in some/many cases.

For the bot-advocate to assert that defects of the NRHP infobox generator and all other content issues are not a subject for this page, and that some RFCs not addressing NRHP items or not addressing any concept of what start and end are supposed to mean, that these RFCs are supposed to dictate what happens now, well, let me say the advocate should not have redirected discussion to here, away from the wt:NRHP page.

I don't think the NRHP wikiproject is ready or willing to take on the burden of getting "start" and/or "enddate" information correct for the use of the startdate and endate templates. I personally see no utility for any user whatsoever of Wikipedia, and I do not want to ask my fellow NRHP wikiproject editors to take this on. I far prefer for NRHP wikiproject focus to be put onto various, more important data quality issues.

Bottomline: No matter how "start" and "end" are to be defined, and assuming there were some value to someone for having this information in microformat, it would be far better to define a new startdate= field and an enddate= field in the NRHP infobox, and to allow NRHP editors to populate that field with information that is correct for whatever definition is chosen. And, then the wikimedia coding of the NRHP infobox can handle the application of startdate and enddate templates. If the advocate of microformatting wishes to advance that usage, please make a proposal at Template talk:infobox nrhp and give notice at wt:NRHP. There certainly is no value in running a bot, IMHO. --doncram 05:15, 8 January 2013 (UTC)

Just remember that there's community consensus for implementing this template for making this type of metadata across Wikipedia, and the |built= parameter is precisely what the template is meant to mark. As long as the bot runs properly (which shouldn't be too difficult to ensure), all erroneous entries will be the result of erroneous entries before the bot came along — there's an underlying issue that this bot operation won't affect. Nyttend (talk) 05:29, 8 January 2013 (UTC)

Over-enthusiastic Addbot

A bot has subst'ed a TfD notice onto about 3000 talk pages - example edit, list of affected pages. The TfD discussion is now closed, so the notice is no longer relevant. Is this something a bot could/should clean up? -- John of Reading (talk) 09:12, 1 January 2013 (UTC)

I believe so. Would replacing the entire substitution with {{OW}} be sufficient?  Hazard-SJ  ✈  01:39, 3 January 2013 (UTC)

Yes, simplest is best. -- John of Reading (talk) 07:58, 3 January 2013 (UTC)

Generate list of Ethiopia-related redlinks

We need to generate a list of common redlinks linked from Ethiopia-related articles. Is it possible for a bot to do this? The articles could be found in a number of ways:

• All articles that have talk pages with {{WikiProject Ethiopia}}. These same talk pages can be found in the Category:WikiProject Ethiopia. The bot should search the related articles for redlinks.
• All articles found listed in any category that begins with Category:Ethiopia.
• All articles found in Category:Ethiopia and all its sub categories.

There are probably even more ways of identifying the articles. But if possible we need the bot to dump the list of redlinks into a page: allredlinks. If the list is too long, perhaps break it down by alphabet like: A-G redlinks or A redlinks, B redlinks, C redlinks. Then also we would like a list of the top 100 most common redlinks.

I don't know if this is possible or feasible. However, it would greatly improve our project's goal of expanding Wikipedia's coverage of Ethiopia. Thanks from (WP:ETH) አቤል ዳዊት (Janweh) (talk) 06:49, 2 January 2013 (UTC)

I believe tools:~magnus/missingtopics.php can help you out, though depending on the length of the list, it might be easier/faster just to have a toolserver user run a query for you manually. Legoktm (talk) 06:53, 2 January 2013 (UTC)

{{Rayment}}

Template:Rayment should have the parameter external links=1 when used as an external link. I have often seen people forget that parameter, and that causes two error messages appear that should only appear when used as a source. Werieth (talk) 21:48, 20 December 2012 (UTC)

• Coding...--Makecat 06:19, 24 December 2012 (UTC)

previous comments where archived, I am un-archiving as this is not resolved. Werieth (talk) 19:08, 2 January 2013 (UTC)

• Wikipedia:Bots/Requests for approval/Makecat-bot 4 was withdrawn by Makecat, however this request is fairly trivial, if the template is below a section called External Links then add the parameter otherwise ignore it. Werieth (talk) 19:08, 2 January 2013 (UTC)

WikiProject tagging request: WP:JAZZ

Hello, WP:JAZZ would like to have a 'bot add the {{WikiProject Jazz}} banner to jazz-related pages that aren't already tagged. We had already left a request at User talk:DodoBot/Requests#WP:JAZZ (with more details concerning inheritance; auto-tagging stubs etc.). However, that account does not seem to be very active (which I did not notice at the time I filed the request). (I later left a request for User:MuZebot, before I noticed an older message indicating that MuZemike would be on administrative hiatus.)

The list of relevant categories is located at Wikipedia:WikiProject Jazz/Categories, but please note that there are actually three lists of categories at that page; they each need to be tagged slightly differently:

1. We need the bot to add {{WikiProject Jazz|album=yes}} to the articles (or rather, the talk pages) within the /Albums sub-listing
2. We need the bot to add {{WikiProject Jazz|song=yes}} to the articles (or rather, the talk pages) within the /Songs sub-listing
3. We need the bot to add {{WikiProject Jazz}} to the articles (or rather, the talk pages) within the /General sub-listing

To the best of my knowledge, /Categories represents all applicable categories and sub-categories (I deliberately omitted those that are outside the project's scope), so you should not need to worry about sub-category depth or "false positives".

FYI in 2010, we had Xenobot Mk V perform (essentially) the same request. (See Wikipedia talk:WikiProject Jazz/Archives/2010 1#Adding WikiProject banner). It also added {{WikiProjectBannerShell}} if and when it was able to do so.

I think we do not want to inherit importance=, only inherit class=.

I have an additional request, but I am not sure whether it's technically possible, and furthermore I'm not sure whether we have consensus (see unanswered comments). I'd be interested in having the 'bot add needs-infobox=yes if the article does not have an {{Infobox foo}} template; or if {{WikiProject Jazz}} can inherit this setting from another WikiProject banner, or it can inherit this setting if the talk page already has {{Infobox requested}}.

Let me know if I can clarify anything, either leave me a message here or at WT:JAZZ.

Thanks and Happy New Year, Gyrofrog (talk) 15:27, 3 January 2013 (UTC)

I can do it. -- Magioladitis (talk) 10:30, 4 January 2013 (UTC)

Thank you! I figured something was underway when I saw all the Yobot edits on my watchlist. -- Gyrofrog (talk) 15:27, 4 January 2013 (UTC)

I 'll do the request in two steps if you don't mind. I don't have the time to rewrite the code so I find it easier to do it this way. -- Magioladitis (talk) 15:40, 4 January 2013 (UTC)

Hey, no problem, you're the one doing us a favor! -- Gyrofrog (talk) 15:51, 4 January 2013 (UTC)

Why is this bot adding the jazz header to unrelated articles? Cruel Summer, Done by the Forces of Nature, Clouds (Joni Mitchell album), to name a few. Dan56 (talk) 16:50, 4 January 2013 (UTC)

I'm really not sure about the first album. Done by the Forces of Nature is in Category:Jungle Brothers albums which rolls up to Category:Jazz rap albums. And Category:Joni Mitchell albums rolls up to Category:Jazz fusion albums. -- Gyrofrog (talk) 17:08, 4 January 2013 (UTC)

I added all the pages found in rhe categories given in /Album. If this helps. -- Magioladitis (talk) 18:55, 4 January 2013 (UTC)

Clouds (Joni Mitchell album) is in Category:Joni Mitchell albums. Recall something important, only reverting won't help unless you do it after I finish everything. Otherwise, my bot will readd the tag. there are three options: Please wait and revert tomorrow or fix the categorisation or make me a list of false positives. -- Magioladitis (talk) 19:27, 4 January 2013 (UTC)

Those genre categories were erroneously place in the artist-album categories ("Category:Joni Mitchell albums" is also under the category "Folk rock albums", which would have nothing to do with jazz fusion). Still doesnt explain Cruel Summer, though. Dan56 (talk) 23:15, 4 January 2013 (UTC)

It's in Category:Common (entertainer) albums. -- Magioladitis (talk) 00:02, 5 January 2013 (UTC)

How about "And I Love Her", "Here Comes the Sun", and "My Sweet Lord"? Thanks! GoingBatty (talk) 01:22, 5 January 2013 (UTC)

The first one is on Category:Diana Krall songs, the second on Category:Nina Simone songs and the third on Category:Nina Simone songs. I am not gonna continue doing this though. I am doing what I 've been told to. I don't have time to fix categorisation tree. -- Magioladitis (talk) 01:33, 5 January 2013 (UTC)

I don't know if these songs were sang in a jazz version but these jazz singers. Someone expert has to tell us I guess. -- Magioladitis (talk) 01:40, 5 January 2013 (UTC)

Thanks for letting me know why they were included in your run. Since it doesn't appear that Krall or Simone's versions were particularly notable, I removed the categorizations you mentioned from those articles. Thanks again! GoingBatty (talk) 01:43, 5 January 2013 (UTC)

I finished the songs, I almost finished albums but a rerun is needed in this case. Now I am doing the general ones. -- Magioladitis (talk) 01:34, 5 January 2013 (UTC)

I finished and double-checked the songs and the general ones. I'll rerun for the albums. -- Magioladitis (talk) 10:31, 5 January 2013 (UTC)

Xeno bot and Dodobot

I just wanted to mention that Xeno bot refers WikiProject Tagging requests to Dodobot and Dodobot has.'t edited in over a year. Someone might want to go and update those pages so that folks won't continue to try and get them to work!. Kumioko (talk) 18:13, 4 January 2013 (UTC)

I can take over all the tasks. -- Magioladitis (talk) 20:09, 4 January 2013 (UTC)

Your the man Magio!. Kumioko (talk) 20:59, 4 January 2013 (UTC)

Bot capable of rearchiving from incremental archives to month-year archives

Background. There's a reason why incremental archives exist: for Talk pages of articles like Talk:Barack Obama that generate so much content in a single month that it would be impractical to archive in month-year format. However, there are other talk pages that don't generate so much content in a single month but that were archived in incremental archives when they should have been archived in month-year format.

Proposition. I need a bot that can rearchive from incremental archives to month-year format. We have to do this manually today (see [1] followed by [2]) or through a special key requested to Misza to operate on MiszaBot. Unfortunately this key has to generated every single time for each rearchive needed. We need a bot capable of doing this without the key restrictions.

—Ahnoneemoos (talk) 02:33, 5 January 2013 (UTC)

Manual SearchBot Not Working

The Coren manual search bot [here] does not appear to be working. There are several unprocessed requests and the last one appears to have run on 3 August 2012. Blue Riband► 04:02, 5 January 2013 (UTC)

CSB has been replaced by User:MadmanBot a long time ago. Legoktm (talk) 04:03, 5 January 2013 (UTC)

Humm...I see from User_talk:Coren that there are recent replies from Coren on this talk page but no reply to the inquiry regarding the bot which I left there. According to the page for User:MadmanBot the CSB has been offline since 31 Dec 2011, but seems to have been just abandoned in place. At Wikipedia:Cv101#Tools I just replaced the existing link to the CorenBot/manual with a link to User:MadmanBot/manual. — Preceding unsigned comment added by Blue Riband (talk • contribs) 22:00, 6 January 2013 (UTC)

Follow up- MadmanBot appears to not process requests consistently. Some copyright checks were processed but others are still "stuck" on unprocessed. The bot owner has deleted some unprocessed requests. However VWBot/manual does seem to function, as an article request for processing went through within minutes. Blue Riband► 17:27, 7 January 2013 (UTC)

Extension infobox update

I hope you don't mind if I post here a request for mw:: we need someone running a bot to automatically (and if possible regularly) update {{Extension}} infoboxes with the hook data now available on Extension Matrix/Hooks (background): for each line of the page, each item in the square brackets should be added as hook1=, hook2= etc. replacing any previous parameter.
If someone is willing to do this and doesn't have bot flag, I'll take care of the paperwork myself to get it approved (processes are quicker on mediawiki.org). A first test run could probably be performed also without flag, however. Thanks! --Nemo 08:59, 5 January 2013 (UTC)

UAA bot

I'd like to run the following idea by you folks for a new bot in the UAA process. This is a bot that would run on four pages: WP:UAA (the main noticeboard), WP:UAA/BOT (the DeltaQuadBot noticeboard), WP:UAA/HP (the noticeboard's holding pen), and CAT:UAA (the noticeboard's category). Currently we have a number of other bots working these pages, including ones that automatically remove any accounts that are blocked.

But an enduring issue that we deal with on all four pages is having to manage a significant number of usernames that have gone stale, and for every one of them we must manually do the work to move or remove them. i.e, we must manually move old reports from the main/bot pages to the holding pen, manually remove stale accounts from the holding pen completely, and manually remove stale accounts from the UAA category.

For this reason, I am asking if it is possible and if there are any people willing to code a bot that would automatically manage this issue. The bot would do the following three tasks:

1. Move any report from WP:UAA and WP:UAA/BOT to its correct section (date) in the holding pen, if (a) nobody has commented on the report for 24 hours*, & if (b) the account has had no edits or log actions in the previous 24 hours. (It is assumed that in such circumstances it is no longer necessary to 'priority'-watch these accounts on the main UAA pages).
2. Remove any report from WP:UAA/HP if (a) nobody has commented on the report for seven days, & if (b) the account has had no edits or log actions in the previous seven days. (It is assumed that in such circumstances the reported users are unlikely to ever return, so they are no longer necessary to watch).
3. Remove any account from CAT:UAA if (a) the category has sat on the page for seven days, & if (b) the account has had no edits or log actions in the previous seven days. (Like above, it is assumed that under these conditions the users are unlikely to return and need no more monitoring).

This would in theory take care of a huge workload for the people who work in this area. Note that the 24 hour and seven day timeframes are a reflection of the timeframes admins and others currently tend to use. If this were to be implemented, we'd likely want to get a more formal consensus on those times.

*Note that a potential issue with task #1 is the bot moving reports that have not yet even been closed by an admin. For this reason we may want to set a third condition that (c) someone has commented on the report with Template:UAA. But I also see a potential risk with this task that the bot will move declined reports that don't need to be in holding pen at all, or that it will move specific reports that require more time on the main pages for comments/discussion. Therefore we might want to scrap this task unless there is a workable way to do it.

Of course, this would not eliminate all issues with stale reports and some would occasionally have to be taken care of manually, but I think there is some potential here to make the UAA process more efficient. Thoughts? Possible? Issues? Anyone interested in coding? NTox · talk 18:39, 5 January 2013 (UTC)

History of Western Sahara

Could a bot replace {{History of Western Sahara}} with {{Western Sahara conflict}} throughout Wikipedia. The vast majorty of pages that transcend the first one should transcend the second instead. I just moved {{Western Sahara conflict}} to it's current title from {{History of Western Sahara}}, and created the beginnings of an real History of Western Sahara template at the old title. Emmette Hernandez Coleman (talk) 18:52, 5 January 2013 (UTC)

Image removal tracker

Would it be possible for a bot to read the recent changes and pick out edits that involved the removal of an image from an article and, subject to conditions below note on the talk page of the removed file the article(s) from which it was removed (with a link to the edit that removed it and/or a copy of the edit summary)?

The conditions would be:

• Do not note articles where the removal was reverted (I guess this would require operating with some sort of buffer?).

  This is because there is no point recording images removed by vandalism or editorial dispute.

• Do not record articles where the addition was reverted (ditto re buffer)

  There is no point recording images added for vandalism or editorial dispute

• Do not record removals where the edit summary indicates that the image was renamed (e.g. [3])

  This is not a removal of the image, although if a renamed file has a talk page at it's old name it would be helpful to move this, but this is likely outside the scope of this bot.

• Do not record removals where the image has been deleted

  The will be no talk page to record to, and while the deletion may be overturned noting where it was is a different issue I don't think solvable by this bot.

• If a removed image is tagged as nominated for deletion, nominate that deletion discussion also

  Ideally avoiding duplicating any manually left messages about this, but I don't know how that could be done.

• Do not record images used in templates if the template is removed (excluding infoboxes).

  Recording the removal of icons used on cleanup templates for example would be foolish and counterproductive.

See Wikipedia talk:Files for deletion for some background, but at this stage this is just a request from bot programmers about feasibility. Do not worry about specifics, I'm interested in the concept and generalities, details can come later if the idea gets that far. I have not sought to determine if there is consensus for such a bot as this would be pointless if it is not realistically doable. Thryduulf (talk) 00:52, 7 January 2013 (UTC)

Time to remove findarticles.com links

The wikilinks from findarticles.com/Special:Linksearch/*.findarticles.com used to lead somewhere, now they are now just a redirect to a search website. I think that it is time to delete the lot of them. They may or may not have been useful at the time, they are not currently useful, and they are worse than linkrot now. Time to remove them. — billinghurst sDrewth 23:26, 7 January 2013 (UTC)

In case the question comes up during the discussion, it appears they excluded the Internet Archive from duplicating their content. So that's not an excuse to keep the URLs. --j⚛e decker^talk 00:07, 8 January 2013 (UTC)

It's sad that the Internet Archive allows a site to put up a robots.txt in 2013 and have it delete (from public view, anyway) archives that had previously been available for years. Anomie⚔ 04:13, 8 January 2013 (UTC)

When the reference includes more than just a URL the article's title and author are often enough to find a copy of it elsewhere, so I think that other parts of the reference(s) should be retained if/when possible. VernoWhitney (talk) 04:57, 8 January 2013 (UTC)