Template talk:Protection table

To request edits to this template, visit Wikipedia:Request for edit

Template editor vs. Pending changes level 1 protection

The table currently [1] suggests that being a template editor allows editing of Pending changes level 1-protected pages. Not that it really matters (since a template editor is unlikely to be not autoconfirmed) but still... that seems unlikely to me. So...? EEng 21:17, 5 January 2017 (UTC)

That's the current layout of the table; any higher permission implies autoconfirmed. Are there actually any non-autoconfirmed template editors? Pppery 21:24, 5 January 2017 (UTC)

I know what the table says -- that's why I asked. I don't know whether there are any non-autoconfirmed template editors, but this is a technical question: yes or no, is it true (as the table implies) that having the template editor right gives you the ability to edit "Pending 1" pages, if you weren't autoconfirmed? The same question would apply to template editor (not autoconfirmed) vs. "Pending changes level 2 with Semi-protection"

Or is it really true that template editor + nonautoconfirmed is an impossible (technically impossible -- not just practically impossible) combination? EEng 21:48, 5 January 2017 (UTC)

No, that combo is technically possible, as is a bunch of other peculiarities, such as an extended-confirmed user not being autoconfirmed. Is it really necessary to bloat the table by listing absurd combinations. Pppery 21:55, 5 January 2017 (UTC)

No, quite the opposite, I'm looking to unbloat the table, but first I need to understand how the permissions actually work. So, if it's true you can be a non-(auto)confirmed template editor, can such a person edit a "Pending changes Level 1" page? A "Pending changes level 2 with Semi-protection" page? I'm guessing the answer is No, but I need to know for sure. (And where are these answers found?) EEng 22:01, 5 January 2017 (UTC)

Special:ListGroupRights (and no) Pppery 22:04, 5 January 2017 (UTC)

OK, goody. Now we're getting somewhere. FTR the answer is that (as one would expect) that template editor is an independent right from everything else (well, they also have "Override the title or username blacklist (tboverride)").

The table is very hard to absorb largely because Template Editor and Pending Changes Reviewer aren't part of a strict "hierarchy" of permissions as you move left to right along the top row. Now, Pending Changes Reviewer is more complicated, but Template Editor can, I think, be untangled from the mix in a way easier to demonstrate than to describe. Now sure how long that will take, but I'd like your opinion when I've done it. EEng 22:12, 5 January 2017 (UTC)

Except that what you've done is yet another breach in consistency, and makes the table handle technically impossible situations (unregistered template editors). Resolving those would require more ugliness involving multiple consecutive red blocks. This all seems like a solution in search of a problem. Pppery 00:04, 6 January 2017 (UTC)

Are you talking about the fact that the intersection of "Unregistered, New" and "Template protection" is "cannot edit (unless Template editor, in which case like Administrator)"? If so, why is that a problem? EEng 02:29, 6 January 2017 (UTC)

Yes, and it is a problem because that implies that unregistered editors can be template editors, when they in fact cannot (it is technically impossible). Pppery 02:34, 6 January 2017 (UTC)

So what if it's technically impossible? The kind of editor who will use this table understands that, and anyway "If you are an unregistered editor who has Template Editor privileges, then you can edit through Template Protection" is a true statement, because F => (anything) is a true statement.

Furthermore, the old table (linked above) didn't even handle cases that can happen. For example, it has separate columns for Template editor and Pending changes reviewer, as if you're in one column or another, when in fact you can be one or the other or neither or both, independently. In that version, the intersection of "Template editor" and "Pending changes level 2 protection" shows as "can edit; changes will go live after being accepted by a reviewer", and that's not always true; if you were a Template editor and a Pending changes reviewer, your changes would go live immediately. This could be patched by adding "changes go live immediately if also..."-type language as elsewhere, but that just makes more of mess unless done consistently.

As observed earlier in this thread, the fundamental problem is that the column headings across the top were trying to treat those labels as a hierarchy when in fact they were not (not all of them, anyway). Removing Template editor from the columns begins to fix that (though not completely, because Pending changes reviewer does not, technically, have all rights that Extended confirmed does, so that still needs to be dealt with).

An important side effect of eliminating the Template editor column is that it frees horizontal width for redistribution to the other columns (especially the "Appropriate for" column), making the rows less tall and thus helping the whole table fit on one screen without scrolling, which really improves comprehensibility. That was, in fact, my original concern when I started looking at this, but it turns out (as shown above) that the table was incorrect in several ways, so I'm fixing that.

EEng 03:34, 6 January 2017 (UTC)

Asterisk location

I don't really get this edit. As far as I know, there is a convention to put asterisks after the text to which it refers but before the footnote that refers to that text. Putting the asterisk at the front of the text, as that edit does, suggests that the text is a footnote... which will just confuse people, since it isn't. Am I missing something? Yaris678 (talk) 12:30, 26 February 2017 (UTC)

Your rigid idea is wrong. This isn't article text. An asterisk in one place ties to an asterisk in another place, period, and you place them where they'll do that job best. I put the asterisks at front so they'll be more obvious, instead of buried at the end of two entries deep within the table. It's obvious which thing is the explainer and which is the explained. EEng 16:44, 28 February 2017 (UTC)

There being no response, I'm reverting. EEng 02:15, 5 March 2017 (UTC)

About the Third Opinion request: The Third Opinion request made in regard to this dispute has been removed (i.e. declined). That's because 3O, like all other moderated content dispute resolution venues at Wikipedia, requires thorough recent talk page discussion before seeking assistance. The discussion here is neither thorough nor recent. If an editor will not discuss, consider the recommendations which are made here. — TransporterMan (TALK) 22:56, 19 June 2017 (UTC)

OK. I thought the simplest way to resolve this would be to ask a third opinion, but apparently we need to discuss it more.

If we look at Asterisk#Typography it says "Typically, an asterisk is positioned after a word or phrase and preceding its accompanying footnote."

This is how it is used in the examples given by Really Learn English and the United Nations editorial manual.

EEng, can you find any sources where the convention you describe is recommended? i.e. does anyone recommend "An asterisk in one place ties to an asterisk in another place, period, and you place them where they'll do that job best."?

Yaris678 (talk) 09:10, 20 June 2017 (UTC)

Not that we use our own articles as style manuals, the key word in what you quoted is typically. The source for "placing them where they'll do the job best" is common sense. A website for semiliterates and a manual for bureaucrats are of no use here. EEng 15:26, 20 June 2017 (UTC)

Insult my sources all you like. an you find anything that recommends your approach? Yaris678 (talk) 20:52, 20 June 2017 (UTC)

In satisfaction of your request that I insult your sources further, here goes: "Really Learn English" is a cartoonish site for people with barely any grasp of English at all, not a venue for discussing style subtleties; and the UN Style Guide is a hyperspecified recipe book meant to keep hundreds of countries from arguing over nothing -- much as is happening here.

As to your "Can you find" query, the answer is that I already did, and already pointed it out for you above. But I'll repeat it for you. Your own "source" -- the article Asterisk -- says typically, which means usually, not always. It means that exceptions apply, according to common sense (which I also already cited).

Someone taught you that everything has to be rigidly one way, or it's "wrong". That advice is, itself, wrong: most things can be done a variety of ways according to common sense (there's that pesky concept again), especially in project (as opposed to article) space, which this is. See WP:SNODGRASS.

By the merest concidence, while you were posting your latest insistence that only things you've seen are acceptable, I had a nice sushi lunch. See right for a bit of the menu. See the little footnote bullets, all on the left? That's what you do when you want to be sure someone doesn't miss the footnote and sue your for giving them food poisoning. EEng 21:33, 20 June 2017 (UTC)

I stumbled upon this interesting discussion and thought I'd add my thoughts. I think both Yaris678 and EEng have made valid points. Asterisks normally go at the end of the text, but sometimes they're best placed elsewhere. My view is that if you're going to deviate from the norm, then you need to have a good reason to do so.

In the example of the sushi menu, that footnote is really important and does need attention drawing to it, so the asterisks do make sense in that position. It doesn't look too odd either, because in that sort of list they seem a bit like bullet points.

However in this template, the footnotes aren't as critical. No-one's going to become ill or sue if they don't read them. So as long as they're not invisible, it doesn't really matter where the asterisks go. But we also need to consider the look and feel, the reader's experience. To my mind, the positioning of the asterisks at the start just seems weird. Maybe it's not technically incorrect, but the unusualness of their location is distracting and detracting. The first thing I thought when I saw the template is "that's odd", and it was playing on my mind when I read the rest of the table. If they'd been in the usual position after the text, I'd still have been led to the footnotes, but without being distracted by how I got there.

Remember that this is only a table to be used in Wikipedia guidance, not in an article, so the asterisk location is certainly not of critical importance. Anyone reading the table should be bright enough to figure out which footnotes pertain to which text, wherever they are. Let's just try not to make it too weird. Bazonka (talk) 20:50, 22 June 2017 (UTC)

Thanks Bazonka. The important thing is that we're past the fussing about there being only one right way, so we can focus on (as I keep saying) simply what help the poor editor studying this table best understand it. Now I'm gonna lay it on the line. I spent a lot of time, with the help of our fellow editor Pppery, on making an essentially unintelligible (and in several instances incorrect) table [2] into something both correct and comprehensible. Along the way I spent a lot of time thinking about how someone coming to the table cold would go about absorbing it. The notes at the bottom stand out, and someone might very well notice one of them and want to find the table cell it "explains". To make it easier to do that, I moved the asterisks to the front of the cells. That's it. Do we really need to discuss this ad nauseam? Deuterononmy 25 says, "Thou shalt not muzzle the ox when he treadeth out the corn"; in other words, Cut some slack to the person doing the actual work. Perhaps that could be applied here. EEng 01:52, 23 June 2017 (UTC)

Well, I understand your motivation, but I disagree with your conclusion. As I said above, having asterisks before the text is distracting, and in my opinion, less comfortable for the reader. Most readers are going to go from text to footnote, and not from footnote to text, so the findability of the asterisks in the text is not of primary importance. Move them after the the text, and the readers won't be distracted by their unusual positioning, and if someone does want to go from footnote to text, I'm sure they'd be quite capable of finding them. Bazonka (talk) 07:55, 23 June 2017 (UTC)

Needless to say, I agree with Bazonka on this. Yaris678 (talk) 10:45, 23 June 2017 (UTC)

I take it the Biblical allusion had no persuasive effect. EEng 20:30, 23 June 2017 (UTC)

Not on me; I'm an atheist :) Seriously though, I appreciate the work you've done here so I don't want to "muzzle the ox", but perhaps part of the corn you're on could be tread in a way that is less distracting to the readers. Bazonka (talk) 20:42, 23 June 2017 (UTC)

Abbreviating "protection"

EEng: Regarding the abbreviation for "Template protection", since the abbreviation isn't used anywhere else in the table, and from what I see, isn't even used anywhere in the article on protection itself, it would be better for consistency and MOS:ABBR to leave it unabbreviated since it is only saving one line, after all. - Vanstrat ⁽⁽🗼⁾⁾ 21:25, 11 December 2017 (UTC)

(For those playing along at home, we're talking about [3].) In the words of Emerson, "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." Every line counts, to make it possible to take the whole table in without scrolling up and down. WP:CONSISTENCY is about article titles, and MOS:ABBR is about articles (which this is not), so they have nothing to do with anything. What, do you think people won't know what prot. means??? EEng 21:32, 11 December 2017 (UTC)

Regardless, the consistency argument still applies and MOS:ABBR applies to any abbreviation on the english wikipedia not just ones used in articles. Since "prot" isn't being used anywhere in the wikipedia policy regarding protection (and that page uses "protection" 191 times!), the abbreviation is not widely used and saving one line in a table does not warrant the use of something inconsistent with other usage regardless of whether you think people will understand what it means or not. - Vanstrat ⁽⁽🗼⁾⁾ 21:42, 11 December 2017 (UTC)

The "policy regarding protection" is not a table; this is, and different considerations apply. And if you think MOS:ABBR applies outside of article space, you need to spend more time brushing up on on guidelines and policies, and less time worrying about trivia like this. I can hardly believe we've had four posts now on this absurd non-issue. Perhaps you missed the bit about little minds and so on? EEng 21:49, 11 December 2017 (UTC)

If you believe this to be an "absurd non-issue"... why can't it be changed?

"If it is necessary to abbreviate in small spaces (infoboxes, navboxes and tables), use widely recognised abbreviations." MOS:ABBR specifically talks about tables, navboxes, and infoboxes so, yeah, it applies to those. Regardless whether you think the policy applies.. I'll point out that no policy, in article space or otherwise.. agrees with your use of the abbreviation. Based on that quote I will point out that A) This table as no space requirement to be small, it's not trying to fit into something of a particular size... so one line does not matter. It is not necessary. And, B) as I have already pointed out, since it's not used anywhere else here, the abbreviation is not widely recognized by the community. - Vanstrat ⁽⁽🗼⁾⁾ 21:59, 11 December 2017 (UTC)

For the third time, MOS applies only, only in article space. If you keep this up, I'm going to seriously consider suggesting to Oshwah that your rollbacker privileges be revoked on the basis of your lack of understanding of policies and guidelines. The protection system is complicated and hard to absorb; I and other editors have worked hard to make if possible to take the table in at one glance, instead of scrolling up and down, and yeah that matters -- here's what it looked like before [4], and that's what comes of your kind of foolish, blinkered thinking.

I'm not worried about whether prot. will be "recognized by the community" in a column whose entries read No protection ... Pending changes protection ... Semi-protection ... Extended confirmed protection ... Template prot. ... Full protection. Let's see... what could that prot. mean? What could it mean?? Oh, I'm so frustrated and confused! But I'm just kidding. Since we have few or no mental defectives making use of the table, I have little doubt all its users will be able to figure it out. Now please stop. You've wasted enough time on this. EEng 22:17, 11 December 2017 (UTC)

I want what's best for this encyclopedia as do most others here, regardless of whether other editors have been here longer or not and have read through more policies or not. My rollback privileges have nothing to do with this debate and making ill conceived threats to have them removed is not going to deter me from having a conversation. I'd prefer to keep this conversation on topic (I'm not scouring your account details and bringing up random unrelated details) and I'll ask that you do too. I do see that you have put a lot of work into this template but as I'm sure you are well aware regardless of the amount of effort, single editors do not own any pages, articles, templates and the like on Wikipedia. Your comments do not alter the fact that that abbreviation is not used elsewhere and as it's not required for space saving on this table, whether policy dictates the removal or not, the abbreviation should not be there. - Vanstrat ⁽⁽🗼⁾⁾ 22:31, 11 December 2017 (UTC)

The logic not needed => should not be there is absurd. The whole table isn't "needed", for that matter -- people could just read the text of the policy on protection and kind of work it out in their heads. The table exists to make things better or easier, and this one, stupid little abbreviation that you're obsessed with is there for the same reason -- not because it's "needed". This has nothing to do with ownership, and everything to do with good sense and taking a global view of the purpose of the table, instead of an obsession with -- yes -- foolish consistency. I won't be responding further unless you have some new argument to offer. EEng 22:41, 11 December 2017 (UTC)

The entire human race is not "needed"... What I'm saying is that nothing breaks and nothing becomes worse if the full word is there... where as if you abbreviate it, it introduces something that has the potential to confuse (whether or not you find it confusing yourself) as that abbreviation is not used elsewhere. Unless you have an argument other than that you don't like it or that it's somehow required to save space, which I have otherwise explained is not the case, I'll be expecting you to keep the full version of the word on the template. As explained, you do not own the template. - Vanstrat ⁽⁽🗼⁾⁾ 22:52, 11 December 2017 (UTC)

It appears I've been pinged here... lol. I'll just state here for the record that the basis for granting (and revoking) rollback is one's demonstrated experience and understanding (or lack thereof) of what is and is not vandalism, and that the rollback button is only to be used for removing blatant vandalism (or your own edits, edits in your own user space, and others). I'd consider revoking rollback from someone if they were repeatedly using the tool in violation of policy and despite being reminded and asked to stop. This is clearly not the case, as Vanstrat left an explanation with his edit here in an edit summary.

I wouldn't revoke anyone's rollback rights because of some apparent confusion with the manual of style guidelines and exactly where they apply (so long as it doesn't involve the inappropriate use of the tool, of course). Back when I was given rollback in 2008 when it first became available, I probably didn't know this either... that doesn't mean that I wasn't fit for having the tool and that I would use it inappropriately... A dispute over an edit regarding whether or not to shorten the word "protection" to "prot." and saying, "Hey, the manual of style says that we should avoid it" is an argument I'd see as completely in good faith (if not an almost-legitimate one). Sure, MOS might have been created and designed only for application in the mainspace, but that doesn't mean that we can't turn to it when trying to make legitimate improvements to the project and in other namespaces. It just means that if there's a dispute, we should talk about it and come to a consensus... :-) ~Oshwah~^{(talk) (contribs)} 00:38, 12 December 2017 (UTC)

Thanks, Oshwah. I never had any doubts about Vanstrat's GF. EEng 00:42, 12 December 2017 (UTC)

EEng - Nah, I didn't think that you did :-). I just mentioned the "good faith" part in order to help draw attention to what's really important in general. I wasn't trying to imply that anyone here had any such thought or belief about the other. ~Oshwah~^{(talk) (contribs)} 02:29, 12 December 2017 (UTC)

Thanks Oshwah! Sorry for bringing you into a random discussion lol

My previous statement remains. For the same reasons that the manual of style states that this should be avoided in the article namespace, it should be avoided here. There's no special reason here for ignoring it, since the abbreviation isn't used elsewhere and one line of space isn't crucial. - Vanstrat ⁽⁽🗼⁾⁾ 02:10, 12 December 2017 (UTC)

Based on this, I have added it back. I have no intention on breaking the 3 revert rule. If you still disagree and undo the edit, I can request a third opinion. - Vanstrat ⁽⁽🗼⁾⁾ 02:21, 12 December 2017 (UTC)

No apologies are warranted here, Vanstrat. I'm always happy to help if I'm needed :-). ~Oshwah~^{(talk) (contribs)} 02:31, 12 December 2017 (UTC)

I see you've finally realized that MOS is only for articles, so that's at least some progress. Beyond that, you keep saying that the abbreviation isn't "crucial", or "necessary", but then (as I've pointed out) nothing in Wikipedia is "necessary", Wikipedia as a whole isn't "necessary", and (as you so helpfully pointed out, not apparently understanding that you were arguing against your own position) even the entire human race isn't "necessary" – and yet we indulge them anyway. So instead of necessity, the question as always comes down to what best serves the reader. You've made no argument along those lines, only repeated your appeal to mindless uniformity.

I've returned the page to its state before your crusade began. If you truly feel this preposterous obsession is worth that much to you, please feel free to get a 3O, but bear in mind that a 3O is simply a way to get fresh ideas that may inform the discussion, not a "tie-breaker". EEng 02:50, 12 December 2017 (UTC)

I have made an argument along those lines.. multiple times. As I've stated: it introduces the potential for misunderstanding when the abbreviation isn't used elsewhere (regardless of whether you understand what it means or not). I see that you aren't a fan of consistency either.. but without an element of consistency in an encyclopedia, things easily turn into mayhem. And yes, third opinions aren't a "final say" but they help us understand which side of the argument other editors agree with, which helps determine consensus.

I have requested the third opinion. For the sake of including all details, to the third party looking at this discussion: there is also a bit of discussion at User talk:Oshwah#Template:Protection table. - Vanstrat ⁽⁽🗼⁾⁾ 03:10, 12 December 2017 (UTC)

Ah yes, the slippery slope argument – if we allow an abbreviation here, soon there will "mayhem"! The idea that anyone won't understand what prot. means is idiotic. Really, you're going to have to do better than that. EEng 03:35, 12 December 2017 (UTC)

And your logic that removing one abbreviation, which adds one line, wrecks all the changes editors "worked hard to make it possible to take the table in at one glance" is definitely no better. I'm willing to wait for a third party on this one. - Vanstrat ⁽⁽🗼⁾⁾ 03:54, 12 December 2017 (UTC)

No, I didn't say anything like that it "wrecks all the changes", merely that it works against the principle that fitting the table on a single screen is important. And in fact the table just barely fits, as it is, on a standard laptop screen at typical settings, so in fact my argument is way, way better, applying as it does to the actually issue at hand and not some hypothetical project-wide "mayhem". EEng 04:08, 12 December 2017 (UTC)

• EEng, per usual, is correct. One line is preferred. TonyBallioni (talk) 04:10, 12 December 2017 (UTC)