Page MenuHomePhabricator

“Special:SpecialPages” link missing by default, shortcut [Alt + Shift + Q] broken
Closed, InvalidPublicBUG REPORT

Description

The "Special:SpecialPages" link is now missing by default from the sidebar. On enwiki, it's manually added via https://en.wikipedia.org/wiki/MediaWiki:Sidebar — is this change meant to force communities to add it themselves?

Also, the keyboard shortcut [Alt + Shift + Q] for Special pages no longer works. Was it removed on purpose, or is this a bug?

Related Tech News:

Event Timeline

See T388927 - you'll have to add the link manually to MediaWiki:Sidebar. The accesskey should be gone unless you re-add it via JavaScript

Closing as the current behavior is expected behavior.

Closing as the current behavior is expected behavior.

Why? Where it was discussed? Why was not announced to local communities (e.g. via tech news)? there was only that link will be moved, not removed.

Why was not announced to local communities (e.g. via tech news)?

See both Tech News links in the task description.

Why? Where it was discussed? Why was not announced to local communities (e.g. via tech news)? there was only that link will be moved, not removed.

Exactly—that's what I wanted to say. This was a poor decision made without informing communities. If it was done without a solid reason, then it's clearly a mistake—and they should expect more phab tasks like these in the future.

See both Tech News links in the task description.

@Aklapper, @JAnD is right—there was no announcement about removing the link, only that it would be moved from one location to another.

The Special Pages link is a core MediaWiki feature—not something hidden or optional. It's the main gateway to access other special pages and should be included by default, not require manual addition.

I wasn't personally involved with this change, so I could be completely wrong here. However, my (very brief) understanding of what's happened here is: I believe that the link to Special:SpecialPages is present in the default MediaWiki sidebar; but — because on-wiki/custom MediaWiki:Sidebar pages override this — wikis with custom-defined sidebars need to manually add the link to their custom sidebar definitions, in order for it to still be visible on those wikis.

For what it's worth, I believe that T388927: [For action] Avoid losing special page link in future MediaWiki version was the task for the Tech/News entry to request that wikis update their custom sidebars to include a link to Special:SpecialPages.

(cc @Jdlrobson-WMF @aliu FYI)

For what it's worth, I believe that T388927: [For action] Avoid losing special page link in future MediaWiki version was the task for the Tech/News entry to request that wikis update their custom sidebars to include a link to Special:SpecialPages.

(cc @Jdlrobson-WMF @aliu FYI)

Probably, but the result is that many wikis lost this link - only bigger wikis with active interface admins updated sidebar (~160 of 1000) and smaller wikis never have mediawiki:sidebar. The rest are middle-sized wikis and big wikis with small community - now without this link.

That's a fair point — I don't disagree that that's an issue.

The link should be added to MediaWiki:Sidebar for all wikis that once had it and lost it with this change, especially because it was just recently moved from page tools to the left sidebar.
Special pages are important and I don't know of any other way of getting there, especially when every wiki has its own localized name.

Please subscribe to tech news (https://mediawiki.org/wiki/Project:Tech_News) All breaking changes follow the process clearly defined on https://m.mediawiki.org/wiki/Stable_interface_policy/Frontend

This particular change was communicated at least three times over a period of 8 months with clear steps on how to avoid loss of the link.

All interface admins should be subscribed.

every wiki has its own localized name

English names for special pages always work: https://pl.wikipedia.org/wiki/Special:SpecialPages works and redirects to the local version

@Jdlrobson True, but interface administrators are only volunteers who could do things but never should. Are there global interface administrators or developers who could/should do this instead?

Spanish wiki is not a small Wikipedia, yet I only see the link on their mobile site. Neither site has it for jpwiki. I don't see it on hewiki.

@Pppery Even that's assuming a lot of knowledge from people who used to click on a link, not having to worry about what url it will take them to. Not talking about myself, but ordinary users, users who don't speak English, whose only experience is their own localized wiki etc.

@Jdlrobson True, but interface administrators are only volunteers who could do things but never should. Are there global interface administrators or developers who could/should do this instead?

I wish there were global interface administrators who were empowered to do this sort of thing but currently we don't have that - at least nothing formal. (I know there are people who have this permission but most are staff and there are no clearly define rules around whether it's desirable to use this right for this sort of thing)

Every community is different - for example a while ago we had a similar situation where somebody in one community told us we should be running an automated script to fix an issue. When we did that, in the same discussion someone complained that we ran the script! For this reason I tend to think it's better that communities manage this sort of thing and define their own policies of how to deal with such changes. For example if a community is lacking in people that can help with this sort of thing it would be useful to know where they are. I could fix Japanese and Hebrew, but I don't currently have rights on those wikis (with my volunteer account) and wouldn't feel comfortable making a change without some kind of "permission" as I wouldn't enjoy being shouted out on wiki if it was not wanted - for example maybe those communities intentionally ignored the tech news notice because they don't think it's useful or it's already there but under a different label because I don't speak the language.

I know there is a similar problem with the dark mode roll out (T395628: Enable dark mode on all Wikimedia projects)- there are various wikis not making / unable to make the changes needed to support dark mode and it's not clear how to address these issues. Perhaps the creation of a global interface taskforce would be a good proposal for a meta wiki RFC on https://meta.wikimedia.org/wiki/Meta:Requests_and_proposals ?

@Jdlrobson True, but interface administrators are only volunteers who could do things but never should. Are there global interface administrators or developers who could/should do this instead?

I wish there were global interface administrators who were empowered to do this sort of thing but currently we don't have that - at least nothing formal. (I know there are people who have this permission but most are staff and there are no clearly define rules around whether it's desirable to use this right for this sort of thing)

Every community is different - for example a while ago we had a similar situation where somebody in one community told us we should be running an automated script to fix an issue. When we did that, in the same discussion someone complained that we ran the script! For this reason I tend to think it's better that communities manage this sort of thing and define their own policies of how to deal with such changes. For example if a community is lacking in people that can help with this sort of thing it would be useful to know where they are. I could fix Japanese and Hebrew, but I don't currently have rights on those wikis (with my volunteer account) and wouldn't feel comfortable making a change without some kind of "permission" as I wouldn't enjoy being shouted out on wiki if it was not wanted - for example maybe those communities intentionally ignored the tech news notice because they don't think it's useful or it's already there but under a different label because I don't speak the language.

I know there is a similar problem with the dark mode roll out (T395628: Enable dark mode on all Wikimedia projects)- there are various wikis not making / unable to make the changes needed to support dark mode and it's not clear how to address these issues. Perhaps the creation of a global interface taskforce would be a good proposal for a meta wiki RFC on https://meta.wikimedia.org/wiki/Meta:Requests_and_proposals ?

It's usually fine (actually desired, because there are no local interface admins on those projects) if WMF employees with global interface editor permissions make the desired changes on all global sysop wikis. That still leaves the issue with medium-sized communities, but at least fixes potential errors on small projects.

I think there is a point here about the amount of waffle in release notes when it comes to upgrade time.

It usually consists of something like:

Bla bla bla localisation updates.
Bla bla bla configuration changes to obscure settings.
etc

When what it also needs is more succinct instructions for what end users actually need to pay attention to.

^ FYI. Reached out to you separately about this feedback.

If WMF employees with global interface editor permissions make the desired changes on all global sysop wikis

This isn't documented anywhere and to be honest this group is too small to deal with the amount of work we are talking about here, but I agree that would be a good situation to be in if we could get there.

If WMF employees with global interface editor permissions make the desired changes on all global sysop wikis

This isn't documented anywhere and to be honest this group is too small to deal with the amount of work we are talking about here, but I agree that would be a good situation to be in if we could get there.

GIE can make routine changes on non-large wikis (those without „established communities and processes for maintaining scripts“) – unless the edits are „controversial“ per https://meta.wikimedia.org/wiki/Global_interface_editors#Scope. While community members might have different opinions about what constitutes a controversial change, I don't think updating MediaWiki:Sidebar in order to ensure that a previously visible link remains visible is controversial (as seen by the number of bug reports related to this change). The policy even mentions an exemption for WMF employees regarding the rule not to edit on larger projects, but I think you are right to still avoid those projects.

And if we are just speaking about global sysop wikis: There's always the option to file a request on https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous asking if stewards, global sysops or volunteer global interface editors can do the necessary changes on those small wikis (providing a list of projects needing changes would be helpful).

@Johannnes89 I think we are saying the same thing here, but there is way too much ambiguity around what constitutes "controversial" and what constitutes a "large project". It's also not clear to me if that is the best use of a staff members time (as writing automation tests and running them could easily take 1-3 days of a developers time given the amount of wikis involved and importance of doing it correctly, whereas a divide and conquer style approach of distributing this work will likely take each community member 5-10 minutes each.

There's always the option to file a request on https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous asking if stewards, global sysops or volunteer global interface editors can do the necessary changes on those small wikis (providing a list of projects needing changes would be helpful).

This is nice but it's currently not required by https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend - perhaps it could be proposed on the talk page? I think what is particularly important here is how we define "small wikis" in a way that doesn't belittle their efforts and respects smaller wikis which have able technical users.