Are you here because you received a notification that someone mentioned your name, but you can't see your name in the diff? This happens when people transclude pages that contain a link to your userpage. Look for {{page name}} in the diff.
bugzilla:53176 (Not getting notified for reverts if Preview or Show Changes is used)
bugzilla:50829 (Echo notifications show [No page] instead of pagename if the page was deleted)
#Problems (3) above. ("My notification count only goes down to 1, even after I look at all the revert notifications. This may only occur when I have more than one page of notifications." ... "'Only when' is probably correct. When there are less than 8 hits (red number), it resets to 0.")
(Mobile editors are seeing, but can't use, the Thank links.) See archived thread.
bugzilla:52510 (Echo and FlaggedRevs) - rejected Revisions part is patched. The approved Revisions code is abandoned in gerrit as it doesn't account for some important cases. Use the FlaggedRevs icon: ?
bugzilla:54391 (Diff link in bundled message should show all diffs instead of just the last one)
bugzilla:56739 (multiple signatures in a single save break Mention Notifications)
bugzilla:56475 (The "You have new messages" link should go to a diff and/or subsection) Currently just a plain link to Usertalk. It Should link to either:
the first of unread messages
"changes since last viewed" (per old OBOD)
bugzilla:56974 users without javascript are not getting a yellow banner, unless they turn on the "Display a floating alert when I have new talk page messages" gadget, which itself appears to be aesthetically broken (close icon overlapping with text. screenshot)
bugzilla:52690 (Notification when user becomes auto-confirmed)
bugzilla:49446 (Linking a username in an Edit-Summary should trigger a notification)
bugzilla:43840 (Echo should support user subscriptions to feeds (for newsletters and publications such as The Wikipedia Signpost))
bugzilla:53564 (IP addresses should link to Special:Contributions instead of userpage)
bugzilla:44787 (Allow excluding pages from the Page Linked notifications)
bugzilla:46692 (Dismissing/removing notifications - a way to remove items from the list) [1]
(A new Notification that someone has emailed you using Special:EmailUser) [2] (A lot of people don't register with their primary email account, or don't check it frequently. Some have userpage notes warning against using email if the matter is urgent. It's more common than you might guess! Even specifically mentioned at mw:Flow Portal/Use cases#User talk namespace)
(Use Different Icons for Talkpage messages and Mentions. (See list of current icons at mw:Echo/Feature requirements#Notification Categories). To give a better visual clue on the flyout (and archive) on what just happened. - Use an @ sign icon for Mentions?)
(disable Page Linked notifications for Reverts. Eg. When someone rollsback a page-blanking vandal.) [3]
At Special:Notifications, change the max-width (currently 600px) to something larger. 60em is suggested.
Inconsistencies between the links given in the Flyout and Special:Notifications and Email
Generally, many users are asking for consistency between what is linked in Flyout/Special/Email, and they prefer the additional links given in Special.
Additionally, the flyout is confusing, because the entire background is clickable, but there is no mousepointer-change or status-bar-hint for the destination. TMg explained it well here.
Related to bugzilla:47665 ( Echo notifications should have a larger clickable surface area) which has pertinent comments.
can Mentions ever be a ~100% reliable notification method? Ie. so that linking someone at ANI counts as the "official notification" that they're being discussed? Or if the editor has opted out (of Mentions or Thanks) then somehow letting others know when they try to utilize these features? Otherwise, "a message on a usertalkpage" will remain the only '~100% reliable' method.
I'll nag Fabrice and the devs during the next few weeks, to look at this, and make bug tickets for things that don't already have one, and address the ones that do, and strike the ones that are fixed, and etc.
It's not complete, but I think it covers most of the important or multiple-requested items. Add or tweak items as needed, but try to keep it concise. I'm off into the last of sun now! and lunch... –Quiddity (talk) 23:11, 8 September 2013 (UTC)[reply]
A complete merge would make notifications unusable - I have over 400 pages on mine (which is hardly any, compared to some people) - so would never stop receiving notifications. On the other hand, I do quite like the idea of there being an option to set a notification flag on specific items when editing your watchlist, for pages that you're exceptionally interested in watching changes to (perhaps when monitoring an ongoing vandalism situation). That would definitely be useful. — Scott•talk10:05, 5 November 2013 (UTC)[reply]
Thanks for the patronizing advice there. Rather than telling people how they ought to be using one of our underperforming maintenance tools, why don't you contribute something to bug 5875, regarding being able to create multiple watchlists, which has been open since 2006? — Scott•talk10:17, 5 November 2013 (UTC)[reply]
I sorta like the idea of multiple watchlists I must admit. I just scotched the last one when it got to 10,000 and became too long to load on slow connections...Cas Liber (talk·contribs) 10:41, 5 November 2013 (UTC)[reply]
There are lots of reasons why they're a good idea - for example, I'd like to be able to watch every page I've ever created, to both protect against vandalism and also see how my creations fare over time (the history of redirects is often interesting). However, if I were to keep all the trivial stuff like redirects and talk page archives on my watchlist, it would clutter it up too badly. Having multiple watchlists would allow me to file stuff like that away somewhere that I would only need to check occasionally, rather than on the main watchlist that's my primary engagement with the project. And so on. I also think that even having multiple watchlists wouldn't obviate the utility of being able to set special page notifications, either - notifications appear while you're editing, meaning you don't have to go and look at your watchlist at all. — Scott•talk10:57, 5 November 2013 (UTC)[reply]
Multiple watchlists (and cross-wiki watchlists) are a frequently mentioned, and long-wished-for feature. mw:Watchlist wishlist and WP:Cross-wiki watchlists are the most uptodate listings that I know of.
Personally, I have... let's see... 8,885 pages on my watchlist as of today (I've been trying to unwatch things, for the last few months, so it's lower than it was). That gives me "176 changes in the last 24 hours". I'd love to have two watchlists (that I could designate/organize however I pleased. I'd go with "high-velocity discussion boards" on one, and everything else on the other. But each editor would surely go with an individual setup). More than two would get confusing, or I'd be more likely to procrastinate checking one of them. –Quiddity (talk) 19:34, 5 November 2013 (UTC)[reply]
I agree with Scott's description of the advantages of multiple watchlists, and heartily support the notion. Now, looking at the developers amongst us: is there any value in commenting on the bugzilla Scott mentioned? Risker (talk) 23:52, 27 November 2013 (UTC)[reply]
@Quiddity: The greatest think ever to happen to my watchlists has been User:Writ Keeper's inline diffs. If I had one request for improving watchlists, it would be to make such inline diff functionality available to everyone as a preference, and a way to (optionally) reset the 'checked' flag when I view an inline diff so that I don't have to visit the page again to get emails. As it is, I basically use the combination of inline diffs and watchlist emails for pages I've actually visited to triage my watchists (and I keep different watchlists on two different accounts, with one browser for one account and another for the other... eep!).--ragesoss (talk) 13:48, 28 November 2013 (UTC)[reply]
The watchlist is one of the most powerful and useful basic tools available by default to all Wikipedia editors. I strongly support having multiple (more than one or two) watchlists available, as a selectable option for more advanced editors. (The default for new editors should be a single watchlist, to reduce confusion). The multiple configurable watch lists are a classic example of letting the computers handle the detail work, and letting the human editors focus on what they do best. This feature would greatly enhance the productivity and enjoyment of Wikipedia editors. Reify-tech (talk) 16:00, 28 November 2013 (UTC)[reply]
@Risker: Re: "is there any value [...]" - Merely commenting with a note of "I support this" on a bug generally won't help push it forward - there's a "(vote)" button that is the recommended way to "+1" a proposed enhancement; I've voted for (or CC'd myself on) bugzilla:5875, bugzilla:4354, bugzilla:15244, bugzilla:33888, bugzilla:32952, bugzilla:42046, bugzilla:6964, bugzilla:9790, bugzilla:41901, bugzilla:2308 and bugzilla:3525. The only way commenting helps (in my experience, as a non-dev), is if you can provide new aspects to consider (ie. implementation details, or potential problems, or technical solutions), or if you can more clearly summarize the bug/featurerequest (and all the comments thus far) in a developer-centric manner. Reading all the past comments on a bug is often very useful (leading to personal insights, or "see also" other bugs). The other main option is to just click "Save changes" without doing anything else, which will add you to the CC: list for the bug. Note: You can set preferences on bugzilla for which actions-by-others will trigger an email to you - very handy for reducing spam.
@Ragesoss: Interesting script, I'm trying it out now. It's not immensely useful on my watchlist because I tend to use WP:Popups a lot there (skimming slowly up the column of (diff| links, each day), but I can foresee it being very useful to me on individual history pages. I'll suggest on the talkpage there, that it might be made into a opt-in Gadget, for wider testing and discovery. –Quiddity (talk) 19:09, 28 November 2013 (UTC)[reply]
I would really like this as a toggle-able setting. Those of us who would benefit from it could include this in our notifications and editors which have longer watch lists could easily opt-out. This'd be great for a number of reasons, especially discoverability of potential misuse of articles. It would also be potentially beneficial for Talk pages, albeit once Flow is implemented that would hopefully solve most associated issues. Nicereddy (talk) 05:19, 1 December 2013 (UTC)[reply]
Commons images
Hi, it would be nice to get a notification (on Commons) if one of my photos that I uploaded to Commons is added to any article in any wiki. A “page link” feature for images. Thanks, ----Stefan »Στέφανος«‽16:53, 2 December 2013 (UTC)[reply]
Yes, provided that you sign your post in the same edit. The requirements for a mention notification are that the edit adds a link to a user page, and adds the signature of the user making the edit. There's no problem with the link or the sig coming from a template. Substituting the template makes no difference to the mention notification either. – PartTimeGnome(talk | contribs)21:59, 6 December 2013 (UTC)[reply]
Disable Thanks on certain pages?
Is this possible? I ask because I am 'thanked' for my edits on the main page on a more-then-daily basis. It would be helpfull if I could, for instance, put a __NOTHANKS__ on the page. — Edokter (talk) — 11:10, 7 December 2013 (UTC)[reply]
And what if other users want to get the notification for that page? How can the system find out who added the magic word? :) --Elitre (talk) 19:10, 19 December 2013 (UTC)[reply]
The __NOTHANKS__ would cause the Thanks button to be removed for everyone. Editing the main page is a thankless job anyway... — Edokter (talk) — 20:08, 19 December 2013 (UTC)[reply]
On it.wp, the question mark in the flyout, when clicked, redirects to mw:Help:Notifications. I want to find out where I can change this to mw:Help:Notifications/it. The reason is simple, there are probably more Italian speakers than non-Italian speakers clicking on that specific link, and, especially if they are newbies, they certainly have not set Italian as their language in the Preferences on that site. So the correct page would be a click away from them, and other users have suggested that this should change. Thanks for your help, --Elitre (talk) 19:10, 19 December 2013 (UTC)[reply]
I really like receiving page link notifications on an article I created, Social network, because so many editors link to it inappropriately (usually referring to Social networking services). However, it's painful to logon and see a notification that one specific article AND a bunch of other unspecified articles have been linked to Social network with no way for me to determine which of several hundred linked articles have been recently linked to Social network. I'm wondering if the notifications could be changed so that each individual article linked has a separate, specific notification? Thanks to all who have worked on the notification project. For the most part, it's been a positive addition to WP! Meclee (talk) 23:37, 4 November 2013 (UTC)[reply]
Hmm. Interesting idea.
Fwiw, the keyword the team is using for this feature is "bundling", and you can see details about its current implementation at mw:Echo/Feature_requirements#Bundling
I guess we'd need to get some research into how many Pagelink Notifications the most active-recipients are getting, in order to determine what repercussions unbundling them, would have. @DarTar: do you know if this would be easy or time-consuming to do?
I don't have much bandwidth to look into this but I also don't think we need to spend a lot of cycles doing data analysis to answer that question. I believe unbundling pagelink notifications would not produce any damage in terms of frequency to anyone but a fairly small group of "special" editors. This is my reasoning:
pagelink notifications only target active page creators, not article contributors, so a relatively small proportion of our entire editor base.
they may become an issue only when articles are linked too rapidly from other pages
the pace of link accumulation for existing pages is too slow to be of any concern
the only real concern is for breaking news articles where links may be accumulating rapidly for articles created from scratch.
it's plausible to assume that we don't have many active page creators who routinely create these types of pages that get massively linked in a very short amount of time.
the only other exception is bulk page creators (currently the #1 recipient of pagelink notifications is a user from svwiki who mostly does just that, and this user is an outlier). These users should be aware of what happens as a result of bulk page creation, given the nature of their activity, so they will probably mute pagelink notifications anyway.
If this line of reasoning holds, I think we can go ahead and change the defaults for pagelink without seeking further evidence. I'd be obviously happy to be proved wrong on the above assumptions :) DarTar (talk) 01:08, 5 November 2013 (UTC)[reply]
The reason I'm hesitant, are comments #0 and #6 at bugzilla:44787. (#0 = linked translations. #6 = editors who help out with WP:AfC and are not personally interested in the article-topics, of which they might have created anywhere from dozens up to low-hundreds). Perhaps that ought to be fixed/resolved somehow, first? Your thoughts or alternative suggestions would be welcome. :) –Quiddity (talk) 19:45, 5 November 2013 (UTC)[reply]
This old discussion was WP:Archived like any other discussion on this page that hasn't seen any new comments for 30 days. It was archived in this bot edit. You can find this (and all other old discussions) through the archive box at the top right corner of the page. Whatamidoing (WMF) (talk) 19:41, 27 December 2013 (UTC)[reply]
?
