Last modified: 2014-11-17 10:36:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1710 - Ability to watch all articles in a category
Ability to watch all articles in a category
Status: NEW
Product: MediaWiki
Classification: Unclassified
Watchlist (Other open bugs)
unspecified
All All
: Lowest enhancement with 19 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 3479 4343 8261 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-18 21:04 UTC by en:brian0918
Modified: 2014-11-17 10:36 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description en:brian0918 2005-03-18 21:04:46 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
Comment 1 Richard J. Holton 2005-03-21 18:24:06 UTC
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.

Comment 2 Zigger 2005-09-17 12:30:38 UTC
*** Bug 3479 has been marked as a duplicate of this bug. ***
Comment 3 Zigger 2005-12-29 06:54:06 UTC
*** Bug 4343 has been marked as a duplicate of this bug. ***
Comment 4 Nadav Perez 2006-02-21 12:41:12 UTC
This can be done now, AFAIK, by using the 'Related changes' link for a category.
shouldn't this bug be marked FIXED?
Comment 5 tsor 2006-02-21 12:58:29 UTC
No, not yet: What about the articles in subcategories?
Comment 6 Mathias Schindler 2006-02-21 13:05:16 UTC
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.
Comment 7 lɛʁi לערי ריינהארט 2006-02-26 20:38:29 UTC
(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'.
Comment 8 Bruno Martelli 2006-06-22 09:26:05 UTC
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).
Comment 9 omniplex 2006-06-30 13:08:14 UTC
Re #7, check out [[Help:DPL]] on Meta, not exactly what you want,
but close.
Comment 10 Ian Brandt 2008-01-12 19:24:12 UTC
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?
Comment 11 Waldir 2008-04-19 12:16:34 UTC
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.
Comment 12 Melancholie 2008-05-05 01:45:02 UTC
Since some months there is an easy way to do this, see bug 5220#c21 (web feed + Mozilla Thunderbird)!
Comment 13 Waldir 2008-05-05 11:57:32 UTC
replied in bug 5220#c24.
Comment 14 Siebrand Mazeland 2009-02-02 12:46:13 UTC
Changed component to "Watchlist"
Comment 15 Dan Jacobson 2009-05-11 06:35:55 UTC
Also noting: http://www.mediawiki.org/wiki/Extension:CategoryWatch
Comment 16 Guillaume Paumier 2009-12-29 17:44:27 UTC
*** Bug 8261 has been marked as a duplicate of this bug. ***
Comment 17 Quim Gil 2013-03-26 17:51:08 UTC
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
Comment 18 Bawolff (Brian Wolff) 2013-03-26 22:36:47 UTC
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
Comment 19 maurizio codogno 2013-03-27 10:41:00 UTC
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.
Comment 20 Waldir 2013-03-29 14:33:55 UTC
(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).
Comment 21 Waldir 2013-03-29 14:36:53 UTC
(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.
Comment 22 Bawolff (Brian Wolff) 2013-03-29 15:36:41 UTC
(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.
Comment 23 Waldir 2013-03-29 17:06:39 UTC
(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.
Comment 24 Quim Gil 2014-04-01 20:32:29 UTC
Open since 2005, inactive in the past 12 months... If we want to reflect the current plans, this should be "lowest".

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links