Talk:Echo (Notifications)

Jump to: navigation, search
Start a new discussion


Thread titleRepliesLast modified
How can I install this extension?213:13, 16 January 2015
Mentions require signature with timestamp?710:52, 19 November 2014
More than 2,000 Notifications, will start to be removed302:57, 21 October 2014
Colours of "Messages" and "Alerts" tabs412:30, 14 September 2014
JavaScript API207:31, 2 August 2014
Is it possible to use Echo to be personally notified about...608:43, 26 July 2014
Create a notification for all users304:50, 10 June 2014
How to insert a JS hook after mw-echo-overlay?409:40, 25 May 2014
Too many notifications sent by the Translate extension without any actual modification, to my mailbox002:45, 18 December 2013
Global notifications216:33, 5 December 2013
Request for a notification419:07, 30 November 2013
Echo and mobile apps223:23, 26 November 2013
Top of the page hidden on mobile200:15, 23 November 2013
Why can't we thank IPs?200:12, 23 November 2013
User rights in local languages203:14, 21 November 2013
Add new feature to Echo200:18, 19 September 2013
Before deployment on deWP220:12, 11 September 2013
Deployment roadmap721:12, 5 July 2013
Enable Echo to Other wikipedia 101:11, 5 July 2013
Buckets315:03, 22 June 2013
First page
First page
Previous page
Previous page
Last page
Last page

How can I install this extension?


I'm a bit confused whether I should install the Extension:Echo or if there's a new version being developed with the "Notifications" name. I can't find an extensions page for that. Any ideas?


Alex Stacey (talk)19:11, 15 January 2015

Those are just different names for the same software. "Notifications" is just the informal-but-practical name, because "Echo" is so 'code-word-ish' for end-users.  :-)

Quiddity (WMF) (talk)22:28, 15 January 2015

Excellent. Thanks for the clarification.

Alex Stacey (talk)13:13, 16 January 2015

Mentions require signature with timestamp?

I've been testing this out on our corporate wiki (currently MW 1.23.2). It seems like for a mention to work, it has to include the wiki-link to the user page I'm mentioning followed by a wiki link to my user page AND a timestamp. Is that correct? I'm curious if it would be possible to make use of the functions that determine who made an edit and when (like what is used for the Recent Changes page) instead of relying on a signature. In my tests, even if I use both usernames in links (the "to" and "from"), but don't include a timestamp, it seems to not be recognized by Echo as a mention event.

Darenwelsh (talk)17:54, 13 November 2014

Yes, it's correct. There are also other checks, for instance if you remove a line then it's not considered a message so the mention doesn't go out.

Nemo20:45, 13 November 2014

Could you explain the reasoning behind using the link to user page and timestamp in the signature instead of the methods that are used to create Recent Changes?

Darenwelsh (talk)21:21, 13 November 2014

What are "the methods that are used to create Recent Changes"?

Nemo22:29, 14 November 2014

My point is that for every page revision, there is a record of who made the revision and when it happened. So why not use that information instead of relying on the signature? The way that it is working now, if your signature doesn't include a link to your user page, it doesn't work.

Darenwelsh (talk)22:51, 14 November 2014

The signature is "only" used to (help) determine whether an edit is a new message or not. The extension checks the edit in the moment it's saved, it doesn't parse the whole talk page looking for new messages if this is what you were "afraid" of.

This was decided in the specifications: Echo_(Notifications)/Feature_requirements#User Mention (I didn't make them).

Nemo07:46, 15 November 2014

More than 2,000 Notifications, will start to be removed - This update adds a script to delete any Notifications that are older than the most recent 2,000.

Up until now, they were stored indefinitely, meaning that some users have many thousands of read Notifications adding up in the database. 2,000 was chosen, because it is the number of Notifications that the "mark all as read" button effects.

Quiddity (WMF) (talk)22:09, 16 September 2014

This change is mainly intended to reduce a performance bottleneck.

It will also enable future separation (perhaps even filtering) of the different types of Notification. There's a tangential discussion about some feature-requests related to this, at en:WP:VPI#Can we have a color scheme for the notifications count, please, and, if not, perhaps some other color than red? currently.

Quiddity (WMF) (talk)16:37, 19 September 2014

What if I want to preserve important notifications and delete the newest instead?

Ricordisamoa02:40, 21 October 2014

For indefinite preservation, I think the best option would probably be to enable the "email" preference for whichever notification types you want to keep records for.

Is there a particular type(s) of notifications that you're thinking of? Giving a few examples almost always helps. :)

Quiddity (WMF) (talk)02:57, 21 October 2014

Colours of "Messages" and "Alerts" tabs

Echo "Messages" and "Alerts" links.png

Using web browsers for quite some time, I grew accustomed to having blue colour mean "I can click on this" and gray to mean "I cannot click on this". But here, it is precisely the opposite. I spent half a minute frantically clicking "Messages" to read the notification before it occurred to me to click on the other link. Who is responsible for this idiocy?

Keφr15:21, 5 September 2014

I filed that as bugzilla:69929. I'll check to see what the status is. Thanks for the nudge.

Quiddity (WMF) (talk)19:24, 5 September 2014

Also, when I get a notification on the "Alerts" tab, the "Alerts" tab should show up by default after clicking the notification button. No-brainer, really. Right now it always shows "Messages" by default.

Keφr17:56, 8 September 2014

That's bugzilla:70461 and was fixed today :)

Quiddity (WMF) (talk)04:57, 9 September 2014

Good to see. Though as for bugzilla:69929#c2, I would prefer something more traditional...

Firefox 2 Tabbed Browsing GNU-Linux.png

Keφr12:30, 14 September 2014

JavaScript API

Is there a JS API to add notifications? I'm maintaining a gadget that shows a message in my personal bar if there are any articles in a speedy deletion candidate category. It would be great if it could use Echo to show a notification instead. Is that possible?

Danmichaelo (talk)08:54, 26 July 2014


Nemo12:37, 26 July 2014

Is it possible to use Echo to be personally notified about...

  1. special community initiatives starting, such as a "Backlog of the week"-drive (on it.wp watchlist notices were introduced just recently and anyway site-wide notices are not really welcome);
  2. specific templates being added to an article, such as "Unreferenced"?

Both the requests are from the Italian Wikipedia community. Thanks,

Elitre (WMF) (talk)14:52, 11 November 2013

Bumping this. Also adding:

  1. what if wikiprojects newsletters, instead than being delivered to single users, were delivered just to the talk page of the project itself while users only get a personal notification that this happened?
  2. does any wiki use a template to notify several users at a time? i.e. something like {{Echo|Elitre|Quiddity|Ironholds|...}}?


Elitre (talk)12:47, 20 December 2013
  1. Are there plans to let users choose which pages they want to get notifications for?
Elitre (talk)12:50, 20 December 2013

Ack, sorry Elitre, I thought I'd replied to this thread ages ago.

  • Re: special community initiatives - It's not currently possible to send Notifications to thousands of users at once. (there's a hard limit of 100.)
  • It's not currently possible to use Echo for that second idea, but it's an interesting one. That's the kind of thing that Flow might eventually solve (because it's more of a workflow&collaboration idea, rather than a "messaging" idea)
    • However, there's Svick's system of "CleanupListingByCat", eg Jainism which might be adaptable by Italian code gurus?

  • Template to ping multiple users:
    • Enwiki has a few. Basically anything that strings together userpage links will work. See en:Template:Reply to, and also the "Related templates" section at the bottom there.
  • Newsletters delivered to a central page -
    • Current best method is to use Extension:MassMessage to send a short talkpage message, pointing to the central location. That way readers can archive or read at leisure, and it advertises the info-source to other talkpage-followers.
    • See also Extension:Newsletter for some closely-related ideas about exactly this.

  • Choosing which pages users get notifications for -
    • There's a request for bugzilla:44787 ("Allow excluding pages from the link notifications").
    • There's also a User blacklist currently implemented (for bots etc) to prevent Mention notifications.
    • I don't think there are requests for excluding other notification types, if you were thinking of something else?
Quiddity (talk)06:51, 21 December 2013

Thanks, Quiddity! What about pages I didn't create but I want to receive notifications for?

Elitre (talk)11:23, 21 December 2013

Hmmm, interesting idea! I think the 2 notification-types of

  • Page links
  • Page reviews

would be specifically what you mean?

Again, I'm not sure if this crosses over into a requested Flow-feature (rather than an Echo-feature)... It's very similar to some of the workflows that are being considered as potential parts of Flow (eg. finding out that a page on my watchlist was tagged for AfD, or a page connected to one of my wikiprojects was submitted to FeaturedArticleCandidates, or etc). We're/They're still trying to find the balance of how to use Echo most effectively, but without turning it into something too feature-heavy, at the same time as brainstorming how Flow could work. As always, more thoughts and suggestions would be great! :)

Quiddity (talk)21:40, 22 December 2013

There's also an interesting template on Wikidata: d:Template:Ping_project, which notifies a list of users without showing the list in the message.

Danmichaelo (talk)08:43, 26 July 2014

Create a notification for all users

Hello, i own a private Wiki and have a question for you guys: is it actually possible for admins/bureaucrats to create individual notifications that reach all users? This would be a nice feature to inform the community about the important stuff goin' on (like important discussions, new guidelines, elections etc.) regards, genjack

GenJack16:44, 26 April 2014

No, it isn't. Such a feature has been developed as Extension:MassMessage, which doesn't use Echo yet because Echo has never figured out a way to be integrated with other stuff.

Nemo09:44, 27 April 2014

What you want is currently tracked as bugzilla:56361.

Legoktm (talk)05:36, 28 April 2014

I think this is a great idea. I'd love to be able to get messages to only groups of users, as well, like "To all admins, the deletion policy has changed significantly" (or whatever that particular community believes is appropriate to announce).

WhatamIdoing (talk)04:50, 10 June 2014

How to insert a JS hook after mw-echo-overlay?

There are no problems with running a personal script after downloading of the dedicated Special:Notifications page, but I do not know how to do it after downloading of the notifications popup as

<div style="display: block;" class="mw-echo-overlay"> </div>

It seems to me that hooks added with jQuery(document).ready() are not called then. There are docs at but I am not a DHTML expert and can’t find easily the thing I need. Suggestions?

Incnis Mrsi (talk)12:24, 19 May 2014

To clarify, are you trying to run some JavaScript after the flyout is shown? I don't think there is currently a way to do that, but we can add a hook point if you have a use-case for it.

Legoktm (talk)17:51, 19 May 2014

Yes, I’m trying to run some JavaScript after "mw-echo-overlay" is shown. Of course, I have not access to the MediaWiki installation (it is Wikipedia).

Incnis Mrsi (talk)05:03, 20 May 2014

Ok, turns out a hook for this already exists.

mw.hook('ext.echo.overlay.beforeShowingOverlay').add( function( $overlay ) {
// javascript you want to run
} );
Legoktm (talk)21:30, 24 May 2014

Thank you much, this hook is exactly what I needed for my notifications’ processor at ru:Участник:Incnis Mrsi/неОбсуждение участника.js.

Incnis Mrsi (talk)09:40, 25 May 2014

Too many notifications sent by the Translate extension without any actual modification, to my mailbox

A thread, Thread:Talk:Echo (Notifications)/Too many notifications sent by the Translate extension without any actual modification., was moved from here to Project:Support desk. This move was made by Jdforrester (WMF) (talk | contribs) on 18 December 2013 at 02:45.

Global notifications

Needs global notifications

Xusinboy Bekchanov (talk)16:30, 4 December 2013

I had started work on a draft at Requests for comment/Global notifications, however I currently don't have the time to follow it up.

Legoktm (talk)04:04, 5 December 2013

Thank you!

Xusinboy Bekchanov (talk)16:33, 5 December 2013

Request for a notification

Can we have a notification when a file we upload on Wikipedia/Commons is added to any article on any project? I guess this is planned when cross-wiki notifications will be up and running, but I'm still adding it as a reminder :)

Elitre (WMF) (talk)12:08, 29 November 2013

Yup! It's on the roadmap for Multimedia#Goals (See Multimedia/Feature ideas#File notifications for a little bit more). :)

Quiddity (talk)20:02, 29 November 2013

Can you point me to the specific goal you're mentioning? I don't see it there. Aren't ideas just ideas?

Elitre, so far this has been proposed by Dereckson as possible project for students etc. at Mentorship programs/Possible projects#Build an interwiki notifications framework and implement it for InstantCommons.

Nemo07:42, 30 November 2013

Ah, I only answered the Re: media usage usage query, above.

For that, See the 1st item in "Q2" at Multimedia/2013-14 Goals#Milestones, plus it got a lot of positive feedback in one of the roundtables. That's almost certainly coming (but local to commons).

Interwiki Notifications is (afaik, last I heard, IANAD, buyer beware) waiting on SUL finalization. (Because having all users in a single database is the only sane way to do it, and that's coming soon for SUL, so...).

That other project you point to, also sounds intriguing - we should point these 2 at each other, in case they've been overlooked or forgotten. (will do)

Quiddity (talk)09:22, 30 November 2013

I had been working on Requests for comment/Global notifications, but haven't had the time lately to work on it. It wouldn't depend on SUL finalization, but users without them wouldn't get some of the new features.

Legoktm (talk)19:07, 30 November 2013

Echo and mobile apps

Are there plans for a mobile app that just delivers Echo notifications? Or for login to be added to the official Wikimedia mobile apps so that users can at least read messages there? Thanks!

Elitre (WMF) (talk)23:11, 20 November 2013

In the "mobile view" of any page (linked at the bottom of all Wikimedia page), the notifications are accessible. eg (top-right corner).

For the Official App (I'm not familiar with it, but I think Wikimedia Mobile engineering and en:Help:Mobile access#Official Application are possibly the most uptodate pages?) it's in the process of being retooled from a reader-app into also-a-contributions-app. I assume Echo will be part of it, at that point?

As for a separate Notifications-app - There are preferences for each notification-type, to send any of them to your email. I guess that should cover it?

Quiddity (talk)00:00, 21 November 2013

Yep, we've just started on the new apps for Android and iOS; it'll be a few more months down the line before all the contrib features are in, but we will have login features and echo notifications will be integrated.

brion (talk)23:23, 26 November 2013

Top of the page hidden on mobile

Visualization problem.jpg
Visualization problem zoom.jpg

A user at it.wp reports he's using a desktop version of the site (with Monobook) on mobile (HTC Cha-Cha) in the default browser in Android Gingerbread. As screenshots show, the top of the page is usually covered by the loading bar. He says it can take up to 2 minutes to complete, so he usually does not need so much time to find the information he was looking for, and therefore, unless he waits so long, he'd never get to see the notifications below that bar. He also reports that before Echo arrived, he could at least force-scroll to see the links at the top of the page, while now this doesn't work anymore. Quiddity, is this known, should I report it elsewhere... ? thanks.

Elitre (WMF) (talk)13:10, 22 November 2013

I think the answer here is that the desktop site, particularly Monobook, is not designed to work on smartphones. We built a mobile site for that reason.

Steven Walling (WMF) • talk16:38, 22 November 2013

I can't think of why that doesn't work. It might be worth looking into why it takes so long for the page to load...

What Steven says is probably the best displays Echo notifications pretty well.

Legoktm (talk)00:15, 23 November 2013

Why can't we thank IPs?

I guess this depends on technical reasons, but it would be actually awesome if registered users could send a Thanks for an IP edit - they could see it as a dismissable pop-up.

Elitre (WMF) (talk)14:40, 22 November 2013


Helder19:04, 22 November 2013

Simply because anonymous users don't get Echo, so they won't be able to receive the thanks. bugzilla:56828 is a bug tracking this, but it's unlikely to happen anytime soon.

Legoktm (talk)00:12, 23 November 2013

User rights in local languages

The user rights are in English, at least on Finnish Wikipedia. They should be in the local language in messages like "X has changed your user rights. You are now member of the group: rollbacker."

Pxos (talk)09:38, 13 October 2013

This is bugzilla:55338

Legoktm (talk)23:32, 20 November 2013

Thank you for telling me the bug.

Pxos (talk)03:14, 21 November 2013

Add new feature to Echo

When deploying Echo at es.Wikipedia, Fremen asked if Echo could be used to follow pages beyond those you created, like the watchlist does. I thought that this was a bit unmanageable until he explained in detail what he was referring to. What he suggests is that Echo can be used to follow certain edits rather than all edits. He gave the example of Echo notifying a user when someone removed a category from a page off their watchlist, and I can also think of more examples, like when a page on your watchlist is moved, or deleted, or restored, or a revision within any of these pages is revision deleted.

Such enhancements will make Echo an even more powerful tool than what it is now, and will expand its usefulness by a broad margin. We can also explore, in the future, the possibility to make Echo to report users when a page off their watchlist received a maintenance tag, et cetera, but since these tags depend on templates that vary throughout the different wikis, that would be time consuming and may not be very useful (we still have the watchlist though). Any thoughts?

ΛΧΣ2120:26, 17 September 2013

It is really good the community is thinking about new ways to use Echo notifications. The current set of notifications is really viewed as just the beginning, and in the future we hope more functionality will be added (by developers, by editors, etc.)

About specific notifications about certain page edits: we were really careful not to replicate a lot of the functionality of the watchlist. Once you go down the path of notifications like that, it gets confusing and muddled pretty quick. It's also not that easy to develop notifications like "notifying a user when someone removed a category from a page off their watchlist" on a per-user basis.

I would suggest that we start a wishlist, perhaps with bugs associated with them, if it doesn't exist already.

Steven Walling (WMF) • talk21:10, 17 September 2013

@Hahc21, those suggestions are definitely overlapping with watchlist functionality.

I suspect what you are really asking for, above, is: 2 (or more) watchlists, or a way to filter our watchlists, with different features for each, eg. 1 could be a high-priority watchlist (or filter) that sends an email for all changes.

w:Wikipedia:Perennial_proposals#Watchlist_changes links a few of the discussions about this. See also Watchlist wishlist here on Mediawiki.

Quiddity (talk)00:18, 19 September 2013

Before deployment on deWP

Hello, it would be really important to have a new notification "gesichtet" (pending change or meta:Flagged Revisions) for German Wikipedia. Really essential. (Probably also for other WPs with this extension: plWP, ruWP, arWP etc.) "Your edit has been sighted by user:X and is now visible" or something like that. On the other hand, "review"?-notifications do not work on german WP. And, please, before deploying to german WP, ask and announce! Thank you! I'm looking forward to it :-)

Atlasowa (talk)12:21, 31 August 2013

I already explained why such notification features are really important for sighted versions in May 2013, [1]. Thank you.

Atlasowa (talk)12:51, 31 August 2013

I think bugzilla:52510 is covering this. I've linked them to your comments.

Quiddity (talk)22:42, 8 September 2013

Thank you very much, Quiddity! --

Atlasowa (talk)14:35, 9 September 2013

Deployment roadmap

I get the feeling, from bugzilla:46678, that I'm supposed to know the roadmap for the extension deployment, but even after reading this page I definitely don't. Could it be made clearer?

My current best guess is: first experiment on for some months, then the other wikis at some point only if they ask it and after that nobody knows. Correct?

Nemo12:28, 26 April 2013

I repeat my question. I overheard in some IRC discussion that after the new "message indicator" is implemented this may be enabled on all wikis, but it's still not written anywhere, nor there is any visible preparation for it.

Please don't activate it by surprise as you did on, especially given that I doubt you'll be having 11 staffers (leaving 205 messages so far) dedicated to discussion with other wikis as on w:en:Wikipedia talk:Notifications.

Nemo07:49, 9 May 2013

The absence of a specific published plan suggests to me that the deployment timeline is not known. However, there is a link to which contains some of the information that you seem to be searching for.

WhatamIdoing (talk)16:12, 9 May 2013

Thank you for the link. I've read that now, but I didn't find anything on stuff.

Nemo17:27, 9 May 2013

Any news on this?

Helder18:27, 3 July 2013

Yup! See Editor Engagement/2013 strategy planning (Features) which was recently updated.

(Do take with a ladle of salt and hesitation though, given that everything is still theoretical and under heavy discussion, and specifically labeled as "preliminary")

Quiddity (talk)21:05, 3 July 2013

Thanks, let me repeat "Please don't activate it by surprise as you did on".

I don't understand this waterfall model you're using: 6 more months spent to "Complete and deploy core features", and only after you've finished the time available to develop them you activate it on other wikis, so making sure you won't be able to process real-life usage consequences and feedback.

P.s.: It's no longer labeled as preliminary.

Nemo07:38, 5 July 2013

Re: P.s. - Yes it is! "the Flow milestones in our E2 planning page are still preliminary" (Editor Engagement/2013 strategy planning (Features)#Flow (Messaging/Discussions/Workflows))

Quiddity (talk)21:12, 5 July 2013

Enable Echo to Other wikipedia

What is the process enable Echo to Other wikipedia (like bn, hi...). Should I submit a bug for that? Or it will deployed every wikipedia?

Jayantanth (talk)08:08, 4 July 2013

It will be deployed to the other languages sometime over the next few months. No bug-report needed. :)

Quiddity (talk)01:11, 5 July 2013

I don't understand why notifications are bucketed only by wiki. Notifications should be bucketed by importance/priority/topic. While one could think that users want to work on a single wiki at a time so that wiki is their current priority, this idea seems quite outdated with a centralised notification system, which should help reducing barriers between wikis. I want to see all the user talk messages I received on any wiki together, before anything else; I may then want to check whether any edit of mine has been reverted on any wiki and still requires my attention; etc. Then I want to review the mass of notifications (e.g. all the other discussions, if they're many) by topic, so probably by wiki. If the bucketing by wiki is not replaced, at least some things should be taken out of it (maybe configurable), like the talk edits.

Nemo17:46, 15 April 2012

There are two differing concepts here, and we don't have a great set of agreed upon terms for them, but for the purpose of my response I'm going to use "bucketing" and "stacking".

"Bucketing" is a "by-wiki" collection: all notifications from a specific wiki go into the same bucket.

"Stacking" is a "by-type" collection: all notifications of the same type go into the same stack.

The current design (as shown) operates on a bucket-primary, stacking-secondary process. That is, notifications are bucketed first, and then stacked within those buckets.

If I understand you correctly, you are asking for a "stack first, then bucket" ordering. There's some merit to that idea; I like it a lot for the use case you're discussing. I'm not advocating a change, however, since the reason we chose "bucket, then stack" is a technical one. It is going to be significantly faster and more accurate to bucket and then stack, because each "bucket" is actually going to be a single api call, which can be loaded and stacked independently. To do a stack-then-bucket process, we'll have to do multiple API calls to multiple wikis before we sort and stack the notifications (which will have to be done client side, in this instance).

I should point out that we are in the very earliest of stages for this feature, and we are still doing research as to the best design we can create. So it may be we do a stack-then-bucket, or that such a thing will be configurable (though probably not: I'm adverse to adding preferences for changing interface behavior).

Jorm (WMF) (talk)18:09, 15 April 2012

Thank you for the answer: yes, you understood correctly. I hope there will be room for at least some "stack first, then bucket" (for user talk edits for instance), but I understand the performance constraints.

Nemo08:38, 28 April 2012

Revisiting this old thread: Our API framework may need an upgrade here. The idea of single wikis living in a vacuum was very simple, and specifically ignored the common cases -- more common now -- of clusters of related wikis. However, most wikis come in clusters:

  • Some are groups of wikis that are really about the same content (but arbitrarily split into multiple 'different wikis' by language[1]).
  • Others are groups of wikis on related topics, used by the same group of people. Here often a 'new wiki' rather than a 'new namespace' was chosen to make it easier to have different main pages, or different policies per topic. None of this technically requires a separate wiki; these clusters of wikis often share 90% of their templates, policies, categories.

The difference between a namespace and a new wiki, for a cluster with shared userpool, is only semantic. And we should offer APIs that let developers ignore that semantic difference. Wikimedia isn't the only group with a cluster of many wikis; most organizations I know that use wikis have a cluster of at least 2 or 3. And all of them need cross-wiki tools, notification, change-tracking.

  1. because of useful interlang features, and because we have no way in the metadata to note the language of individual pages on a single wiki, or to filter RC by such metadata
Sj (talk)15:03, 22 June 2013
First page
First page
Previous page
Previous page
Last page
Last page