Last modified: 2014-10-20 23:44:36 UTC
"and finally... a nice feature would be a possibility to remove a watched article from "my watchlist" (in the "my watchlist" view)" This would be very convenient.
*** Bug 513 has been marked as a duplicate of this bug. ***
There already is the "edit watchlist" view which allows this.
(In reply to comment #2) > There already is the "edit watchlist" view which allows this. Yes, but it's a super pain in the ass, particularly if you've got a large watchlist that will take time to load and search through.
(In reply to comment #2) > There already is the "edit watchlist" view which allows this. yes but we would like it in the regular view too. instead of trying to remember several articles we want to delete while waiting for the page to load, etc.
If you install Lupin's Navigation popups, http://en.wikipedia.org/wiki/Wikipedia:Tools#Navigation_popups you can hover over an article link and then middle-click unwatch for almost the same effect, since no one with coding skills seems to see the necessity of this function... (Hopefully I can get my watchlist under 1000 again! (It's like a weight-loss program.))
Perhaps the watchlist view and edit pages ought to be unified - there should certainly be an unwatch link next to entries on the regular watchlist.
(In reply to comment #6) > Perhaps the watchlist view and edit pages ought to be unified - there should > certainly be an unwatch link next to entries on the regular watchlist. Absolutely. For now, I've written a little script that adds an "un"(watch) link next to the "diff" and "hist" links. I'm not really a coder and I haven't tested it much so point out any bugs on my talk page. Look for function unwatchlinks() on http://en.wikipedia.org/wiki/User:Omegatron/monobook.js and also add something like if(document.title.indexOf("My watchlist") == 0) unwatchlinks(); to your Main() loader or whatever. You still have to click the link and load the "Removed from watchlist" page, but it saves some steps. If you middle click in Firefox you can go through a bunch at a time. If I really knew what I was doing, there would be a little link on the left of each article in the watchlist that lets you unwatch it, and the article link would turn gray or something to show that it was unwatched, without actually opening any other pages. On refresh the unwatched ones would disappear. I just learned how to do this much, though.
Perhaps a user could set a "max number of watched items" parameter in his preferences. If he then adds a new watched item that takes him over his limit, the software would drop the oldest watched item from his list.
Better version at http://en.wikipedia.org/wiki/User:Quarl/unwatch.js
See also http://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Scripts/Unwatch
*** Bug 5300 has been marked as a duplicate of this bug. ***
I'd like to endorse this ER and was about to make the same suggestion. The trouble with the edit view is that the watchlist is presented in alpahbetical order. I mostly want to unwatch articles if I get tired of seeing them on my regular watchlist. I do use navpops for that, but it's still a hassle because of the extra window it makes, and the extra clicking and mouse motions needed. I suggest replacing the bullet at the left of each watchlist item displayed in the regular view, with a checkbox. You'd then just check the box for each item you want to unwatch, and finally press a "submit" button at the bottom of the page.
(In reply to comment #12) > You'd then just check the box for each item > you want to unwatch, and finally press a "submit" button at the bottom of the page. The javascript unwatch links are better. Just push "unwatch" next to the ones you don't want to see anymore, and they go away. One click is better than two clicks and a scroll.
Any update on this enhancement from the developers?
(In reply to comment #14) > Any update on this enhancement from the developers? "The official position was that bug 424 has not been implemented at this time."
(In reply to comment #13) > > The javascript unwatch links are better. Just push "unwatch" next to the ones > you don't want to see anymore, and they go away. One click is better than two > clicks and a scroll. The problem with unwatch links is that they clutter up the already cluttered interface. Now, I don't personally mind that at all, compared to how useful they are, but for something that would be enabled by default for all users, checkboxes might be a cleaner solution. You could still press enter rather than scrolling down and clicking the submit button. That's one click per entry plus one keypress, which compares favorably with my own scripts if you want to unwatch more than one entry at a time. The AJAX solution is probably unbeatable in terms of click count, but for general use, the checkboxes have the major advantage of not requiring AJAX or even JavaScript at all.
*** Bug 9502 has been marked as a duplicate of this bug. ***
Since nobody seems to have mentioned it yet, there's an absolutely phenomenal script on en.wp written by [[User:Alex Smotrov]]. It's located at http://en.wikipedia.org/wiki/User_talk:Alex_Smotrov/wlunwatch.js. I've been using it for ages, and I really like the way you can have it add an Unwatch... link, which only adds the removal links if you click it first. That decreases clutter quite well.
*** Bug 12626 has been marked as a duplicate of this bug. ***
Okay, I don't know if this bug is really in line for what I was looking for, but frankly, Bugzilla isn't really forgiving in what to search for... I was looking for a way to click a button that would allow me to select all deleted pages on my watchlist and remove them off my watchlist...
Re: comment #20, would [[User:Ilmari Karonen/unwatchredlinks.js]] do what you're asking for? (The script will only select titles that don't have existing talk pages either. As an unintended -- but probably desirable -- side effect, it will not select user pages of existing users either.)
Changing component to "Watchlist"
A while ago I found a JavaScript implementation. Recently during my tour through wikis I found it again and 'had' to rewrite it to work with Vector (as it was kinda broken). I took the oppurtunity to optimize it a bit and shorten it with jQuery, posted it in the Snippets section: * http://www.mediawiki.org/wiki/Snippets/Unwatch_from_watchlist That can be used for people using 1.17, 1.16 or older, assuming it will be in core by 1.18+
This will be a very useful enhancement
Add a link to action=unwatch next to (diff | hist) in the brackets.
http://www.sociotopia.com/wiki/watchlist_unwatch.patch ^I have created a patch that adds the unwatch link to watchlist recent changes lines. Currently, system messages only has the string "Unwatch" capitalized which is not consistent with the lower case diff and hist links. I am still new to developing for Mediawiki, so I'd really appreciate it if someone reviewed my code and gave me feedback, even if the JS fix is sufficient for the time being. I am interested in preparing a proposal to overhaul the watchlist page for GSOC. The scope of my project would include: *a way to group similar pages into subdirectories (e.g. Special:Watchlist/GroupName) *allowing bulk watchlist modifications (rollback/unwatch) with checkboxes *unify the "watched changes", "view/edit" sections *incorporate ajax for actions that don't require a page reload (if time allows) Does anyone have additional features/bugs that they'd like to see added/fixed on the watchlist? Please provide links to bug requests if they exist. Any other advice is appreciated - thanks.
Aaron, can you submit the patch as an attachment here in Bugzilla? https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes has instructions. Thanks. You should probably also email the wikitech-l developers' mailing list to get more feedback, and come into IRC -- https://www.mediawiki.org/wiki/Communication Thanks!
(In reply to comment #26) > http://www.sociotopia.com/wiki/watchlist_unwatch.patch > Hi Aaron, The general idea of the patch looks good. The surrounding code offers most of the functionality already. This extends it nicely to add the unwatch link. > if( !isset( $this->message ) ) { >- foreach ( explode( ' ', 'cur diff hist last blocklink history ' . >+ foreach ( explode( ' ', 'cur diff hist last blocklink history unwatch ' . > 'semicolon-separator pipe-separator' ) as $msg ) { > $this->message[$msg] = wfMsgExt( $msg, array( 'escapenoentities' ) ); > } As you mention already this re-uses the message key "unwatch" (which is used elsewhere in the interface) for the link here. We try to avoid re-using messages for different purposes as translators can otherwise not translate it properly (although it is the same word in English, for other languages it might differ). This code was written several years ago when message keys were very generic. I suggest using a key like "watchlist-toollink-unwatch". And then in ./languages/messages/MessagesEn.php add it with a lowercase message value "unwatch" and in ./languages/messages/MessagesQqq.php add a short description about where the message is used and what it does (e.g. "unwatch link on Special:Watchlist) I was wondering about this part of the patch: > if( $szdiff === 0 ) { >- return "<$tag class='mw-plusminus-null'>($formatedSize)</$tag>"; >+ return "<$tag class='mw-plusminus-null'>($formatedSize)<$tag>"; > } elseif( $szdiff > 0 ) { >- return "<$tag class='mw-plusminus-pos'>(+$formatedSize)</$tag>"; >+ return "<$tag class='mw-plusminus-pos'>(+$formatedSize)<$tag>"; > } else { >- return "<$tag class='mw-plusminus-neg'>($formatedSize)</$tag>"; >+ return "<$tag class='mw-plusminus-neg'>($formatedSize)<$tag>"; > } What is the purpose of this? It appears this is a bogus change not meant to be part of the patch (it changes the 3 <span>..</span> HTML tags into double-opening without closing tags. >+ $s .= Linker::linkKnown( >+ $rc->getTitle(), >+ $this->message['unwatch'], >+ array(), >+ array( >+ 'curid' => $rc->mAttribs['rc_cur_id'], >+ 'action' => 'unwatch' >+ ) As of MediaWiki 1.18 watch/unwatch require a token. Use UnwatchAction::getUnwatchToken
Thanks for your feedback. The tag change might have been some hasty find/replace work on my part. I'm working on adding the new unwatch string and tokens to my code.
Created attachment 10384 [details] added Krinkle's suggestions I have uploaded a new version of the patch - any comments are appreciated. Thanks.
Aaron, feel free to get and use Developer access https://www.mediawiki.org/wiki/Developer_access to submit this directly into our source control system for faster review. https://www.mediawiki.org/wiki/Git/Workflow#Getting_set_up Thanks!
(In reply to comment #30) > Created attachment 10384 [details] > added Krinkle's suggestions > > I have uploaded a new version of the patch - any comments are appreciated. > Thanks. Thanks, nice improvement. I'll see if I can give this a try locally soon. Someone else is of course welcome to review it instead, as well. In the mean time, maybe you're interested in getting a Developer account (check Sumana's comment), that way you can submit it directly to the review queue.
(Review of attachment 10384 [details]) >Index: ./phase3/includes/ChangesList.php >=================================================================== >--- ./phase3/includes/ChangesList.php (revision 112982) >+++ ./phase3/includes/ChangesList.php (working copy) >@@ -103,7 +103,7 @@ > */ > private function preCacheMessages() { >- foreach ( explode( ' ', 'cur diff hist last blocklink history ' . >+ foreach ( explode( ' ', 'cur diff hist last blocklink history unwatch ' . i18n file uses "watchlist-toollink-unwatch" but here it says "unwatch". Please make it match and update the array access (->['unwatch']) as well > public function insertDiffHist( &$s, &$rc, $unpatrolled ) { >+ global $wgUser; No need for the global anymore. In the current git master ChangesList.php has been updated to use Context. Below you can pass $this->getUser() directly to the UnwatchAction method. >+ 'action' => 'unwatch', >+ 'token' => UnwatchAction::getUnwatchToken( $rc->getTitle(), $wgUser ) >+ ) >+ );
Why don't you do this with js completely... I mean if you want to make it as good as possible then make it ajax and if you want to make it ajax you kinda need js... jquery takes care of 90% of the individual browser bugs and even so, this is simple and even IE should be able to take care of this... I can give some code for this if needed.
Aaron, what's the status on this?
Hi, I am new to mediawiki development and I thought of starting off with this bug. I had 3 alternatives in mind. 1> As pointed out in Comment 34, I was thinking of handling the whole situation in Jquery. We could have an unwatch link just like (diff|hist|unwatch) and on clicking that it would simply slide up signifying it to me unwatched and behind the scenes we can have an ajax call which can take successive actions. 2> We can also think of having a checkbox for each watched item which can be "Marked" and at the bottom of the page we can have a button "Unwatch all checked items" - a procedure similar to the standard view of Gmail 3> Or should I proceed in the direction of the already submitted patch? Please share your thoughts upon this.
I'm setting the target milestone of this bug to MediaWiki 1.22. Come hell or high water, this bug is getting resolved before MediaWiki 1.22 is released. Krinkle: you're listed as this bug's assignee. Is this still accurate?
I'm copying a few talented people on this bug. It's still a little unclear what the best path forward here is. There's a concern that a lot of "(unwatch)" links would add clutter. As far as I see it, the hard requirements here are that this feature: * be in MediaWiki core; and * not rely solely on JavaScript.
As the Target Milestone on this ticket has been set to 1.22.0: According to http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072030.html "MediaWiki 1.22 is slated for release on November 30th, at the very latest." If this is still intended to get fixed for 1.22.0, a patch is needed soon.
Removing 1.22 Target Milestone as per http://lists.wikimedia.org/pipermail/wikitech-l/2013-October/072538.html - in case anybody manages to get a bugfix into Gerrit, feel free to reapply.
Krinkle, do you still plan to work on this?
(In reply to Quim Gil from comment #41) > Krinkle, do you still plan to work on this? Bump. If there's no response in a week or two, we should probably un-assign.
Note that it wasn't status ASSIGNED. It was merely assigned to me. I tend to use that as things in my area that I'd review or look after. Only with it has state ASSIGNED is it something I'm actively "assigned" to work on myself.
*** Bug 70924 has been marked as a duplicate of this bug. ***
