Template talk:Protection table

Archives

Archive 1

March 17 2024 reverts

Latest comment: 1 year ago34 comments6 people in discussion

Placement of Office Protection in table and footnote about editing fully protected pages

An editor reverted using the edit summary "what is the point of fiddling with this?" That's obviously a poor reason to give for revert.
To the point, the edits that were reverted

1. Added footnotes to explain that although administrators can edit fully protected pages, policy does not allow them to edit without a consensus on the talk page (i.e. they're not supposed to edit fully protected pages at will).
2. Brought the office protection into the table, since functionally it's the same as full protection.

Unless a reason is provided why those edits are bad, I will re-instate those edits. Up the Walls (talk) 05:49, 17 March 2024 (UTC)Reply

• You need to open a discussion here regarding whether your changes would be advisable before reinstating the changes. I'm not sure you have made a persuasive argument. -- Ssilvers (talk) 15:22, 17 March 2024 (UTC)Reply
• I was about to revert, but Johnuniq beat me to it. This table's primary function is to explain the technical effects of the most common protection levels, and to a lesser extent give nods to where each level is typically meant to be used. It is not meant to be, and cannot be, a compendium of how different protection levels interact with other editing guidelines. For example, while it's true that (as you say in your edit summary here) Although administrators can technically edit a fully protected page ... they're not supposed to abuse that privilege to impose their POV, it's also true that EC editors are not supposed to abuse their ability to edit ECP pages to impose their POV, nor are autoconfirmed editors supposed to abuse that privilege to impose their POV on semiprotected pages, and so on; none of that needs to to repeated in this table. Meanwhile, it's not true that, as you claim in the text you actually added to the table in the same edit, Even administrators are not allowed to edit fully protected page without a consensus on the talk page, because if a BLP violation is found that should be removed without delay.

I've added back Office protection to the table -- see my edit summary [1]. EEng 17:41, 17 March 2024 (UTC)Reply

Point taken, I have adjusted the wording of the footnote. Up the Walls (talk) 18:35, 17 March 2024 (UTC)Reply

Sorry, but when I posted above I'd forgotten that the more obscure protections, including Office, are already listed at the bottom of the table. Given that, there's absolutely no reason to clutter the table proper with that one special case. I've reverted again (keeping one or two useful changes). EEng 04:13, 18 March 2024 (UTC)Reply

I think the office protection belongs in the table because the table is for edit protection, and office protection falls under that. The protections under the table are for other types of protection, not edition (uploading, creating, moving, etc).
It's also not clear why you deleted the revised footnote. Up the Walls (talk) 16:40, 18 March 2024 (UTC)Reply

And just because an office protection is "unusual" does not mean it does not belong in the table. Up the Walls (talk) 15:57, 23 March 2024 (UTC)Reply

And just because you think it does belong does not mean it does. BTW, since I'm the one who added the "other modes" to the table -- the one, in fact, who architected the format and appearance of the table overall (in collaboration with several others, of course) -- I certainly know what the different parts of the table are for. EEng 14:44, 24 March 2024 (UTC)Reply

WP:OWN. Up the Walls (talk) 14:48, 24 March 2024 (UTC)Reply

If you are unable to engage with issues raised by other editors, you will have to stop editing the template and stop commenting here. Your comment is a misunderstanding of what EEng wrote. Regardless of that, talk pages are not available for scoring points. Johnuniq (talk) 10:09, 25 March 2024 (UTC)Reply

Use of Small caps and method for marking up footnotes

Two things: one, what benefit do MOS:SMALLCAPS provide in this instance? They are certainly harder to read, and thus less accessible. Two, my understanding of how {{notelist}} works is we can use the |group= parameter to show only specific references in a specific {{notelist}}. So we can use something like {{efn|group=protection-table-note}} combined with {{notelist|group=protection-table-note}} to achieve the desired result and not mess with the notes on the rest of the page. HouseBlaster (talk · he/him) 18:53, 17 March 2024 (UTC)Reply

The small caps visually tie together the telegraphic statements of can/cannot edit, allowing red-green colorblind readers to see immediately the patterns in the table. So you see, it's actually an accessibility enhancement.

You're absolutely right about group=, but an asterisk is nonetheless more eyecatching, especially when there's only one note. EEng 03:58, 18 March 2024 (UTC)Reply

There's two notes :)

And if we are going for a font difference, I think it would be best to use small caps for one and normal text for the other, no? HouseBlaster (talk · he/him) 04:07, 18 March 2024 (UTC)Reply

There's only one note now. I'm not looking for a font difference between the two cases (can/cannot edit) but rather font unity among the two cases, yet with distinction from the more narrative information elsewhere on the page. Look, I'd be more sympathetic to this accessibility argument if these entries were more than two words each. But they're not. You can't possibly be suggesting someone's going to get eyestrain, or be confused, because two words are sans serif. EEng 04:16, 18 March 2024 (UTC)Reply

I don't think people are going to get eyestrain, but I do think there are better ways to convey emphasis (e.g. bolding). HouseBlaster (talk · he/him) 05:05, 18 March 2024 (UTC)Reply

It's not emphasis, it's commonality. EEng 10:05, 18 March 2024 (UTC)Reply

Is there a reason we can't use something a little more legible for commonality? HouseBlaster (talk · he/him) 17:41, 18 March 2024 (UTC)Reply

I don't have a preference one way or the other, but just curious: "commonality" with what? Where does it say that we need to use small caps? Up the Walls (talk) 17:56, 18 March 2024 (UTC)Reply

The commonality is what I already explained: font unity among the two cases (can edit / cannot edit), yet with distinction from the more narrative information elsewhere on the page. EEng 20:51, 18 March 2024 (UTC)Reply

How does (can edit / cannot edit) have any more "commonality" than (Can edit / Cannot edit)? Up the Walls (talk) 21:38, 18 March 2024 (UTC)Reply

Because there's other stuff in the table in the normal font. Small caps sets the (can edit / cannot edit) entries off as related to one another. EEng 04:37, 19 March 2024 (UTC)Reply

Would using bolding be acceptable to you? It really is more annoying to read something in small caps, and I don't see why bolding would not have the same effect. HouseBlaster (talk · he/him) 04:43, 19 March 2024 (UTC)Reply

The table already uses bold for bold's usual purpose -- emphasis -- and your suggestion would negate that. We've spent a huge amount of time on your preoccupation with small caps and it's getting more than tiresome. EEng 13:50, 19 March 2024 (UTC)Reply

I am trying to find a compromise. Small caps are not accessible, and I care about accessibility. HouseBlaster (talk · he/him) 19:00, 19 March 2024 (UTC)Reply

^{[citation needed]} EEng 19:50, 19 March 2024 (UTC)Reply

See, e.g. this from Stanford or this from Harvard. HouseBlaster (talk · he/him) 21:24, 19 March 2024 (UTC)Reply

And if we were talking about content for a Harvard or Stanford website, those might have some value. As a counterpoint, I offer [2] ("Myth 2: All caps are not accessible") and, of course, [3]. EEng 12:58, 20 March 2024 (UTC)Reply

The APA says It is true that presenting text in all caps will slow down all readers, especially those with certain types of visual and/or cognitive impairments, and what is good for the sauce (Stanford and Harvard) is good for the gander (Wikipedia). I am going to request a third opinion, because it is clear we are not going to convince one another. HouseBlaster (talk · he/him) 19:16, 20 March 2024 (UTC)Reply

(a) But what APA also says is that it's not an accessibility problem. Big words slow down reading too, but we don't go around turning everything into Basic English. (b) The expression is "What's sauce for the goose is sauce for the gander". (c) You need to look it up, since you obviously have no idea what it means. (d) You've got your third opinion (below), so can we stop now? EEng 03:52, 21 March 2024 (UTC)Reply

What's good for the goose is good for the gander is an alternative saying, no less valid than the sauce. In any event, please avoid comments on the person. Happy with the compromise. HouseBlaster (talk · he/him) 04:20, 21 March 2024 (UTC)Reply

No doubt What's good for the goose is good for the gander is a fine alternative. But what you wrote is What's good for the sauce is good for the gander, which makes no sense at all. Glad we're done, after only several days of pointless discussion. EEng 15:06, 21 March 2024 (UTC)Reply

• The text in question is acting functionally as a label identifying a category of allowed behaviour for a given intersection of characteristics. That plus its brevity allows for stylistic concerns beyond maximal legibility to be accommodated. As discussed in the All caps article, increasing the tracking would improve legibility. I also think starting each label with a full-height capital letter would add a bit more variation, giving the label a bit more prominence from its surrounding text.isaacl (talk) 22:19, 20 March 2024 (UTC)Reply

  Finally a voice of sanity. I changed each label to begin with a full-height honest-to-god cap like you suggested, and it looks good. I don't know how to increase the tracking. EEng 03:52, 21 March 2024 (UTC)Reply

  Note I'm not sure I actually favour using all caps, but its legibility can be managed when used for a few words. The link I provided gave instructions on how to increase the letter spacing. I put an example in the sandbox. isaacl (talk) 18:19, 21 March 2024 (UTC)Reply

Protected

Latest comment: 1 year ago2 comments2 people in discussion

To avoid the minor edit war, I have fully protected the template for a month. When consensus is demonstrated, ask me or any admin to restore the previous indefinite semi-protection. @Up the Walls: You want to change the template. Therefore it is up to you to get agreement on this talk page. If there is objection, you need to demonstrate a consensus supporting your preferred version before changing it again. Leaving nonsense templates such as at User talk:EEng#March 2023 is not a substitute. Johnuniq (talk) 01:46, 24 March 2024 (UTC)Reply

The Protection table has been protected. I can die happy now. EEng 01:53, 24 March 2024 (UTC)Reply

Cascade-protected description

Latest comment: 10 days ago16 comments4 people in discussion

Green Montanan alright, we can't keep reverting each other. I'm opening this section to get other people's views. To summarise:

This is Green Montanan's preferred version

Level Unregistered or newly registered Confirmed or autoconfirmed Extended confirmed Template editor [α] Admin Interface admin [β] Appropriate for (See also: WP:Protection policy) [...] [...] [...] [...] [...] [...] [...] [...]  Full Cannot edit Noncontroversial editing and editing authorized via consensus on talk page Pages with persistent disruption from extended confirmed accounts.  Office Cannot edit Can edit with approval from the Wikimedia Foundation Pages that the Foundation has determined to be exceptionally sensitive.  Cascade[γ] Cannot edit Normal editing[δ] Particularly visible pages, such as the Main Page, to prevent vandalism.  Interface Cannot edit Normal editing Scripts, stylesheets, and similar objects fundamental to operation of the site or that are in other editors' user spaces. [...] [...] [...] [...] [...] [...] [...] [...]

From their most recent undo:

The reason for making simplifying assumptions is to simplify the table, with the exceptions noted in footnotes. This particular exception, cascading of pages with interface protection, simply does not exist, meaning that explicitly incoporating the exception into the table is not justified.

This is FaviFake's preferred version

Level Unregistered or newly registered Confirmed or autoconfirmed Extended confirmed Template editor [ε] Admin Interface admin [ζ] Appropriate for (See also: WP:Protection policy) [...] [...] [...] [...] [...] [...] [...] [...]  Full Cannot edit Noncontroversial editing and editing authorized via consensus on talk page Pages with persistent disruption from extended confirmed accounts.  Office Cannot edit Can edit with approval from the Wikimedia Foundation Pages that the Foundation has determined to be exceptionally sensitive.  Cascade[η] Cannot edit Depends on protection level[θ] Normal editing[ι] Particularly visible pages, such as the Main Page, to prevent vandalism.  Interface Cannot edit Normal editing Scripts, stylesheets, and similar objects fundamental to operation of the site or that are in other editors' user spaces. [...] [...] [...] [...] [...] [...] [...] [...]

My most recend undo:

I've been thinking about this for a long time and I've come to the conclusion that this cell is needed. White the table makes assumptions about community practices, such as the requests for the "template editor" flag or the RfA, this case is different because this isn't a community norm but rather a normal thing that can happen in normal circumstances. There are no standard processes that effectively prevent interface pages to be cascade-protected. Also, without this, it looks identical to FULL.

So, could someone chime in and help us reach a consensus? It seems clear we both care about the table. FaviFake (talk) 20:30, 15 August 2025 (UTC)Reply

Notifying main contributors: @Oshwah @The Mountain of Eden @EEng @Up the Walls @Hello71 @Yaris678 @RobLa. FaviFake (talk) 21:25, 15 August 2025 (UTC)Reply

Thank you for the notification. I haven't edited this page for a long time, but I am happy to give my view. That said, I think I need to clarify something first. Favi, is your assertion that footnote ζ (footnote δ in the snippet of Green Mountain's preferred version) is insufficient? Is it that "almost never the case in practice" is untrue? Something else?

Yaris678 (talk) 01:33, 16 August 2025 (UTC)Reply

Clarification: within the template itself, the two versions use the same footnote symbol scheme, with footnote ζ slightly reworded in the two versions (the differences in the footnote symbol is an artifact of the copy and paste into this talk page).

The question is: should the green rectable in the current version of the template (my preferred version) in the cascade protection row be split into two? (FaviFake's preferred version): a yellow square for regular administrators and a green square for interface administrators.

The slightly different wording for footnote ζ is to accommodate the different construction of the table. —Green Montanan (talk) 01:50, 16 August 2025 (UTC)Reply

The wording of the footnote is not in dispute. If the consensus is to go along with FaviFake's preferred version, then we would use the version of his footnote, as it would make sense for his construction of the table. —Green Montanan (talk) 01:56, 16 August 2025 (UTC)Reply

The differences in the text of the footnote are inconsequential. —Green Montanan (talk) 01:58, 16 August 2025 (UTC)Reply

There are changes that I'd make to this table that are outside of the differences between the versions listed above, and my thoughts regarding the "cascade-protection" colors are also different than the both of them. I'll explain my thoughts and then provide a table with my proposed changes in a separate discussion below. For the record, I prefer Green Montanan's proposed table change, since cascading Interface admin protection has never been used. Hence, there's no point of even talking about it. ~Oshwah~^{(talk) (contribs)} 08:45, 16 August 2025 (UTC)Reply

I think Green Montanan is missing my point. Whether to use the yellow rectangle on the cascade row of the table is the main question here, but I want to know why Favi thinks this extra rectangle is useful. There are other places where we simplify the table by using a footnote. Green Montanan's version does that in relation to cascade protection. All else being equal, simple is good. So what is Favi's concern with the simplification? Yaris678 (talk) 12:02, 16 August 2025 (UTC)Reply

Everything below is incorrect! See Oshwah's comment in the next section. Striked 00:02, 17 August 2025 (UTC)

Yes, that is the main focus of this discussion. There are a few reasons why I believe another cell to be needed, some of which are quoted in the edit summary in my first message on this topic:

1. To distinguish it from the office and full protections. It is a more powerful level of protection. While full and office at their "max settings" only protect one page and are unable to prevent admins from editing it, cascade can also be applied to interface-protected pages and can apply to more than one page.
2. While there are indeed other places where we simplify the table with a footnote, these cases are set in stone and cannot be bypassed. One can't just become a template editor without being confirmed, there's no way an admin will let them. On the other end, cascade protection can easily be applied to interface-protected pages without any due processes preventing it.
3. While there aren't any pages both interface- and cascade-protected right now, it could technically happen at any moment and the table wold be wrong.

I don't think this is an exception; rather, I'd consider it a rare process that can happen and that should be mentioned in the table beyond a footnote contradicting it own green color.

Oshwah I agree with @Green Montanan on the footnote. The only reason I changed it was to accomodate the new color and wording; I do not mind changes to it. FaviFake (talk) 22:47, 16 August 2025 (UTC)Reply

Your point #3 is the very reason why there shouldn't be a separate square for the non-existent case, and the non-existent case should only be dealt with in a footnote should the case ever come into existence.

But I like (what sounds like) @Oshwah is proposing: take the cascade protection out of the table and put it back as a note under the table (the way it used to be up until a couple of weeks ago). That would eliminate the question regarding need to have a separate square for regular administrators vs. interface administrators. —Green Montanan (talk) 22:56, 16 August 2025 (UTC)Reply

OK. I am not really convinced by Favi's reasons. I would be inclined to go with Green Montanan's version... but... I actually like the idea of cascading protection not appearing in the table. Perhaps more controversially, I actually think we should remove office, create, move and upload protections from the table too. I think theses are all special types of protection that can be at different levels and the interesting thing is the way in which they are special, not the levels, so I think just describe what each one does in the text, without them being in the tables. Yaris678 (talk) 23:33, 16 August 2025 (UTC)Reply

I think the idea for the table is to be as comprehensive as possible. I would actually agree with you regarding the removal of the move/create/upload protections if the protection/no protection was obvious (cannot move/create/upload vs. can move/create/upload). However, it's not obvious: new and unregistered users are not able to move/create/upload even when not protected, and I think the footnote detailing the history of how the priviledge to create was taken away from new and unregistered users is useful. If anyone knows the history of how the priviledge to upload and move was taken away from new and unregistered users, I hope they will add that as footnotes as well. —Green Montanan (talk) 23:41, 16 August 2025 (UTC)Reply

And although the office protection and the full protection are technically the same type of protection, they are treated differently, which is why I think they should be listed as two separate entries in the table. —Green Montanan (talk) 23:46, 16 August 2025 (UTC)Reply

Hi I'm back! I intended to strike this comment as soon as i read oshwah's message below. My entire understanding of cascade protection is wrong!

1. "cascade can also be applied to interface-protected pages". Actually it can't! So that's just wrong. See oshwah's comment #7
2. "cascade protection can easily be applied to interface-protected pages without any due processes preventing it.", nope, it cannot.
3. "while there aren't any pages both interface- and cascade-protected right now, it could technically happen at any moment", again, that can't technically happen.

So Yaris678 you're right, you shouldn't be convinced! However, I do think cascade should remain in the table and it should look like it does in Oshwah's example below. I really do not like removing any other protection from the table because I see no benefit in doing that. I think the table should include all protections and it's unlikely that a few sentences are easier to parse than a table, especially sinc ethe protections have so many configurations. FaviFake (talk) 00:00, 17 August 2025 (UTC)Reply

OK. Great. It looks like the disagreement that this thread was about has been resolved. I may or may not think a bit more about whether removing (or perhaps combining?!?) some rows makes sense, but if I do have any thoughts on that worth expressing I will do it in a separate thread. Yaris678 (talk) 14:06, 17 August 2025 (UTC)Reply

I encourage you to look at the thread below, because @Oshwah has made additional proposals (some of which have already been incorporated). —Green Montanan (talk) 15:02, 17 August 2025 (UTC)Reply

Proposed table changes by Oshwah

Latest comment: 10 days ago9 comments3 people in discussion

Hi everyone! The discussion above prompted me to review the protection table as a whole, and I think there are changes that can (and should) be made in order to 1) make the table simpler and easier to read, 2) reduce or remove confusion by not mentioning unused or rarely practiced protection levels and situations that account for maybe 0.01% of accounts that are in the relevant protection level, and 3) keep the table focused on its primary purpose, which is to matrix what user levels can and cannot edit a page given its protection level.

Here is a list of some of the changes I proposed (and are present in the table below), and why I believe the changes are important or should be made:

1. The note with the further explanation regarding the interface administrator user rights doesn't need to be there at all and should be removed. What the note currently states on both tables above is both unnecessary and incorrect. Being an interface administrator while also being an administrator is not "almost always the case in practice"; it is always the case on the English Wikipedia. Minus one bot account, being an administrator is a requirement for being granted the interface administrator permissions, which is clearly stated on the relevant page. With that fact in mind, the note is completely unnecessary, only adds confusion, and yields no benefit with being there.
2. Change the "Admin" column title to be "Administrator" instead. It doesn't change the width of the column, and it aligns with the other column titles that use the full name (except for "interface admin").
3. Change the "Unregistered or newly registered" column title to be "Unregistered users or new accounts" instead. The change uses the proper name for both levels and reads as more complete short description.
4. Change the "Confirmed or autoconfirmed" column title to be "Confirmed accounts" instead (move the "autoconfirmed" portion into a note if users really believe that it absolutely must stay). Again, this reads as more of a complete description, and I personally believe that the separation of terms that we use ("autoconfirmed" and "confirmed") is quite silly, completely unnecessary, and just adds questions and confusion to new and novice users that wouldn't exist at all if we were to just stop doing that. Accounts are actually marked as being "Confirmed"; there's just an automated process that does this automatically when they reach the required threshold. This is the exact same case when it comes to the Extended confirmed user level, but we don't differentiate it into two different terms and call it "Autoextended confirmed" and "Extended confirmed". Why not? There's an automated process in place for the rights like with Confirmed, so we should do the same here, right? No? Why not? Because it sounds silly and unnecessary to you to do that? ;-) My point here is that we should be consistent; either change the "Extended confirmed" column to add "Autoextended confirmed", or remove "Autoconfirmed" from the other. My vote is for the later.
5. The note with the further explanations with the template editor user right can be much shorter and to-the-point. Take out the "which is always the case except for bots part" and leave only the direct assumptive statement, "This table assumes that template editors are also extended confirmed users". It's more direct and doesn't add any "except for this and that" statements that complicate the whole thing. If an assumption is almost always the case (I'm quite certain that it is always the case), then why talk about the situations that account for 0.01% of accounts that are template editors? Also, we should stop talking about bot accounts on this table and in any of the notes. This table matrix is about accounts used by humans; we don't care about bots here. Stop thinking about bots - right now. Stop it. Don't think about bot accounts. Also the game. :-P
6. Change the description in the columns for admins and interface admins on the Full protection row to state "Can edit" and then move any important details into a note. This is the main point of this table: Can you edit the page with this protection level or not? Yes or no? If we include that in the main table instead of a side note, we start creeping into "situation territory" - which is partially what causes this table to become a mess regarding what should be included and stated, and where. If we try our best to stick to "yes or no" on the table itself where possible, it becomes easier to read and the reason the table exists becomes easier for readers to understand.
7. Both notes that are in the cascade protection row are unnecessary, unfeasible and incorrect (if not impossible), and can be removed. The interface protection level isn't actually a protection level like the others that are listed here. It's simply a protection that's automatically set by the MediaWiki software and to the pages described on the interface protection level and interface administrator pages. It is not a protection level that an administrator can manually apply to any page, nor is it a protection level that can be modified on pages currently under interface protection. Because of this, administrators cannot set a "cascading protection level" to a page that's under interface protection because it's a protection level that does not exist. The only way that it could exist is if it were set as part of a change to the MediaWiki software. Why are we mentioning situations that are completely minute and talking about protection levels that don't exist, are never used, or that can't even ever be set? This, like the proposed change I discussed above with the "full protection" row, is partially what causes this table to become a mess and why so many changes to it have been made.

There are other small changes that I'd make as well, but the main points I wanted to touch on are what I discussed in detail above. Anyways, without further to do, here are the changes that I believe should be made to the protection table, and what I'd personally do if I were "tasked" with improving it as much as possible.

Oshwah's proposed changes to the protection table

Interaction of Wikipedia user groups and page protection levels Function Level Unregistered users and new accounts Confirmed accounts [notes 1] Extended confirmed Template editor [notes 2] Administrator Interface admin Appropriate for (See also: WP:Protection policy) Editing No protection Normal editing The vast majority of pages.  Pending changes Can edit Any changes saved will be marked as "pending changes" until reviewed and approved by a pending changes reviewer or administrator. Can edit Changes are immediately visible to everyone unless there are any pending changes currently awaiting review. Otherwise, any changes saved will be marked as "pending changes" until reviewed and approved by a pending changes reviewer or administrator. Can edit If there are any unreviewed pending changes, they will be required to review them before they can edit. Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users.  Semi Cannot edit Normal editing Pages that have been persistently vandalized by anonymous and newly registered users. Some highly visible templates and modules.  Extended confirmed Cannot edit Normal editing[notes 3] Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive.  Template Cannot edit Normal editing High-risk or very-frequently used templates and modules. Some high-risk pages outside of template space.  Full Cannot edit Can edit[notes 4] Pages with persistent disruption from extended confirmed accounts.  Office Cannot edit Can edit[notes 5] Pages that the Foundation has determined to be exceptionally sensitive.  Cascade Cannot edit Normal editing Particularly visible pages, such as the Main Page, to prevent vandalism.  Interface Cannot edit Normal editing Scripts, stylesheets, and similar objects fundamental to operation of the site or that are in other editors' user spaces. Page creation No protection Cannot create[notes 6][notes 7] Can create The vast majority of page titles.  Create Cannot create[notes 7] Depends on protection level Can create Pages that have been repeatedly and problematically re-created. This form of protection is often called "salting". Page move No protection Cannot move Can move The vast majority of pages.  Move Cannot move Depends on protection level Can move Pages that have been the subject of move wars. Upload files No protection Cannot upload Can upload The vast majority of file names.  Upload Cannot upload Depends on protection level Can upload Files that have been repeatedly uploaded after deletion Notes: This includes accounts that are autoconfirmed. This table assumes that template editors are also extended confirmed users. Restrictions are typically spelled out in edit notices. Only noncontroversial changes or requested changes following an achieved consensus should be performed. Only after receiving approval from the Wikimedia Foundation. This has been in effect for unregistered users since 5 December 2005. The restriction was extended to newly registered users on a six month trial basis starting on 14 September 2017. The extension became permanent on 18 April 2018. Under the default no protection, unregistered and newly registered users can create talk pages in all namespaces and draft articles in the Draft namespace. For these namespaces, it would therefore be possible for the creation protection to only apply to unregistered and newly registered users

Please note that I changed all of the notes in the table from using the efn-lg template to be plain ref tags in a different group so that they don't get mixed in with the notes added to the two proposed table changes in the discussion above this one. Please feel free to respond with any comments, suggestions, issues, concerns, complaints, or other thoughts that you have. I'd like to hear about the things you like, don't like, or have other opinions or thoughts about. Thanks for taking the time to read through this discussion I started, and I wish you happy editing. :-) ~Oshwah~^{(talk) (contribs)} 08:47, 16 August 2025 (UTC)Reply

I like most of your changes.

For Item #7, you propose removing the cascade protection from the table, yet in your draft table you have it in the table. Note that the cascade protection level used to be mentioned beneath the table in this version before being incorporated into the table in this edit. However, your sample table still shows the cascade protection in the table. Perhaps we should go back to placing it as a note under the table the way it used to be until a couple of weeks ago? The added benefit of moving the cascade protection out of the table and to a note under the table, would make the differences between my preferred version vs. FaviFake's preferred version discussed in the section above a moot point.

Regarding item #5:

• I think if exceptions exist, no matter how rare, should be documented in a footnote.
• In line with the previous point, bots are only mentioned in the footnote about template editors being extended confirmed in that there are many bot accounts that do not obey the rule of template editors also being extended autoconfirmed.

Changes not mentioned in your discussion:

• Why did you remove the note "Protection may be applied to neither, either, or both groups" from the entries for create protection, move protection, and upload protection? perhaps the note should be moved down to a footnote, but I don't think it should be eliminated.
• I don't understand why you edited the text in the pending changes row to take out who can see the edits.

Thank you for putting all that thought into improving the table. —Green Montanan (talk) 14:53, 16 August 2025 (UTC)Reply

(edit conflict) Green Montanan - Thanks for the response and for all of your input and feedback here! Okay, I'll go through your responses and explain my thoughts - and hey, let's talk about them! If more editors would like to join in on the discussion, by all means - please do! :-)

• Regarding item #7: The removal that I detailed there was only meant to apply to the notes on the cascase-protection row, not the entire row. I was going between your proposed changes and some others while putting together that table draft, which is why you'll see on the page history that I went back and fixed a few things that I talked about but didn't actually implement into the draft. That should be fixed now. I agree and believe that the cascading protection level should be a row within the table, since unfamiliar users may reference it to figure it where it applies and how it involves their accounts directly. One note on the cascade-protection row was left in the draft on purpose because I thought it might be useful (I had removed the portion of the note that mentioned "interface cascading protection"), but after reading through it again - I don't think it really needs to be there... does it? Here is the diff where I removed the note from the row. Let me know if my response here doesn't fully clear everything up and I'll be happy to explain my thoughts and intentions. I took out (or shortened down) most of the notes because I think that they start getting into the "this situation, but then that, but then this" territory. If readers want a deep-drive level of understanding about a protection level and the different situations that can apply, and how this situation can cause certain events, they can find this within the content of the article. Much of these notes - in whole - add very unnecessary complexity to the table and discuss things that are much better detailed in the article, not the table.
• Regarding item #5: I'm completely open to discussing that further and I'd like to know more about what you suggest, but hear me out first! ;-) I absolutely see your point and why you (and likely a number of others as well) feel that if a situation exists, even if extremely rare, it should at least be mentioned in the notes with the table somewhere. Something I want to mention is the comment that's on the current revision of this table (located next to the template protection column definition). It states, "There are other cases that could be mentioned (e.g. a Template editor needs to be confirmed/autoconfirmed, or an admin, in order to edit through semiprotection) but they're just too esoteric." Allow me to "play Devil's advocate" for a moment (I'm just sharing my thoughts in a light-hearted, fun, and silly manner): "So you're telling me that we should document all possible situations - regardless of how rare they are and while acknowledging the fact that some of them won't apply to anyone who views this table, but we don't want to document THEEEESE situations over here because those are TOO, TOO rare?" Okay, "Devil's advocate" is over now. :-) A few simple questions that should be asked and then answered using only one sentence are: "what is the primary purpose of this table?", or "what is this table created and designed to provide to those who read it?" I think once these answers are established, we'll have a much easier time agreeing on what should be included, what can stay out, what we (and those who read the table) care about, and what we don't. Anyways, this is was what was going through my mind when I went through everything, reviewed the current table, read through the talk page discussions, and when designing the draft version I proposed above. ;-)
• Regarding the changes I made to the create, upload, and move protection entries: I changed all of that text to instead simply state that it "depends on the protection level". It conveys the exact same information but in a shorter and more-concise message. It also makes the table more simple to scan through and quickly review. When I think about why most readers would stop and look through this protection table, I can think of a few reasons: To quickly understand how a certain protection level applies to them, to see a quick and simple summary of the protection levels and which user group levels they affect, or because they are "visual learners" and gain a better overall understanding of things when they also see them in a visual form in addition to reading them in text form (oh and hey, I think this might just fit in with those two questions that I mentioned above! What do you think?). I thought that simplifying those rows would help achieve this. What thoughts came to mind when you saw those changes? It sounds like you might not agree with them, so I'm curious to know more about that.
• Regarding the changes I made to the pending changes protection entries: My thought was that the wording should be changed to reflect a consistent use of terms throughout each column in the row. I took out the notes because, like with many of the other notes that I removed, I think that they start getting into the "this situation, but then that, but then this" territory. If readers want a deep-drive level of understanding about a protection level and the different situations that can apply, they can find this by reading through the content within the article. It doesn't need to be on the table, does it?

Thanks again for looking through the draft table that I created and for reading through all of my thoughts and explanations for making the changes that I did. I'm looking forward to reading your responses to the answers that I provided above, as well as any other thoughts, input, questions, or other things that you might have on your mind with this table. :-) Cheers - ~Oshwah~^{(talk) (contribs)} 00:36, 17 August 2025 (UTC)Reply

1. I weakly oppose #1, but I definitely think it should be reworded, by stating it is a requirement and only 1 bot account isn't an admin. E.g., Interface administators are required to be admins and almost all Interface administators accounts are." (this is a really bad way to phrase it, it's just an example)
2. Oppose, but only because (at least on my end) it indeed changes the width of the column by a non-trivial amount. Also, this would mean that we would need to change the "Interface admin" label too. I do not like calling it "admin" but I don't see a better way.
3. Support
4. Support changing it but I think that, in the name of consistency, we should also remove the word "account" and only leave "Confirmed". In your example, for the Extended confirmed user level we don't call it "Extended confirmed accounts". I support not adding a note specifying it is almost always granted automatically. Also weakly oppose using a footnote, since virtually all confirmed accounts are automatically confirmed.
5. Oppose removing the link and "almost always" part from the footnote, but I would support rewriting it as "Template editors are almost always also extended confirmed privileges." to make it shorter.
6. Support placing everything in footnotes.
7. Weakly oppose removing the 1st footnote (it doesn't seem to be inaccurate, it might just need a cleanup. Interface-protected pages can indeed be transluded into a cascade protected page if i'm not mistaken again) and fully support everything else. I wrote the incorrect info thinking that was the case. I think we should also add what you said (interface can't be manually applied, is decided by mediawiki, etc.) in a new footnote for the interface row. Otherwise it looks like any other protection level and confuses people like me. Far less important details are mentioned in other footnotes.

Other changes:

1. I oppose removing the footnotes from the pending changes protection and generally oppose the changes to its explanations, mainly because they are longer and also convey less information (i.e., about who can see the changes).
2. Support the rephrasing of the (Admin/Pending changes) cell.
3. Weakly oppose the new color for the (Extended/Pending changes) cell because it complicates the table. Also, it could also be applied to other cells, such as the (Admin/Office) cell.
4. Oppose the replacement for "Protection may be applied to neither, either, or both groups" because I do not think your version is as clear as the current one; still, there might be better ways to explain it.

@Green Montanan, I think you may have misread #7. If i'm not mistaken, he's advocating for the removal of the two footnotes in the row and not of the entire row itself. However, he did keep a footnote he said he would like removed in his example so there is an inconsistency. I'm not sure why you suggested removing the entire row from the table. I see no benefit in doing that.

That was really thoughtful, thanks for caring about the table so much. Pelase feel free to try to convice me to support changes you haven't explained if I've opposed them. FaviFake (talk) 23:48, 16 August 2025 (UTC)Reply

The advocacy for the removal of the footnoes is the first sentence in item #7 of Oshwah's post. In the next sentence, they write: "The interface protection level isn't actually a protection level like the others that are listed here".

I could be wrong, but to me, that sounds like an advocacy to remove the entry from the table. —Green Montanan (talk) 23:57, 16 August 2025 (UTC)Reply

Yes. In your previous comment, you said (emphasis mine) For Item #7, you propose removing the cascade protection from the table, yet in your draft table you have it in the table. [...] However, your sample table still shows the cascade protection in the table. I was responding to that. (Also note that he mainly said "[it] isn't [...] like the others that are listed here".) Fwiw, I think interface should also be kept as it protects a page from edits that aren't from a certain group of users. FaviFake (talk) 00:13, 17 August 2025 (UTC)Reply

(edit conflict) FaviFake is correct in that I was referring only to the notes on the cascading protection level row, not the entire row itself. Here is a clarification of the statements I made about the interface protection level earlier: Okay, If I were to go to any typical page and apply a protection level to it, "interface protection" is not an option that is listed that I can use. It is not available for general use like the other protection levels are. Hence, yes - the interface protection level isn't actually a protection level like the others. It's hard-coded into the MediaWiki software that this protection level is applied only to the locations stated on the policy page: pages in the MediaWiki namespace, system-wide CSS and JavaScript pages, and personal CSS and JavaScript pages of other user accounts. In addition, if I go to a page that is currently under interface administrator protection and attempt to modify the page's protection level, it takes me to the page protection function just like any other page, but it shows that no protection level is currently set at all. Hence, I cannot apply cascade protection to the interface protected page unless I fully protect it first, which would serve no purpose or do anything at all. Because I also can't set any page to the interface protection level (and hence can't cascade it with that option), "cascading interface protection" isn't a function that exists. That's why I advocated for the removal of those notes, because they detailed a protection level that doesn't exist. :-) ~Oshwah~^{(talk) (contribs)} 00:56, 17 August 2025 (UTC)Reply

@Oshwah, Regarding the hidden text: I tried to remove it, but was reverted. In my opinion, the footnote covering template editors must also be extended confirmed covers the cases envisioned in the hidden text. I didn't edit-war over this, because it's pointless to edit-war over hidden text.
Regarding "protection level" for the create/move/upload protections: For editing, protections have different levels that are displayed as different entries in the table. Given this situation, I think it gets confusing to talk about "protection level" for the create/move/upload protections. —Green Montanan (talk) 00:51, 17 August 2025 (UTC)Reply

Agree with Green on the create/move/upload protections wording. As I said in my message above, I do not think your version is as clear as the current one; however, there might be better ways to explain it or display it. FaviFake (talk) 15:35, 17 August 2025 (UTC)Reply

Stealth revert

Latest comment: 10 days ago3 comments2 people in discussion

@Oshwah, in this edit you reverted my copyedit w/o declaring it in your edit summary. Was it an accidental revert? or deliberate?
The copyedity was intended to take out the ambiguity in the word "they", since the word seems to revert to the pending changes. —Green Montanan (talk) 05:10, 17 August 2025 (UTC)Reply

Green Montanan - Aww crap... How the hell did I manage to do that without noticing? Weird... Anyways, you are indeed correct; that was completely unintentional. I'm resolving this now as we speak. Stand by... ~Oshwah~^{(talk) (contribs)} 07:22, 17 August 2025 (UTC)Reply

Green Montanan -   Fixed. Sorry about that! Thanks for pinging me and let me know about it. ~Oshwah~^{(talk) (contribs)} 07:23, 17 August 2025 (UTC)Reply

Cite error: There are <ref group=lower-greek> tags on this page, but the references will not show without a {{reflist|group=lower-greek}} template (see the help page).