@TheDJ or @matmarex do you know the current state of this one? Will see what I can do if still open since we're about to look at indicators in the desktop improvements project.

It seems free for taking to me. I suggested earlier using the indicator system:

In T12347#1910365, @matmarex wrote:

We could. If we use the indicator system from T25796 for this, and use an indicator name that is also valid in <indicator> (I don't think we disallow any :P), and add our indicator with OutputPage::setIndicators() before the ParserOutput is added – then the indicator could naturally be overridden/hidden from wikitext.

In T12347#6779891, @matmarex wrote:

It seems free for taking to me. I suggested earlier using the indicator system:

In T12347#1910365, @matmarex wrote:

We could. If we use the indicator system from T25796 for this, and use an indicator name that is also valid in <indicator> (I don't think we disallow any :P), and add our indicator with OutputPage::setIndicators() before the ParserOutput is added – then the indicator could naturally be overridden/hidden from wikitext.

Given we show a locked icon next to edit on mobile that would perhaps be a little confusing when we finally render indicators on mobile.
Paging @alexhollender - how do we plan to visually tell somebody a page is protected on desktop?

In T12347#6793736, @Jdlrobson wrote:

Given we show a locked icon next to edit on mobile that would perhaps be a little confusing when we finally render indicators on mobile.
Paging @alexhollender - how do we plan to visually tell somebody a page is protected on desktop?

As far as I know we're not planning any changes regarding page indicators aside from moving them slightly. People currently can see that a page is protected from the icons editors place on the page. cc @ovasileva

just remembering that we did have an aspirational idea early on that we would communicate whether or not a page is locked/protected within the Edit button (similar to what we do in Minerva)

I feel like communicating that within the edit button makes more sense than adding an additional indicator for it

In T12347#6797373, @alexhollender wrote:

just remembering that we did have an aspirational idea early on that we would communicate whether or not a page is locked/protected within the Edit button (similar to what we do in Minerva)

I feel like communicating that within the edit button makes more sense than adding an additional indicator for it

That unfortunately wouldn't work for the entity pages on Wikidata since they don't have a global edit button but instead a lot of edit links for each statement, etc.

Can someone please clarify what the purpose/proposal of this task is? Otherwise I think we should close it given it was filed in 2007 and there has been little discussion on it since then.

• The title of this task is Add page indicator to show that the page being viewed is protected. As far as I am aware we already do this, and have no planned changes.

• Some comments mention adding text / additional elements to indicate the page is protected. Why is this necessary? I agree with T12347#150059

In T12347#6953316, @alexhollender wrote:

Can someone please clarify what the purpose/proposal of this task is? Otherwise I think we should close it given it was filed in 2007 and there has been little discussion on it since then.

• The title of this task is Add page indicator to show that the page being viewed is protected. As far as I am aware we already do this, and have no planned changes.

MediaWiki core has not and does not indicate protection status visibly besides the subtle lack of an edit button, or "view source" rather than "edit". Subsequently, many/most wikis have templates and modules providing that classic lock icon for what is seen to be as a deficiency.

I suspect the reason it has not been commented on is because fixing it is taken to be a given. I'm sure I can go onwiki and ask users to leave feedback, but I expect that would be a bunch of +1s rather than meaningful feedback. Your conclusion that it means something that the task hasn't seen a comment and thus it should be closed is unsupported.

It is not reader-friendly to be lacking the less-subtle cue, or i18n friendly for every wiki to implement this on its own, or external MediaWiki users to require the same as each editor, and can lead to "non-standard" appearance and editor/MediaWiki user annoyance that to provide this icon they may need to do it themselves or via a bot, changing the page content to emit a lock. (Which is dumb.) Which you seem to understand is what happens. The point of the task is ultimately to make it appear automatically as a result of the protection itself rather than require editor or bot workaround.

@Izno thanks for the clarification. If I am understanding your comment correctly it seems like the main issue here is the technical method with which indicators/notices appear on pages, rather than the visual presentation of those indicators/notices. Is that correct? If so, would you be willing to update the task title and description to clarify that this is about making a technical change, rather than a visual change? It might also be appropriate to open a related task regarding the visual appearance (ie I think it would be better to discuss in a separate task).

In T12347#6953587, @alexhollender wrote:

@Izno thanks for the clarification. If I am understanding your comment correctly it seems like the main issue here is the technical method with which indicators/notices appear on pages, rather than the visual presentation of those indicators/notices. Is that correct? If so, would you be willing to update the task title and description to clarify that this is about making a technical change, rather than a visual change? It might also be appropriate to open a related task regarding the visual appearance (ie I think it would be better to discuss in a separate task).

Well, as you can pointed out, the change was previously reverted for aesthetic reasons, so I don't think this task will close before the aesthetics are sorted. If you want the related task to block, I can reorganize stuff, but that seems like just enough effort to decline on my part until then. :^)

I boldly added a couple downsides for the manual approach; please remove if that was inappropriate, since I don't know if there's some extra etiquette here or anything.

Change #1033697 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[mediawiki/core@master] [WIP] Add protection indicators to mediawiki/core

https://gerrit.wikimedia.org/r/1033697

I would like the mediawiki platform to be involved in this, and to look at the patch from Sohom as this change feels like and adjustment to the "platform" and touches code in Article.php which is traditionally outside the scope of the web team.

+ @mwilliams and @JScherer-WMF to coordinarte review from DST and Web design perspective as it appears this task involves proposed addition of visible indicators of protected status to core. Per the most recent patch the changes proposed are:

• Add a disabled by default feature flag 'EnableProtectionIndicators'
• When the config flag is enabled, show a lock indicator at the top

of the page.

• The lock icon should be overridable by the content of the page
• The indicator has a predictable ID which could be potentially used to style the icon using the onwiki Common.css file.
• The lock icon by default links to https://www.mediawiki.org/wiki/Help:Protection. However

this link can be customized per wiki per protection level using a
empty message (for example: protection-sysop-helppage)

It would be extremely helpful if screenshots could be added (and/or a patchdemo created) to show what the proposed change is for design review. Curious if for example how the proposed change differs from the exisitng padlock style, position, and behaviour as the current protected enwiki pages like this one:

In T12347#9841301, @RHo wrote:

It would be extremely helpful if screenshots could be added (and/or a patchdemo created) to show what the proposed change is for design review. Curious if for example how the proposed change differs from the exisitng padlock style, position, and behaviour as the current protected enwiki pages like this one:

A wiki exists at https://patchdemo.wmflabs.org/wikis/0ab533954a/ now :) (This is how it looks like on a semi-protected page and a fully protected page)

Thanks for sharing @Soda! I'm seeing the same icon (Lock with nothing in it) for both semi-protected and fully protected. Is that to be expected as any update to the icon to visually communicate its protection level would be at a higher/ more specific presentation level?

In T12347#9844450, @mwilliams wrote:

Thanks for sharing @Soda! I'm seeing the same icon (Lock with nothing in it) for both semi-protected and fully protected. Is that to be expected as any update to the icon to visually communicate its protection level would be at a higher/ more specific presentation level?

The default implementation in the patch is to show the same icon with a different tooltip. However, the expectation is the communities will be able to customize the icon for each protection level using some mechanism (since currently, every community has different icons for showing the status of different protection levels).

In my patch, this can be done through a wiki's common.css file, for example, adding the following piece of CSS

#mw-indicator-protection-sysop > a.mw-protection-indicator-icon--lock {
    background-color: rgba(0,0,0,0);
    mask-image: none !important;
    background-image: url('https://upload.wikimedia.org/wikipedia/en/thumb/4/44/Full-protection-shackle.svg/30px-Full-protection-shackle.svg.png');
    background-repeat: no-repeat;
    background-size: contain;
}

will show the English Wikipedia's fully protected icon for fully protected pages. However, this is a bit clunky, and if we can come up with a better mechanism that will be great :)

In T12347#9844517, @Soda wrote:

The default implementation in the patch is to show the same icon with a different tooltip.

v/s

Thanks for the additional details! The design and layout of what you are proposing seems good to me as it maps to the spacing and positioning of the current lock icon and seems flexible to swap out with the icon needed.

As far as the specific process and the CSS required to swap it out - I don't quite have the context or expertise to comment on that.

In T12347#6797373, @alexhollender_WMF wrote:

just remembering that we did have an aspirational idea early on that we would communicate whether or not a page is locked/protected within the Edit button (similar to what we do in Minerva)

I feel like communicating that within the edit button makes more sense than adding an additional indicator for it

I would strongly prefer this over keeping it separated out. Fundamentally, the salient piece of information for most editors regarding protection status is "Can I, with my current permissions, edit this page?" And that piece of information is most logically presented at the point when someone seeks to enter the editing workflow, which is the edit button.

Yes, a separate solution will be needed for Wikidata, but we should not let the exception define the rule. Overall, this is a great design. Also: This is a huge design decision, so I'd suggest (a) making a separate Phabricator ticket to track it, and (b) consulting with the community on Meta to seek out additional perspectives.

I feel like an edit icon lock button should reflect if that editor is able to edit that page (i.e. there would be no lock icon for an extended confirmed user on an extended confirmed protected page because they can edit through that protection.

Whereas a standalone lock icon should reflect if that page has any kind of protection at all.

So these might be slightly different concepts.

In T12347#9851905, @Sdkb wrote:

I would strongly prefer [communicating if you can edit the page within the edit button] over keeping it separated out. Fundamentally, the salient piece of information for most editors regarding protection status is "Can I, with my current permissions, edit this page?" And that piece of information is most logically presented at the point when someone seeks to enter the editing workflow, which is the edit button.

We already do this – the "Edit" button turns into "View source" if you can't edit. However, it seems that people desire to know the protection status even if they can edit the page themselves.

We need to separate "people" out into readers and editors. For readers, the protection level has minor salience for information literacy purposes, as it can indicate e.g. how wary they should be of information on the page. For editors, the "can I edit?" question is primary, but the overall protection level still has some value for understanding the overall situation with the page (and can be accessed through the notice in the edit window or through the page information page).

In T12347#9852076, @Sdkb wrote:

We need to separate "people" out into readers and editors. For readers, the protection level has minor salience for information literacy purposes, as it can indicate e.g. how wary they should be of information on the page. For editors, the "can I edit?" question is primary, but the overall protection level still has some value for understanding the overall situation with the page (and can be accessed through the notice in the edit window or through the page information page).

I think combining protection icons with edit icons is a different task. My implementation simply implements the existing enwiki system (that relies on templates) into core.

Change #1033697 merged by jenkins-bot:

[mediawiki/core@master] Add protection indicators to mediawiki/core

https://gerrit.wikimedia.org/r/1033697

Hi, thanks for adding the User-notice tag. For a Tech News entry, please could someone suggest what needs to be communicated to editors, and also when it is best to announce it?
I.e. Are there any immediately visible changes in next week's deployment train that technical editors (or interface admins) will need to prepare for, at any or all wikis?
Plus, is there any documentation that can be linked to from the entry? (or if documentation still needs to be written/updated, should we postpone the Tech News entry until it is ready?) Thanks.

There is no immediate impact to the wikis since the feature is disabled by default. As far as I can tell, this feature isn't documented yet.

MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request.

Thank you for the reply and the draft @JJMC89 , much appreciated.
I will postpone including this in Tech News for now, in the hopes that someone can write/update the related documentation.

It might even be best if we wait until a single wiki with a familiar expert has enabled the feature and updated their local templates, so that other wikis can more easily follow an example (rather than having to piece it together from clues)? -- E.g. Are you (JJMC89) or anyone planning on requesting this at Enwiki soon and then updating/replacing Enwiki's templates?
In other words: I welcome any of your advice on when exactly to include this in Tech News. :)

In T12347#9912216, @Quiddity wrote:

Thank you for the reply and the draft @JJMC89 , much appreciated.
I will postpone including this in Tech News for now, in the hopes that someone can write/update the related documentation.

I've started a draft for the documentation at https://www.mediawiki.org/wiki/User:Sohom_Datta/protection_indicators lmk if I should include anything else (for example, do we want to include the config flag/request process?).

It might even be best if we wait until a single wiki with a familiar expert has enabled the feature and updated their local templates, so that other wikis can more easily follow an example (rather than having to piece it together from clues)? -- E.g. Are you (JJMC89) or anyone planning on requesting this at Enwiki soon and then updating/replacing Enwiki's templates?
In other words: I welcome any of your advice on when exactly to include this in Tech News. :)

I'll be happy to help with any migration efforts if any community is interested (tho maybe starting with smaller wikis might be easier than immediately starting with enwiki 🙂)

In T12347#9912469, @Soda wrote:

I've started a draft for the documentation at https://www.mediawiki.org/wiki/User:Sohom_Datta/protection_indicators lmk if I should include anything else

That's a great start!
I think it might be good to include an example of a completed-change (if that's available yet, or can be done before this is announced more widely?). E.g. links to related to page-edit diffs from a single project -- I assume that would make it easier for someone semi-technical to adapt the examples for a local change.

(for example, do we want to include the config flag/request process?).

Yes that sounds good. Perhaps just re-use the proposed wording for the Tech News entry? I.e. Just add this to the top of the page as a good summary:

MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request.

In other words...
If I understand correctly, each wiki community will need to EITHER:

1. Ignore it, and nothing will change
2. They have local templates [and want to change to use this new system, because [BENEFIT?]], so they need to follow the instructions in "Preparing for the change" to update them
3. They don't have local templates, and can automatically get these features if they make a config-request.
4. PLUS, if any wikis wants to use CSS instead of templates to change the icons that are used, then they should follow the instructions in the last section.

It might be good to tweak the page-structure to be clearer about those 3 (or 4) options.

Lastly, I suggest clarifying whether this new feature uses the same icon design for all protection types, or unique padlock icons for [many? all?!?] protection-types. Perhaps with image-examples embedded.

Hope that helps!

@Soda btw. should we perhaps set the default for WMF to false, and then flip the default for MW core to true ? I think it is good to have features like this enabled by default for new installs, otherwise most MW installs will never use them.