After a discussion on wikitech-l titled "bot approval request", we decided that perhaps it would be better if my bot were implemented on the server side, so that everyone could use it, and so that it would be relatively efficient. I offered to do the coding, on the condition that someone will block me if I try to make any ordinary edits -- I don't want Wikipedia totally taking over my life :)

Anyway, here's my proposal. I originally posted it on wikitech-l, but it drew no responses. What I'm suggesting is a significant extension to Special:Movepage capabilities.

------------------------------------------------

What we want to be able to do is:

1) Change a set of links pointing to a redirect, so that they're pointing to the real article 2) Change a set of links pointing to an incorrectly named image, to a new, correctly named image.

The second one was suggested by Tarquin on [[User talk:Timbot]]. Now the problem with this feature is that it has the potential to create excessive server load, especially if an edit war breaks out utilising it. My scheme below is intended to do the following things:

* Make it appear weighty and time-consuming, so that users won't do it frivolously. * Make the smallest impact on the server possible while not wasting people's time. * Make edit wars utilising the feature take up a minimum of server load, and to favour a conservative (changeless) outcome.

As a tentative short name, I suggest the "backlink redirect". It's a mouthful, it doesn't make much sense, but it's better than anything else I've come up with.

Here's my current vision for how it will operate:

On Special:Movepage, you now get an OPTION group looking like this:

(*) Move page only ( ) Make the page a redirect, and update all links so that they point to the new article ( ) Move page and update links

Any logged in user has access to these options. If the user selects the second or third option, a new thread is created on the server, set to low priority -- low enough that it might take an hour or more during peak times to fix a large set of articles. This new thread does the following:

* Updates Wikipedia:BacklinkRedirects (or related DB table) to indicate that a backlink redirect has started. This appears on RC. * Starts updating the links, one at a time. Changes do not appear on RC. * After it finishes updating each article, it checks to see if someone has clicked on the "cancel" link in Wikipedia:BacklinkRedirects. If so, it reverts its changes and stops, indicating this on RC and Wikipedia:BacklinkRedirects. * Once it has finished, it updates the table related to Wikipedia:BacklinkRedirects to indicate that the job is now over. This does not appear on RC.

The job stays there on the lower half of the page for all time, with some method of accessing multiple pages of them. Anyone can revert such completed jobs. Reversions of complete jobs are handled at the usual thread priority (arguable, I could be wrong). Articles which have changed since the initial update are, of course, not reverted.

As you can see, with this scheme, even an edit war over a huge set of links will create little server load in peak times, as long as both sides of the fray watch Wikipedia:BacklinkRedirects vigilantly.

-- Tim Starling.

_________________________________________________________________ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp