Page semi-protected

Wikipedia:Bots/Requests for approval

From Wikipedia, the free encyclopedia
Jump to: navigation, search

If you want to run a bot on the English Wikipedia, you must first get it approved. To do so, follow the instructions below to add a request. If you are not familiar with programming it may be a good idea to ask someone else to run a bot for you, rather than running your own.

 Instructions for bot operators

Current requests for approval

edit WP:BRFA/MusikBot_6

MusikBot 6

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

Time filed: 01:54, Friday, October 9, 2015 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): Ruby

Source code available: GitHub

Function overview: "Rotate" headings at T:TDYK every day. This means moving the "Current nominations" heading to the current day minus seven days, and then adding a new heading for the current date.

Links to relevant discussions (where appropriate): Special:PermaLink/684810934#Updating_T:TDYK_every_new_day

Edit period(s): Daily

Estimated number of pages affected: 1

Exclusion compliant (Yes/No): No

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

Function details: The bot will run every day at 00:00:00 GMT, acting on T:TDYK. It will move the level 2 "Current nominations" heading above the level 3 headings for the current day minus seven days (specified by User:MusikBot/RotateTDYK/Offset). Next, it checks if a heading exists for the current date, and if it doesn't, creates it along with the instructional comment. This is best exemplified by diffs, see [1] (the bot on testwiki) versus [2] (human on enwiki).

The important thing is that the bot doesn't try to do anything that's already been done, and is programmed to handle edit conflicts. Conceivably if the page gets mangled the bot will error out and abort, since we're using explicit regex to identify what to change on the page. If it fails it will wait 3 minutes and try again, and continue to do so for up to 15 minutes before aborting entirely. Errors are logged at User:MusikBot/RotateTDYK/Error log MusikAnimal talk 01:54, 9 October 2015 (UTC)


edit WP:BRFA/Monkbot_9

Monkbot 9

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

Time filed: 10:16, Sunday, October 4, 2015 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): awb

Source code available: User:Monkbot/Task 9: Ship infobox lists

Function overview: replaces line-break (<br />, {{br}}) lists and {{plainlist}} and {{unbulleted list}} templates with generic unordered lists in the various ship infobox templates.

Links to relevant discussions (where appropriate): WT:SHIPS#lists in infobox parameter values

Edit period(s):

Estimated number of pages affected: 20k-ish

Exclusion compliant (Yes/No): yes

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

Function details: complete description at User:Monkbot/Task 9: Ship infobox lists


  • I am curious to see how this works. <br /> should definitely be replaced because of the accessibility issues, but is it worth replacing {{plainlist}} or the other template assuming nesting is not required on a particular page? How often is this construct used? — Earwig talk 08:43, 6 October 2015 (UTC)
    I'm a bit unclear about what it is that you are asking. At the time of this writing, there are about 29250 transclusions of {{infobox ship begin}} which is required to be present in every ship-article infobox. That number defines the upper bound. At the time of this writing, Category:WPSHIPS:Infobox list errors has about 20500 articles.
    Articles get into Category:WPSHIPS:Infobox list errors through Module:WPSHIPS utilities for one or more of four reasons:
    1. a parameter value has <br />
    2. excepting white space, the first characters following the parameter's assignment operator is two or more asterisks (|<param>=** <text>)
    3. when a line in a standard unordered list does not begin with one or more asterisks
    4. when the number of asterisks at the start of a line is more than one more than for the preceding line (from *<text> to ***<text> for example)
    Though it can, Module:WPSHIPS utilities does not currently detect {{plainlist}} and {{unbulleted list}}s. If they alone are the method by which editors have chosen to implement lists in an article's ship infobox, then those articles are not a member of Category:WPSHIPS:Infobox list errors.
    If you look at Special:Contributions/Trappist the monk you can see that the edits made by the task 9 script all report converting line-break lists. Shortly after I updated the ship infobox templates to use Module:WPSHIPS utilities I ran an earlier version of the task 9 script on the articles in Category:FA-Class Ships articles so there are articles where only plainlists were converted.
    Because task 9 converts <br /> to ordinary unordered lists, where it can, it also converts {{plainlist}} and {{unbulleted list}} for consistency in the whole of the infobox.
    Trappist the monk (talk) 11:00, 6 October 2015 (UTC)
    I noticed that this edit does something odd – bullet points are added to the "Operators" field – but it also look like the original format wasn't quite right. Can you take a look? — Earwig talk 19:16, 6 October 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Yep, saw that when I made the edit and elected to allow it to stand. The parameter value is definitely broken so a case of garbage-in-garbage-out. In wikitext, two lines of text without an intervening blank line are rendered as a single line of text – the end-of-line marker is converted to a simple space. This paragraph is written one-sentence-per-line to illustrate that.

Probably the editor intended to include another <br /> tag following the Coastguard flag. The script can't know, so it only operates on the explicit <br /> tags. The result may look a little odd, but no more odd than it did before and, I think, even though wrong, is more meaningful to a reader.

Trappist the monk (talk) 22:10, 6 October 2015 (UTC)

Hm, but shouldn't the template be making that a plain list rather than adding the bullet points? — Earwig talk 23:00, 6 October 2015 (UTC)
Never mind, I misunderstood how the module works. This looks like the correct behavior; GIGO, as you said. — Earwig talk 23:56, 6 October 2015 (UTC)
  1. Although... this edit adds bullet points to the "complement" section, but I'm not sure why, since the syntax looks correct. Same thing with this edit.
  2. This edit is not quite right. I'm not sure if we could consider this GIGO, since the original format is technically valid. (I think?)
  3. This edit is also leaving an odd result; again, don't know if this is an expected format. Honestly, I hate the look of the three giant flags in the header like that.
  4. Same issue as the first one I noticed with this edit. Would it be better to have the bot skip these cases (i.e., where a parameter uses <br /> but there are some lines not separated by them) and leave them for manual review?
  5. Another instance of clear GIGO with this edit, leaving behind an empty parameter. Probably not worth doing anything about.
Those are the only issues I noticed. Apologies if you already fixed any of them already, since I noticed you made some changes to the bot between edits. — Earwig talk 01:18, 7 October 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── 1a. ARA Santa Fe (S-21) is broken not because of anything that the task 9 script or Module:WPSHIPS utilities did, but because of how other processing outside of my control (HTML cleaner?) mangled the malformed lists in |Ship speed= which see. Here is the raw HTML for the start of |Ship complement=:

<tr style="vertical-align:top;"><td>Complement:</td><td><ul style="list-style:none none; margin:0;"></li></ul>

and the first line of the same when the two non-list lines of |Ship speed= are prefixed with asterisks to make them part of a single list:

<tr style="vertical-align:top;"><td>Complement:</td><td><ul style="list-style:none none; margin:0;">

In the broken example, </li></ul> are closing tags from the previous (submerged speed) list. It is no wonder then that |Ship complement= renders poorly.

1b. Acasta-class destroyer is the same kind of problem; making the |Ship propulsion= parameter value a single list causes the infobox to be rendered correctly.

2. Abeille-class brig at |Ship armament= was a parameter with both <br /> and unordered list mark up so not at all technically correct.

3. Af Chapman is a misuse of one {{infobox ship career}} template to hold three careers. The correct solution to this issue is two or three career templates instead of just the one (ARA Veinticinco de Mayo (V-2) is an example).

4. Abercrombie-class monitor is broken for the same reasons as 44-foot motor lifeboat. When (if) this bot task is approved and after it has run and presumably cleared the majority of articles from Category:WPSHIPS:Infobox list errors, I will do some work to improve the currently crude error messaging in WPSHIP utilities and then turn them on. It is, in my opinion, necessary to educate editors. Leaving malformed lists in an infobox (where they have been malformed for who knows how long) and without any obvious visual cue that there is something wrong, doesn't seem to be a good way of getting the lists fixed.

5. ARA Santísima Trinidad (1974) has a pipe left over from the conversion of a {{plainlist}} template. I agree that such leavings are harmless.

Trappist the monk (talk) 12:30, 7 October 2015 (UTC)

I'm still a bit unsure about the first error. Why is having lists within the parameter, when it starts with non-list text, considered invalid? — Earwig talk 05:36, 8 October 2015 (UTC)
Beyond mishandling of unordered lists over which the infobox templates, Module:WPSHIPS utilities, and task 9 have no control (the broken html </li></ul>), lists like that in the |Ship speed= parameter in are probably best done as description lists which markup is semantically correct when compared to <some text> followed by an <unordered list>. In wikimarkup, description lists are the semicolon (term) and colon (description).
Trappist the monk (talk) 10:54, 8 October 2015 (UTC)
Okay, that's fair. One final question: is it feasible for the template to automatically place these articles in Category:WPSHIPS:Infobox list errors on the basis of that issue? My concern is that (given the number of edits this bot will make) we'll end up with a number of slightly-broken pages without a clear way to identify which ones need this particular problem fixed. — Earwig talk 03:54, 9 October 2015 (UTC)

edit WP:BRFA/JackieBot_1

JackieBot 1

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

Time filed: 08:12, Tuesday, September 8, 2015 (UTC)

Automatic, Supervised, or Manual: Supervised

Programming language(s): Python

Source code available: Standard pywikipedia bot

Function overview: simple and complex replacements

Links to relevant discussions (where appropriate):

Edit period(s): none

Estimated number of pages affected: about 20 per day, depending on the number of occurrences (for regular task)

Exclusion compliant (Yes/No): Yes

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

Function details: regular run for replacements invalid url (see latest edits and fix error with manual control or by request. — Jack 08:12, 8 September 2015 (UTC)


This bot is already performing this task in article space? I thought that was not allowed. Maybe I missed a previous discussion.

Please post the source code and describe the edits that are proposed. – Jonesey95 (talk) 13:08, 8 September 2015 (UTC)

Code - it is standard script from Pywikipediabot package. Or what are you want? It for search weblinks, which contain 1 - 3 wrong prefixes with hhtp, http, Http, HTTP, https, Https, HTTPS writing and replace to the http. Correct links with http / https not applicable. Uncertain weblinks (to the unknown for me internet services) I check manual before saving. Example. — Jack 19:11, 12 September 2015 (UTC)
  • Running the bot without first obtaining approval was an issue already brought up in this bot's last BRFA. ~ RobTalk 14:36, 8 September 2015 (UTC)
  • @Jackie: Yeah, that's... bad. Please don't run unapproved bots. Regarding the actual task: it looks fine, but I'd like to see the actual regexes or code involved. There is potential for some issues. For example: in cases like 1 and 2, a link that is ambiguously https or http is made to be http. It's arguable that is not the best behavior. — Earwig talk 05:15, 11 September 2015 (UTC)
    Final links is correct and such replacement is more universal between cases if a few mixed prefixes are present in URL. For the popular internet services I stay http (if knew, that http is supported; else I check it before saving by bot). You want to offer "https" as result? Or if incorrect url contain mixed prefixes - what prefix is correct? For bot's edits I select same option as in cases manual edits. — Jack 19:11, 12 September 2015 (UTC)
  • So, looking at the bot's edits, I have a few problems with it.
    • To me, not a bot guy, it seems like adding a check to see if the website supports https should be trivial. Python has SSL libraries, all you'd need to do is have it check if it can connect to the site over https, and if it can, if the certificate is valid. I could be way off here, but in any case, I don't like that it assumes http over https. You could also have it get rid of the "http:" and "https:" all together - that wouldn't be ideal, because it wouldn't do much over having "https://http://", but that way there's a better chance the link will actually work.
    • The bot edited in other people's userspace. Not only on their userpages, but also their talk pages. I just don't like bots changing the userspace unless there's a good reason for it. If I want to put a broken link in my userpage, I'll put a broken link there, and I don't want a bot "fixing" it for me.
    • The bot edited without approval. Not only a handful, but well over 50. Not even a few days, but for *two and a half years*. That makes me seriously question whether or not you know, or care about, the bot policy.
  • Just my 2¢. Frood 20:44, 13 September 2015 (UTC)
@Jackie: Can you respond to the above concerns? — Earwig talk 06:32, 25 September 2015 (UTC)
Now only on main space. For check links via SSL libraries - I try, but then it will not standart pywikipediabot. Bot's work is useful or broken links prefer? I ran the bot for useful work, not for fun. — Jack 06:48, 28 September 2015 (UTC)
I do think the task is useful, but it requires a more sophisticated implementation with regard to deciding which protocol to go with, as others have noted. ~ RobTalk 14:19, 28 September 2015 (UTC)
Maybe if the proposing editor posted the source code, as requested above, helpful editors could make suggestions about how to improve the protocol detection and decision-making. I don't think that would help with the editor's dismissive attitude toward the bot policy, however. – Jonesey95 (talk) 15:01, 28 September 2015 (UTC)
(edit conflict) Of course the task is useful; that's not my concern here. You still haven't addressed the fact that you've run this task unapproved for over two years. Without some assurance that you understand the bot policy, I am not comfortable moving forward with this. — Earwig talk 15:30, 28 September 2015 (UTC)

Bots in a trial period

edit WP:BRFA/ASammourBot


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

Time filed: 09:26, Thursday, October 8, 2015 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): Java

Source code available: No

Function overview: The bot will work in this list of categories, which is stubs categories. The bot will search in the pages of each category, if it found in the content of the article "category:...stub"; it will replace it with the template of the stub. More details here

Links to relevant discussions (where appropriate): The idea is taken from here.

Edit period(s): Continuous.

Estimated number of pages affected: I have no specific number, but it will be the number of pages that contains stub category.

Exclusion compliant (Yes/No): Yes

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

Function details:

  1. The bot will work in the list above.
  2. The bot will get the category members of the category.
  3. Then it will loop througt the pages of the category.
  4. if found the stub category in the content, and the article content doesn't has stub template; the bot will remove the stub category, and replace it with the stub template.
  5. if found the stub category in the content, and found stub template; it will remove the category and keep the template.


I unblocked the bot for you. This task seems fine and I'm glad to see you pick it up. Approved for trial (50 edits). The one issue that strikes me is WP:STUBSPACING; make sure per convention that you put the stub template at the absolute end of the page, with two blank lines separating it from any categories. — Earwig talk 19:49, 8 October 2015 (UTC)

edit WP:BRFA/Luke081515Bot_2

Luke081515Bot 2

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

Time filed: 17:26, Friday, August 14, 2015 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): PHP

Source code available: No

Function overview: Bot moves pages without leaving a redirect per user request

Links to relevant discussions (where appropriate): Special:PermaLink/676087384

Edit period(s): per user request

Estimated number of pages affected: unknown

Exclusion compliant (Yes/No): No

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

Function details: This bot works on a queue. Users can schedule there a page move, the bot will complete this move after 10 seconds (sometimes 20, when tool labs is a bit slower) To avoid vandalism, the following features are enabled:

  • Don't set a botflag when moving a page (Mark a request as done uses a botflag)
  • Only move pages from own userspace, the bot controls the author of every request)
  • Don't move talk or main userpages
  • If existant, the bot moves the talk page also (if talk page is move protected, the bot will abort the request)
  • If wished by members of BAG, I can enable, that the bot moves pages only to article namespaces
  • Bot can be deactivated without a block (simple site which have to set from true => false, to abort this task)
  • If wished by a sysop or the Arbitration Committee (for example a user should not move pages, or so on, I didn't read decisions from then yet, users can set on a blacklist, the bot will abort all request form that user

Additional details:

  • This script runs already succesfully at the german wikipedia since May 2015, I just have to fix the namespaces and page names, then I can start.
  • As you can see here, there were no user opposing that since now, and I also don't know reasons to oppose this. The only thing is, that the request page have to be semi protected by a sysop.
  • This bot needs no adminflag, because bots got the right suppressredirect by default.

So if you have any questions to the details, please ask. Sincerely, Luke081515 17:26, 14 August 2015 (UTC)


{{BAGAssistanceNeeded}} Luke081515 09:16, 21 August 2015 (UTC)

Approved for trial (7 days). -- Magioladitis (talk) 09:00, 24 August 2015 (UTC)

OK. @Magioladitis: I need some time to prepare the trial, I will tell you, when I'm ready. Grettings, Luke081515 09:34, 24 August 2015 (UTC)
Luke081515 OK. No problem. You requested BAG assistance :) -- Magioladitis (talk) 09:38, 24 August 2015 (UTC)

By the way, YES this should be limited to ARTICLES and corresponding talk pages. No templates, categories, etc. We already have a bot for categories. -- Magioladitis (talk) 09:40, 24 August 2015 (UTC)

Ok, no problem, this is also enabled at dewiki, so this is no problem. But I need time to fix namespace names etc form german to english, so I will test this at beta enwiki first, before I will start the trial. Greetings, Luke081515 09:53, 24 August 2015 (UTC)
Ok, there are only a few tests to do, so I guess that I can start this week. @Magioladitis: Can you protect this page with edit=autoconfirmed and move=sysop? A move will be the reason of errors, and only users that have the right move should request a move, that's my view, it also prevents vandalism. Also this page needs protection, in this case full protection, because user can edit this site via buttons (they will write at the first page), so it's better if nobody will edit this page. Thank you, Luke081515 17:16, 25 August 2015 (UTC)
Protected. -- Magioladitis (talk) 10:06, 26 August 2015 (UTC)

{{OperatorAssistanceNeeded|D}} @Luke081515: What's the status of this? — Earwig talk 20:39, 20 September 2015 (UTC)

Sorry, I'm very busy at the moment. I guess that I can start next Sutaruday (not this week, but the week after that, so the only thing to do is, that we got users at this 7 days, who use the bot, I don't know, there here (enwiki) is a good place, to talk about that, but I will prepare the last things to next week saturday, I hope this is ok. Greetings, Luke081515 09:38, 21 September 2015 (UTC)
Ok, the bot is now running for the next 7 days, I will stop it, after these days. If I forget it, please just press the stop button (at the userpage of the bot). The only thing that I need now, are people, who want to move a page. Greetings, Luke081515 18:33, 3 October 2015 (UTC)
@Luke081515: Don't worry about the trial length; let's just make sure it's long enough to guarantee that people use the bot and it works correctly. How does the German bot "advertise" itself so users know it exists? I was considering that we could mention it when users go to Special:MovePage, but I don't know if that's a good idea. — Earwig talk 15:36, 6 October 2015 (UTC)
At the german wiki there was a big controversal discussion about that bot, so there are people which know it. At Special:MovePage could be a good idea, but I guess it's better, if the user can only see this, if he tries to move a page from his userspace. Greetings, Luke081515 20:52, 6 October 2015 (UTC)

edit WP:BRFA/APersonBot_3

APersonBot 3

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

Time filed: 03:30, Wednesday, August 12, 2015 (UTC)

Automatic, Supervised, or Manual: Supervised

Programming language(s): Python

Source code available:

Function overview: Fixes an error with the duplication of {{Wikipedia:Teahouse/AfC Invitation}} on user talk pages.

Links to relevant discussions (where appropriate): WT:AFCH#Teahouse invite (permalink)

Edit period(s): One time run

Estimated number of pages affected: On the order of 10,000

Exclusion compliant (Yes/No): No

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

Function details: As seen in the discussion, I accidentally introduced an error in the code of the invitation template that makes it possible for multiple notices to end up on the same user talk page. This bot task will remove duplicate occurrences of the template while adding the correct category. It isn't exclusion compliant because we're fixing an error in the template code itself anyway. (Although I can make it exclusion compliant with no trouble.)


Approved for trial (100 edits). -- Magioladitis (talk) 17:56, 14 August 2015 (UTC)

@APerson: Status of this? — Earwig talk 05:27, 11 September 2015 (UTC)
The Earwig, the main issue I'm having is finding pages to edit. At the moment, I'm snarfing through all user talk pages, which I know is quite inefficient. Oddly enough, using search results doesn't work for me. I'm continuing to improve how the bot finds pages, as that's the main thing holding up the trial. APerson (talk!) 12:01, 11 September 2015 (UTC)

Bots that have completed the trial period

edit WP:BRFA/AvicBot_12

AvicBot 12

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

Time filed: 08:54, Wednesday, October 7, 2015 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): AWB

Source code available: Standard AWB

Function overview: Maintaining Category:User talk pages with conflict of interest notices. Removing category after a month 6 months.

Links to relevant discussions (where appropriate): Wikipedia_talk:Template_messages/User_talk_namespace#COI_category_maintenance.3F, with notices posted at Category talk:User talk pages with conflict of interest notices and Template talk:Uw-coi-username.

Edit period(s): Weekly.

Estimated number of pages affected: Initially ~ 41k? I'll space these out and monitor the jobs for any errors that might arise. After that, it'll depend on the number of COI warnings issued.

Exclusion compliant (Yes/No): Yes

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

Function details: AvicBot will maintain a list of user talk pages in this category. After a months' time, it will remove the tracking category from the user talk page. This will help to remove 'stale' reports and keep the category up to date and useful.


I don't know. A little disappointed to see no comments from anyone else even after three talk page posts and three weeks of waiting. I personally find a month to be too soon for removal, especially for accounts. I would definitely agree with one year as an upper bound on the time limit, but I'm thinking somewhere between three and six months if the template is not explicitly removed by another user or the user is blocked. (On that second point, it looks like Wikipedia:Bots/Requests for approval/KingpinBot 4 isn't running anymore, which might be useful here. Want to take it over as well? Shouldn't be too bad.) I'm curious to see how many of these 42,000+ warnings are older than a year, to get a sense of what we're dealing with. — Earwig talk 18:46, 7 October 2015 (UTC)

Even 6 months would be much better than the de facto "indefinitely" that currently seems to be the case. An SQL query could probably show which pages haven't been updated in 6 months+. I've amended the request above. As for picking up KingpinBot 4, I'll add it, sure. It'll be a nice compliment to AvicBot 6. Avicennasis @ 00:20, 25 Tishrei 5776 / 00:20, 8 October 2015 (UTC)
I collected the following data:
  • Total pages: 42,102
  • Older than 3 months: 37,066
  • Older than 6 months: 35,285
  • Older than 1 year: 32,643
  • Older than 2 years: 27,467
Interpret as you wish. Six months sounds like a good starting point. I'm not sure why User:KingpinBot/UWCOIreport says there were 6,215 just this past March, though. At any rate: Approved for trial (50 edits). — Earwig talk 03:29, 8 October 2015 (UTC)
Trial complete. Test run is here. Avicennasis @ 19:37, 25 Tishrei 5776 / 19:37, 8 October 2015 (UTC)



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

Time filed: 04:12, Saturday, September 26, 2015 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): AWB

Source code available: AWB

Function overview: Substitute from sandbox for {{Infobox China station}} and {{Infobox Japan station}} as per TfDs.

Links to relevant discussions (where appropriate):

Edit period(s): One time run

Estimated number of pages affected: 1,722 + 5,474 = 7,196

Exclusion compliant (Yes/No): Yes, per AWB default

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

Function details: This task will substitute from the sandbox of both templates to complete the merge into {{Infobox station}}. You can find the sandbox versions at {{Infobox China station/sandbox}} and {{Infobox Japan station/sandbox}}. Testcases are at Template:Infobox China station/testcases and Template:Infobox Japan station/testcases. The sandbox versions (which were created by another editor) appear to work fine, and the task itself is technically trivial.


I promoted the China sandbox to live before noticing this BRFA. It's working cleanly on the 25 I substed. Should be no issues. Alakzi did a good job on the rewrite. Bazj (talk) 13:25, 26 September 2015 (UTC)

Approved for trial (50 edits). — Earwig talk 05:16, 27 September 2015 (UTC)

@The Earwig: Is there any particular way you want me to divide up this trial? Since it involves substituting two distinct infoboxes, I imagine there should be edits for both. I can just split it 25/25, or if you prefer to see 50 edits of each, I can do that too. ~ RobTalk 19:56, 27 September 2015 (UTC)
@BU Rob13: Hmm, good point. Let's do 50 each. — Earwig talk 21:01, 27 September 2015 (UTC)

Trial complete. Overall went well, but a few notes:

  • The sandbox versions as they stand add a lot of empty parameters. I consider this to be a positive thing, personally. The Japan/China station infoboxes have evolved over time and have not always had functionality to include many of these parameters. I do not believe alt names were an option under these templates, for instance. By adding in the empty parameters, it encourages editors to fill in relevant information that isn't currently present. I can edit the sandbox versions to take out empty parameters if you'd like, but I think that's a net negative considering we lose nothing but a few bytes of storage space by keeping them in.
  • {{Infobox China station}} had in-template categorization by administrative district, which appears to violate WP:TEMPLATECAT. Alakzi's solution when creating the sandbox version was apparently to have the previously automatic categories be inserted after the new infobox. This violates WP:ORDER. The order issue can't be fixed by genfixes, because AWB doesn't receive the output of the substitution before running the genfixes. It's possible to handle that part with AWB instead and then enable genfixes to fix the order issue. I'll look into that later today or tomorrow, as time permits.
  • When this bot task is approved, either template protection or full protection should be placed on both sandboxes. Any vandalism that occurred in the middle of the bot run would be automatically substituted onto potentially thousands of articles, which is a huge risk that doesn't have a very easy fix (mass rollback, I guess). Please don't place that protection yet, because I don't have the template editor permission and I'll need to remove a few lines if the categorization is handled by AWB instead of the sandbox version. ~ RobTalk 22:25, 27 September 2015 (UTC)
    • I've written regex to handle categorization in AWB and tested it. It works as expected. It was needed in the China station template, where Alakzi had created a piecemeal solution, but also in the Japan station template, where the automatic categorization was missed. Let me know if you want an extended trial on this; it probably wouldn't hurt. As a side note, both sandboxes are ready for template or full protection now. ~ RobTalk 02:01, 28 September 2015 (UTC)
Some things I noticed (so far):
  1. Weird category placement — A few of these had that dangling category (e.g. Category:Railway stations in Shanghai). This then encourages a followup bot edit, which is less ideal. Is that what you're saying you've already addressed?
  2. Template-merge formatting — Somewhat less of a bot issue and more of a template issue (possibly), but already a few editors have added {{Nobold}} to presumably make things easier to read. It might be an idea, if this is a reasonable problem with merging the two templates, to either account for this in the template or potentially just use it pre-emptively while merging. I don't truly know if this applies (as I'm not a fluent speaker or reader of either Japanese or Mandarin), but examining the before-and-after versions does lead me to see why the bolded headers might be problematic when it comes to reading these languages (e.g., pre-merge version vs post-merge version of the subtitle, whereby the post-merge clearly looks more difficult to read, at least in my browser on my platform).
--slakrtalk / 00:59, 30 September 2015 (UTC)
  1. The categories are already fixed, yes. Basically, the problem was that the templates used to automatically categorize articles, which is against guidelines. The editor who created the wrapper that I'm substituting handled these in a way that caused the weird category placement. I've taken that part of his code out and replaced it with additional find and replace rules in AWB which will handle this better. General fixes will need to be turned on for my fix, by the way.
  2. I'll discuss this with WikiProject Japan. The easiest fix, in my opinion, is to make use of the {{Nobold}} template within templates such as {{Nihongo}}, which should contain all instances of Japanese text. I can't imagine any circumstance where bolded Japanese text would be desirable, but maybe they'll have a different take on this. ~ RobTalk 01:29, 30 September 2015 (UTC)
Link to the WikiProject Japan discussion is here. I've also alerted the accessibility WikiProject, as this concerns them. I don't believe bolded Japanese text can be considered to be accessible to those with visual impairments, which would certainly violate the spirit of WP:ACCESS and the word of the WMF's non-discrimination policy. ~ RobTalk 01:42, 30 September 2015 (UTC)
  • The replacement template has a lot of differences from the original (at least for the Japanese ones that I looked at), some subtle and some more glaring. In Hakata Station, for example, the image size gets mucked up and we lose the Station/駅 text. The layout is also slightly different – I guess we're going with the {{Infobox station}} standardized form, but honestly I prefer {{Infobox Japan station}}.
  • In the few examples I looked at, the empty parameters didn't concern me. Will need to look at more, but this isn't like the baseball player task where a lot of the added parameters would never apply, so I don't think we need to worry about that too much here. — Earwig talk 06:26, 30 September 2015 (UTC)
  • @The Earwig: I've fixed that issue with the station. This task is a bit tricky for me because I'm inheriting the wrapper from an indefinitely blocked user, so I'm unable to consult them in how they put it together. In this case, it appears they left out if statements that are present in the original template. I've re-added them. If Station (or the Japanese character for it) appears in Infobox Japan station, it will now also appear in Infobox station. The merge discussion did not address stylistic uniformity within this template, and that can be achieved at a later date if anyone cares enough to get consensus on it. I doubt anyone will. ~ RobTalk 08:34, 30 September 2015 (UTC)
  • @BU Rob13 and The Earwig: A couple of things about {{Infobox Japan station}}:–
    • Alakzi removed the image size parameter, probably without taking into account the portrait images used in the infobox (landscape is near-universally used in {{Infobox station}}); this is because the parameter can only pixels for size, whereas images with size of a multiple of upright (which evidently he prefers) scale according to user preferences.
    • I removed "駅" and "Station" because typically in {{Infobox station}} and the other remaining railway station infoboxes, with the exception of Singapore only the station name (e.g. "Great Victoria Street" (Belfast), "Charles de Gaulle – Étoile" (Paris), "Corrientes" (Buenos Aires), "München Ost" (Munich), "Pacific Central" (Vancouver), "Central" (Sydney), "Shanghai Hongqiao" (Shanghai), "34th Street – Hudson Yards" (New York), "King's Cross" (London), "Seoul" (Seoul)) is shown in the header. I personally think it should be removed for consistency, but I don't particularly mind if it's kept.
  • Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 14:22, 30 September 2015 (UTC)
  • Reviewing more edits, it looks pretty good. The Chinese infobox seems to have been modified to transclude the main template already, so it's hard to tell if there are meaningful visual differences there, but I don't see hints of anything too problematic. Did you manage to fix the nobold issue with the Japanese infoboxes? I see the Chinese ones have the same issue, in case that wasn't noticed (1). Jc86035 presents a good case for leaving "Station" out, but I'm not entirely sure, since it has been the standard in this group of articles until now. (Singapore was brought up as an exception—is that for a particular reason for that or could we consider China/Japan exceptions too?) Perhaps we should consult the relevant WikiProject(s). That just leaves the image size bug, which I admit I don't understand fully. Any other concerns? — Earwig talk 07:36, 2 October 2015 (UTC)
  • The image size isn't a bug; there was previous consensus that {{Infobox station}} should have a larger default image size than is typical. We can debate whether that consensus was a good idea (it wasn't), but until a discussion about that is started, we should stick with the default for the merge target. To do otherwise would be to ignore the consensus there. I've corrected the nobold issue in the wrappers. The discussion taking place at the Japanese WikiProject shows no opposition to making these non-bold, and a more general solution (using nobold as the default for templates like {{Nihongo}}) does not affect this bot task. ~ RobTalk 07:49, 2 October 2015 (UTC)
  • Noted about image size; the reason I brought it up is because we are dropping that parameter regardless of its value (although the station infobox doesn't even have an image size parameter, so I guess we have no choice there). Maybe I misunderstood, but doesn't {{Nihongo}} already apply the no-bold effect? (That's what I gather from reading its source.) — Earwig talk 14:28, 2 October 2015 (UTC)
  • @BU Rob13: Please, please do not add templates like {{nobold}} through the wrappers which are going to be substituted; add them in {{Infobox station}} as something like {{#switch:{{{native_name_lang}}}|zh-Hans={{nobold|{{{native_name}}}}}|ja={{nihongo|{{{native_name}}}}}|{{{native_name}}}}}. This makes it easier to remove if for some reason we decide we don't want it anymore. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 10:39, 3 October 2015 (UTC)
  • Jc86035, if you'd like to code it that way, go ahead, and we can place this on hold until you make the necessary edits. My activity level has dropped off a cliff the past week, and I don't have time to do it myself. I think it's a non-issue since the WikiProject Japan discussion appears to conclude that bold in these subheadings is not desirable for the Japanese characters, and the Chinese characters are very similar. ~ RobTalk 15:13, 3 October 2015 (UTC)
  • I agree that we should keep the nobold/nihongo invocations out of the individual transclusions, but is there really no more general way of doing this than special cases for each language code? — Earwig talk 19:34, 3 October 2015 (UTC)
  • A yes/no switch |nativename_nobold= makes the most sense. Just don't have time to add it myself at the moment. ~ RobTalk 07:02, 4 October 2015 (UTC)
  • @The Earwig and BU Rob13: Alternatively we could have a style template for each infobox (like {{Amtrak style}} or {{TTC style}}), since {{Infobox station}} already has a parameter (|style=style template; e.g. "Amtrak") for calling these like {{S-line}} does, and then change {{Infobox station}} so that it calls something from the switch parser function of the style template:
| 2 = {{#if:{{{native_name|}}}|<span class="nickname {{#if:{{{style|}}}|{{{{{style}}} style|native_name_class|{{{style2|}}}}}}}" {{#if:{{{native_name_lang|}}}|lang="{{{native_name_lang}}}" xml:lang="{{{native_name_lang}}}"}} style="{{#if:{{{style|}}}|{{{{{style}}} style|native_name_format|{{{style2|}}}}}}};">{{{native_name}}}</span>}}
(Additions to actual template shown in bold.) Then {{Infobox station}} will call native_name_format from the style template. The addition to the class declaration makes {{Nihongo2}} unnecessary, since all Nihongo2 does is add the class declaration class="t_nihongo_kanji" and the ja language code. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 14:46, 4 October 2015 (UTC)
@Jc86035: That sounds like a good idea to me. Are you or BU Rob13 willing to implement it? — Earwig talk 03:39, 8 October 2015 (UTC)


  • Is it not more complicated to go that route than to just put in a nobold switch that works for all languages and all styles? Nihongo/nihongo2 are used outside of this template, so doing away with them here isn't really simplifying the template space. I don't really care what the final implementation looks like, to be honest, but this seems particularly messy to me. My time has disappeared for the coming weeks, as I'm trying to rush to finish my thesis around half a year ahead of schedule so I can send it off to potential grad schools as part of my application package, so I unfortunately couldn't code anything much more difficult than a nobold switch. ~ RobTalk 05:10, 8 October 2015 (UTC)
    Possibly. You know, I think you might be right; it seems like the style templates are used for a different purpose than this and the |native_name_lang= is most closely related to what we're trying to do here. I'll let the final implementer do what they think is best. Don't worry about your free time; we'll get this stuff sorted out and you can run the bot when you are able. Hope the thesis goes well. — Earwig talk 05:29, 8 October 2015 (UTC)

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 anytime. 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.