On de.wikipedia, we were discussing the topic of blocked titles, meaning topics that otherwise would go through a cycle of deletion and re-creation by trolls/vandals/fanatics. Currently, this is done by putting a template on it and protecting the page.
This is rather ugly and has certain side effects, e.g., filling up the "short pages" list.
Many would prefer a clean technical soution. The simple way would be to add a new table to the database, listing the topics blocked from recreation. This table would only be accessed * when an admin clicks on an "(un)block this article" link on a non-existing page (write access) * when someone tries to edit a non-existing article (read access)
As table fields, I suggest title, blocking user id, and maybe date. Unblocking a topic would, im my model, equal the removal of the entry from the table; I don't see the need to keep a history on such a rarely used and easy-to-counteract-by-another-admin function. Perhaps a new log would be in order, though.
Magnus
On 8/4/06, Magnus Manske magnus.manske@web.de wrote:
On de.wikipedia, we were discussing the topic of blocked titles, meaning topics that otherwise would go through a cycle of deletion and re-creation by trolls/vandals/fanatics. Currently, this is done by putting a template on it and protecting the page.
This has the advantage of allowing the user to see a human-written explanation of why that particular topic is banned. It would be good if any technical solution can maintain that property.
Steve
Steve Bennett schrieb:
On 8/4/06, Magnus Manske magnus.manske@web.de wrote:
Currently, this is done by putting a template on it and protecting the page.
This has the advantage of allowing the user to see a human-written explanation of why that particular topic is banned. It would be good if any technical solution can maintain that property.
No; at the moment the template just says that "this page has been deleted according to the (speedy) deletion guidelines for several times in the past. In order to prevent further attempts in creating this article, it has been blocked" or something like that (full text: [1]). This explanation may be an explanation for what has happened with this article and it may be human-written, but I don't think it will really help the user (or reader) who coincidentally comes about it. It would be good, if any technical solution for this problem gave the blocking administrator the possibility to enter a reason for the block and if this reason could be displayed directly on the page (i.e. instead of {{MediaWiki_Noarticletext_NS_{{NAMESPACE}}}} on non-existing pages some kind of {{MediaWiki_Noarticletext_blocked}} for blocked non-existing pages where the comment can be seen - dunno, but it surely will be too complicated/expensive regarding ressources ;-)
rdb
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Manske schrieb:
On de.wikipedia, we were discussing the topic of blocked titles, meaning topics that otherwise would go through a cycle of deletion and re-creation by trolls/vandals/fanatics. Currently, this is done by putting a template on it and protecting the page.
This is rather ugly and has certain side effects, e.g., filling up the "short pages" list.
Maybe an option to filter all blocked pages from the shortpages-list? In this case the software has not to look into the source so I assume a filter is not so expensive?
Raymond.
On 8/4/06, Magnus Manske magnus.manske@web.de wrote:
Many would prefer a clean technical soution. The simple way would be to add a new table to the database, listing the topics blocked from recreation.
Why not extend the protection mechanism to be applicable to deleted pages? That would be the most intuitive way, to my mind. See also http://bugs.wikimedia.org/show_bug.cgi?id=2919.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Simetrical schrieb:
Why not extend the protection mechanism to be applicable to deleted pages? That would be the most intuitive way, to my mind. See also http://bugs.wikimedia.org/show_bug.cgi?id=2919.
Yes, think so too. I have voted for the bug now :-)
Raymond.
wikitech-l@lists.wikimedia.org