Jump to content

Template talk:EP

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

"Consensus" option

[edit]

The consensus parameter should probably be locally defined, and not passed through to {{EP}}, since the text refers to "the {{editprotected}} template", which will just confuse users. I'd do it myself, but I'm afraid I'd mess it up. Thanks for creating this, it's useful.--Aervanath talks like a mover, but not a shaker 21:22, 19 January 2009 (UTC)[reply]

Actually {{ESp|c}} produces
 Not done for now: please establish a consensus for this alteration before using the {{Edit protected}} template.
I just didn't bother to document the small difference because I didn't think it would cause too much confusion! Thanks for the compliment. Martin 21:55, 19 January 2009 (UTC)[reply]
Oh, I didn't notice that, I guess because I was just looking at the documentation, which doesn't specify that. Anyway, good work.--Aervanath (talk) 17:15, 21 January 2009 (UTC)[reply]

GFDL compliance

[edit]

{{editsemiprotected}} This template instructs established users to copy text provided by new users. It should remind them that the new user must be credited for the text, for compliance with the GDFL.

So please add the text "Don't forget to give credit to the user who suggested the change in your edit summary" or words to that effect. Jemima PD (talk) 13:38, 25 April 2009 (UTC)[reply]

You probably want to add this to Template:EP/doc. This is not protected so there is no need to place the {{editsemiprotected}}. Regards, — Martin (MSGJ · talk) 14:55, 25 April 2009 (UTC)[reply]

Red crosses and bitiness

[edit]
Not done: please be more specific about what needs to be changed.

The above might look harmless to established editors, but remember it's aimed at a new contributor who's just made a good-faith suggestion – I'm concerned the big red cross comes accross as a little bitey in tone. I propose that [[Image:X mark.svg|20px]], which I presume gets here through {{EP}}, be either removed outright or else replaced with something softer, though I'm not sure what. Adrian J. Hunter(talkcontribs) 12:41, 21 March 2010 (UTC)[reply]

I've never thought about it like that. But it's fine by me if you find a better image. — Martin (MSGJ · talk) 13:05, 21 March 2010 (UTC)[reply]

Thanks Martin. For now I've replaced the cross with the information symbol from the AGF user warnings, as illustrated below. There's probably something better out there, though. Adrian J. Hunter(talkcontribs) 11:54, 22 March 2010 (UTC)[reply]

Not done: please be more specific about what needs to be changed.

I thought you were proposing the change for {{ESp}} but the change has affected {{EP}} as well. Is this intentional? — Martin (MSGJ · talk) 08:46, 27 March 2010 (UTC)[reply]

I was initially more concerned about {{Esp}} which is only used by newcomers, but the argument applies to {{EP}} as well. Also it seems simpler for both templates to use the same set of icons. I found a couple of better icons in Wikimedia Commons, shown below. Comments welcome! Adrian J. Hunter(talkcontribs) 04:23, 29 March 2010 (UTC)[reply]
Not done: please be more specific about what needs to be changed.
Not done:
Not done for now:
Not done: please establish a consensus for this alteration before using the {{editprotected}} template.
I personally don't like the minus icon very much. :( And why are they not showing correctly in the documentations? --JokerXtreme (talk) 08:40, 29 March 2010 (UTC)[reply]
The documentations update automatically but it seems to take a few hours; they're fine now. Ok, well here are some more ideas from the Commons:
Not done for now:
Not done for now:
Not done for now:
My first choice at the moment is the red spot, which seems to convey a negative without judging the original poster. Adrian J. Hunter(talkcontribs) 04:11, 31 March 2010 (UTC)[reply]


Not bad, but it seems too intense. I like the Information icon more, yet it lacks red, which has the effect you mention. How about these? I like the first exclamation mark.

Not done for now:
Not done for now:
Not done for now:
Not done for now:

--JokerXtreme (talk) 05:39, 31 March 2010 (UTC)[reply]

I'm changing it to the first exclamation mark. It can be reverted back, if you don't like it. --JokerXtreme (talk) 08:58, 1 April 2010 (UTC)[reply]

An exclamation mark is better than a cross, but to me it still carries the suggestion that the original poster is being warned for some kind of transgression; notice the level 3 vandalism templates use an exclamation mark. How about a red version of the information symbol? I should be able to make one when I have access to photoshop next week. Adrian J. Hunter(talkcontribs) 11:41, 3 April 2010 (UTC)[reply]

Yeah, I was thinking of the same thing. I don't know if it will actually look good, but you can try it. Preferably, this information icon: . --JokerXtreme (talk) 12:49, 3 April 2010 (UTC)[reply]
I made some changes and uploaded the result. This it:

Not done for now:

They seem to have a tendency to look faded when sized down. You can edit it or ask me to do it. --JokerXtreme (talk) 13:24, 3 April 2010 (UTC)[reply]

That was quick – nice work! I'm not seeing any fading problem, not on Firefox nor IE, so I'll need to leave that one to you. Good call on the talk page move, too. Adrian J. Hunter(talkcontribs) 13:58, 3 April 2010 (UTC)[reply]
Yeah, it's pretty easy with SVGs and Inkscape. Maybe it's just me, but it seems faded compared to this [1]. Anyway I'll change the template then. Thank MSGJ for the move :) Also, please look at the section below. --JokerXtreme (talk) 14:11, 3 April 2010 (UTC)[reply]
>_< Must have been past my bedtime. No thoughts on the section below; I'll leave that to people who use these templates more frequently. Adrian J. Hunter(talkcontribs) 02:39, 4 April 2010 (UTC)[reply]

Merge options

[edit]

Shouldn't those be merged and select the output within template?

 Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details.


--JokerXtreme (talk) 05:53, 31 March 2010 (UTC)[reply]

Add switch options to {{ESp}}

[edit]

Please add |permission|perm|p to the second switch option in {{ESp}} to account for the new parameter in this template. — Bility (talk) 22:57, 22 March 2012 (UTC)[reply]

 Done Tra (Talk) 23:13, 22 March 2012 (UTC)[reply]

Edit request on 4 May 2012

[edit]

Please unlink the icons (by using [[File:imagename|imagesize|alt=imagealttext|link=]]). There is no need to link the icons to their description pages, as I can see from some other similar templates such as {{RFPP}} and {{AIV}}.

jfd34 (talk) 15:26, 4 May 2012 (UTC)[reply]

Note this may not be done for File:Torchlight help red.png, File:Padlock-silver-slash.svg, File:Padlock-skyblue-plus.svg, File:Padlock-dash.svg, or File:Padlock-olive-arrow.svg, as the licenses on those images require a statement of which license the image is released under, which in practice means we have to have the backlink. The other images could be delinked, if no one minds the inconsistency.
BTW, I've fixed some images with the same problem on {{RFPP}} and {{AIV}}, thanks for pointing them out. Anomie 03:12, 5 May 2012 (UTC)[reply]
Since the original padlock files are cc0 (File:Padlock-silver.svg, File:Padlock-skyblue.svg, File:Padlock.svg, File:Padlock-olive.svg), I'll go back to those versions and make some new ones which i'll also license as cc0, so that it will only be File:Torchlight help red.png which can't be unlinked. -- WOSlinker (talk) 13:57, 6 May 2012 (UTC)[reply]
 Done apart from File:Torchlight help red.png. If you can find a suitable alternative image that is cc0 or pd licensed then it can be replaced. -- WOSlinker (talk) 14:42, 6 May 2012 (UTC)[reply]
I've changed the question mark icon to alt (File:Red question icon with gradient background.svg), which is a new cc0 icon, so it can be unlinked as well. -- WOSlinker (talk) 18:28, 6 May 2012 (UTC)[reply]

Misplaced edit requests

[edit]

I often see the {{editprotected}} template being used on the wrong page. Sometimes it's used on a talk page which is vaguely related to the desired edit, as here; sometimes on a page related to protection, as here; and sometimes the connection is tenuous at best, as here. I would like to suggest that {{EP}} and {{ESp}} be given a stock answer to such posts, something along the lines of "Not done: this is the talk page for discussing improvements to the page Template:EP. Please make your request at the talk page for the article concerned." Does anybody have any thoughts about this? --Redrose64 (talk) 13:30, 11 July 2012 (UTC)[reply]

Sounds good to me. Anomie 13:43, 11 July 2012 (UTC)[reply]
 Done it looks like this -
 Not done: this is the talk page for discussing improvements to the template {{EP}}. Please make your request at the talk page for the article concerned.
--Redrose64 (talk) 19:38, 12 July 2012 (UTC)[reply]
Good idea! — Martin (MSGJ · talk) 21:23, 12 July 2012 (UTC)[reply]

ESp switch case fix

[edit]

{{editprotected}}

Note: Template talk:ESp redirects here. This is not a misplaced request.

The current switch is not feeding parameters correctly. The line with "={{{1}}}" is the terminal case for flow-through, and so the line "|u|un|unprotected=semi" must either come before all flow-through lines (i.e. immediately following the switch line) or after the ={{{1}}} line. To be more prescriptive, remove the line:

  |u|un|unprotected=semi

And re-insert this line in-tact below the line |misplaced|mis={{{1}}}, that is, insert it as such:

  |misplaced|mis={{{1}}}
  |u|un|unprotected=semi
}}

BigNate37(T) 04:19, 6 August 2012 (UTC)[reply]

 Done. Thanks for the clear instructions (trust me, much clearer than many such requests). Cheers.--Fuhghettaboutit (talk) 05:05, 6 August 2012 (UTC)[reply]
Thanks! BigNate37(T) 06:16, 6 August 2012 (UTC)[reply]

Edit request on 6 August 2012

[edit]

I have already added a parameter called xy on the EP template. I would like it to be in the ESp template as well.

FloBo A boat that can float! (watch me float!) 10:30, 6 August 2012 (UTC)[reply]

 Done - it's strange that {{ESp}} is full-prot whereas {{EP}} is only semi-prot. --Redrose64 (talk) 11:00, 6 August 2012 (UTC)[reply]
Thank you! FloBo A boat that can float! (watch me float!) 12:22, 6 August 2012 (UTC)[reply]

ETp time

[edit]

Is it time to update this template to include ETp specific outputs? Mr. Stradivarius, do you think it would be useful/convenient to convert this template to Lua and have it automatically detect the level of protection on the previous page and output accordingly? If that was done, then the {{ESp}} could be done away with and we wouldn't need a {{ETp}} to be created. It would simply be use {{Ep}} for everything and the module will figure out the rest. Technical 13 (talk) 14:39, 19 December 2013 (UTC)[reply]

ETp-specific outputs would be good, but automatic protection detection might not be so good. For a start, we can't do it accurately - pages protected by the title blacklist and by cascading protection are currently undetectable from wiki pages or Lua modules. And also, because protection levels change, and a message that made sense with one protection level might not make sense at all with another protection level, and having them change automatically when the protection level changes is bound to confuse people. — Mr. Stradivarius ♪ talk ♪ 14:57, 19 December 2013 (UTC)[reply]
AFAIK there are only two messages that are different between {{EP}} and {{ESp}} - s and u:
{{ESp|s}} Not done: {{edit semi-protected}} is not required for edits to unprotected pages or pending changes protected pages.
{{ESp|u}} Not done: {{edit semi-protected}} is not required for edits to unprotected pages or pending changes protected pages.
{{EP|s}} Not done: {{edit protected}} is not required for edits to semi-protected or unprotected pages or pending changes protected pages.
{{EP|u}} Unprotected
the last one is an anomaly. --Redrose64 (talk) 21:47, 19 December 2013 (UTC)[reply]
I've been working on getting EP|u fixed. Jackmcbarn (talk) 22:13, 19 December 2013 (UTC)[reply]

Sandbox option

[edit]

Jack, while I like the idea for your new output option. I have a few questions:

  1. Where would the "sandbox" be for article space pages?
  2. Would it be better for the word "sandbox" to be a link to the sandbox itself?
  3. Would it be good to add a section like "and display appropriate testcases"?
  4. If the testcases wording is added, would it be good for it to be a link to the testcases page?

Thanks for any answers/ideas on these points! Technical 13 (talk) 18:33, 8 January 2014 (UTC)[reply]

  1. It's not intended for use in responding to edit requests to articles.
  2. That's a good idea, but it can't always work. For example, a request to edit Template:Uw-vandalism1 would be made at Wikipedia talk:Template messages/User talk namespace, so there's no way the template could know what it was meant, unless another parameter was added, and just putting a link after usage of the template would probably be better than adding a parameter.
  3. I'm not sure if this is necessary. Usually, the existing testcases are good enough to show their new change. Maybe we could have two versions of the message, one with it and one without.
  4. Yes, but the problem with #2 applies again.
Jackmcbarn (talk) 20:45, 8 January 2014 (UTC)[reply]
  1. Then it shouldn't work on article pages.
  2. Those are edge cases though, are there enough of them to prevent it from happening most of the time?
  3. I've seen quite a few times where a new parameter has been introduced and the testcases not updated to reflect it. I have no objections to a |sb|sand|sandbox= current version|tc|testcases= current version + testcases note.
  4. Same as #2 I suppose...
Jack && Rose, what do you think? Technical 13 (talk) 21:06, 8 January 2014 (UTC)[reply]
Since any page may be set to any protection level (except pages in MediaWiki: space which are never protected but behave as if they're full-prot), an {{edit protected}} request may be used on pages in any of the Talk namespaces, which therefore means that the {{EP}} template may also be used on pages in any of the Talk namespaces. However, WP:TESTCASES is written primarily for Template: space (although largely applicable to Module space as well), so using {{EP|sand}} as a response to an {{edit protected}} request which is not in Template talk: or Module talk: might be seen as bitey. But the discussion page for certain templates is not actually in Template talk: space (for example, try going to Template:Chembox and clicking its talk page tab), so restricting the use of {{EP|sand}} to Template talk: and Module talk: could be counterproductive.
Editors responding to unclear edit requests should therefore think carefully before responding with {{EP|sand}}; but there is certainly potential for its use, since it can yield more satisfactory results than if e.g. {{EP|?}} or {{EP|xy}} had been used. --Redrose64 (talk) 22:56, 8 January 2014 (UTC)[reply]

s, t, and u outputs don't make a lot of sense to me...

[edit]

I'm not sure what the message to be relayed by these parameters is suppose to be...

  • |s
  •  Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details.
  •  Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details.
  •  Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details.
  • |t
  • The parameters template & t are deprecated and is succeeded by hr. If it isn't what you're looking for, visit Template:EP/doc to find appropriate parameters for your use.
  • The parameters template & t are deprecated and is succeeded by hr. If it isn't what you're looking for, visit Template:EP/doc to find appropriate parameters for your use.
  • The parameters template & t are deprecated and is succeeded by hr. If it isn't what you're looking for, visit Template:EP/doc to find appropriate parameters for your use.
  • |u
  •  Not done: The page's protection level has changed since this request was placed. You should now be able to edit the page yourself. If you still seem to be unable to, please reopen the request with further details.
  •  Not done: The page's protection level has changed since this request was placed. You should now be able to edit the page yourself. If you still seem to be unable to, please reopen the request with further details.
  •  Not done: The page's protection level has changed since this request was placed. You should now be able to edit the page yourself. If you still seem to be unable to, please reopen the request with further details.

This seems very inconsistent, inaccurate, and confusing. I propose changing to (and adding a new parameter):

  • |f|full|cascade|interface
  •  
  • Not done: {{{Edit protected}} is required for edits to {{#switch:{{lc:{{{1}}}}}|f|full = fully protected|cascade = cascade protected|interface = user interface}} pages. Please wait patiently until an administrator who can help you looks this request over.
  • Not done: {{{Edit protected}} is required for edits to {{#switch:{{lc:{{{1}}}}}|f|full = fully protected|cascade = cascade protected|interface = user interface}} pages. Please wait patiently until an administrator who can help you looks this request over.
  • |s
  • |t
  • Not done: {{Edit protected}} is not required for edits to template-protected, semi-protected, unprotected, or pending changes protected pages.
  •  
  • Not done: {{Edit template-protected}} is required for edits to template-protected pages. Please wait patiently until a template editor or administrator who can help you looks this request over.
  • |u

Is this agreeable? If so, I'll make the changes (can someone make/upload those images, I'm horrible at it.) As far as existing usage, I would be happy to run through and update all usage of these parameters as need be with AWB. Technical 13 (talk) 02:34, 9 January 2014 (UTC)[reply]

For the most part, I find those messages (clarification: the originals, not yours in particular) unnecessary and BITEy. If someone uses {{Edit protected}} on a semi-protected page, someone reviewing it should just change that to {{edit semi-protected}} and then proceed accordingly. The only useful ones are the |u ones. The anomaly with {{EP|u}} can likely be fixed now, since nothing uses it anymore (unless the job queue is over 6 weeks long). Jackmcbarn (talk) 02:42, 9 January 2014 (UTC)[reply]
The images have all been added... What do you think of my proposed replacement texts? I think they are a little less BITEy and more explanatory myself. I agree with what you think should be done, but admins or TEs may only have a few moments and not have time to read requests for pages that are "only" semi protected. Technical 13 (talk) 04:08, 9 January 2014 (UTC)[reply]
These are likely going to be totally obsolete in 2-3 weeks when my changes to MediaWiki land here. See Module talk:Protected edit request#Fully detecting all forms of protection. Once that's done, the request banner will automatically use the right form of itself no matter which template the requester used. Jackmcbarn (talk) 15:15, 9 January 2014 (UTC)[reply]
@Jackmcbarn: I have a question regarding that. Presumably, if the prot level is changed whilst the request is still open, the template will update itself, and that's fine. But what if the prot level changes after fulfilment? Will the template also update itself in those circumstances? If so, I don't think that's a good idea, since it will cause a closed discussion to change after the event, perhaps giving subsequent readers the impression that there had been (say) an edit-protected discussion concerning an unprotected page. --Redrose64 (talk) 17:17, 9 January 2014 (UTC)[reply]
Hadn't thought of that. To address that, I'd probably make the closed version of it be generic, like "This edit request has been answered". Jackmcbarn (talk) 17:18, 9 January 2014 (UTC)[reply]

To subst or not to subst

[edit]
  • As far as this specific template goes, I would think it should be subst: instead of transcluded anyways... I mean, it's not like the answer is going to change. If there is more discussion, then you would just use another template after that discussion (like we do now anyways). Then this wouldn't be an issue. It "may" still be an issue on {{Edit protected}}, {{Edit template-protected}}, and {{Edit semi-protected}} though, which I don't think should be subst: as I've often enough seen them reopened after some more comments/discussion. I have an idea, but I don't know if it is feasible and would take some parsing of the protection log to accomplish it. We could start using ans=((subst:currenttimestamp)) instead of ans=y and the lua module could parse the protection log to find out what the protection level was at that timestamp and display accordingly. That may be more work than it is worth though. Technical 13 (talk) 17:57, 9 January 2014 (UTC)[reply]
Although we might advise users to subst: in the future, there are thousands of past uses which were not substd. We would not wish these to change their meanings. --Redrose64 (talk) 18:36, 9 January 2014 (UTC)[reply]
Couldn't we use bots to subst them all, then change the template? Jackmcbarn (talk) 18:36, 9 January 2014 (UTC)[reply]
  • If you do that, don't forget to remove the subst guard first (if you haven't already). I think we should figure out why this wasn't always a subst-only template first, because there might be something we don't know. Jackmcbarn (talk) 19:01, 9 January 2014 (UTC)[reply]
I'm not a member of WP:BAG. --Redrose64 (talk) 19:31, 9 January 2014 (UTC)[reply]

Rose that is fair, and I have no issues with going to BAG. Do you think that subst: existing uses is a good idea, or do you know why it isn't already done before I do so I can have some background on this. Thanks. Technical 13 (talk) 19:40, 9 January 2014 (UTC) [reply]

Sorry if you already know this, but a current reason protected edit request templates aren't subst'd is because after they're answered they turn into the box to the right. If a requester wants to re-open a request, we shouldn't assume they know how to add a new template from scratch, as if they followed the path from "view source" the original template would have been added automatically. Adrian J. Hunter(talkcontribs) 22:17, 9 January 2014 (UTC)[reply]
We're talking about the {{EP}} template, not the {{Edit protected}} template. Jackmcbarn (talk) 22:23, 9 January 2014 (UTC)[reply]
Derp. Thought I must have been missing something. Adrian J. Hunter(talkcontribs) 00:51, 10 January 2014 (UTC)[reply]
I don't know the history of {{EP}}, I only really started using it after I got the admin rights in 2011 and started processing edit-prot reqs. I've hardly ever seen anybody else subst: it; indeed, if you do use {{subst:EP|n}} (or similar), it gets saved as {{EP|n}} - the subst: is filtered out. --Redrose64 (talk) 22:39, 9 January 2014 (UTC)[reply]
I don't really remember exactly why I added it, but it was probably after encountering someone substituting it and creating a messy switch statement. seems like using some form of module:unsubst would be the way to go, but whatever makes sense is fine with me. Frietjes (talk) 14:31, 13 January 2014 (UTC)[reply]
I modified the sandbox version to make substing not leave a big switch mess. Are we good to change these to be subst'd now, then? Jackmcbarn (talk) 21:22, 13 January 2014 (UTC)[reply]
As far as substing them goes, AnomieBOT will do that if someone puts {{substituted|auto=yes}} on the template, and adds them to User:AnomieBOT/TemplateSubster force since they almost certainly have more that 100 existing transclusions. Anomie 17:11, 16 January 2014 (UTC)[reply]
@Redrose64, Technical 13, Mr. Stradivarius, and Frietjes: If there's no objections, I'm going to go ahead and do that then. Jackmcbarn (talk) 17:16, 16 January 2014 (UTC)[reply]
Sounds sensible to me. User:AnomieBOT/TemplateSubster force is fully protected, so you'll need someone else to make that edit for you. About {{EP/sandbox}}, you need to make the SUBJECTSPACE parser function instances subst-able as well, otherwise the #ifeq comparison will fail. Try both transcluding and substituting my sandbox to see what I mean. Also, MSGJ might be interested in this proposal. — Mr. Stradivarius ♪ talk ♪ 21:55, 16 January 2014 (UTC)[reply]
I've gone ahead and made the changes that I can for now. Jackmcbarn (talk) 03:04, 17 January 2014 (UTC)[reply]
The ETp template subst'd without incident. Jackmcbarn (talk) 03:35, 17 January 2014 (UTC)[reply]
I've flipped the switch - AnomieBOT should substitute EP and ESp any minute now. — Mr. Stradivarius ♪ talk ♪ 04:51, 17 January 2014 (UTC)[reply]
I estimate AnomieBOT will get done substing in about 24 hours after it starts editing again. Jackmcbarn (talk) 19:29, 17 January 2014 (UTC)[reply]

Complete rework of s, t, u, nlp, and hr

[edit]

Since s, t, u, nlp, and hr all essentially said the same thing (that the requester is capable of making the edit on their own), I've combined all of these into a single message. I left all of the old abbreviations for these active, but removed them from the documentation. Jackmcbarn (talk) 19:10, 16 February 2014 (UTC)[reply]

Undone

[edit]

@Technical 13: I've rewritten undone to just use 2 names instead of trying to use an extra parameter. I think this template is complicated enough without adding extra switches to some of the outputs. Jackmcbarn (talk) 19:40, 29 January 2014 (UTC)[reply]

rfpp

[edit]

Perhaps the rfpp parameter should be split into two versions: one for responding to requests to protect the page, and one for responding to requests to unprotect it. Jackmcbarn (talk) 03:56, 13 February 2014 (UTC)[reply]

@Callanecc and Technical 13: ping. Jackmcbarn (talk) 03:59, 13 February 2014 (UTC)[reply]
  • Adding a new parameter to the template is fairly straight forward and I don't think anyone would complain (although at some point there is going to start being sooo many options a script will be needed to help remember and pick the correct one. :P). — {{U|Technical 13}} (tec) 04:16, 13 February 2014 (UTC)[reply]
    • I agree with Technical 13 on this one, I think there are enough parameters as is and having to work out whether they are asking for an increase or a decrease would just be annoying. Hopefully people start to notice the highlighted comment at the top of the unprotection request section. Callanecc (talkcontribslogs) 08:50, 13 February 2014 (UTC)[reply]
Disclosure: the previous change to the wording was made by me. I believe that the current text is overcomplicated: the wording directs people to "the protecting admin", who simply doesn't exist for an unprotected page; and your average Joe might not even know how to find the page logs, let alone determine the protecting admin from those. Regarding finding the page logs: yes, there's the link "View logs for this page" at the top of the history, but they may not know that. Logically, when you go into "View source" for a protected page, it would show the most recent entry from the prot log either above or below the {{protected page text}} (rather like the deletion log entry that you get when clicking the redlink for a previously-deleted page), but it doesn't - of course, there is the link in the text "The reason for protection can be found in the protection log", but they might not spot that. --Redrose64 (talk) 14:30, 13 February 2014 (UTC)[reply]
  • Um, wait... We are talking about the answer template that us seasoned editors use to point the new editors in the correct direction, right? We could simple have a "rpp" for those that want to request page protection and a "rpu" for those requesting unprotection. I support having both of these for the record, it's just that the list of possible answers is getting to a length now that we need to keep that in mind. Jack, would it be possible for a Lua module to be added to the group editnotice for all talk pages and if the associated space page is protected, offer a collapsible box with a reminder key of all the possible answers we can give that are templated for that protection level that can only be seen by editors with that protection level (using sysop-show, templateeditor-show, or autoconfirmed-show css class)?? — {{U|Technical 13}} (tec) 16:16, 13 February 2014 (UTC)[reply]

Unprotected

[edit]

@Jackmcbarn: Why was the unprotected option removed? I use this one fairly frequently for protected templates that are no longer transcluded anywhere. It's a bit bureaucratic to require users to go to [{WP:RFPP]] to request such templates be unprotected, so I usually just unprotect them when answering the request. I was going to use it for Template talk:Age in years, months and days#Post-merge redirects today, but then I found out that it had been removed. — Mr. Stradivarius ♪ talk ♪ 23:56, 23 March 2014 (UTC)[reply]

@Mr. Stradivarius: I cleaned up a bunch of messages that effectively meant the same thing. I think {{EP|hr}} is the closest thing to what you want to say now. My goal is to just have one message to mean "you can make the edit yourself", no matter why that's the case. Jackmcbarn (talk) 21:36, 27 March 2014 (UTC)[reply]
Hmm, I wouldn't use {{EP|hr}} in that situation, as it implies that the requesting editor made a mistake and was actually already able to edit the page. I can tell you from personal experience that not all requesting editors realise that the {{EP}} messages are boilerplate responses, so a message that implies a requesting editor got something wrong is bound to make someone annoyed. If we have to minimise the number of messages, I would add just one more, "Protection level reduced: The protection level of the page has been reduced, so you should now be able to edit it yourself". — Mr. Stradivarius ♪ talk ♪ 03:13, 28 March 2014 (UTC)[reply]
I think I'll split hr into two versions: one for if they could have edited it all along, and one if something changed after the request was made (such as protection being removed or expiring, or the requester becoming autoconfirmed). Jackmcbarn (talk) 01:11, 30 March 2014 (UTC)[reply]
@Mr. Stradivarius: Okay, that's done. {{subst:EP|hr}} produces the old message, and {{subst:EP|nlp}} produces the one suitable for when you unprotect. These correspond to the "Could always edit" and "Can edit now" buttons in EPH. Jackmcbarn (talk) 17:48, 8 April 2014 (UTC)[reply]
Thanks! — Mr. Stradivarius ♪ talk ♪ 17:53, 8 April 2014 (UTC)[reply]

Protection level

[edit]

Would anyone object to reducing the protection level of this template? I see that Callanecc increased it to template protection in February, but it no longer has the thousands of transclusions that caused it to be protected previously: now there are only 15 transclusions, and most of those are due to the template documentation. Personally I would just unprotect it completely, but I can see an argument for semi-protection, seeing as this is used for administration and non-autoconfirmed users can't technically answer any kind of edit request as "done". — Mr. Stradivarius ♪ talk ♪ 00:04, 24 March 2014 (UTC)[reply]

I'd be happy to have all three ({{EP}}, {{ETp}} & {{ESp}} all semi protected (edit and move). I think they'll still be used enough both in terms of the number of subst's and the locations and reasons they are used that they warrant semi protection. Callanecc (talkcontribslogs) 01:17, 24 March 2014 (UTC)[reply]
I am perfectly fine with edit being lowered to semi, but I can't think of any reason they would ever need to be moved and think that move protection should stay at least at  Template editor. This would greatly increase the chances of there being a discussion before any move. — {{U|Technical 13}} (tec) 15:58, 24 March 2014 (UTC)[reply]
All three templates are now at edit=semi and move=templateeditor. Callanecc (talkcontribslogs) 12:58, 27 March 2014 (UTC)[reply]
@Callanecc: I'm not sure that was a good idea. If a barely autoconfirmed vandal account were to mess with these templates, it could create a big mess since they're subst'd so often and would require a lot of work to clean up. Jackmcbarn (talk) 21:38, 27 March 2014 (UTC)[reply]
I understand Jack's concern, and it would be a little bit of a nuisance to have to clean up after, and it is a highly visible (highly-substituted template). However, I'd like to think that won't happen and if it does then it was an intentional vandalism and such an editor would simply be blocked. The protection here is only intended to prevent (or at least greatly reduce) accidental edits to the template from a non-understanding new editor. — {{U|Technical 13}} (tec) 22:33, 27 March 2014 (UTC)[reply]
That plus they really aren't subst'd that much from memory of the number of transclusions (which are historical as well). The only one I would think might need templateeditor protection is the ESp template and even then it isn't a major target (as opposed to the warning templates which are only semi protected. Callanecc (talkcontribslogs) 00:36, 28 March 2014 (UTC)[reply]
@Callanecc: it's incorrect to say "they really aren't subst'd that much" - they used to always be transcluded, yes; but are now normally substd, and since 03:00, 17 January 2014 a bot has come along and substd any uses that were transclusions - here's an example from today. Just glance down AnomieBOT's Talk contribs or AnomieBOT's Template talk contribs to see just how often "Substing templates: {{EP}}. See User:AnomieBOT/docs/TemplateSubster for info." (or similar) comes up. --Redrose64 (talk) 07:50, 28 March 2014 (UTC)[reply]

Proposal for "p" (permission) option rewording

[edit]

I'm often finding myself in a dilemma when someone asks for permission to edit a specific protected article. They are not actually asking for additional user right nor are they asking for a change in page protection level. I believe they often have a fundamental misunderstanding of how page protection works and they are literally just asking for permission to edit that page (like there is a username specific override to the protection). So, my proposal is for a new wording for this decline reason that looks like:

  •  Not done: this is not the right page to request additional user rights. You may reopen this request with the specific changes to be made and someone may add them for you.
  •  Not done: this is not the right page to request additional user rights. You may reopen this request with the specific changes to be made and someone may add them for you.
  •  Not done: this is not the right page to request additional user rights. You may reopen this request with the specific changes to be made and someone may add them for you, or if you have an account, you can wait until you are autoconfirmed and edit the page yourself.

Thoughts? Improvements? — {{U|Technical 13}} (etc) 19:04, 27 May 2014 (UTC)[reply]

Why did you change the way all of the safesubst's look? I think they looked better before. I don't think telling them they can request unprotection is a good idea; rather, just tell them to make their specific request. Jackmcbarn (talk) 19:11, 27 May 2014 (UTC)[reply]
  • I changed the safesubst:s because this way has been tested and proven to be faster and more efficient. If we aren't suppose to tell them they can request unprotection, why do we have the rfpu reason (that you added)?
  •  Not done: requests for decreases to the page protection level should be directed to the protecting admin or to Wikipedia:Requests for page protection if the protecting admin is not active or has declined the request.
I just combined the existing permission reason with the rfpu reason and offered the ?xy reason as a lastly. — {{U|Technical 13}} (etc) 19:26, 27 May 2014 (UTC)[reply]
If they ask for unprotection, we'll tell them where to go, but we're not going to offer that information, since in 99% of the cases, it would result in a frivolous request. Jackmcbarn (talk) 19:37, 27 May 2014 (UTC)[reply]
  • "Let me edit this protected page" sounds like it could be a request for a change in protection levels to me... Perhaps the thing to do is to move the existing p/perm/permission to wr/wantrights so that we can both have a version that works? — {{U|Technical 13}} (etc) 19:47, 27 May 2014 (UTC)[reply]
[edit]

I suggest changing this:

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template.

to this:

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template.

as it is too often needed, and perhaps it would save a lot of wasted time and energy, and save some feelings if we hammered the message home a little more. fredgandt 17:51, 2 April 2016 (UTC)[reply]

Donefredgandt 10:06, 4 April 2016 (UTC)[reply]

RfC: Add "thank you" text to done output

[edit]

Currently {{subst:ESp|d}} (and alike) outputs:

Done

which we can of course add to manually. I propose adding some encouraging gratitude to it to form something like:

Done: Thank you for your contribution to Wikipedia.

by default. fredgandt 02:22, 8 April 2016 (UTC)[reply]
  • Support – I've noticed most people's responses to edit requests are very dry and impersonal. I normally add some thanks myself, but adding it by default would improve many people's responses. It's not only the "Done" requests, though – ideally we'd thank good-faith but misguided requesters for their attempt. A default thank you message should probably be suppressed if a responder enters their own addendum. The colon after "Done" should probably be a full stop in this proposed default message. I'm surprised no-one else has commented – with ever more pages having semi-protection, more and more people's first experience at editing Wikipedia will be through an edit request, so how we respond is of great importance to retaining interested editors and thus to the long-term success of the entire project. Adrian J. Hunter(talkcontribs) 13:37, 17 April 2016 (UTC)[reply]
Well said; agreed; I've had a few humbling experiences fulfilling requests that were far from trivial and deserving of a lot more than a tick (and I'll stop myself from getting started on how often I see responders fail to attribute the requesters in the edit summaries >.< ); we do indeed need to be more thankful for these contributors.
I proposed the colon to be consistent with the other responses. I'd argue that a period is grammatically incorrect and that it should really be a semicolon, but that's just pedantic ;-)
To suppress the default automatically if the responder adds their own text, would require that the added text was entered as an argument of the template (to replace the default), so the template knows it's there.
I only just added the RfC tag, so actually the (your) response is rapid from my perspective :-) fredgandt 13:56, 17 April 2016 (UTC)[reply]
  • Oppose. Canned "thank you" is worthless: It is insincere (which is worse than impersonal), people rapidly get used to it and mentally censor it, and we will recurrently find ourselves overriding it because, depending on the context, it becomes ridiculous. Best regards, Codename Lisa (talk) 16:07, 17 April 2016 (UTC)[reply]
I have sincerely typed those exact words several times in response to edit requests. I forward the notion that nobody using the internet these days is under any illusions that everything that happens is by manual will. Templates on Wikipedia is a well established way to communicate simple uncontroversial standardized messages. The tick itself for example is symbolic and insincere, but quickly relates an agreed message. And whilst I agree that standardized messaging becomes invisible when we're repeatedly subject to it, I'd argue that there's likely to be few individual requesters who don't take control of their own editing after only a limited number of requests; i.e. Sally will probably only see this message directed at her a few times, as soon after she'll be doing her own editing.
The "context" issue is worth evaluation; when might thanks be "ridiculous"fredgandt 00:14, 18 April 2016 (UTC)[reply]
"nobody using the internet these days is under any illusions that everything that happens is by manual will" – So, you are saying other stuff exists, right? Because the majority is insincere, Wikipedia should be insincere too? In that case, I retain my opposition and I let you know that I hate OSE arguments the most.
"when might thanks be "ridiculous"?" When you write it and then proceed to explain how you did almost everything, reminding the requester that his request was a mere idea and you did all the hard work. For more instances of incorrect places to say thanks, find a cheap Chinese product and read its fineprint.
Best regards,
Codename Lisa (talk) 10:58, 19 April 2016 (UTC)[reply]

RfC: Soften "consensus" response

[edit]

Currently, the Not done: at the beginning of the consensus message seems a bit harsh, since we're not rejecting the idea per se, we're just saying that mode discussion is needed. I propose changing it to use the formatting from {{NeedsDiscussion}}, so it would appear as:

 Needs discussion: please establish a consensus for this alteration before using the {{edit semi-/extended-/template-protected}} template.

If we still think we need the red "i" instead of the softer blue/gray "i", we could at least change it to Not done for now:, since we're not actually commenting on the quality of the change, just the procedure. --Ahecht (TALK
PAGE
) 18:24, 19 July 2016 (UTC)[reply]

Okay, can support — Martin (MSGJ · talk) 12:54, 21 July 2016 (UTC)[reply]
Somehow I missed the conclusion of this discussion three years ago. Is there still support for changing the "consensus" option to Not done for now:? --Ahecht (TALK
PAGE
) 13:59, 2 October 2019 (UTC)[reply]

Not clear what changes you want to be made

[edit]

How about changing:

  • Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format.

to

  • Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide reliable sources if appropriate.

Reason: It's prevents a second round of declines when the user subsequently asks for a specific change but doesn't know enough to provide a source. --NeilN talk to me 00:43, 10 January 2018 (UTC)[reply]

Sounds good to me, though "reliable sources" --> "a reliable source", and replace "WP:RS" with "Wikipedia:Identifying reliable sources" so the name of the guideline will appear upon mouseover. Adrian J. Hunter(talkcontribs) 06:13, 10 January 2018 (UTC)[reply]
Thanks Adrian. I'll make that change later today if no one objects. --NeilN talk to me 14:57, 10 January 2018 (UTC)[reply]

Differentiate {{subst:EP|xy}} and *{{subst:EP|xys}} to make asking for a source optional

[edit]

While I think it's a good thing {{subst:EP|xy}} asks for reliable sources by default now (see section just above), I believe it would be nice to have the option to just ask for specificity in case the requester has already provided some, so as to not make them think their sources are seen as unreliable by the responder. It would probably best to make the new option, however it might be called ({{subst:EP|xys}} maybe?), the one without the sources part, so as to not interfere with muscle memory, if this were to be implemented. Of course, one could always just write a custom message after {{subst:EP|nfn}}, but the whole point of this template is to make answering edit requests quick and convenient. Thoughts? I have not yet tried to implement this in the sandbox because templates are scary. This is just an idea for now. Rummskartoffel (talk) 10:38, 30 June 2020 (UTC)[reply]

Phrasing suggestion

[edit]

I think the line Not done: please establish a consensus for this alteration before using the {{edit protected}} template might be better if it were changed to Not done: please establish a consensus for this potentially controversial alteration before using the {{edit protected}} template. Per WP:ER, uncontroversial changes do not need consensus before being suggested, so this reply should only be used for potentially controversial changes. It's sometimes used outside of that context, though, so adding "potentially controversial" would help make it clearer to responders when it should be used. {{u|Sdkb}}talk 20:51, 13 July 2020 (UTC) [reply]

Discussion from editProtectedHelper talk on forum
The text is intentionally the same as that in {{subst:EP|c}}. --Redrose64 🌹 (talk) 21:17, 13 July 2020 (UTC)[reply]
Redrose64, my suggestion is to change the text there, too, then. Would it make more sense for me to place the suggestion at Template talk:EP? {{u|Sdkb}}talk 21:56, 13 July 2020 (UTC)[reply]
Yes. --Redrose64 🌹 (talk) 22:35, 13 July 2020 (UTC)[reply]
Oppose. The request for establishing a consensus by itself indicates that the proposed change is controversial. The suggested wording is awkward and redundant. Nardog (talk) 17:50, 17 July 2020 (UTC)[reply]

Capitalization

[edit]

Re: [2][3]

I believe the revert rationale is invalid. Using the first case for an example, "Not done: page move requests should be made at Wikipedia:Requested moves." is not a grammatically correct sentence. The bolded part is a status indicator – not part of the prose – and the bolding sets it apart from the prose. A nit perhaps, but important enough (to me) for a discussion, albeit just barely. ―Mandruss  00:19, 27 August 2020 (UTC)[reply]

The Chicago Manual of Style (6.61) requires a capital if the colon introduces more than one sentence. That covers at least some of these. --Bsherr (talk) 02:43, 27 August 2020 (UTC)[reply]
A sentence is terminated with a full stop, question mark or exclamation mark, and nothing else. A colon is a form of punctuation that is used within a sentence, and just as you wouldn't use a sentence-start capital after a semicolon or a comma, you shouldn't do it after a colon either. See the "Dinner: chips and juice" example at Colon (punctuation)#Usage in English. --Redrose64 🌹 (talk) 18:20, 27 August 2020 (UTC)[reply]
Sorry, that was a reply to Mandruss, not me, right? --Bsherr (talk) 19:18, 27 August 2020 (UTC)[reply]
Both. Whilst it is true that "Not done: page move requests should be made at Wikipedia:Requested moves." is not a grammatically correct sentence, the reasoning is incorrect. A better way of writing it would be along the lines of "This request to move a page that is currently under move protection has not been processed because page move requests should be made at the Wikipedia:Requested moves page." but that's too verbose for our needs. Push that through CMoS if you like, but I don't see why notices intended only for use on our discussion pages should follow any form outside style guide, Chicago or otherwise. --Redrose64 🌹 (talk) 08:22, 28 August 2020 (UTC)[reply]
If we don't rely on conventions, we end up with an inconsistent product. Obviously, that don't mean we need to enforce that on talk pages generally. But on templates? If we insist people take care in the article space, we must take the same care in our project space. But I was more specifically asking whether you are saying you disagree with the rule that colons introducing multiple sentences should be followed by a capital letter. --Bsherr (talk) 13:38, 28 August 2020 (UTC)[reply]
Well, yes. Each sentence is, grammatically speaking, effectively an independent item – the punctuation within any sentence should not be dictated by the construction of any adjacent sentence. --Redrose64 🌹 (talk) 19:53, 28 August 2020 (UTC)[reply]
I concur with Mandruss. I bet most people interpret the part in boldface as a sort of caption or label rather than a full-fledged sentence.
  • Note: here is a sentence.
  • Note: Here is a sentence.
Which is more natural? Which one does an average person write? Also in XfDs etc. a lot of people write e.g. '''Oppose''' Here is a sentence. (While I'm at it, I'm not even sure if the colon is needed at all, given what people do when using a {{Done}} type of template, which is usually followed by a period or nothing.) Nardog (talk) 03:38, 29 August 2020 (UTC)[reply]

Is it appropriate to require consensus before using the "edit extended-protected" template?

[edit]

Currently, one response for {{edit extended-protected}} reads: Not done for now: please establish a consensus for this alteration before using the edit extended-protected template. Is this appropriate? It's wording intended for edit protected, which does require consensus in advance because all edits have to go through administrators and they're not supposed to be put in the position of having to make content decisions, while full-protected is supposed to shut down any controversial editing in any case. But WP:ECP is different - it is supposed to shut down disruption, but it is not supposed to be used to privilege older users over newer ones; that means that, like with normal edits, consensus is presumed for things that haven't been previously discussed until / unless someone objects. I feel that that one should be reworded to say something like Not done for now: this alteration has faced an objection or is clearly controversial, so a consensus must be established for it first, making it clear that it's inappropriate to reply to an extended-protected request this way in the absence of any objections. Note that this is not as big of a change as it seems at first (it is entirely fine for the editor rejecting it to express the necessary objection themselves; and in practice the template is largely used that way anyway); the important thing is the principle that non-extended-confirmed editors can suggest uncontroversial edits, and it is fine for them to be added without further discussion, because the purpose of ECP, unlike full-protection, isn't to make absolutely all their edits go through the consensus-building process. --Aquillion (talk) 18:33, 17 May 2021 (UTC)[reply]

@Aquillion: The five templates in this group offer exactly the same 24 options as each other (this greatly simplifies the coding), and for 19 of the options the resultant message is independent of the template that is used. For |hr and |nlp, the image varies - for example, {{subst:ESp|hr}} emits but {{subst:EP|hr}} emits . For |c and |doc, the template name enclosed in double braces is adjusted appropriately - {{edit semi-protected}}, {{edit protected}} etc. Only in one case, |p does the text vary in any significant way - {{subst:ESp|p}} emits ", or if you have an account, you can wait until you are autoconfirmed and edit the page yourself" which is absent for the other four levels.
So {{EEp|c}} is allowed, because it's easier to allow it than to prevent its use. It's also legitimately used on occasion; for example, imagine a semi-protected page where two or more people (not yet past the 30/500 threshold) have been edit-warring over the inclusion of some sentence. We EC-protect the article (this is explicitly permitted by WP:ECP, second paragraph), and hopefully they go to the talk page and discuss it. But imagine that instead of discussing, one of them decides to submit an ECP edit request - clearly this is controversial, because it's what the edit-warring and consequent protection were all about, so an EC user would be exceeding their authority to put the edit through without others agreeing to it. So we deny it by using {{EEp|c}}. --Redrose64 🌹 (talk) 13:37, 18 May 2021 (UTC)[reply]

Add duplicate option?

[edit]

I've been seeing duplicate edit requests quite often (as in, multiple requests for the same edit being created at the same time, or opening a new request for the same issue while the original issue is still under discussion; examples: 1, 2, 3), so given the frequency of this occurrence, does anyone think it would be worth adding a duplicate response for convenience and standardisation? Perhaps it could look like this:

Duplicate request: if you have anything to add, please comment under the original request or discussion.

Ideally, there would also be some convenient way to link to the original request, but I don't think that's possible to code into the template itself. Liu1126 (talk) 13:39, 31 December 2023 (UTC)[reply]

@Liu1126: Only the request at Talk:Las Anod was a true duplicate. and the thing to do with those is to merge the threads. The two at Talk:Dunki (film) should not have been responded to, both were revertable per WP:TPO#empty edit requests. Personally, I would also have reverted both of the requests at Talk:Jehovah as being trolling/disruptive. Do you have any more examples of genuine duplicate requests? --Redrose64 🦌 (talk) 20:55, 31 December 2023 (UTC)[reply]
Good points. In my own responses, I did find these that might be considered true duplicates: 1, 2, 3 (and this instance, if we stretch WP:AGF a bit), but like you said, merging the threads would probably be the most optimal way to go. Liu1126 (talk) 21:11, 31 December 2023 (UTC)[reply]
Two by the same editor like that? I just remove one, noting it's a duplicate. If there are multiple near identical requests that seem to be the result of off-wiki coordination or publicity, or even just disruptive repetition like at Talk:Adam's Bridge I also remove those. ScottishFinnishRadish (talk) 21:15, 31 December 2023 (UTC)[reply]