Last modified: 2014-11-17 10:36:19 UTC
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
Conceptually, this could be done in (at least) two ways: 1. At the time of request, all a current members of the category to the user's watch list. 2. Somehow add the category itself to the watch list. If new pages are added to 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.
*** Bug 3479 has been marked as a duplicate of this bug. ***
*** Bug 4343 has been marked as a duplicate of this bug. ***
This can be done now, AFAIK, by using the 'Related changes' link for a category. shouldn't this bug be marked FIXED?
No, not yet: What about the articles in subcategories?
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.
(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'.
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).
Re #7, check out [[Help:DPL]] on Meta, not exactly what you want, but close.
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.
Since some months there is an easy way to do this, see bug 5220#c21 (web feed + Mozilla Thunderbird)!
replied in bug 5220#c24.
Changed component to "Watchlist"
Also noting: http://www.mediawiki.org/wiki/Extension:CategoryWatch
*** Bug 8261 has been marked as a duplicate of this bug. ***
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. More: https://www.mediawiki.org/wiki/Summer_of_Code_2013
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
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".
