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