Template talk:Protection table

Archives

Archive 1

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

119.158.58.205 (talk) 12:53, 26 May 2023 (UTC)[reply]

Niazi Family Tribe Tree

 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 a reliable source if appropriate. Aidan9382 _(talk) 13:03, 26 May 2023 (UTC)[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

June 12th, 2023 Jokic became a father to his second child, Jimmy Butler. 2600:1700:4C00:29E0:406:3C0B:410F:E7F9 (talk) 13:23, 13 June 2023 (UTC)[reply]

 Not done: please provide reliable sources that support the change you want to be made. — Paper9oll (🔔 • 📝) 14:38, 13 June 2023 (UTC)[reply]

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]

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]