Not only is that the third (at least) time in this thread that Special:EditWatchlist and Special:EditWatchlist/raw have been mentioned, it was also in the opening comment of T143809 which was closed as a duplicate of this task in 2016. The other solutions mentioned in the past day are also not new.

Whatever is holding up the implementation of this much-requested feature it is not a lack of realistic UX integration possibilities.

I'd think there isn't much of a use case for pages you do want to get page link notices for but do not want on your watchlist.

So if page link notices are restricted to pages that are on your watchlist, I'd think that would help? (it could even be made into a preference if there actually is a use case) While this isn't the ultimate solution as for example @Quiddity mentioned because you may want to watchlist a page but don't want its page link notices, this would alleviate the pain for users who are getting spammed to death by a single page they deeply regret ever creating that ended up in a navbox.

I'm guessing this would be the simplest option to implement?

I definitely don't want link notices for every page on my watchlist - e,g, I have many policy pages on my watchlist but I don't want to get spammed by links to them. Getting link notices for pages not on your watchlist is probably rarer, but I wouldn't discount a desire for it.

In T46787#5627661, @Thryduulf wrote:

I definitely don't want link notices for every page on my watchlist - e,g, I have many policy pages on my watchlist but I don't want to get spammed by links to them. Getting link notices for pages not on your watchlist is probably rarer, but I wouldn't discount a desire for it.

No, I mean you would have to be both the page creator and have the page watchlisted in order to receive page link notices.

Whatever is holding up the implementation of this much-requested feature it is not a lack of realistic UX integration possibilities.

I agree that there are many nice UX possibilities proposed here but as someone who might work on this with pretty limited time (or for any other developer interested in this), it would be really nice to see the phab task description updated with a consensus on exactly what to implement.

In T46787#5640173, @kostajh wrote:

I agree that there are many nice UX possibilities proposed here but as someone who might work on this with pretty limited time (or for any other developer interested in this), it would be really nice to see the phab task description updated with a consensus on exactly what to implement.

I think the consensus would be that any solution is better than none! As a dev, you're the one with the best idea of what can be achieved in a short/feasible time. If you think multiple options are possible to be implemented in the time you have to spare (thank you!), let us know which ones and we can rapidly discuss further.

A simple interface in Preferences:Notifications, like the "mute user" input box, would be fine: just a box labelled "suppress link notifications for these page(s)" and the ability to list one or more page. Or, as Quiddity suggests, any other workable interface to get the same result.

Agree with the anything is better - but If you want a direction, I'd section @PamD 's idea. Putting it in (Special:Preferences#mw-prefsection-echo) would put it near the other similar control, perhaps "Muted pages". Note, since this area looks integrated with global pages, you may need to store the entire page value in there (e.g. :w:en:Project:Pagename) (as opposed to "users" that are already global things)

I would also suggest starting with a simple input box like the "Mute user" one on the notifications tab. And put it on the same tab as well to keep everything together.

I am a bit confused by reading https://www.mediawiki.org/wiki/Help:Notifications/Types#Page_links
Is it possible - or even default behavior that

1. the page I once created is not anymore in my watch list
2. the "Page link" notifications still arriving to me because I am the page creator
3. so the only way to stop it is to uncheck "Page link" notification for my whole watch list?

It never happened to me but some very experienced users claiming it to happen.

@Neolexx Yes, that is correct. Unfortunately, it is currently only possible to uncheck all "Page link" notifications. There is no relationship between the "watchlist" feature, and this notification feature, at all.

In T46787#6071872, @Quiddity wrote:

@Neolexx Yes, that is correct. Unfortunately, it is currently only possible to uncheck all "Page link" notifications. There is no relationship between the "watchlist" feature, and this notification feature, at all.

Wow... That sounds really nasty im many circumstances. Now I understood the problem duscussed at the ru-wiki techforum https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#que01

Just imagine some old standing participant who once happenned to create an article like Authority control or Animal or similar.
His/Her "notices" (the square thingy) will be spammed to hell on a daily basis by "Page link" notifications. And no way to stop it unless to kill "Page link" for the entire watch list.

I also do not understand why at [[ T250673]] (closed as a dup of this) @Aklapper asked me "Could you explain why you do not drop that page from the watch list?" Now the answer is plain obvious: because "there is no relationship between the "watchlist" feature, and this notification feature, at all".

While that thing is not fixed (it may take some long time) - is there a way to emulate "Muted pages" feature using client-side Javascript? I found a hook demo at https://www.mediawiki.org/wiki/User:MSchottlender-WMF/GadgetEchoMarkAllRead.js - but it is rather far from what is needed.
Some code to emulate "Muted users" but for articles. I am not a Javascript guru but with some hints I could write a custom script for that.

I'm not a developer at all, but maybe @kostajh can give some quick insights?
p.s. Thank you for being a Tech Ambassador from ru-wiki!

Change 591154 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/Echo@master] Add page linked event title blacklist

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

no, a JavaScript hook isn't really going to work for this, it has to be dealt with server side.

I've pushed a patch that adds a preference for storing page link blacklists, basically in the same way that you can mute users. When the event is of a "page-linked" type, if the title that event is about is in the page link blacklist, that event won't get delivered. Here's what the preference looks like:

Is this going to satisfy the use cases that have been written up here? By using a preference, this will not scale to hundreds of pages in the blacklist. How many titles would you blacklist if you had the ability to?

If anyone wants to try to evaluate this patch in a local development environment (https://www.mediawiki.org/wiki/MediaWiki-Docker) I'm happy to provide some guidance in getting set up.

Based on the screenshot, I think this solution will solve the majority of the problems, for the majority of users.
Can another editor or two, please confirm, with your thoughts?

By using a preference, this will not scale to hundreds of pages in the blacklist. How many titles would you blacklist if you had the ability to?

Hmm. (1) Please could you give us a rough-guesstimate about how many is too many ? (50, 500, 5000?).
(2) And please confirm, is this a technical-limitation (i.e. the databases would be unhappy if thousands of editors each added hundreds of pages into this feature),
or simply a user-experience-limitation (i.e. It would be awkward for users to see the entire list if it got too big)

Unfortunately it's not easy to get guesstimates of how many pages a majority of editors would want to blacklist.
The Enwiki WP:List of Wikipedians by article count gives a slight sense of the people in the long-tail, although most of those pages they've created are not likely to be causing them problems. It's the handful of articles that appear in nav-templates, or are very-common-links (like Country names) that they'd most want to exclude.

I think it makes sense that massively-prolific page-creators will simply need to (continue to) disable the feature completely.
At the very least, this proposed solution would solve a huge part of the problem in the short-medium term. So I'll repeat the standard quote of "don't let perfect be the enemy of good". :)

Thank you for looking at this again! <3

In T46787#6073227, @kostajh wrote:

Is this going to satisfy the use cases that have been written up here?

Yes, that would match perfectly.

By using a preference, this will not scale to hundreds of pages in the blacklist. How many titles would you blacklist if you had the ability to?

I cannot speak for the whole ru-wiki community and for the entire future but based on all known cases ever since notifications appeared: the black list will be 1-2, hardly ever more than 10 exceptions per user.
To have this really annoyant several conditions needs to be met:

1. a old yet still active user
2. who once created a basic set article (Authority control, Animal, Writer, etc.)
3. tha article is now largely deployed by linking from other articles as is or as a part of a template.

So no, no "hundreds of pages" for sure. But to be on the safe side you could set the max limit to say 16 (20?). So to add over it one will need to remove something previous.

In T46787#6073256, @Quiddity wrote:

Can another editor or two, please confirm, with your thoughts?

Speaking for myself, yes. the proposed solution would be great. I would add less than 10 pages to my list, but I can see how some users would add many more, though I agree that this situation would be atypical. In any event, the proposed solution would be a very useful upgrade to what we have now (which is nothing), even if it's not the perfect solution for all users. Thank you!

I think this idea would be good, and would work for me. I think if you're wanting to exclude very many pages that you'd be better off using an opt-in system (which is T66090) - although I I realise that would require that to be or to have an option for "only these" instead of/in addition to "plus these"

In T46787#6073227, @kostajh wrote:

Is this going to satisfy the use cases that have been written up here?

Yes, this solves the problem.

In T46787#6073227, @kostajh wrote:

no, a JavaScript hook isn't really going to work for this, it has to be dealt with server side.

I've pushed a patch that adds a preference for storing page link blacklists, basically in the same way that you can mute users. When the event is of a "page-linked" type, if the title that event is about is in the page link blacklist, that event won't get delivered. Here's what the preference looks like:

Is this going to satisfy the use cases that have been written up here? By using a preference, this will not scale to hundreds of pages in the blacklist. How many titles would you blacklist if you had the ability to?

I think this would solve the problem. I would have blacklisted only one had the functionality existed at that time. I haven't found any need to blacklist more since that comment so it's a fairly uncommon event, but when it does happen it pretty much drives you mad. So a solution is very much welcome.

I've been watching this bug for 4 years now, and for all that time, Page link notifications have been useless for me. Fellow Wikipedians regularly mock me (or at least get easily distracted whenever I an showing them something while logged in) for the "99+" unread notifications in my top panel.

I am one of those "old-standing participant[s]" that @Neolexx wrote about – I slap my face everyday for having created two articles on Czech Wikipedia that get linked very frequently. Major source of problems is the one about the official national book catalog which is linked from every writer's article and currently has 21 thousand backlinks; the other article is about a top-level unit of church administration which gets linked at least from every single parish article which also keep emerging every day.

Regular users do not happen to have created such fundamental articles, but long-time and/or innovative editors do. As a consequence, they are currently condamned to being flooded with backlink notifications for eternity. I am not going to disable notifications for "pages that I have created" in bulk, because most of the articles I have created are about niche topics that I care for and want to be notified when someone links to them from another article. I also cannot remove those pages from my watchlist, exactly because they are highly exposed and therefore also need high attention, so engaging watchlist is also not a workable solution. I am convinced that only being able to "disown" specific page creations for the purpose of notifications (i.e. the proposed "muted pages" list) is one. And I would be very happy to eventually see it in practice soon!

Has using a system similar to the raw watchlist editing mode been considered?

In T46787#6078162, @Trizek-WMF wrote:

Has using a system similar to the raw watchlist editing mode been considered?

I see at as a unnecessary complexity - given the nature of the problem. As me and other here pointing out, the issue happens with a narrow set of pages per each user: but then it happens. it really drives you made worst then any dedicated spammer.
In such circumstances the solution of @kostajh (analogous to spammer blacklist) looks the most adequate by its interface representation and by the expected usage scale.

What could be additionally considered - the original idea of this ticket from 2015: to have "mute this user" and "mute this page" buttons right in the expandable notification list right from each notification. So no need to go to #mw-prefsection-echo tab and to fill it manually.
But as long as the PHP update rolled out, the latter will be rather easy to achieve by a separate client-side Javascript gadget.

In T46787#6078162, @Trizek-WMF wrote:

Has using a system similar to the raw watchlist editing mode been considered?

It has been mentioned more prominently at the related T66090 but I don't recall seeing any feedback from developers regarding it.

I've got just two pages whose incoming links I don't want to see: an article I created on a publisher, which gets linked in many references to their publications, and a redirect I made from [[Districts of Russia]] to [[List of districts in Russia]], which was then overwritten by an article which has been included in infoboxes and linked from 23,000 articles: I think I have been notified every time. Conceivably an editor could create a group of related articles which all turn out to be as toxic - eg systematically writing about the publishers of a country or topic - so would have a larger number of pages to suppress, but I don't imagine many editors would get beyond, let's say, 50.

Overall the question "how many is too many" (@Quiddity) is more philosophical rather then programmatical. While programmers normally prefer more casual definitions.

Let's say that by the decades-old established practice at Wikipedia we have 4 distinct scale:

1. casual (0 ...50)
2. extended (51...500)
3. robotic (501...5000)
4. system (5001...POSITIVE_INFINITY)

each level is not just a numeric range but a system demand change (need to change default query, need to be a bot, need to have extended system provileges)
So the update in question is expected to be at "casual" level, highly unexpected to be "extended", definitely never "robotic" or "system".

@kostajh - sorry to bother you but is there any rough estimate when the patch might by rolled out? (so I could cheer or break hearts at ru-wiki :-)

Thanks everyone for the feedback. The patch I have in review will store article IDs for each page you want blacklisted, in a field in the user properties table which allows 65,535 characters. A recent article on enwiki has a page ID of 8 characters (63785095), so... there is plenty of room in that preference to store all the articles you want blacklisted from page linked notifications :)

@kostajh - sorry to bother you but is there any rough estimate when the patch might by rolled out? (so I could cheer or break hearts at ru-wiki :-)

It's in code review, my guess is that it would reach group 2 wikis on May 7.

In T46787#6084628, @kostajh wrote:

Thanks everyone for the feedback. The patch I have in review will store article IDs for each page you want blacklisted, in a field in the user properties table which allows 65,535 characters. A recent article on enwiki has a page ID of 8 characters (63785095), so... there is plenty of room in that preference to store all the articles you want blacklisted from page linked notifications :)

To expand on that a little more: with each page ID being up to 8 characters, plus a newline character separating each page ID, you should be able to store at least 65535 / 9 = 7281 pages in the list.

@kostajh - sorry to bother you but is there any rough estimate when the patch might by rolled out? (so I could cheer or break hearts at ru-wiki :-)

It's in code review, my guess is that it would reach group 2 wikis on May 7.

I've reviewed the patch and I will merge it tomorrow after the branch cut, so it will be deployed to Wikipedias on May 7 as Kosta said. (If I had merged it today, it would have been deployed this week, but without translations; I'd rather wait a week to give translators some time to translate the new labels on the preferences page.)

Change 592806 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] Add dynamic secondary action to mute/unmute page-linked notifications

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

In T46787#6087366, @Catrope wrote:

I've reviewed the patch and I will merge it tomorrow after the branch cut, so it will be deployed to Wikipedias on May 7 as Kosta said. (If I had merged it today, it would have been deployed this week, but without translations; I'd rather wait a week to give translators some time to translate the new labels on the preferences page.)

Slight change of plans: after talking to @MMiller_WMF we're now targeting this for May 14th.

Change 591154 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Add page linked event title muted list

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

Checked in betalabs - will keep in QA column to do some check after deployment (it's scheduled for wmf.34).

The screenshot to just illustrate the implemented UI:

Works as expected; redirects and double redirects have been checked. Checking templates in betalabs is quite problematic, and there might be some other cases in production that probably were not covered with betalabs testing.

See some notes below - all are minor.

• the link - learn more on Special:Preferences-Notifications redirects to the page where 'Muted pages' feature is not mentioned.
• 'Muted pages' field has `maxlength="255" ; 'Muted users' field doesn't have such limitation
• 'Muted pages' field will add non-existing pages - "Muted users" will not show suggestions for non-existing users.

when entering	a non-existing page is added

However, upon clicking 'Save', a non-existing pages won't be saved.

@Etonkovidova -- since this is a user-facing feature, we need to also apply Design Review and PM Review, so I'm moving it to @RHo's column. Note that her review and my review block whether it can go into production.

Hi @MMiller_WMF - after reading through the history of this task I think this is a good solution that covers the core ask to enable muting page link notifications for specific pages.
Besides the three minor things @Etonkovidova picked up on, my only minor copy recommendation is to change the title from Muted pages to Muted pages for page link notifications to be clearer what is being muted. The reason is there could be confusion that all notifications will be muted for entered pages, since the above “Muted users” section mutes all notifications from those users.

Change 597334 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/Echo@master] (wip) Muted pages: Adjust title multiselect to not allow non-existent titles

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

the link - learn more on Special:Preferences-Notifications redirects to the page where 'Muted pages' feature is not mentioned.

I added some brief docs: https://www.mediawiki.org/wiki/Help:Notifications#Muting_pages

'Muted pages' field will add non-existing pages - "Muted users" will not show suggestions for non-existing users.

I started working on this here https://gerrit.wikimedia.org/r/597334

my only minor copy recommendation is to change the title from Muted pages to Muted pages for page link notifications to be clearer what is being muted.

@RHo thanks for the suggestion. The reason it's implemented as it is, is because in theory we could add the ability to mute other types of notifications related to pages, so "Muted pages" would be the overall section while each input field (with corresponding help text) would be for a particular notification type. That said, since we have no immediate plans to add support for other notification types maybe we should just go ahead and change the section header for now.

@kostajh -- I don't see anything additional, and I agree with @Etonkovidova and @RHo's comments. I'm putting this in Needs More Work since it sounds like there are a couple changes.

Change 598506 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/Echo@master] Change pref header to specify it's about page link notifications

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

Change 598506 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Change pref header to specify it's about page link notifications

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

Change 592806 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Add dynamic secondary action to mute/unmute page-linked notifications

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

@kostajh, can you explain what you're changing and when this change would be available? Thanks!

@Trizek-WMF there are two related things:

1. Users now have the ability to mute "page linked" notifications for individual pages via Special:Preferences#mw-prefsection-echo. The help page for this is here https://www.mediawiki.org/wiki/Help:Notifications#mute
2. Users also have the ability to mute these "page linked" notifications dynamically via the notifications widget at the top of the screen (see T115264#6098961 for screenshots), in addition to adding them manually via Special:Preferences.

The first part of the feature will be deployed to group2 wikis today if the train is unblocked. Otherwise, sometime next week.

The second part (dynamic mute/unmute) will be deployed to all wikis next week (June 4).

Change 599865 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Do not use title length limit as total input limit in TitlesMultiselectWidget

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

In T46787#6149909, @kostajh wrote:

the link - learn more on Special:Preferences-Notifications redirects to the page where 'Muted pages' feature is not mentioned.

I added some brief docs: https://www.mediawiki.org/wiki/Help:Notifications#Muting_pages

Done.

In T46787#6149924, @kostajh wrote:

my only minor copy recommendation is to change the title from Muted pages to Muted pages for page link notifications to be clearer what is being muted.

@RHo thanks for the suggestion. The reason it's implemented as it is, is because in theory we could add the ability to mute other types of notifications related to pages, so "Muted pages" would be the overall section while each input field (with corresponding help text) would be for a particular notification type. That said, since we have no immediate plans to add support for other notification types maybe we should just go ahead and change the section header for now.

Done - the field title is changed to "Muted pages for page link notifications".

In T46787#6173761, @kostajh wrote:

@Trizek-WMF there are two related things:

1. Users now have the ability to mute "page linked" notifications for individual pages via Special:Preferences#mw-prefsection-echo. The help page for this is here https://www.mediawiki.org/wiki/Help:Notifications#mute
2. Users also have the ability to mute these "page linked" notifications dynamically via the notifications widget at the top of the screen (see T115264#6098961 for screenshots), in addition to adding them manually via Special:Preferences.

The first part of the feature will be deployed to group2 wikis today if the train is unblocked. Otherwise, sometime next week.

The first part has been deployed - the option for muting pages for page link notifications is on Special:Preferences#mw-prefsection-echo.

The second part (dynamic mute/unmute) will be deployed to all wikis next week (June 4).

T46787 Allow excluding pages from the page links notifications is verified and in Design review - no issues have been found.

Change 599865 merged by jenkins-bot:
[mediawiki/core@master] Do not use title length limit as total input limit in TitlesMultiselectWidget

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

Change 597334 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Muted pages: Adjust config to not show missing titles

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

For @RHo review - two things are added to make "Muted pages for page link notifications" field behave as "Muted users" field:
(1)

In T46787#6182804, @gerritbot wrote:

Change 599865 merged by jenkins-bot:
[mediawiki/core@master] Do not use title length limit as total input limit in TitlesMultiselectWidget

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

Done - no length limit in "Muted pages for page link notifications"

(2)

In T46787#6188710, @gerritbot wrote:

Change 597334 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Muted pages: Adjust config to not show missing titles

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

"Muted pages for page link notifications" field behaves as "Muted users" field- non-existing pages cannot be added

• • non-exisitng pages are not displayed in the list of suggestions
• 'Save' control is still disabled