Author: anti0918
Description:
Request: The ability to watch all of the articles within a category (not necessarily
within the subarticles, but it would also be nice). This would more easily allow
individuals with interests in specific topics to watch for vandalism and new
articles, and add content. It would also encourage such actions.
en:User:Brian0918
(This feature request was #149 in the 2016 Community Wishlist Survey.)
| Unknown Object (Diffusion Commit) |
richholton wrote:
Conceptually, this could be done in (at least) two ways:
watch list.
the category, these pages would also be watched.
1 has the advantage of being almost certainly simpler to implement. However,
it's probably less useful.
adinadav wrote:
This can be done now, AFAIK, by using the 'Related changes' link for a category.
shouldn't this bug be marked FIXED?
mathias.schindler wrote:
Using Related changes is a different concept.
Many/Most/A lot of/ people consider their own watchlist their main source of
suggestion where to work next. There is no feature yet to tell Mediawiki to add
all (current and future) articles of an existing category to my own existing
watchlist. Related Changes is a half-suitable workaround. It is not an
replacement of this feature request.
gangleri wrote:
(In reply to comment #4)
This can be done now, AFAIK, by using the 'Related changes' link for a category.
shouldn't this bug be marked FIXED?
'special:Recentchangeslinked/Category:foo' is neither a 100% substitute for
watching all 'members' of 'category:foo' nor of the members of its subcategories.
It will *neither* show if category membership is removed for some 'members'
(because the new revision is no longar a member of 'category:foo') nor if
'members' are moved (move tests where made to ilustrate the request of bug 5052).
A 'nice to have' would be a special tag for the category namespace named 'watch
membership' (or similar) which should lead to a form haveing both radio buttons
as 'watch all members', 'watch all subcategories' *and* the option to watch only
individual members using a list with checkboxes similar to the one from
'special:Watchlist/edit'.
martelli wrote:
As it was said above, it would encourage experts to watch the category related
to their subject for vandalism (with all subcategories included, that would be
very nice).
omniplex wrote:
Re #7, check out [[Help:DPL]] on Meta, not exactly what you want,
but close.
ian wrote:
Greetings. I came upon this request in my requisite search before submitting an "Ability to watch Recent Changes" request. I also came across bug 2308, bug 12308, and this forum post: http://www.mwusers.com/forums/showthread.php?t=5579. They all seem to be asking for the ability to subscribe to a push feed of changes to existing and/or new pages of a given criteria, without having continuously seek out, and manually subscribe to, each one individually. Examples include: "all pages", "all sub pages of a parent page", "all pages in a category", "all pages with title, content, or certain metadata matching these patterns or parameters", and so on.
Would it make sense to generalize this bug, or perhaps create a meta-bug that groups this with those mentioned previously--"Selectively watch page edits and additions", or the like?
The correct link to DLP is [[m:Help:DLP]] (there's also [[m:DynamicPageList]] which should be moved to mediawiki.org sooner or later, and has in my opinion a better explanation of the extension.
Another alternative "solution" was referred in bug 7148 (geez, there are really a bunch of bugs about this issue as #10 said above, and they have slight differences so they can't be marked as dupes... a meta-bug really is something that should be done) is a user script: [[User:Ais523/catwatch.js]].
I hope this gets fixed, as it's be really useful and improve the efficiency of the editors.
Wiki.Melancholie wrote:
Since some months there is an easy way to do this, see bug 5220#c21 (web feed + Mozilla Thunderbird)!
It has been suggested at https://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_projects#List_of_project_ideas_25327 that this feature could be a project idea for Google Summer of Code 2013.
This is a reality check to know whether this feature is feasible for a students within that time-frame, whether the MediaWiki maintainers would be happy to take the changes if they meet quality requirements and (hopefully) whether someone would volunteer to mentor a student to accomplish this task.
This request has a bunch of different interpretations of varrying difficulty:
*when you hit watch on a category all articles in the category are added to your watchlist. This is a one time event. If someone later removes an article from the category it does not get removed from your watchlist. Ditto for adding.
This is not that difficult and is doable in gsoc. In fact it might be too short. However one would have to be careful about big cats. Unprintworthy redirects has over a million entries. We already have problems with watchlists exploding when they get too big. Combining such a project with tools to prune your watchlist when it gets too big might makr a good project. (Someone more familar with watchlists would probably be better at saying if scope is appropriate than I could)
Possible interface might be better as a add-all-things from cat foo box on special:watchlist rather than associating with watching the category.
*the previous one+watch subcats.
If that's taken as all subcats of all subcats I cab say right now that's a wontfix. Doing just one level maybe ok, but I would still be hesitant.
*add a cat to watchlist all things in cat are in watchlist. If something is added to cat it gets added to your watchlist
Its unclear how to do this (in a good fashion). I would not reccomend this to a student. However if a student is particularly interested tell them to post a detailed implementation plan on this bug so we could judge its feasibility.
*previous point + noting removals and additions to the category.
Probably what is truley wanted, but even more difficult than previous point. Noting category additions/removals is rather independant issue and essentialy bug 7148
dotmaudot wrote:
as for me, watching subcats is not an issue (I could subscribe to subcats too), but at least additions to the category would be useful.
(In reply to comment #18)
*add a cat to watchlist all things in cat are in watchlist. If something is
added to cat it gets added to your watchlist*previous point + noting removals and additions to the category.
So, just to be clear, the last point only differs from the preceding one by allowing removals to be tracked (not only additions)? If so, what exactly makes tracking removals so much harder than tracking additions?
*the previous one+watch subcats.
If that's taken as all subcats of all subcats I cab say right now that's a
wontfix. Doing just one level maybe ok, but I would still be hesitant.
One level would cover too narrow a subset of use cases, imo. Perhaps for this kind of need, the best would be a separate feature, to watch all pages linked from a specific page (e.g. a list).
(In reply to comment #20)
what exactly makes tracking removals so much harder than tracking additions?
bug 13588 comment 0 explains it:
Currently the only link that is timesstamped is cl_timestamp. With this it is
only possible to track additions to categories.
(In reply to comment #20)
(In reply to comment #18)
*add a cat to watchlist all things in cat are in watchlist. If something is
added to cat it gets added to your watchlist*previous point + noting removals and additions to the category.
So, just to be clear, the last point only differs from the preceding one by
allowing removals to be tracked (not only additions)? If so, what exactly
makes
tracking removals so much harder than tracking additions?
Additions are kind of hard to track. Cl_timestamp isnt really sufficient.
Basically the hard part is attributing arthurship to the category change, especially when templates change. Categories can also change on events not associated with an edit action. See bug 7148
If we don't care who changed which category something is in, things become a lot easier.
(In reply to comment #22)
If we don't care who changed which category something is in, things become a
lot easier.
Maybe an ideal implementation would have to be planned from scratch to take authorship in consideration, but for the purposes of this specific request, I don't think *who* performed a given change is that relevant; as long as the relevant pages are being kept in the watchlist, the goal would be achieved.
Open since 2005, inactive in the past 12 months... If we want to reflect the current plans, this should be "lowest".
For anyone watching this task you can now watch a category for membership changes in Mediawiki.
I guess this makes it slightly easier to watch all pages in a category (as you get notified of pages being added to the category).
But this bug remains open!
Hi, I wrote a simple user script to do this: https://en.wikipedia.org/wiki/User:NKohli_(WMF)/megawatch.js
It adds a "Megawatch" tab to Category pages clicking which watches/unwatches top 500 pages in a category. It doesn't track new category additions or removals.
It works well with Wikisource too.
I'm not sure if something similar already exists.
@Niharika: Awesome job! It works great for me. I tweaked the code a bit to make it skin agnostic. It now shows up under the "More" menu in Vector. I also tried to minimize the use of the global scope so it won't conflict with other gadgets or user scripts.
Thanks. I fixed a bug where it didn't actually wait for the user to confirm. Also sadly, it's restricted to watching/unwatching top 50 pages at the moment. See https://www.mediawiki.org/wiki/API:Watch
It's possible to make it 500 if the Ajax request happens by a bot, which should be possible to do with a simple tool labs service, if there's any interest. :)
If there were a tool to do it, perhaps it could also handle periodic adding/removing of category members? And do more than 500 (in batches)?
🤔 Should be possible. We'd need a database to keep track of who opted to megawatch which categories so we can update their watchlists on category updates.
Doing more than 500 should be easy enough.