Page MenuHomePhabricator

Investigation: Related changes by category, including main and talk namespaces (for WikiProjects)
Open, LowPublic


It would help WikiProject members to have an easy way to monitor changes on all of the articles in their project, including both the main and talk namespaces.

Right now, you can use Special:RecentChangesLinked/Category:Foo to get RC for pages marked with a category, but this only shows results in the namespace where the category is linked. Since WikiProjects tag an article's talk page, the only items that show up in RCLinked are talk pages.


Investigate creating a new special page (Special:RecentChangesCategory?) that would include an option to show recent changes to associated pages (the talk pages of content pages and the content pages of talk pages). This would allow the page to effectively act as a watchlist for WikiProjects.

Questions to answer:

  • How difficult would be to create such a page? Are there any blockers?
  • Are there other use cases for such a feature?

Description from merged task T105747

I'd like to use Special:RecentChangesLinked to filter the recent changes to articles that are associated to a particular WikiProject in Wikipedia. This would allow WikiProject members to more effectively patrol edits to pages related to their subject matter interests/expertise.

It's a common practice in Wikipedias to have WikiProjects "claim" articles using links to categories. Special:RecentChangesLinked is capable of using such categories to filter the RecentChanges feed. However, categories are usually added to article's associated talk pages.

While Special:RecentChangesLinked has an option to include edits to the "Associated namespace", selecting this option does not does not result in Article changes being included. See this query as an example of what I thought would work.

I propose that Special:RecentChangesLinked be altered to include edits to content namespaces (even numbers -- e.g. 0) when the talk namespace (odd numbers -- e.g. 1) are linked to the target page (e.g. Category:WikiProject Biology articles) and the "Associated namespace" option is selected.

This card tracks a proposal from the 2015 Community Wishlist Survey:
This proposal received 11 support votes, and was ranked #61 out of 107 proposals.

See also:

Event Timeline

DannyH raised the priority of this task from to Medium.
DannyH updated the task description. (Show Details)
DannyH added a project: Community-Tech.
DannyH moved this task to Older: Team Work on the Community-Tech board.
DannyH subscribed.

Doing a solo evaluation, cause it's a straightforward idea that we've talked about a bit.

Support: Medium
Feasibility: HIgh
Impact: Medium to High
Risk: Low

DannyH renamed this task from Related changes by category, including main and talk namespaces (for WikiProjects) to Investigation: Related changes by category, including main and talk namespaces (for WikiProjects).Nov 6 2015, 9:09 PM

Making this an investigation card. We should figure out what some other use cases would be, and talk to people about how they would use it, before we go ahead and build a new page.

Why can't this be as simple as doing the following on Special:RecentChangesLinked/Category:WikiProject_Foo_articles?

  • Check a new checkbox named "Reveal associated pages" (since this recent changes page will only have talk pages -- this would show the associated subject pages)

I modified the above as the first change actually didn't make sense because 'all' shows all.

I built transcluding changes should be good enough until its implemented in MediaWiki.

I built transcluding changes should be good enough until its implemented in MediaWiki.

Note that this doesn't work for projects using the WikiProject United States template. Correct me if I'm wrong.

It takes:

  • 50 seconds to get 420,000 article transclusions
  • 8 seconds to mirror for talk pages
  • 10 seconds for read link lookups

So over a minute which is comparable to doing the same with Related Changes.
This could be sped up to 5 seconds by using my existing pre-computed projectbanner table, but would require a separate code path and wouldn't show any new pages between the weekly updates.

Quiddity added subscribers: Halfak, StudiesWorld, aaron and 3 others.
Quiddity subscribed.

Comments from merged task:

I used to run a bot that would recursively go through a WikiProject's category tree and dump a list of the subject pages so people could use RecentChangesLinked, and IIRC there were a few Toolserver tools that did this too.

But this request feels like a bad hack that we store WikiProject membership information on talk pages using antiquated templates, when we need something like T97210: MediaWiki extension for WikiProjects / on-wiki working groups instead.

I have no idea on how technically feasible this is though.

@Legoktm there is work on a project assessment database table that will be populated by a parser function. Ideally in the future there is a dedicated interface for this kind of thing but the approach to populate via parser function requires the least disruption. See T117142.

Hi everyone, I wanted to add one more use case and also "bump" this task in case anyone was interested in taking it on. I'd like to patrol Wikipedia's "vital articles", which are in Category:All Wikipedia vital articles, containing about 35,000 pages. The problem is all the pages in that category are in the Talk: namespace, because (I think) the category is populated automatically based on the talk page having the WikiProject template. So, if I put Category:All Wikipedia vital articles into Huggle, it'll only check the Talk pages, and not the associated mainspace pages. It seems there is no way to set Huggle to patrol vital articles. I could see this feature being useful not only for patrolling vital articles, but also for patrolling articles associated with any wikiproject. Thanks in advance to anyone taking this on.

Since namespaces can be filtered out with other options, couldn't we just always join on the associated page? I can't think of a situation where you'd only be interested in the linked page and not the associated page (that couldn't be solved by filtering all namespaces).

I think this ticket would greatly improve WikiProject collaborations and encourage more people to watch recent changes.

Adding another use case to this, it would be useful for creating a "go to random vital article" button, which I don't know of a way to code otherwise.

I'm making an extension which will hopefully make this work. This is the first time I've done any hacking of MediaWiki itself, though, so I can't promise it'll be perfect!

I do have a working version of this at the moment (place a tag on the talk page, the corresponding page is categorised), but I need to test it - and it'd be good to get someone more experienced than I am in extension dev to review it, especially in terms of performance.

I've started a discussion on the enwiki Village Pump about (eventually) implementing my extension to categorise pages from their talk pages - which would be a way of resolving this issue - to try and gather consensus at this early stage. Comments and feedback would be appreciated. You can find the discussion here at VPT.

@Naypta: Hi! This task has been assigned to you a while ago. Could you maybe share an update? Do you still plan to work on this task, or do you need any help?
Also, as this is tagged with MediaWiki-extensions-CatTalk (requested a while ago) I'm wondering if there is a code location to link from the extension home page? Thanks!

@Naypta: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!

Aklapper lowered the priority of this task from Medium to Low.Mar 8 2021, 7:55 AM

Any recent progress on this? I recently came back from a hiatus, and I'm still having to manually regenerate a list of all a project's pages for project change patrol purposes. It would be nice to no longer have to do that.