Last modified: 2012-07-26 20:49:39 UTC
==Background and Rationale==
:''You can safely skip this and not miss much.''
As things stand right now, there are only two messages for the block tab,
default of which are "Protect" and "Unprotect." With the advent of
semiprotection and page move protection, this simple toggle system is not only
insufficient, it can be downright misleading. Pagemove protected pages are not
"protected" in any conventional sense (most users will never notice), yet they
cause the tab to show up as "Unprotected."
Discussion on [[Wikipedia:Village pump (proposals)#Change "Unprotect" to "Change
protection"]] appears to have resulted in this recommendation that:
Protect -> Unprotected
Unprotect -> Protected
The second change deserves special note in this case: the old Unprotect can be
just plain old wrong in certain circumstances. Suppose a move is page-move
blocked, but has recieved a spate of anonymous vandalism. It would have a tab
saying "Unprotect," but the admin would actually be clicking the tab to
*increase* protection. Saying that the page is simply "protected" removes this
But, as you may have already noticed, it does not prevent the core problem:
these tabs offer little/no information on exactly *what* is blocked. Thus the
There are several possible ways to make the current scheme more descriptive.
1. For each aspect that can be blocked (as of now, page move and regular
editing), create a new tab. The tabs have three values, "Unprotected"
"Semiprotected" and "Protected". This can be extended as far as necessary, but
can get unwieldly beyond two tabs. However, I can't think of an elegant way to
cycle all nine possible combinations in one tab
2. Simply name the tab a generic "protection", and offer the information in a
seperate area, perhaps in the same area you see the redirect notice (which is
quite unconspicuous). This would eliminate the need for locked page templates:
the software would tell the user so. I prefer this solution.
It's a feature request, so if you think it's a good idea, go and implement it.
Otherwise, no pressure. :-D
*** Bug 6176 has been marked as a duplicate of this bug. ***
Mostly? done in r90833.