@Stevietheman is absolutely right. We need all the list. Or, at least, a notification for each category move. It will not be worth than a notification for every flow post.

So the message keys you are seeing here are recentchanges-page-added-to-category-bundled and recentchanges-page-removed-from-category-bundled

These are used when a page that has a category change is embedded on other pages (so mainly templates).

Of course the number of pages that a page can be embeded by is great, hence the handling of this here, simply specifying the number of pages.

A reasonable improvement that I can think of would be a link to the list of pages the changed page is embeded on?

So essentially a link to a page such as https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Foo&hideredirs=1&hidelinks=1

I as a user would like to know precisely which pages were added and which ones were removed. How that is accomplished is open.

Now, if just one page is added or removed, which seems to be the usual case, the current approach is perfectly fine. But if two more are added/removed, I will somehow need to know which ones those are, whether in a popup list or a separate page or some way that presents them. Preferably I would like these pages linkable. My need for this information is generally about catching incorrect adds/removes, but more specifically about knowing about new articles/pages to be included in WikiProjects.

Also note that as far as putting this feature into use in the English Wikipedia, I would prefer that resolving this task not be a dependency to that. I am sanguine with the current approach for now as it's all right most of the time.

In T119712#1851111, @Stevietheman wrote:

I as a user would like to know precisely which pages were added and which ones were removed. How that is accomplished is open.

Would you count a link to Special:WhatLinksHere as an adequate solution?

The bottom line is a user needs a way to know exactly which pages were added or removed. If those are lost in a longer list, that would be only marginally helpful. We shouldn't make users hunt these pages down.

Change 273425 had a related patch set uploaded (by Addshore):
Link to Special:WhatLinksHere in CatWatch bundeled summary

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

Tested the proposed solution with the given example. With it seems to be useful. Without not really.

For the given example with the link would be https://www.mediawiki.org/w/index.php?title=Special:WhatLinksHere/Project:Sandbox&hideredirs=1&hidelinks=1 revealing the mysterious page.

While https://www.mediawiki.org/w/index.php?title=Special:WhatLinksHere/Project:Sandboxdoes not really helps.

I looked into the patch and getting the parameters needed into the link is not easy using Wikitext. The only option there would be using an external link, but external links wont get parsed in the entries of the generated and an external link there would also be irritating.

Generating an internal link with the linker in does also not work because the html gets escaped later when creating the . Looking into that changing the parsing there would be possible but surely bad for everything else using it.

It seems that one solution would be introducing a setting for the to parse entries without escaping html. This also would affect where the actual escaping happens.

Before I work on a patch doing that. @Addshore any comments? Might I have missed something?

Change 273425 merged by jenkins-bot:
Link to Special:WhatLinksHere in CatWatch bundeled summary

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

A simple link to the WhatLinksHere page was added. I created a follow up task to refine the link by adding the parameters suggested.

https://phabricator.wikimedia.org/T130373

To clarify, will this WhatLinksHere link only show those categories just added or removed?

In T119712#2134284, @Stevietheman wrote:

To clarify, will this WhatLinksHere link only show those categories just added or removed?

No, I think it would just show the whole list.

Closing this now, since further improvements are now tracked in T130373. I've also recorded @Stevietheman's concerns in T130373#2157443.