Template talk:Protection table

Semi-protected edit request on 26 May 2023

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

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)

Semi-protected edit request on 13 June 2023

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)

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

March 17 2024 reverts

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)

• 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)
• 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)

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

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

EEng 19:50, 19 March 2024 (UTC)

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

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)

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)

(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)

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)

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)

• 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)

  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)

  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)

Protected

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)

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