Last modified: 2014-11-18 13:14:26 UTC
Per generally favorable discussion at [http://en.wikipedia.org/wiki/Wikipedia_talk:Enforce_inclusion_of_categorie s], we would like a function to permit users to watch for additions to or deletions from categories, in order to quickly address improper additions and deletions.
This is going to be practically impossible to implement unless we start versioning category links.
*** This bug has been marked as a duplicate of 4605 ***
Okay, this has been marked of a duplicate of a duplicate of a duplicate of a FIXED, so something went wrong here. Special:Recentchangeslinked is *not* a substitute for category watchlist, because a) it doesn't show articles' removal from the categories and b) it provides vastly more noise than signal (probably 95% of changes are going to be unrelated to the category itself).
The issue that has been resolved is different from the request. Earlier requests appear to have sought a "related changes" list emanating from a category. We would like a watchlist type function (only the most recent change would need to be shown) so that a group of categories can be watched simultaneously, and an entry will appear on the list when an addition (or subtraction) is made to any of those categories. Changes to the content of the articles in the category are unimportant; what matters is the ability to see when an article is added or removed.
This isn't a duplicate, irrespective of possible (hopefully not) WONTFIX, so I'm reopening.
Comment 1 still stands.
How hard can it possibly be? When I add a category to an article, some kind of information transfer must occur to let the category know the article has been added to it. Same thing with category removal. Catch those signals and make 'em light up a watchlist.
The problem is that "lighting up a watchlist" requires storing the information somewhere. Watchlists aren't generated from a big list, but from a SELECT which looks at who's watching what, and what changed recently.
*** Bug 10225 has been marked as a duplicate of this bug. ***
An additional complication is that membership may be conferred or removed indirectly through changes to templates -- or even conditional statements using time-sensitive variables. Since there isn't necessarily an editing action with which to associate such a change, it might be a little tricky to work out how to stuff it in there... But something's probably possible. A special recentchanges table entry could perhaps be generated for each categorylinks change when doing differential updates (similar to the log entries, these would not be associated with any page revision record).
Should work with a javascript tool http://en.wikipedia.org/wiki/User:Ais523/catwatch.js currently used on the English Wikipedia.
"RESOLVED FIXED" for bugs filed under the MediaWiki product implies that the bug has been fixed in the default MediaWiki software (implying all Wikimedia sites plus all third-party sites when they respectively update). It has not. Furthermore, a JavaScript solution to this is not acceptable for inclusion in the core software: it has to be solved in the PHP, for reasons of efficiency, accessibility, and speed. The first paragraph of the opening comment on the linked hack shows that the hack used has serious limitations anyway.
I thought someone might do that. :)
(In reply to comment #11) > Should work with a javascript tool > http://en.wikipedia.org/wiki/User:Ais523/catwatch.js currently used on the > English Wikipedia. > That, of course, is merely a user script, not a software feature, and has several limitations (as mentioned above). If this is implemented in the software, though, it might be useful to have an option to ignore removals from a category (like the script does due to necessity, as removals can't be deduced from the categorylinks table); I use the script for watching (among other things) [[:w:en:CAT:HELP]] and [[:w:en:CAT:PER]], when in both cases an addition to the category is a much more useful thing to notice in the watchlist than a removal would be (and I suspect the same applies to other 'work-queue'-type categories.)
But for something like [[Category:Living people]], you definitely want to watch removals. Better to give more information than less, if we aren't going to give an option.
Presumably at *some* point the wiki software recalculates the category membership. That's a good place to add some behaviour. One option would be, rather than have a change record, to have a way of dumping the category membership out in strict textual list form. With that ability, the wiki software could dump this category list into another associated article- for example [[WP:CategoryChanges/Rocketery]] would be associated with [[Category:Rocketry]] Then the user could just do a watch on that article if they require it. It would be desirable, but perhaps not essential that the list not be recalculated immediately so that if a template causes thousands of changes that you not get thousands of versions produced, just one, ideally by delaying it by a time period, 5 minutes or something might be desirable.
(In reply to comment #16) > Presumably at *some* point the wiki software recalculates the category > membership. That's a good place to add some behaviour. Yes, during article edits/jobs. However, this would still take considerable effort to do, in practice: creating a new recentchanges-style table for category changes, and maybe using a covering index on a designated server the way we do for watchlists. Or whatever. > One option would be, rather than have a change record, to have a way of dumping > the category membership out in strict textual list form. With that ability, the > wiki software could dump this category list into another associated article- > for example [[WP:CategoryChanges/Rocketery]] would be associated with > [[Category:Rocketry]] > > Then the user could just do a watch on that article if they require it. Probably not as clean an idea as a dedicated database table. You'd have these weird article revisions in the database that aren't actually article revisions, which would cause who knows what problems. Plus if these are only kept around for watchlist, we don't really need to keep them forever the way we do revisions.
If you're keeping old revisions of articles anyway, there's no major harm. And you can always get rid of old revisions by deleting the log article and recreating it. Sure, it's probably not *as* clean, but it may be a lot less work.
It would probably not much less work. In the dirty case you want an extension to hook LinksUpdateComplete, calculate the link changes and write it to a page. In the neat case, you want a function which is called just before the LinksUpdateComplete hook, calculate the link changes and write it to a table in the database. Then you want a special page to actually view the contents of that table. So it is not very much more work. Besides any extension that uses the dirty way of doing it is definitely not going to pass the sysadmins.
Or perhaps rather than build it in to the wiki, just create a bot to go around once a day or so and simply list/snapshot any selected categories in textual form and submit that to an associated log article. If they haven't changed, then the submit will be textually identical and ignored by the wiki and no watchlists will trigger, but if they have, existing watchlist mechanisms are good at detecting deltas. Provided the bot uses archives in a sensible way I don't see that the versions are likely to be a problem, and by doing this periodically the number of versions is sharply constrained anyway.
Changing component to "Watchlist"
Also noting: http://www.mediawiki.org/wiki/Extension:CategoryWatch
*** Bug 28396 has been marked as a duplicate of this bug. ***
I want to request the same thing and would like to see some action on this. The last comments sound more promossing than the beginning :) Here's the content of the dupe I created: Watching: When I "follow" a category I will be informed about new pages in that category. Currently there is no way stay informed about new articles on topics I'm interested in. Informing the user: The user could be informed about new pages in categories he follows in different ways (maybe a user pref): - on a special page, e.g. Special:Dashboard. Just like the Watchlist he may be able to edit the list of followed categories here too. - via e-mail - via RSS. The feed should be unique so I can't guess other people's RSS feeds. If it's live (via special page) or just by a daily script (via e-mail and RSS) wouldn't matter much to me. It'd be all better than current situation. Scenarios to think about: What happens if * a users starts following his first category. (His list would be empty, since nothing was added since he started following it. Maybe the last page added should be listed as a dummy.) * a page in a watched category is moved (title should be updated in relevant table) * a page in a watched category is deleted * a page is added to a followed category days after page creation * a page is removed from a followed category before teh user saw it * the user follows 100 or categories (using a max value may be possible but should be avoided) * the user follows a main category (such can include thousands of pages) (maybe a blacklist of non-followable cats would help)
*** Bug 41014 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > *** Bug 41014 has been marked as a duplicate of this bug. *** Thanks, but I was trying to say that in the current situation, at least some warning should be given to the user that he will only be "watching" part of what he sees, in contrast to non-category pages, where "what he watches is what he gets."
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
(In reply to comment #27) > 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 I do not believe this is a suitable gsoc project. Doing this bug right does not appear to be straightforward and thus not something I would reccomend to someone with little experiance. If there was a *student* who was particularly interested in doing this, I would suggest they post a detailed plan of their proposed approach on the bug so we can give feedback to the approach's feasibility. I do not think we should suggest this bug to students unless they are already interested.
Question: Would it be easier to resolve this by using notifications, instead of watchlists?
Andy, I think the difficulty is not in the getting-the-news-to-you bit, but in the defining-what-the-news-are and capturing-the-news-effectively bits. (See Comment 10 for example.)
FYI: https://en.wikipedia.org/wiki/User:Svick/CW http://svick.org/CatWatch.aspx
I hacked me around this by using favorites and filtering new pages by faved categories. Favorites is another thing MW misses...
