Jump to content

Template talk:Unblock

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:Unblock/doc)

Instructions needed

[edit]

Apparently there are unwritten rules for usage of this. They should be written down. (SEWilco 17:47, 30 December 2006 (UTC))[reply]

Instructions are needed for this template, either on the template page or in a Usage section at the top of this Talk page. I discovered this undocumented template, tried it on User:RefBot because the evasion justification is false; when the block was not reviewed I tried again to get a review and {{Unblockabuse}} got slapped on with rules which are not in this template. How many other undocumented traps exist? (SEWilco 04:04, 29 January 2007 (UTC))[reply]
That appears to reflect on the admin in question, more than anything else. I generally do prefer to see warnings before page protection. Either way, the note you added to the template is inappropriate; I suggest you take these matters up with the protecting admin, or via WP:RFC. – Luna Santin (talk) 06:48, 12 February 2007 (UTC)[reply]
It is inappropriate to warn that there are undocumented rules for using a template? Most templates have Usage instructions or documentation on the template page. Usage of this seems obvious from the template message, but isn't. A recent edit message on the template confirms that people don't know what rules I'm referring to. Those rules should be documented. (SEWilco 07:05, 12 February 2007 (UTC))[reply]
The warning you added to the template was grossly inappropriate, yes -- see WP:POINT. All else aside, the circumstances where protection can be used to stop unblock abuse are documented at Wikipedia:Protection policy. I do agree, however, that users should be warned prior to the protection of their talk pages. Again, please take this incident up with the blocking administrator, or via RfC. – Luna Santin (talk) 07:16, 12 February 2007 (UTC)[reply]
Wikipedia:Protection policy mentions this template but has no usage instructions, and doesn't even describe rules for protection based on usage of this template. What rules apply to this template? They should all be documented. (SEWilco 07:32, 12 February 2007 (UTC))[reply]
The warning was to prevent others from stumbling into its undocumented traps. If there are few who use the template, then the warning is not disruptive. If there are many who use the template, there are many who are at risk from this template with no usage instructions. (SEWilco 07:38, 12 February 2007 (UTC))[reply]
I've added a note to the template page, then. Please note also that MediaWiki:Blockedtext has a similar mention. Elaborating on the "rules" of the template is rather difficult, because for the most part, it's up to admin discretion and community consensus. Controversial actions are and should be discussed, frequently at WP:AN or WP:AN/I. A hard rule set would be needless rules creep that would only hamper the process, I think. – Luna Santin (talk) 07:47, 12 February 2007 (UTC)[reply]
Documentation of the existing rules is not rules creep, it just helps people to properly use templates which they discover. The Arbitrators have shown they are arbitrary, and why encourage their interference by scattering undocumented traps? (SEWilco 19:33, 12 February 2007 (UTC))[reply]
Elaborating on the "rules" of the template is rather difficult, because for the most part, it's up to admin discretion and community consensus. Controversial actions are and should be discussed, frequently at WP:AN or WP:AN/I. A hard rule set would be needless rules creep that would only hamper the process, I think. You've had a single negative experience, please take it up via more appropriate channels. – Luna Santin (talk) 21:09, 12 February 2007 (UTC)[reply]
I'm discussing this template; my experience is due to the lack of documentation and that lack of documentation is the issue here, not my experience with it not existing. Template:unblockabuse states the rule "using the {{unblock}} template to relay abusive messages to administrators or reposting it after having been denied an unblock by more than one admin." Why should users of this template not be warned of the existing rules? (SEWilco 21:26, 12 February 2007 (UTC))[reply]
You may notice that there's no "guideline" tag on {{unblockabuse}} -- it's not a policy or a guideline, or even the most common practice. The key issue here is not template documentation, but admin discretion and the protection policy. – Luna Santin (talk) 21:31, 12 February 2007 (UTC)[reply]
But the rule in {{unblockabuse}} is being used. The rules should be documented. Rule creep is the creation of new rules, not listing those which exist. (SEWilco 05:06, 13 February 2007 (UTC))[reply]
Was used by one admin in one situation, so obviously it's an all-encompassing policy? Right. I'll say it more clearly: there are very few rules, if any, to document, because it's largely left to admin discretion and community consensus -- that could be changed, but I'd want to see some community consensus before making that change. Controversial actions can and should be discussed in appropriate venues. At this point, I see no consensus change the template, and I should hope it's clear that we disagree with each other rather strongly. If you'd like to bring in some fresh voices, feel free to make a post to WP:3O, WP:VP, WP:AN, WP:CN, or wherever you like, but other than that, we seem to just be going in circles with no end in sight. – Luna Santin (talk) 05:58, 13 February 2007 (UTC)[reply]
'What links here' for {{unblockabuse}} shows over 200 pages. Shouldn't the reasons given in that template be documented in the template which is likely to trigger that response? (SEWilco 02:57, 14 February 2007 (UTC))[reply]

Unblocking others

[edit]

Can you use this on behalf of other users? —The preceding unsigned comment was added by RedsBot 2 (talkcontribs).

I would say yes, but be careful to make it clear that you're doing so. On the other hand, you'd probably be better off posting your thoughts (and request) at the admin noticeboard (or the incidents subpage), as that'll probably get wider and quicker attention. If you prefer email, try the unblock-en-l mailing list. I'd personally probably go with AN/I in that situation, but it's your call. – Luna Santin (talk) 01:21, 13 February 2007 (UTC)[reply]
There's nothing in the template that says so, but I have never agreed to unblock any user based on another user's request via this template, and I doubt I ever will. Once a block is issued, it's between the blocked user and WP admins to work out the situation. The decision of the blocking admin can certainly be addressed, either via that admin's talk page, or if broader input is needed, via WP:AN or WP:ANI. Mangojuicetalk 14:41, 25 July 2007 (UTC)[reply]

"Admin use only" part

[edit]

Does anyone actually use this text? I never do: I just insert "reviewed" into the existing request and add my reason, rather than cut & paste, and I don't bother with {{Request accepted}}, I just leave a message in such circumstances, and <nowiki> the request. Most times it doesn't get in my way, but sometimes someone has a very long unblock reason and then this part is extremely burdensome. Does anyone mind if I get rid of the copy-paste text? Mangojuicetalk 14:44, 25 July 2007 (UTC)[reply]

I almost exclusively use the copy/paste text at the bottom of the unblock request when reviewing. I actually find it easier when reviewing multiple requests, and would not like to see it disappear. - auburnpilot talk 01:56, 8 August 2007 (UTC)[reply]
Your prerogative. Would you object to it being hidden behind a drop box? Mangojuicetalk 04:15, 20 August 2007 (UTC)[reply]
Why not, sounds like a good idea. I'm using the text also. -- lucasbfr talk 18:48, 29 August 2007 (UTC)[reply]

Please display kindness

[edit]

I've discovered this page. I see some people begging to be unblocked. Please consider if you deny the unblocking that you make a notation but leave it for another adminstrator to review it. After all, if you deny it, that's like killing a person.

Please note that I don't condone behavior leading to a block but there seems to be a wide variation of blocking for similar behavior. Some prefer the death penalty. Others prefer 24 hours. Still others prefer a very odd 31 hours.

I experienced a bit a kindness by an administrator, Reedy Boy, about a month ago. His kindness really encouraged me to edit more, correct errors and add references, etc. In fact, I'm going to look for a barnstar to give him. Archtrain 22:14, 17 August 2007 (UTC)[reply]

[edit]

I just added a link to http://jodies.de/ipcalc today. Not all administrators are aware of how to calculate if an IP is within a range. Hope this helps someone out. ^demon[omg plz] 18:56, 2 October 2007 (UTC)[reply]

Updating

[edit]

This template really needs updating because inclusion of wikilinks and external links in a user's unblock reason request breaks it. Example:
{{unblock|Putting [[wikilinks]] here or [http://externallinks.com] here breaks this template.}}
So yes, it needs some work. - ALLSTAR echo 21:34, 6 February 2008 (UTC)[reply]

User friendly

[edit]

Does anyone else think templates like this or ((help)) are a bit complicated for new users to correctly use? Would an idea be to set it up as a link that says "Click here to request ot be unblocked" and that link would take them to a form field where they could type their reason and click submit. As it is now, a user must know how to add a template to the page and add the | to separate their reason. MBisanz talk 09:20, 10 February 2008 (UTC)[reply]

I agree. This really should be simpler. I suppose we'd need help from the dev's for this. - Rjd0060 (talk) 00:54, 11 February 2008 (UTC)[reply]

RDNS link.

[edit]

Hey, I noticed today, that the RDNS link in the unblock template no longer works, unless you pay for it. Is there a *free* alternative out there, that anyone knows of? (I just use host, but, I don't think windows has that). Perhaps, it's time that we re-evaluated using dnsstuff.com links in our templates, as they're pages seem to be getting spammier over time, and, who knows what tool will wind up switched to 'pay only', as time goes on. It probably wouldn't be very hard at all to replicate the functionality of these tools, on the toolserver. SQLQuery me! 15:20, 3 March 2008 (UTC)[reply]

Overhaul needed

[edit]

This template is getting a little cumbersome, and I think it would be beneficial to overhaul it—perhaps trimming it down, and making it more "user friendly". Does anybody have any proposals? AGK § 18:16, 23 March 2008 (UTC)[reply]

My 2 biggest gripes are.
  • It doesn't have the unblock email on the template or within 1 link to it.
  • It requires the user to know how to set a variable. It should be like AfD setup, where you click a link in the template and get a preloaded page saying (enter reason HERE). MBisanz talk 21:03, 23 March 2008 (UTC)[reply]

Notice to Admins and why Admins only?

[edit]

Shouldn't we have a notice like {{unblock-un}} has: "Administrators should not unblock without attempting to discuss with the blocking administrator (see the blocking policy)" on this template to remind admins that they generally need to discuss this with the admin who blocked? All admins were new admins once upon a time. :-)

Additionally, why do we say that the review section is for Administrator use only? WP:APPEAL seems to be a bit undecided on what word to use but often refers to editors reviewing the block and is clear that even if the reviewer happens to be an admin he or she probably won't remove the block but will still discuss it with the blocking admin. See especially Wikipedia:Appealing_a_block#What_happens_next. Why shouldn't experienced editors, the same sorts of editors who close non-delete XfD's, decline or discuss in the same way? Very few unblock requests should be granted without discussion with the blocking admin anyway. This Admins only language does not appear to be supported by policy.

Finally, I agree with the comments above that this is far too complicated for new users.--Doug.(talk contribs) 03:24, 17 April 2008 (UTC)[reply]

[edit]

Could some administrator include a link to Swedish Wikipedia, using [sv:Mall:Avblockering] . Best regards Ulner (talk) 08:01, 20 April 2008 (UTC)[reply]

 Done. UltraExactZZ Claims ~ Evidence 20:23, 22 April 2008 (UTC)[reply]

Editprotected

[edit]

{{editprotected}} What's with the "you may not unblock your own account"? Everyone knows that only admins can block/unblock, and we rarely see non-humorous blocks on admins.

 Not done I'm going to decline your request, because that sentence is in the "Administrators only" section reminding them that they are not allowed to unblock themselves; it's not meant for general readers. I agree with the previous sections on this talk page that this template needs a redesign, and this request is something to keep in mind for when that happens. --CapitalR (talk) 13:43, 7 May 2008 (UTC)[reply]

I'm the admin who put that in there. You'd be surprised at how many people try copy and paste {{Request accepted}} into their own talk thinking that it'll automatically unblock them. I'm hoping that there is something that can be written there to reduce that. --  Netsnipe  ►  06:52, 9 June 2009 (UTC)[reply]

Removing a request

[edit]

The template presently adds:

Do not remove this unblock request while you are blocked.

I have not found a guideline that says this. IMHO the request and the block notice should never be separated. This implies that if the block notice is removed or archived during the block then the request should go with it, whereas if the block notice is kept after the block expires then the request should stay too. Also, an unblock request should of course remain until it has been resolved or withdrawn. So, the text should rather read something like:

Do not disattach this unblock request from the block notice. Guido den Broeder (talk) 10:02, 6 June 2008 (UTC)[reply]

As an admin frequently patrolling CAT:RFU, I've written a guide to appealing blocks which I think reflects our current practice. Are there any objections to adding something like the following to the "Notes" section or to some other space within the template?

Please read our guide to appealing blocks to make sure that your unblock request will help your case. You may change your request at any time.

Best,  Sandstein  21:59, 11 July 2008 (UTC)[reply]

Done, since there have been no objections.  Sandstein  19:04, 18 July 2008 (UTC)[reply]

Iwiki

[edit]

Add please [[ro:Format:Deblocare]] in the interwiki links list. Thank you!  Daniel  Message  14:58, 20 September 2008 (UTC)[reply]

 Done. UltraExactZZ Claims ~ Evidence 19:02, 23 September 2008 (UTC)[reply]

Checkuser Attention

[edit]

I frequently see unblock requests from editors (or socks) protesting their innocence, or claiming that the checkuser results are wrong, or offering some esotetic explaination as to why the checkuser would see that this account and 12 others were run by the same IP, and so on. I'm thinking that it might be worthwhile to add a parameter to this template that would flag an unblock request requiring a Checkuser's expertise. It might be something as simple as {{unblock|1=Your reason here|c}}. The "c" would add the request to Category:Requests for unblock requiring Checkuser attention, which could in turn be monitored. Am I overthinking this? UltraExactZZ Claims ~ Evidence 19:05, 23 September 2008 (UTC)[reply]

Template should work if accidentally put on user page

[edit]

{{editprotected}} This template currently tests to make sure it's on a user talk page, and only if so does it add the page to Category:Requests for unblock. This means that if a user accidentally puts the request for unblock on their user page instead of their talk page, the request will silently fail—admins will not be alerted to the request. This should be changed: either the template should work if placed on the user page, or the template should display a warning if placed in the wrong namespace. User:Citation bot has been blocked for several days due to this "bug" in the template.--Srleffler (talk) 23:44, 30 September 2008 (UTC)[reply]

 Done. The template will now add pages it is transcluded on to Category:Requests for unblock when placed on a userpage or a user talk page. J.delanoygabsadds 02:19, 1 October 2008 (UTC)[reply]

What is the point of this? If a user can only edit their own talk page while blocked, and not their userpage, how would this even occur? Cirt (talk) 07:36, 2 October 2008 (UTC)[reply]

There is one situation in which it may occur - I've seen the rare occasion where one user makes an unblock request on behalf of an other. I don't think, however, that it makes the requested edit above be necessary. עוד מישהו Od Mishehu 09:52, 2 October 2008 (UTC)[reply]
The caveat there is that the request could be posted by a third party on the user's userpage if the talk page is protected for some reason. If E-mail is disabled and the talk page is protected, this would actually be the only other way that a user could request unblocking, and even then would require an advocate to post the template. UltraExactZZ Claims ~ Evidence 13:16, 2 October 2008 (UTC)[reply]

Suggested addition:

[edit]

"If the block was on the basis of the use of the checkuser tool and the checkuser finding is disputed, this request should be brought to the attention of a checkuser rather than declined out of hand" - any objections? --Random832 (contribs) 20:37, 5 December 2008 (UTC)[reply]

Uhm. I thought that was common sense. Were there any incidents that led to you believing this addition is necessary? --PeaceNT (talk) 15:38, 9 December 2008 (UTC)[reply]

Wording change

[edit]

I've changed "can" to "may" in "If you accept the request (note that you can NOT unblock your own account), replace...", since it's technically possible to unblock oneself while blocked if one is an admin, but obviously it's not allowed. Nyttend (talk) 02:39, 24 June 2009 (UTC)[reply]

[edit]

Please change

 [http://wiki.riteme.site/w/index.php?title=Special%3AGlobalBlockList&ip={{PAGENAMEE}} global blocks]

to

 [{{fullurl:Special:GlobalBlockList|ip={{PAGENAMEE}}}} global blocks]

so that users of the secure server are not needlessly taken to the non-secure server and vice-versa. Thanks.—C45207 | Talk 05:25, 14 July 2009 (UTC)[reply]

 Done Thanks for spotting it. Plastikspork (talk) 05:45, 14 July 2009 (UTC)[reply]

Error

[edit]

{{editprotected}} It says "edit the text" but it should say "add text". Chevy Impala 2009 17:47, 30 July 2009 (UTC)[reply]

No, I think it is correct. There is some text after decline= already, which is {{subst:Decline reason here}}. Apologies if I haven't understood your request properly. — Martin (MSGJ · talk) 18:23, 30 July 2009 (UTC)[reply]

Unblock on hold

[edit]

May I ask why a block may be placed on hold only by an administrator? Sometimes a non-sysop may wish to delay an imminent rejection of an unblock request in order to comment, maybe a non-sysop version of unblock-on-hold could be added, or unblock-on-hold be modified to allow this? —what a crazy random happenstance 07:44, 6 January 2010 (UTC)[reply]

Jpgordon error

[edit]

{{editprotected}} Jpgordon, I think your <p> addition broke the template. Peoples' unblock requests are not showing up inside the template itself. mechamind90 18:22, 30 July 2010 (UTC)[reply]

Of the 8 current unblock requests, only two users are having issues, and their requests contain external links which are known to break some templates. At least that's what it looks like to me. Anyway, the template will work if 1= is added before the reason, i.e. {{unblock|1=Your reason here}}. —DoRD (talk) 01:10, 31 July 2010 (UTC)[reply]

instructions seem to be broken

[edit]

The instructions for accepting an unblock request seem to be broken. If they're not broken, what is the point of replacing the template with {{tlx|1=unblock|2=reason}}?? Kaldari (talk) 17:44, 3 August 2010 (UTC)[reply]

To keep a record of the successful unblock petition. –xenotalk 18:01, 3 August 2010 (UTC)[reply]
It seems to be a pretty weird way of keeping a record. Why not add an "accepted" parameter that marks the request as accepted and gets rid of all the admin instructions. Turning it into an unparsed template call is very unintuitive and makes it look like someone has done something wrong. Kaldari (talk) 22:33, 3 August 2010 (UTC)[reply]

Hiding

[edit]

Why aren't we hiding the "administrator" part of the unblock notice? Seems it would reduce a lot of the common occurrence of blocked editors attempting (generally out of ignorance, rather than bad behavior) to unblock (etc) themselves. Then we could also make the admin-only part uglier, like have a big noisy "OFFICIAL USE ONLY" section. --jpgordon::==( o ) 18:30, 22 August 2010 (UTC)[reply]

I don't know about adding OFFICIAL USE ONLY - I'd have to see what that looked like - but I think that hiding the instructions is a very good idea. —DoRD (talk) 19:15, 22 August 2010 (UTC)[reply]

Overhaul, comments welcome

[edit]

The ugliness of this template has bugged me for years, especially the layout. I have prepared an overhauled version in the sandbox. Any comments are welcome. EdokterTalk 16:57, 5 September 2010 (UTC)[reply]

Does look better. I wonder if there's a way to lose the "if your reason contains a URL with an = in it" language; perhaps use a named parameter instead, and just always have it say {{unblock|reason=your reason here}}. Would that be more confusing, I wonder, to the users who are baffled by the bad behavior that can occur in the absence of the totally opaque "1=" thing? Or less? Can the template macros detect when an equal sign is causing the bad behavior? --jpgordon::==( o ) 00:21, 7 September 2010 (UTC)[reply]
I think 'reason=' would be better. Templates cannot detect '='. EdokterTalk 03:05, 7 September 2010 (UTC)[reply]
Yeah -- I see that the behavior when the reason has an equal sign is the same as when there's no reason provided at all -- the lhs of the equal side is treated as a named argument, and as such the whole reason gets ignored. At the very least, there's no reason to say If your reason contains a URL with a "=" in it; more accurate might be If your reason contains an "=", e.g. in a URL or something like that. Regarding the parameter name, it's an interesting juggling acts. All the block templates talk say to use {{unblock | your reason here}}; I don't think expecting the prospective unblockee to say {{unblock | 1=your reason here}} is desirable, given the total obscurity of that 1= thing. However, it might be OK to expect them to say {{unblock | reason=your reason here}}; it's just enough less obscure. (I know this stuff is nitpicky, but, given my fondness for hanging around CAT:RFU, I see a lot of unblock requests...) --jpgordon::==( o ) 05:41, 7 September 2010 (UTC)[reply]
All the block templates...? There are more? EdokterTalk 17:12, 9 November 2010 (UTC)[reply]

I finished all messages ({{unblock}}, {{unblock on hold}}, {{unblock reviewed}} and {{request accepted}}); they now have a consistent look, but maybe too consistent? I need more eyes and comments. Have a look at the test cases page. EdokterTalk 20:44, 14 November 2010 (UTC)[reply]

Looks generally good to me. One thing I don't like, though, is the pink color background. Yes, it matches the you-are-now-blocked messages, but a different color makes it easier to distinguish from other block notices and I simply don't like staring at pink. Blue makes my eyes hurt less. Do you have any concerns to changing back the background colors? /ƒETCHCOMMS/ 23:28, 14 November 2010 (UTC)[reply]
It's not pink, it's salmon :) But anyway, personally I think the blue is overused, so any other color will do. EdokterTalk 00:14, 15 November 2010 (UTC)[reply]
I love salmon, but not the color of it :( Maybe grey or peach? /ƒETCHCOMMS/ 16:42, 15 November 2010 (UTC)[reply]
How about the current yellow? EdokterTalk 17:23, 15 November 2010 (UTC)[reply]
It's kinda...yellow. Not sure yellow-highliter color is the right shade for a request, though. But everything else looks good. --jpgordon::==( o ) 17:55, 15 November 2010 (UTC)[reply]
OK, I toned down on the yellow... back to 'salmon', but then halfway to white. EdokterTalk 18:13, 15 November 2010 (UTC)[reply]

Looks good. But shouldn't "a user may not in fact be blocked, or their block may be expired" be rephrased as "you may not in fact be blocked, or your block may be expired"? The rest of the paragraph also directly addresses the blocked user. Also, "Note that misuse of the unblock request procedure may result in the removal of your talk page editing privileges for the duration of your block" could perhaps be made to sound less bureaucratic: "If you make too many unconvincing or disruptive unblock requests, you may be prevented from editing this page as long as you are blocked."  Sandstein  18:07, 15 November 2010 (UTC)[reply]

I also added a "handled=1" example to the test page. Could that perhaps be made to look distinct from an unhandled request, such as e.g. by decoloring it and omitting the admin instructions?  Sandstein  18:12, 15 November 2010 (UTC)[reply]

Good idea, I'll have a look. EdokterTalk 18:14, 15 November 2010 (UTC)[reply]
I chopped of the bottom half, but I left the color. EdokterTalk 18:30, 15 November 2010 (UTC)[reply]
Looks also good. But on reflection, doesn't this approach make a separate "Request accepted" template superfluous? Perhaps if we used "unblock|unblock-reason=text" to result in output similar to your design for "Request accepted|1=reason", but retaining the unblock request text (if any)? We would get one box instead of two. The "Request accepted" template could then redirect to "unblock|unblock-reason=text".  Sandstein  18:50, 15 November 2010 (UTC)[reply]
{{Request accepted}} is an existing template and used a lot, and it is usually substed unlike the other boxes. However, I am going to test with {{unblock reviewed|1=reason|accept=reason}}, and we could indeed get rid of {Request accepted}, and even {unblock|handled=1}. EdokterTalk 13:44, 16 November 2010 (UTC)[reply]
I simplyfied it further and did away with {{Request accepted}}, as {{unblock reviewed/sandbox}} now has an accept= parameter. When the instructions are followed, there will be only one box during all stages of the unblock request. EdokterTalk 15:14, 16 November 2010 (UTC)[reply]
Looks good. But the "accepted" version dosn't need the text "Other administrators may also review this block, but should not override the decision without good reason (see the blocking policy)", I think.  Sandstein  20:16, 16 November 2010 (UTC)[reply]
Good point. I filtered it out. EdokterTalk 21:52, 16 November 2010 (UTC)[reply]

Hm, in practice, the color doesn't work very well; it blends in with the declined unblock requests, and the block notices themselves, which makes it harder to scan a talk page and figure out where exactly the request is. Perhaps a return to the previous blue would be better. --jpgordon::==( o ) 15:34, 17 November 2010 (UTC)[reply]

Well, it was kind of the goal of the overhaul to make the block templates more unified in appearence. The unblock is brighter then the block- and reviewed boxes, so they should still be easy to spot. EdokterTalk 16:07, 17 November 2010 (UTC)[reply]
They're not. (Remember, the relative brightness is going to vary significantly from monitor to monitor and setting to setting.) The unblock notice, which is something calling for third-party action, should be really easy to find for that third party. --jpgordon::==( o ) 16:30, 17 November 2010 (UTC)[reply]
Not to dismiss your complaint, but if you see so little difference, you really need to adjust your monitor. Having said that, I tried a different shade of blue in the sandbox. EdokterTalk 17:43, 17 November 2010 (UTC)[reply]
Or perhaps I need to adjust my eyes. But of course I see a difference -- I just don't see it anywhere near as quickly or as easily. Those of us who frequent WP:RFU are probably the only people who would really care about this; let's not let aesthetic interests override functional concerns. --jpgordon::==( o ) 17:56, 17 November 2010 (UTC)[reply]
I'm not putting looks over functionality, but I am trying to balance them. I think it is a matter of simply getting used to the new color. Since I don't want to make a hasty change again, I'd really like some more input from the RFU folks, so I'll pose the question there on what is the preferred color. That talkpage hasn't been used for over a year. Where would be the best place to get more comments? EdokterTalk 18:12, 17 November 2010 (UTC)[reply]
To be honest, i find myself agreeing with the sentiment that jpGordon states. One of the advantages of the blue unblock template was that it stood out clearly among the handled templates. Sometimes people add unblock templates in the middle of a messy page, which makes finding them more difficult now that they have the same color as every other template. In other words: I have to look at every template to see the difference in color and wording, rather then seeing this from just scrolling past as fast as possible. This is quite monitor specific as well - my left monitors color settings show a fair amount of difference, but my right screen shows little difference.
So in short:
  • I would prefer some more contrast between the templates.
  • The unhandled unblock template should have a color distinct from the other templates for ease of viewing.
  • If possible: The reviewed template is exceptionally large now due to the added linebreaks. Can that be scaled down a bit, to be more like the previous version in terms of size?
Other then that i find the changes to be an improvement over the old template, so no complaints here, just some improvement suggestions. Excirial (Contact me,Contribs) 18:44, 17 November 2010 (UTC)[reply]
As a RFU patroller, I agree with Excirial and Jpgordon, notably with respect to the colors, but thanks nonetheless for the substantial overhaul!  Sandstein  19:07, 17 November 2010 (UTC)[reply]
Can the new blue in the sandbox meet with eveyone's approval? As for the size of {{unblock reviewed}}, I think readability is better served in the new layout, which also makes it hard to miss by the blockee. EdokterTalk 19:26, 17 November 2010 (UTC)[reply]
The sandbox blue looks fine. I'm used to searching for blue when I review unblock things - the current color is far too close to the old declined color. Hersfold (t/a/c) 21:14, 17 November 2010 (UTC)[reply]
Seconded. The blue should stand out enough to recognize the template easily. Excirial (Contact me,Contribs) 21:15, 17 November 2010 (UTC)[reply]
 Done I'll update the remaining templates in Category:User block templates for a consistent look accross the board. EdokterTalk 21:50, 17 November 2010 (UTC)[reply]
Excellent work, thanks! --jpgordon::==( o ) 03:34, 18 November 2010 (UTC)[reply]

Other templates

[edit]

By any chance, will such an overhaul be performed on the Username and Autoblock templates? mechamind90 00:50, 18 November 2010 (UTC)[reply]

Preferably, yes. They're not all listed in the category (should also be fixed), but they are listed here and here. I intend to do them all, in time. EdokterTalk 01:08, 18 November 2010 (UTC)[reply]

Note

[edit]

I have slightly modified the colors of {{unblock on hold}} so that the template catches the eye more easily, like it is intended to do. Access Deniedtalk to me 04:12, 18 November 2010 (UTC)[reply]

I undid your change. It makes the template hard on the eyes. Goodvac (talk) 04:13, 18 November 2010 (UTC)[reply]
I put it somewhere in between our two versions; now it should grab attention but not be eye straining. Access Deniedtalk to me 04:19, 18 November 2010 (UTC)[reply]
Fine with me, but I don't see why a change was necessary in the first place. Goodvac (talk) 04:23, 18 November 2010 (UTC)[reply]
Please keep experiments in the sandbox (they're all linked in the testcases page). EdokterTalk 12:43, 18 November 2010 (UTC)[reply]
I'm sorry, I've reset it. It was too in-your-face. I am trying to get the wall-of-colors to a minimum, and we already have the blue and green. EdokterTalk 12:53, 18 November 2010 (UTC)[reply]
[edit]

See Wikipedia_talk:Template_messages/User_talk_namespace#Redesign_block_templates. Access Deniedtalk to me 05:20, 18 November 2010 (UTC)[reply]

A tweak.

[edit]

I suggest replacing "<tt><nowiki>{{subst:Unblock on hold-notification | 1={{BASEPAGENAME}}}}</nowiki></tt>" with

"<tt>{{subst:Unblock on hold-notification|1={{BASEPAGENAME}}}}</tt>", which will simply change "BASEPAGENAME" to the current username itself. Click the "edit" button to see what I mean. mechamind90 08:30, 23 December 2010 (UTC)[reply]

Oppose BASEPAGENAME is a fail-safe way to ensure the proper name is displayed, even when the code is copied from the template page itself (which happens a lot). EdokterTalk 14:27, 23 December 2010 (UTC)[reply]
But nothing gets substituted in the unblock template, including the {{BASEPAGENAME}}, so it should still be safe. Besides, copying and pasting from there when it still says {{BASEPAGENAME}} will just lead the administrator to their own pages, not the ones of the blocked user. My proposal allows for it to be directly copied from the template as displayed on the blocked user's talk page to the administrator's page. mechamind90 21:22, 23 December 2010 (UTC)[reply]
The idea is that BASEPAGENAME is displayed before the {{Unblock on hold-notification}} code is pasted to the admion's talk page. Actually, your code is confusing, and is even displayed the same in preview. So I fail to see the benefit of this change, if it even is a change; I only see you escape some pipe characters, whcih is completely unnecessary. If it ain't broke, don't fix it. EdokterTalk 22:38, 23 December 2010 (UTC)[reply]
Your code is too confusing, sorry. But I may have a faint idea what you want: to display the username while this template is in place of the blocked user. Right? How does it look now? EdokterTalk 22:43, 23 December 2010 (UTC)[reply]
Yes. That's what I want. mechamind90 20:29, 24 December 2010 (UTC)[reply]
OK, done. Next time if you want to propose some code, put the code in between <pre> and </pre> tags; that way it won't distort the output. EdokterTalk 20:57, 24 December 2010 (UTC)[reply]

Edit own Talk Page Revoking Option Needed!

[edit]

I should reccommend that the option used if administrators disables the user's ability to edit own talk page with this template, if he proposes an unblock which is abusive. Garygoh884 (talk) 12:03, 25 May 2011 (UTC)[reply]

Hide the template on the template page

[edit]

This page is the top hit for google:Wikipedia unblock, and we point all blocked users at this template page. To avoid confusing readers, can we hide the template from the top so they first focus on the instructions, and then transclude the template into the documentation with 'Example' as the dummy user instead 'Unblock'. John Vandenberg (chat) 00:03, 16 January 2014 (UTC)[reply]

Two changes to the 'on hold' instructions

[edit]

I've made two changes to the instructions for putting the request on hold. Firstly I've made it clear you need to add the name of the blocking admin, since I've seen this used with the words 'blocking admin' left in. Secondly I've removed the instruction about Template:Unblock on hold-notification, which no long exists. Olaf Davis (talk) 11:34, 23 May 2014 (UTC)[reply]

Modify template

[edit]

Hey, I'd like to get consensus for changing the template to [1]. The current wording may be seen as very confusing to a non-Wikipedian, and when a (possibly long) list comes up, it won't be clear to them what to do. Also, this makes it easier for admins to check as well, to see if a short block has already expired. User:DoRD, mind if you take a look at this? Thanks, Lixxx235Got a complaint? 15:14, 30 June 2014 (UTC)[reply]

What is the "(possibly long) list" you are referring to? A long block log? If an editor has a long block log, I have little doubt that they would know how to interpret it. Although, if it is an IP, I suppose that there could be some confusion. As a side note, the current behavior of Special:Blocklist is somewhat misleading. If a blocked account, IP or range is re-blocked by another admin, the page shows the original blocking admin rather than the current blocking admin.
Other than this, I don't have any particular objection to the change, but I did notice an error in your code. Special:Blocklist expects a username or IP only without "User:", and since the link is an internal wikilink, it doesn't need to be wrapped in the "plainlinks" class. ​—DoRD (talk)​ 15:32, 30 June 2014 (UTC)[reply]
@DoRD:Thanks. I'm not exactly a good template editor, and I was just trying to do things I felt were intuitive. The block-modifying admin shouldn't matter, the template fills that in by itself. Are you good with templates? If so, would you mind if you took the hassle of fixing it? Thanks, Lixxx235Got a complaint? 15:50, 30 June 2014 (UTC)[reply]
I personally like the idea of showing the block list instead of the block log there. It makes it easier to see whether not a block is active. Jackmcbarn (talk) 16:13, 30 June 2014 (UTC)[reply]

Template-protected edit request on 25 March 2019

[edit]

Please replace with the current version of the sandbox (diff) to hide the checkuser links from non-checkusers. Thanks, --DannyS712 (talk) 19:49, 25 March 2019 (UTC)[reply]

 Done - FlightTime (open channel) 20:16, 25 March 2019 (UTC)[reply]

Change clock image

[edit]

I am proposing replacing the current clock image, , with the very similar . The advantage of the latter is that it is licensed under CC0, so the link could be suppressed to avoid confusing readers. This change would also be made to:

--Ahecht (TALK
PAGE
) 21:07, 13 September 2019 (UTC)[reply]

 Done since there were no objections after a week. --Ahecht (TALK
PAGE
) 00:57, 23 September 2019 (UTC)[reply]

Template-protected edit request on 7 January 2020

[edit]

This template is causing obsolete HTML lint errors because it uses obsolete <tt> tags. I have created a new version in Template:Unblock/sandbox. Please copy that wikitext into Template:Unblock. — Anomalocaris (talk) 09:48, 7 January 2020 (UTC)[reply]

 Done — Martin (MSGJ · talk) 11:21, 7 January 2020 (UTC)[reply]

Creating an "idletimestamp" parameter

[edit]

The list at CAT:RFU often contains entries that currently do not require attention from administrators. The "administrative backlog" template is then also displayed incorrectly, without there actually being a noticeable backlog.

When an administrator replies to an unblock request without accepting or declining it, there should be a way for the administrator to temporarily remove the request from CAT:RFU, until the user has answered the question.

The most user-friendly and simple way to implement this might be an "idletimestamp" parameter. It is filled with {{subst:CURRENTTIMESTAMP}} by the administrator. If the "idletimestamp" parameter is equal to {{REVISIONTIMESTAMP}}, a subcategory ("Unblock requests awaiting response from the blocked user") replaces CAT:RFU. ~ ToBeFree (talk) 22:50, 12 April 2020 (UTC)[reply]

Courtesy ping: SQL ~ ToBeFree (talk) 22:51, 12 April 2020 (UTC)[reply]
Also pinging Yamla, who appears to be often procedurally declining such cases. This parameter might alleviate the need for procedural inactivity closures in the future, allowing the user to respond months later without clogging the category. ~ ToBeFree (talk) 22:56, 12 April 2020 (UTC)[reply]
Oh! Sorry for the delayed response. I must admit, I'm not immediately clear on how this would work technically, but trust ToBeFree on that point. I really like the idea. Most of my work is monitoring CAT:RFU and anything we can do to increase the signal there is great and I'm very much in favour. Ping @331dot: who often asks follow-up questions on open unblock requests, where this could be most useful. --Yamla (talk) 11:43, 15 April 2020 (UTC)[reply]
Thanks for the ping. Yes, this sounds like a good idea. Would this be similar to how a request can be put "on hold" to wait for a comment by the blocking admin(which also removes the request from the active queue, I believe)? 331dot (talk) 21:18, 15 April 2020 (UTC)[reply]
Hi 331dot, the "on hold" status is created by replacing {{unblock}} by {{unblock on hold}}, which is a permanent, clearly visible modification that changes the box background color, the text and the template's syntax. The "on hold" modification can only be undone by manually removing the text "on hold". It is meant as a last step before unblocking and may even be interpreted to discourage further input by the affected user for a while. The proposed "idletimestamp" parameter is a temporary, invisible measure that practically undoes itself in the moment any later edit is made to the page. The slightest typography fix or any kind of response, no matter how badly formatted, causes the unblock appeal to re-appear at CAT:RFU. The measure is invisible on the rendered page, with the exception of the category list: The category name "Requests for unblock awaiting response from the blocked user" is shown instead of "Requests for unblock".
Adding a visual indication, perhaps a text like "You have been asked a question at the bottom of this page. Please respond to it.", could be part of a future proposal. At the moment, this is purely about categorization. ~ ToBeFree (talk) 01:45, 16 April 2020 (UTC)[reply]
Additional note: The re-categorization will even happen if an edit is made and self-reverted. Looking at the timestamp has some interesting benefits. ~ ToBeFree (talk) 01:48, 16 April 2020 (UTC)[reply]

I have implemented and documented the parameter now; there are currently 11 user talk pages in the new category, "Category:Requests_for_unblock_awaiting_response_from_the_blocked_user". Worth it. Thank you very much for the detailed feedback and questions; let's see how this works out in practice. The parameter has been added to {{unblock-spamun}} and {{unblock-un}} as well. ~ ToBeFree (talk) 05:25, 16 April 2020 (UTC)[reply]

Thanks for your work on this. 331dot (talk) 09:01, 16 April 2020 (UTC)[reply]

Template-protected edit request on 4 January 2021

[edit]

Please change <samp>blocking administrator</samp> to {{mono|blocking administrator}}

This markup was installed as a result of an edit request I made a year ago, to get rid of the obsolete HTML <tt>...</tt>. At that time I believed <samp>...</samp> was the correct replacement, but I was wrong; that markup is reserved for computer output. Here, we need the generic monospaced markup. There is no effect on the display. It's just for "correctness".

Also, please change two occurrences of {{subst:Accept reason here}} to Accept reason here, which were installed as a result of the same edit request I made. This is to restore it to the way it was before and undo the confusion, as {{subst:...}} doesn't belong here.

Anomalocaris (talk) 22:03, 4 January 2021 (UTC)[reply]

To editor Anomalocaris:  done, and Happy New Year to You and Yours! P.I. Ellsworth  ed. put'r there 04:55, 6 January 2021 (UTC)[reply]
Paine Ellsworth: Thanks, and also thanks for removing the now-superfluous <nowiki>...</nowiki> markup! —Anomalocaris (talk) 07:37, 6 January 2021 (UTC)[reply]

FYI, a related response template, Template:Ipberemoved (edit | talk | history | links | watch | logs) has been nominated for deletion -- 65.92.246.142 (talk) 02:25, 6 April 2022 (UTC)[reply]

Formatting

[edit]

OK, now this template is having the same problem as "unblock reviewed" used to: punctuation (a colon, an equals sign) before the template breaks the formatting. I brought this up in January at Template talk:Unblock reviewed#Can this be fixed?. The problem appears to be metastasizing. I'm not sure what the source of this is, but I imagine it's the result of the message a blocked user gets? --jpgordon𝄢𝄆𝄐𝄇 15:01, 27 July 2022 (UTC)[reply]

Template-protected edit request on 2 August 2023

[edit]

Remove "blocked" from "This blocked user's is asking..." as it is redundant since it mentions it's an unblock request. foobarbaz 09:25, 2 August 2023 (UTC)

 Completed. P.I. Ellsworth , ed. put'er there 19:58, 2 August 2023 (UTC)[reply]
But now "this user" is a link to wp:Blocking policy, which doesn't make much sense. Perhaps "block" in that sentence should link to blocking policy instead. --jpgordon𝄢𝄆𝄐𝄇 01:46, 3 August 2023 (UTC)[reply]
 Link moved to the word "block". P.I. Ellsworth , ed. put'er there 02:36, 3 August 2023 (UTC)[reply]
Nice. Now do similar for Template:Unblock-un please? --jpgordon𝄢𝄆𝄐𝄇 13:52, 4 August 2023 (UTC)[reply]
 Completed. (Also at {{Unblock-un reviewed}}) P.I. Ellsworth , ed. put'er there 14:39, 4 August 2023 (UTC)[reply]
[edit]
Please add the relevant TfM templates linking to Wikipedia:Templates_for_discussion/Log/2023_August_11#Unblock_templates. <noinclude>
{{subst:tfm|Unblock}}
</noinclude> Aasim - Herrscher of Wikis ❄️ 19:52, 11 August 2023 (UTC)[reply]
 Done — Martin (MSGJ · talk) 20:55, 11 August 2023 (UTC)[reply]

Edit request 14 November 2023

[edit]

Description of suggested change:

Diff:

ORIGINAL_TEXT
+
CHANGED_TEXT

87.1.48.40 (talk) 15:09, 14 November 2023 (UTC)[reply]


https://wiki.riteme.site/wiki/Draft:Gaetano_Minale?fbclid=IwAR1hUdAs248Zr1naKwLqEQSWbwNIkaE5NE9yx26utL-slYQjLKnadZoi4pA chiedo sblocco

 Not done It's unclear what you are asking. I think you are in the wrong place. This is for suggesting edits to Template:Unblock. --Yamla (talk) 15:15, 14 November 2023 (UTC)[reply]

Please unblock my transaction from binance account to another wallet 117.20.116.225 (talk) 11:23, 23 February 2024 (UTC)[reply]

You are confused, this is a Wikipedia talk page to discuss improvements to Template:Unblock. You want a completely different website. --Yamla (talk) 11:38, 23 February 2024 (UTC)[reply]