Hmm, just to check -- the way the watchlist emails work is that they don't send you another notification mail until you've gone to visit the page, at which point you're assumed to have seen everything up to the present time.

You'll then get a single notification mail on the next edit, which'll be the last one you receive until you visit the page again.

So for instance, if the page is edited three times before you next visit it, you'll only get a single email.

Related: bug 41759 and its patch (for unexpected behavior when viewing non-latest revisions and diffs).

That said, and apart from that, I have been experiencing unreliable notifications for quite some time myself, especially on often-edited pages like [[WP:VPT]]. I really can't tell if this is caused by the aforementioned behavior or if there's actually a bug here.

Brion: that's... interesting. So maybe the bug is:

1. doesn't work like any other notification system; or

2. preference label is misleading, since it says "when changed" and not "the first time it changes after you visit it"; or

3. the email's statement about this is completely unclear/not a good place to try to explain to a user that #1 is true ('There will be no other notifications in case of further activity unless you visit this page'); or

4. the email's other attempt to clarify this (link to "all changes since your last email") should be the *first* link, not the second, because that link is the one that actually contains the accurate/complete information that you should want to see.

To focus on #1 for a second: if your goal is to reduce the # of inboxes you have to check, then you have to get *all* the notifications, not just some of them. Because likely the most common action will be:

1. Get the notification of a change.
2. Read, and decide the correct action in response to the change is "do nothing".
3. File/archive/mark read/delete as appropriate for how you handle your inbox.
4. Go back to #1.

That keeps you entirely within your email for the most common use case - most efficient for anyone who has to/wants to read and process a lot of notifications.

With this system, you add Step 2.5: leave your email by clicking on "all changes since your last visit" to make sure nothing else has changed, because you have no way of knowing whether or not something has happened without breaking out of your mail handling workflow.

So for inexperienced Mediawiki users, it breaks expectations from every other notification system they've ever worked with; and for experienced mail handlers, it completely breaks workflow and forces you to swap back and forth between tools.

If this is all by design, I suppose this is really just venting/WONTFIX, given everyone's change aversion and the work necessary to fix it. In the meantime, I'll chalk it up as yet another systemic inefficiency that makes me wonder how this thing ever got built :) And wait patiently for Flow. :/

(Or set up rss2email :)

Oh yeah there's some, shall we say, "user experience issues" here that need work. :)

Worth filing any of them, and/or leaving this bug open? The overarching bug that I've described is obviously a huge one, but the text/string changes could be worth filing, I suppose?

With the caveat that I have no idea how painful/non-painful our l10n/i18n story is, or what other process strings have to go through to get changed, I'm even happy to provide patches for at least those.

(In reply to comment #3)

With this system, you add Step 2.5: leave your email by clicking on "all
changes since your last visit" to make sure nothing else has changed, because
you have no way of knowing whether or not something has happened without
breaking out of your mail handling workflow.

I hate to admit it, but that's exactly what I end up doing quite often (specific change does not interest me, but I want to get notified of the next change which might interest me).

Right, and that's horribly inefficient :)

Bug 41759 is fixed now, which should make it a lot harder to accidentally mark revisions as "read" when you haven't actually seen them. Let's see if it makes the situation better.

I don't really think that solves the core problem, but maybe that is in part because the core problem is not well-described here. At least I'll change the bug name to reflect the underlying reality :)

I wish:

• a reliable E-Mail notifications for all changes (small and normal) to selected pages (whether I visited they logged in or not)
• an E-Mail notifications if an "own" Commons image is embedded in one of the sister projects.

Can anyone tell me, how is the status of this case and as the chances are that it comes here to improve.

see also: https://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests#Optimierung_der_Benachrichtigung_.C3.BCber_.C3.84nderungen_an_Artikeln_.28per_Mail.29

(In German: Ich wünsche mir: * eine zuverlässige eine E-Mail-Benachrichtigung für alle Änderungen (kleine und normale) von markierten Seiten (egal ob ich sie angemeldet besucht habe oder nicht); * eine E-Mail-Benachrichtigung, wenn ein "eigenes" Commons Bild in einem der Schwesterprojekte eingebunden wird. Kann mir jemand sagen, wie der Stand dieses Falles ist und wie die Chancen sind, dass es hier zu einer Verbesserung kommt.)

@Molgreen

• This task is probably a duplicate of T33928: Enable users to set their preferences to receive watchlist notifications regardless of whether the page has been visited
• That new notification idea, is tracked at T77154: Notification: Your file was used

Neither task has been worked on recently.
The first (this) one is complicated.
For the new notification idea, some upcoming documentation might make it easier for other people (e.g. WMDE, volunteers, etc) to implement this, sometime soon. T136372: Document how to create a new notification type Also, I see Lea has added T77154 to the TCB and German-wishlist projects, so that is hopeful. :-)

@Quiddity, thank you for your help

For the watchlist, I would wish me three options:

• Page not on the watchlist
• Page on the watchlist
• Page permanently on the watch list (new function)