MediaWiki talk:Siterawhtmlprotected
Appearance
Protected edit request on 21 December 2019
[edit]![]() | This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
There are additional MediaWiki pages not editable by admins apart from site css, js and json pages. These raw HTML pages show this message to users with insufficient permission. To unify this with the rest of the messages of its type, create the subject page of this talkpage with
{{protected interface|$1|type=interface}}
– Ammarpad (talk) 19:38, 21 December 2019 (UTC)
On hold @Ammarpad: can you give an example of a page where you are seeing this message? — xaosflux Talk 17:11, 23 December 2019 (UTC)
- I'm not Ammarpad, but https://wiki.riteme.site/wiki/MediaWiki:Copyright?action=edit (when viewed by a non-interface-admin) appears to work. * Pppery * it has begun... 18:14, 23 December 2019 (UTC)
- I made the patch that added the messages, that is how I came to know about them. Example by Pppery above is correct, there are more though. – Ammarpad (talk) 18:50, 23 December 2019 (UTC)
- I'm not Ammarpad, but https://wiki.riteme.site/wiki/MediaWiki:Copyright?action=edit (when viewed by a non-interface-admin) appears to work. * Pppery * it has begun... 18:14, 23 December 2019 (UTC)
On hold the proposed message seems to be losing some key information that is available in the default message, "because it contains raw HTML which can be modified to affect all visitors" - without that information administrations may be confused about why they can't edit this page as it's content model isn't something they would normally be expected to not be able to edit. Can that template be expanded to support some other variable that will present this reasoning first? — xaosflux Talk 19:22, 23 December 2019 (UTC)
- @Ammarpad and Pppery: — xaosflux Talk 19:23, 23 December 2019 (UTC)
- @Xaosflux: You don't need to modify that template. Even Common.js/Common.css are using it as is, the additional explanation is then handled with editnotice (cf. Template:Editnotices/Page/MediaWiki:Common.js). So that's what should be done here. I will track down the affected pages and create the notices, maybe tomorrow, if someone has not gotten to do it. – Ammarpad (talk) 20:43, 23 December 2019 (UTC)
- @Ammarpad: commons.js is a contenttype js page, so it is obvious why interface admins are needed. Also, the default messaging already says why pages like MediaWiki:Copyright aren't editable (by virtue of being rawhtml enabled) - this should certainly not require manual edit notices when the software already provides for calling this out when needed. I'm just saying we shouldn't obscure that, and it should be automatic. — xaosflux Talk 21:28, 23 December 2019 (UTC)
- The software also already explains clearly why common.js is not editable, but nonetheless the message was overriden on enwiki with template and editnotice. So I don't agree with your argument. Also just above you said "
administrations may be confused about why they can't edit this page as it's content model isn't something they would normally be expected to not be able to edit.
" and the current message is exactly what would lead to that confusion, more than if the page is common.js/css and the like which gives clear clue from their title and content. These raw HTML messages in contrast have no distinguishing clue in their title nor in their content. They are just normal MediaWiki pages as the restriction is purely enforced in backend. – Ammarpad (talk) 21:50, 23 December 2019 (UTC) - Right, so admins can normally edit "normal mediawiki" pages. Normal admins can also easily tell what the contentmodel for a page is, and have been informed about things like interface protection. These pages have a special backend protection, which is explained by the default message with a very clear reason why they are are protected - it isn't going to help administrators to replace it with message that isn't as clear. — xaosflux Talk 00:05, 24 December 2019 (UTC)
- I think the best solution would be to add another set of text at the template you want to use, perhaps {{protected interface|$1|type=rawhtml}} so that the useful reason can still be passed though - why do you think this is a bad idea? — xaosflux Talk 00:24, 24 December 2019 (UTC)
- Hmm, I am opposing it for the sake of consistency and simplicity. It seems you're misunderstanding what
|type=interface
is doing here and you're right to be. Your suggestion is exactly what I initially intended to suggest before I later fully understand what {{protected interface}} actually does. The|type=
parameter is not actually meant to tell user the detailed reason why they are not able to edit the page (what you're attempting to do). It is only meant to tell the groups eligible to edit the page (while leaving the reason explanation to editnotice example given above). It's a misnomer. It's correct name should be|permission=
or even more accurate|group=
since permission can also mean "right", but the template only consider groups. We can still go with your suggestion of passing the reason from {{protected interface}} and using|type=rawhtml
in calling. But if we do that, we should also pass the error reason of all similar messages from that template, then delete Template:Editnotices/Page/MediaWiki:Common.css (and its likes), so that on MediaWiki:Sitecssprotected we can just call {{protected interface|$1|type=css}}. That would be fine to me. But of course, we can also do the simpler (which also builds on the status quo).... just create this message and its associated editnotice like the rest. – Ammarpad (talk) 07:11, 24 December 2019 (UTC)- As the default message already tells the detailed reason, I'm not seeing any good argument for why we should stop providing this information to administrators. How many admins are saying "I wish I didn't really know what is going on here!" — xaosflux Talk 12:52, 24 December 2019 (UTC)
- Hmm, I am opposing it for the sake of consistency and simplicity. It seems you're misunderstanding what
- I think the best solution would be to add another set of text at the template you want to use, perhaps {{protected interface|$1|type=rawhtml}} so that the useful reason can still be passed though - why do you think this is a bad idea? — xaosflux Talk 00:24, 24 December 2019 (UTC)
- The software also already explains clearly why common.js is not editable, but nonetheless the message was overriden on enwiki with template and editnotice. So I don't agree with your argument. Also just above you said "
- @Ammarpad: commons.js is a contenttype js page, so it is obvious why interface admins are needed. Also, the default messaging already says why pages like MediaWiki:Copyright aren't editable (by virtue of being rawhtml enabled) - this should certainly not require manual edit notices when the software already provides for calling this out when needed. I'm just saying we shouldn't obscure that, and it should be automatic. — xaosflux Talk 21:28, 23 December 2019 (UTC)
- @Xaosflux: You don't need to modify that template. Even Common.js/Common.css are using it as is, the additional explanation is then handled with editnotice (cf. Template:Editnotices/Page/MediaWiki:Common.js). So that's what should be done here. I will track down the affected pages and create the notices, maybe tomorrow, if someone has not gotten to do it. – Ammarpad (talk) 20:43, 23 December 2019 (UTC)
- @Ammarpad and Pppery: — xaosflux Talk 19:23, 23 December 2019 (UTC)
I have disabled the request because there is not a clear consensus for a particular option here — Martin (MSGJ · talk) 14:02, 6 January 2020 (UTC)
- @Ammarpad and Pppery: now that this is stalled, lets see about getting it moving again? I do think that using a standardize message on these is a good idea, I just don't want to loose some additional information. Is there an objection to adding an additional parameter to Template:Protected interface, perhaps "subtype" (or anything really) that can be used to inject the "because it contains raw HTML" verbiage? Then this could use that template, pass one more parameter, and have that template include this special information? — xaosflux Talk 14:54, 6 January 2020 (UTC)
- FWIW, I agree with Xaosflux. There are way too many times when you run into a brick wall where the software won't let you do something (whether for permissions or for functionality or for configuration) but there's no clue as to why whatever you're trying won't work or where you can find more documentation. If you don't already know the reason, it is darn near impossible to reason it out. In this specific case I happen to know the reason, but that's mere coincidence (there's no reason to assume everyone would know that). In other words, I think at a minimum the message should give enough breadcrumbs to let whoever sees it reason it out; and preferably there should be a mw:-prefixed link to a page explaining the issue in detail.I have less strong opinions on how to achieve that, but going by way of a editnotice instead of a template param seems suboptimal. I would imagine a lot, if not all, cases could be covered by
|rawhtml=
and a few others; and if an actual need for it exists, I see no particular reason there can't be a|custom-reason=
(or whatever) parameter. --Xover (talk) 09:09, 7 January 2020 (UTC)
- FWIW, I agree with Xaosflux. There are way too many times when you run into a brick wall where the software won't let you do something (whether for permissions or for functionality or for configuration) but there's no clue as to why whatever you're trying won't work or where you can find more documentation. If you don't already know the reason, it is darn near impossible to reason it out. In this specific case I happen to know the reason, but that's mere coincidence (there's no reason to assume everyone would know that). In other words, I think at a minimum the message should give enough breadcrumbs to let whoever sees it reason it out; and preferably there should be a mw:-prefixed link to a page explaining the issue in detail.I have less strong opinions on how to achieve that, but going by way of a editnotice instead of a template param seems suboptimal. I would imagine a lot, if not all, cases could be covered by