Well, I tried fixing this and related pages, but some of my changes were reverted, like here. Here's my understanding: in 2016, there was a big push to try to get the functionality of the Echo extension into core MediaWiki, where it would be a feature called "Notifications". For whatever reason, this didn't happen - but the documentation remains more or less frozen at the 2016 state, so that the merge into MediaWiki has, for the past eight years, remained forever just around the corner. This is extremely confusing, especially to new users. Imagine hearing about the Echo extension, typing in "echo", and ending up here - at a page that does its best to convince the reader that the Echo extension no longer exists. I hope someone can fix it - apparently it won't be me, but that's alright.
Talk:Notifications
That's definitely an improvement (thank you), although I still find this page confusing. The text starts with this: "Notifications (formerly known as Echo) is an engagement tool ...". So the Echo extension provides a tool that used to be also called Echo, but is now called Notifications? Was anything in the code ever renamed from "Echo" to "Notifications"? None of this makes sense.
"So the Echo extension provides a tool that used to be also called Echo, but is now called Notifications?" - Yes.
"Was anything in the code ever renamed from "Echo" to "Notifications"?" - No, just the user-facing name, because "echo" was a non-intuitive name (especially for translators, but also for people who know English).
"None of this makes sense." - Naming things is hard.
I've named many things, so I'm aware of the challenges in naming, but in this case there already is a name: Echo (a great name, by the way), so that's not an issue. If the goal in calling it "Notifications" instead is to not confuse users, I think this has the opposite effect. People understand that the name of something is different from its functionality; they manage to deal with it fine for every other extension. Do you think the documentation for the Scribunto extension should actually be at the page "Lua modules", and should begin with the text "Lua modules (formerly known as Scribunto) is a feature ..."?
I don't think this series of changes is accurate. The move into core has been repeatedly thwarted, but is not frozen.
Thanks for responding. It's good to hear that a move of this functionality to core is still possible - I personally think that the functionality belongs in core. I don't think anything I wrote in the documentation contradicts that, though. Beyond that, the main problem I see with the current documentation is that it places most of the content about the Echo extension not at Extension:Echo or Manual:Echo but at a page called Notifications - a page which then compounds the confusion by telling the user that Echo was renamed to Notifications.
Yes, the plan vaguely is to expand this page as the other notification systems (ENOTIF, etc.) are killed off and merged into Echo/Notifications, but they can't happen until the merge happens (as otherwise key features of MW suddenly go missing if someone installs from git rather than the tarball).
Would you agree that, until this merge happens, the current documentation is misleading?
No. I would say that your edits made it mis-leading, though.
That's an odd thing to say, given that some of my edits are still up. Anyway, I've heard directly from potential users of the Echo extension who thought that it no longer existed, because of the wording on this page. Which is not surprising in the least - I still have no idea what "Notifications (formerly known as Echo)" means.
I really hope these comments of mine didn't cause the Echo extension to just be renamed to "Notifications"! In my opinion, "Echo" is the much better name - more graceful and less ambiguous, not to mention the fact that it's contained in every setting name, DB table name, etc. I hope you reconsider.
https://gerrit.wikimedia.org/r/#/c/159413/ - 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.
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.
What if I want to preserve important notifications and delete the newest instead?
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. :)
I would have thought the number of users with > 2000 edits would be small. If you ware worried about database size, maybe deleted some of those millions of "users" who have never edited or been welcomed.
This change was just regarding number of echo notifications, not edits.
Yes, that's not what I meant.
How can one determine how many notifications one has?
@Ottawahitech, what do you mean? You want to know how many notifications someone has?
.
Ah, English language. :) Thank you Rich.
Ottawahitech, why do you need to know how many notification someone has? It is some private information.
I want to know how many notifications I have at enwiki where I am indefinitely blocked since 2017 (I think), after almost ten years of contributions. I have not been able to participate (even my talk-page access has been removed), so there is no way for me to do things like thank people, etc.
I am still hoping that my indef block will be lifted someday, and I would like to keep my notifications at least until such time.
He wants to know how many notifications he has.
It is displayed on Special:Notifications for a given wiki.
Not on en:Wikipedia, as far as I can see.
I see 52 for me: click on the arrows close to "1-50" to see the total.
This is not optimal, but we never had any feedback about displaying the total.
Looks like some of my notifications have already been deleted then? Can they be recovered?
No. They are removed from the database.
I have no idea where to look for "arrows" and where "1-50" is supposed to be. I suspect this may look different to someone using a different platform. For example, is this viewable to someone using a [[w:mobile]], or someone using a [[w:linux]] system?
BTW, I pretty much gave up on anyone responding to my questions here on mediawiki. [[User:Quidity]] was always pretty prompt, but I think he is no longer involved?
Another BTW, since FLOW is being tested here: where can I provide feedback to the FLOW developers?
AH.. so after 39 clicks I see that I have 1996 notifications... I would really rather they not be deleted, it seems contrary to the spirit of the WIki to loose history like this. By this principle we would delete page history over 2000, or maybe decide we could manage with the 2000 most important articles! :)
Is it possible to compare Notifications to Article history? I don't think it is.
Article history are a fundamental feature for the wikis: without them we wouldn't have the reliability we have.
Notifications are just tokens you immediately take action from. Did you had once to find something on the 1996 notifications you've received since 2013, apart from the 20 most recent ones? It is a real question, not some cynical rhetoric wording. :)
Yes, in particular the number of thanks for fixing up reference names is an important metric. Keeping thanks is also important for understanding social issues. Having a list of mentions is useful if you can't find a discussion you were pinged in.
Makes sense. I've documented it.
I would have thought the number of users with > 2000 edits would be small. The number with > 2,000 echoes smaller still.
Rich Farmbrough 02:15, 7 May 2016 (UTC).
How come there is no response from the wmf employees?
Please... I do not see the word kilobyte here, so you really are just poking at this with a stick... And if you don't see why that is relevant, you should ''especially'' stop talking about what should be done about it! Apologies,
I should just add my opinion. Never delete any notification ever without a genuine good reason. I have hundreds of notifications from the last year. I don't want someone to come along and delete them while I am off doing something even if they think I've seen them before, They're mine. Is that not fair?
I agree. Please stop deleting information that is important for contributors. Please don't decide for me what is important and what is not!
Very very fair imio
> Very very fair imio
This is a Flow comment: I have no idea why I wrote this and who I was responding to?????
... and to save others the hassle of trying to follow links, here is the link I ended up at explaining why Flow is no longer under development. It was written by Danny Horn and was dated 2015! https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/082993.html
I now have a good example of where this has made my life difficult. An editor caused over 2000 notifications to my account, and this means everything previous has been wiped.
This is a seriously flawed idea.
Looks like there is least one more discussion forum for notifications at Help talk:Notifications. Divide & conquer? Ottawahitech (talk) 02:24, 14 December 2020 (UTC)
Hello!
I create users in my wiki manually and specify a correct email adressess.
New user first time logging to my wiki can see its first notice "Welcome to mywiki, newuser! We're glad you're here."
How can i sent this Welcome message or any other greetings message to the users mail automaticall after create accounts?
My wiki can sent messages to another users, its work with test mail from one user to other
Here are some other settings that may be needed:
$wgEnableEmail = true;
$wgEnableUserEmail = true; # UPO
$wgEmailAuthentication = false;
Hello
I asked engineers regarding your request.
The answer is you can't do it without creating a new notification type (via Extension:Echo) and calling it yourself.
You'd have to change $wgEchoNotifications['welcome']['category'] from system-noemail to system. But unless you use some nonstandard registration mechanism, the user won't have a confirmed email address at this point and the email won't actually be sent.
Hi, I have a bot that tries to notify people and it seems those notifications do not arrive. I don't see any limitation in the docs, so I'm wondering what could cause the failed notifications?
I use a substituted template which receives a username as param ({{subst:pșn|user=X}}) and outputs the username using a {{u}}-like template: "Try to notify {{u|X}}". I tried substitution by hand and it seems to work, as well as the template itself and other notification methods, so the only hypothesis I have left is the bot flag.
Could you link to one or more example edits/diffs, where
- the bot made an edit, and
- the user has confirmed they didn't receive anything, and
- the user has confirmed their Notification-preferences are set to receive that type of Notification, and
- the user has confirmed they haven't "muted" the bot
- (last 2 are within Special:Preferences#mw-prefsection-echo)
That information might help someone to investigate further.
Sure, see for instance https://ro.wikipedia.org/w/index.php?title=Wikipedia:Pagini_de_%C8%99ters/Adrian_N._Matei&oldid=15105058 Gikü is receiving notifications from me, he hasn't mutd the bot but does not receive any notifications from the bot.
Hmmm. With the I-am-not-a-dev disclaimer... and after looking at the technical docs for this feature in Manual:Echo#Mentions... My guesses would be it's either:
- The level-3 ===header===.
- If I understand correctly, the code doesn't send mention-pings for new level-3 sections. Is it feasible for the bot to use a level-2 ==header== instead?
- or the bot-signature is not close-enough to a default-signature.
- perhaps just remove the fullstop after the bot's userpagelink?
The way I read the code, only level 1 does not count. It's very likely the second hypothesis, will test. Thanks!
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.
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).
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.
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.
- ↑ 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
Bump: Can we unbucket notifications now?
I would like the option to receive notification by email for any event. This would mean that infrequent users, like me, would not have to log-in to the Wiki to check things.
The emails should include as much information as possible about the notified event, in the email body.
The emails should keep being sent, even if the user hasn't logged-in to check the previously notified event.
Thanks for the suggestion, and the detailed use-case explanation on phabricator. :)
As you probably saw, I've merged the task you filed, into the older task (Phab:T114587 into Phab:T33928).
That said, Echo is not part of the software used for sending these watchlist notifications - Echo is an extension that is only ~3 years old, and watchlist notifications are part of "core" mediawiki. However, there have been discussions about changing that, and hopefully things will change in time, as the developers decide how to best handle these things.
Hope that helps.
Thanks, Quiddity.
I would also like my comments here to be taken into account for all Echo notifications, as well as Watchlist notifications.
As a relatively infrequent user, I would like to monitor everything from my email client without logging-in to Wiki - email is where many of the notifications I receive about other things arrive.
Ideally, the emails would have taglines in the subject, or be from a specific email address so they can be automatically filed for checking together.
I'd appreciate NOT to be notified by email from bots like InternetArchiveBot. Adding them to Notifications setting in Preferences does not suppress those emails.
What kind of emails does it send to you?
Example from zhwiki:
您好！
Wikipedia页面东禅寺水库已于2021年2月12日 (星期五)被InternetArchiveBot更改，请浏览
https://zh.wikipedia.org/wiki/%E4%B8%9C%E7%A6%85%E5%AF%BA%E6%B0%B4%E5%BA%93
查看当前版本。
要浏览此次更改，请参见https://zh.wikipedia.org/w/index.php?title=%E4%B8%9C%E7%A6%85%E5%AF%BA%E6%B0%B4%E5%BA%93&diff=next&oldid=59810881
要查看您上次访问以来的所有更改，请参见https://zh.wikipedia.org/w/index.php?title=%E4%B8%9C%E7%A6%85%E5%AF%BA%E6%B0%B4%E5%BA%93&diff=0&oldid=59810881
编辑摘要：补救1个来源，并将0个来源标记为失效。)
#IABot (v2.0.8
It looks like this is the issue being discussed at phab:T262750 - you may want to follow the discussion there.
I just discovered this. Knowing that could mute notifications from individual users might have helped dispel a fight on Wikinews six months ago. I felt like people were ringing my doorbell over and over while I was trying to sleep. More people need to know about this feature. I don't know if it does exactly what I hope, but it looks great and my thanks to all the users who worked on it.
Thank you for your gratitude!
A good way to be aware of these new things is to subscribe to Tech News. Only 7 Wikinews community pages receive this newsletter, I invite you to check if your Wikinews is subscribed. You can also subscribe to Tech News for yourself if not already done.
It would be nice if there was a prominent link from the actual notification to this page, so people know where to go for more information. Not everyone has the time to go through all the technews. Just my $.02
@Ottawahitech, I'm not sure to understand what you mean. Can you rephrase your suggestion?
@ Trizek (WMF):
> @Ottawahitech, I'm not sure to understand what you mean. Can you rephrase your suggestion?
I would love to, but just finding my way back to your post took way too much effort. Let's face it, these flow discussions do not work. I cannot even indicate who I am replying to, is it Darkfrog24 or to you?
No, Ottawahitech, it's not me. I made the first post in this thread but no others. I keep getting notifications about it (they do not bother me).
@Ottawahitech, this topic is about Notifications, not Flow. If you want to complain about Flow, it is there.
If you have feedback about notifications, and especially how to mute notifications, please share them in this topic.
@ Trizek (WMF):
> If you want to complain about Flow, it is there.
I tried, but failed. So, since I have your attention here @ Trizek (WMF) I get the distinct impression that wmf is ignoring feedback from us? I have a feeling I can spend my life following links from page to page, but never get a straight answer from anyone. Surely I am not the only one who feels this way?
I say I failed, because I clicked on the link you suggested and found this: "no longer in feature development" - why? There are only two messages in that discusion, the first one is the question that is on the minds of many, posted by User:Martin m159. The 2nd and last message is a post by User:AKlapper (WMF) ithat instead of replying merely links somewhere else.
But worse, THERE ARE NO REPLY BUTTONS anywhere for anyone who wants to participate in that discussion.
---
UPDATE: I see a different userid now when I look at the same thread: User:Valerio Bozzolan, weird?
First, would it be possible to have this discussion using a different tone. I can understand that you are frustrated and you want to share your frustration, but I invite you to remain civil, and avoid using caps or passive-aggressive wording.
About your impression of the Wikimedia Foundation ignoring feedback, I hope this is not the case. I'm sorry of you have this feeling. I like to get feedback about active projects I work on and the teams I'm helping like feedback too.
Flow/StructuredDiscussions are no longer developed and will be replaced at some point by this new talk pages system.
If you like to reply to a conversation on Flow/StructuredDiscussions that has been resolved, please re-open it. You can re-open a Topic anytime, by clicking on the Topic's menu (three dots icon).
This said, I'd like to keep things in topic here. So I won't reply to comments about Flow/StructuredDiscussions anymore in this current topic; please post at the appropriate venues.
Thank you for your understanding.
I have attempted to respond, again. This time on your talk-page.
2 years later there is still no watchlist support?
I plan to add Echo on my wiki, but this will be the first thing users will miss.
Email Notification for Pages on User's Watchlist
The current system of email notifications for pages on a user's watchlist needs improvement:
- It is not clear which types of edits (normal, minor, or bot) will trigger emails.
- Because the notification emails stop if a user doesn't visit the changed page while logged-in, it can be difficult to report any problems with the notification emails, because the reporter will always be asked if they are sure they visited the page.
- I would personally like a notification email for every change to a page on my watchlist, whether I visited the page after the last change or not.
- The current system has reported bugs.
See the following tasks in Phabricator:
https://phabricator.wikimedia.org/T29884 - Enotif doesn't send email if page on watchlist edited following a minor edit and enotif not configured to send minor edits.
https://phabricator.wikimedia.org/T40874 - Minor bot edits don't trigger email notifications even with "E-mail me also for minor edits of pages" selected.
https://phabricator.wikimedia.org/T110850 - Wikipedia Watchlist Notification Emails Not Arriving.
https://phabricator.wikimedia.org/T114587 - Email notification for every single change to a page on watchlist.
Someone came up with a patch for that in T203942.
I haven't tried though.
It appears that subscribing to changes on a categories' page doesn't notify you when new pages are added to the category, this feature would be very useful.
Does anyone know if this is possible, and if so, how?
Thank you for your feedback!
At the moment, it is not possible to get a notification when a page has been added to a category.
Getting a notification, or a watchlist entry, when a page is added to a category, is something requested time to time. Overall, this is covered by the need to have better tracking options for categories.
The need of a tracking option has been suggested as a feature request during the last Community wishlist survey. But I'm afraid that this suggestion is far from being the most wanted feature.
Notifications aren't on a feature improvement list for now, so I'm afraid that you may have to wait until new plans are made for Notifications. Sorry. :(
Thanks for your response :)
In the meantime I found Extension:CategoryWatch, which seems to fit my needs.