Currently, if you open a page which you can't edit because you're not an administrator or autoconfirmed (and this page is protected), you only see the message that this page is protected to prevent vandalism. This statement may be inaccurate though, and sometimes, the administrator (or whoever protected the page) wrote much more information on why he/she protected the page, which is visible in the page protection log. We should make that information available to the user, for example by linking to the page protection log in this case.
|Declined||Florian||T95305 If a user is prevented from editing a protected page (due to being in the wrong user group), there should be a link to the protection log, or other relevant information|
|Resolved||Florian||T96352 MobileFrontend should show the correct reason, why a user can't edit a page|
|Open||None||T102289 Special:Log needs some design love|
|Resolved||None||T150189 Make toasts tappable links when redirecting a user away from a page|
|Declined||None||T155835 Mobilefrontend doesn't allow raw HTML in toast messages|
- Mentioned In
- T150189: Make toasts tappable links when redirecting a user away from a page
rMEXT1c9bd7512efd: Updated mediawiki/extensions Project: mediawiki/extensions/MobileFrontend…
rEMFR7a525903b28f: Revert I59122b568cd353ca5c3aba0a28522effb15cfab4
rEMFRd6c5b7e8b31a: Show a better error message, when the user can't edit a page due to the false…
rMEXTc002e948a8e4: Updated mediawiki/extensions Project: mediawiki/extensions/MobileFrontend…
Change 202424 abandoned by Florianschmidtwelzow:
Add link to history page, if the user can't edit a page
@JKatz: I rethought this, especially because of I146800e176e12d70ccb93d5d5ade934bc31740b3, and i think we should rethink the actual handling. There are several reasons (at least two), why an editor can't edit a page, but we always think (at the moment), that the user can't edit, because the page is protected (and in reality, maybe, the user is blocked). I will work on this separation first to give the user the correct reason, why he/she can't edit a page and after this, i will try to use the ContentOverlay and add a screenshot to the bug, ok? :)
I'm a little confused here and missing the 'why'. What value does this give to the user? What is the goal of this? Do we expect this will increase edits? Build a better understanding of the project?
I'm not sure adding a link for the user to the history page is the best idea - what if the page was protected a year ago? How do I find that information? Why does it matter to know upon clicking edit? Why can't we just say "view the edit history to know more? in a standard toast."
Wouldn't it be better to say "This page has been protected because of "X"?"
Wouldn't it be better to say "This page has been protected because of "X"?"
Sure, that would need a new Api module or we extend mobileview, because we can't get the protection reason via the Api as far as i know :/
The value would be to give the user a concret reason, why he can't edit a page to better understand, _why_ the page was protected :)
It's an information, right, but maybe you want to leave a comment on the talk page saying, that the reason for the protection is gone, or better: With the reason you can better decide if it makes sense to ask on the talk page :)
And i think in favour of our openess we should at least give a rudimental way to find out the information you're looking for (in this case: the reason for the protection) :)
Still playing 'devils advocate'  :)
I'd say the information is already available - you can click history link and find it, but I'd say the majority of people don't really care. For example, most of the time I don't care. I don't even click on an edit link for a protected page usually... usually you can guess the reason e.g. it's an article that might be vandalised frequently or is in the news etc...
I'd argue that most people that do care would know to look at the history page and then ask on the talk page...
I think we generally have to be very vigilante about what JS is loaded on the mobile site. We should only have a finite set of futures that are truly essential to the viewing experience. To add anything from now on I think we have to have some hard conversations about what is the minimum experience we should be giving our users here.
I'd be interested in other people's thoughts as obviously this is just my opinion :-)
I agree with Jon that the page history may not be very useful in this case. However, just stating that "This page is protected to prevent vandalism" (the currently used message) is even worse. For starters, many page protections are actually not because of vandalism, but e.g. because of edit wars between disagreeing but good-faith editors (cf. this list on enwiki). The software shouldn't call these people vandals.
Per https://www.mediawiki.org/wiki/API:Logevents , the page protection log can actually be accessed via the API, see (examples - the protection reason is in the "comment" field). This information can certainly be useful to the user who is trying to make the edit. More generally I would argue that it's also a matter of transparency as basic value of Wikipedia - we don't want to present admin actions as a black box with Kafkaesque connotations ;)
It might be worth reviewing how the same issue has been solved on desktop. It involves the system message MediaWiki:Protectedpagetext which is often modified locally (example: English Wikipedia ) to include a link to the protection log alongside other information.
By default, that system message on desktop includes the needed user right as parameter ("This page is currently protected so that only administrators can edit it" vs. "This page is currently semi-protected so that only established registered users can edit it."), because "protected" is never absolute - some people can always still edit the page. A clean solution on mobile should do the same. That said, a simpler version like the following would already be a great improvement:
"Editing of this page has been restricted for the following reason: " + the reason string from the protection log
@Tbayer: Damn, sorry! I totally overlooked your comment :( But you're right, the actual merged change redirects to the pages history, not to the protection log, but it would be an easy change to point the link to the protection log.
I don't think, that the protection reason should be in mobile (it's not in desktop, too), but i think, that a link to the protection log of the page is a more valueable target for the link. I don't think, if different messages (semi-protected, fully protected...) is valueable enough to be used on mobile, if I think about the target audience :)
Let's make the protection log the target for now, as it seems the most easy thing :) Looking forward to further comments!
@Tbayer, thanks for the comment.
"This page is protected to prevent vandalism" (the currently used message) is even worse.
into account I think this is a step to the right direction. I don't see any disadvantages of the new patch compared to just a simple toast message. In fact, we can build upon the patch and add more features.
i do not think we should surface this. anyone who can understand it will be able to get their by clicking on history. I do not think it is acceptable to suggest that unsuspecting users be taken to this page.
This should not be deployed until we can figure out how to present the message in terms a new user would understand.
also, kaity had this to say about CTA message:
Can we change that toast to read "this page is protected. See protection log for more information"
"Wether a reason was given or not" sounds confusing
As discussed above, it's entirely possible to extract only the rationale for the current protection, via the API. On desktop, English WP (and I guess most other projects) link to the entire log instead, but I don't see a compelling reason for that, especially if we want to reduce the amount of text that needs to be read in order to understand the current protection.