Last modified: 2014-11-17 10:36:10 UTC
Please consider providing wikimedians with crosswiki watchlists. Such could also be made public as an option. ACrush
Hallo! *benefits* This would help to save a lot of time. *disadvantages* If the number of changes for [[special:Watchlist]] is limited there are scenarios where the changes from major wiki's would make it impossible to see the "events" from the local wiki's watchlist. *implementation* a) It should be possible to select / deselect - the local part - the global part b) For sites with a great number / amount of wiki's each user should have the possibility to select the "watched wiki's" using checkboxes. Buttons as "select all" / "deselect all" should be available too. best regards reinhardt [[user:gangleri]]
Bug 3544: Single Recent changes on several mediawikis is related to the implementation od a crosswiki "Recentchanges". If both will be implemented the functionality should provide the same options. best regards reinhardt [[user:gangleri]]
*** Bug 12778 has been marked as a duplicate of this bug. ***
*** Bug 13605 has been marked as a duplicate of this bug. ***
until this bug is fixed you can use http://tools.wikimedia.de/~luxo/gwatch/ - one watchlist for all wikimedia-projects.
In some extent bug 5220#c21 (web feed + Mozilla Thunderbird) could help! All wikis, but only one email/news account. @public viewing: Maybe "Google reader" etc. could be a help.
Re public viewing: See Bug 471 for a related bug, as all the issues that apply there apply to this bug as well. Ideally, this bug should be split into cross-wiki and public viewing parts of the bug, although the latter would be redundant to Bug 471 as well.
*** Bug 14488 has been marked as a duplicate of this bug. ***
*** Bug 16695 has been marked as a duplicate of this bug. ***
Changing component to "Watchlist"
*** Bug 17914 has been marked as a duplicate of this bug. ***
Retargetting: this is clearly a CentralAuth feature-request; and splitting the bug as suggested: comments on the "with option for public viewing" part --> bug471.
Now that bug 471 has been fixed, a new tool has been developed to allow this. It could still use some polishing, but I thought it'd be worth mentioning here: http://www.watchlistr.com
I'm thinking that either a new field, identifying the wiki on which the page is located, will need to be added to the watchlist table, or a whole new table will need to be created to store the necessary data. If unified logins are in effect, it does seem to make sense to tie that in with this functionality. So then, what strategy should be used to implement this? Create a branch of CentralAuth, get code review approval, and then merge into the trunk? Or create another extension that relies on this extension without being an integral part of it?
I will attempt to implement this.
Related reading: http://strategy.wikimedia.org/wiki/Proposal:Global_watchlists http://strategy.wikimedia.org/wiki/Proposal:Common_watchlists
Looks like global watchlist will be a side-effect (!) of the new notification system: <https://www.mediawiki.org/wiki/Thread:Talk:Echo_(Notifications)/Bundling_and_expiry>
Victor: This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED. In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help! [assigned>=1y]
Victor, I'd like to echo Andre's comment above; are you still interested in working on this feature? There's a renewed interest in a global watchlist now that SUL is being finalized: [[mw:Watchlist wishlist]]. It would be great it you could confirm your interest in working with users to implement this, or let other developers know if you don't currently have the time. Thanks!
(In reply to comment #19) > It would be great it you could confirm your interest in working with users to > implement this, or let other developers know if you don't currently have the > time. In my opinion, it's not a question of whether Victor has time to work on this. It's a question of whether anyone has time to review code that Victor puts together for this. As a volunteer contributor, he's had enormous difficulty getting his code reviewed in a timely manner.
If there is no objection, I'd like to fix this bug. I'm going to try a different approach than what I did last time with the InterwikiIntegration extension; rather than duplicate all the code that implements the watchlist special page, I'll either (1) make the core code more extensible or (2) implement the interwiki watchlist as core functionality. Does anyone have a preference for one of those two options? Personally, I'm for the latter.
(In reply to comment #19) > Victor, I'd like to echo Andre's comment above; are you still interested in > working on this feature? > I am interested, if there are people interested in reviewing the design of that feature. I had a ~working prototype of it, which I made, IIRC, during one of the Wikimanias I attended. It is, however, probably lost because it was done in a pre-git era when branching was hard and I have no idea where it is. The back end part basically requires that you maintain a global recent changes table, since reading RC tables from all individual wikis is not feasible. That is not really hard, as long as you make sure that you mirror all revision deletion correctly. Surprisingly, the front end is the more problematic part here. When I tried to work on it, the UI code for watchlist showed active resistance to being adopted for the cross-wiki purposes.
Victor: Yeah, you'll need to add new parameters and such to quite a lot of functions. However, I think it will be well worth it, because it will save users quite a lot of time checking all the different watchlists in the WMF wiki farm. I too made a working prototype of it that used a global recent changes table, but the interwiki watchlist special page UI duplicated much of the code from includes/specials/SpecialWatchlist.php (the existing single-wiki watchlist). It would be better, of course, to reuse code as much as possible by changing the existing functions to handle both single-wiki and interwiki use cases. Let me know if you get too busy and want to hand this off to me; otherwise, I'll leave it in your able hands.
I wrote a small proof of concept script to do this completely client side: https://github.com/legoktm/xwiki-watchlist/blob/master/xwikiwatchlist.js The basic concept is that you just make API requests to each wiki, pull the watchlist, and merge it with the changes made on other wikis, and nicely display it to the user. This also makes it easy for users to pick which wikis to include/exclude. That said, I'd love to see a sever side solution to this bug :)
(In reply to Victor Vasiliev from comment #22) > > Victor, I'd like to echo Andre's comment above; are you still interested in > > working on this feature? > > > I am interested, if there are people interested in reviewing the design of > that feature. > > I had a ~working prototype of it, which I made, IIRC, during one of the > Wikimanias I attended. It is, however, probably lost because it was done in > a pre-git era when branching was hard and I have no idea where it is. Victor: So is there any initial code currently to share?
(In reply to Andre Klapper from comment #25) > Victor: So is there any initial code currently to share? I did a quick search through my local source copy and did not find anything.
*** Bug 65969 has been marked as a duplicate of this bug. ***
