Enable email notification on changes to user talk pages also on big wikis
Closed, ResolvedPublic

Assigned To
None
Priority
Low
Author
Wikinaut
Blocks
T15781: delayed/duplicate mail notification
Subscribers
Nemo_bis, waldyrious, Pathoschild and 7 others
Projects
Tokens
"Like" token, awarded by Kozuch.
Reference
bz5220
Description

I hereby propose:

to enable now this switch and therefore the e-mail notification for _UserTalk_
pages in all main wikis.

DefaultSettings.php line #972

Change $wgEnotifUserTalk = false; # UPO
to $wgEnotifUserTalk = true; # UPO

or add a corresponding line in LocalSettings.php .

RE:
http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/DefaultSettings.php?annotate=1.441


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz5220.
Wikinaut created this task.Via LegacyMar 9 2006, 10:55 PM
Wikinaut added a comment.Via ConduitMar 29 2006, 6:51 PM

(In reply to comment #0)

I hereby propose:

to enable now this switch and therefore the e-mail notification for _UserTalk_
pages in all main wikis.

DefaultSettings.php line #972

Change $wgEnotifUserTalk = false; # UPO
to $wgEnotifUserTalk = true; # UPO

or add a corresponding line in LocalSettings.php .

RE:

http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/DefaultSettings.php?annotate=1.441

When will this be finally enabled in enwiki, dewiki and others ?

bzimport added a comment.Via ConduitMar 30 2006, 12:40 AM

gangleri wrote:

Bug 5323: "ENotif on changes at own talk pages" feature at Yiddish Wiktionary
is a request about a small project which reached community consensus

Personaly I would be happy to have the feature at many / all Wikimadia
Foundation projects.

best regards reinhardt [[user:gangleri]]

bzimport added a comment.Via ConduitApr 25 2006, 6:20 PM

robchur wrote:

*** Bug 5714 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitApr 25 2006, 6:25 PM

marco wrote:

I would be happy about a fast change...

bzimport added a comment.Via ConduitJan 8 2007, 9:44 PM

ayg wrote:

*** Bug 8545 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitJan 8 2007, 9:52 PM

krisspearse wrote:

Apologies for the duplicate report. Evidently a popular request.

Wikinaut added a comment.Via ConduitJan 8 2007, 11:24 PM

(In reply to comment #7)

Apologies for the duplicate report. Evidently a popular request.

Basically, it's adding a line in LocalSettings.php
$wgEnotifUserTalk = true;

It is currently only enabled in

section "Email notification (Enotif) settings" in
http://www.mediawiki.org/wiki/Manual:Configuration_settings describes the
meaning of all enotif switches.

demon added a comment.Via ConduitJul 9 2007, 4:03 PM
  • Bug 5505 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJan 6 2008, 7:27 PM

jeluf wrote:

Enabled on dewiki. No community consensus on any of the other wikis. Please open new bugs for those were a community consensus has been found.

Wikinaut added a comment.Via ConduitJan 7 2008, 6:45 PM

(In reply to comment #10)

Enabled on dewiki.

@ JeLuf:
Pls. can you check this setting on dewiki again ? The Special:Preferences page still does not show the "E-mail me when my user talk page is changed" user option (on dewiki)

bzimport added a comment.Via ConduitJan 7 2008, 7:35 PM

jeluf wrote:

The option has been disabled again, due to unwanted side effects, i.e. the tracking of unvisited changes on the watchlists. These side effects have to be removed before this option can be enabled.

> Removed "shell" keyword, since this is now a coding task, not a shell task.

Wikinaut added a comment.Via ConduitJan 7 2008, 7:43 PM

(In reply to comment #12)

The option has been disabled again, due to unwanted side effects, i.e. the
tracking of unvisited changes on the watchlists. These side effects have to be
removed before this option can be enabled.

=> Removed "shell" keyword, since this is now a coding task, not a shell task.

Merci for swift reply and explanation. I don't fully understand what you mean with "side effects" (I haven't noticed any) but will watch the code changes.

Danke

bzimport added a comment.Via ConduitJan 7 2008, 8:26 PM

gangleri wrote:

(In reply to comment #12)

The option has been disabled again, due to unwanted side effects, i.e. the
tracking of unvisited changes on the watchlists. These side effects have to be
removed before this option can be enabled.

=> Removed "shell" keyword, since this is now a coding task, not a shell task.

Can you please provide more details about the difference of enabling the feature at [[de:]] versus its availability at [[cs:]], [[pt:]] where it runs since months, versus [[commons:]], [[meta:]], [[mw2008:]]?

Best regards REinhardt [[user:Gangleri]]

bzimport added a comment.Via ConduitJan 7 2008, 9:19 PM

jeluf wrote:

Re #13: Unvisited changes were in bold font on the watchlist, after visiting the diff page, the line became none-bold.

Re #14:
a) The users on dewiki didn't want to have the bold watchlist entries
b) dewiki has much more changes and more watchlists than the projects that you've mentioned
c) the projects that you mention have wgEnotifWatchlist enabled,

while dewiki asked for wgEnotifUserTalk.
Wikinaut added a comment.Via ConduitJan 7 2008, 9:53 PM

(In reply to comment #15)

Re #13: Unvisited changes were in bold font on the watchlist, after visiting
the diff page, the line became none-bold.

Yes. Because it was a designed feature and is correct and wanted behaviour: when a page is visited _or_ the diff page to the current version, you have seen the current version (the current version is at the bottom of the diff page). Consequently the "unvisited" flag is reset.

Re #14:

a) The users on dewiki didn't want to have the bold watchlist entries

@ JeLuf:
EnotifUserTalk adds the option to the users, it does not mean, that a user _needs_ to enable that. Thus, as long as users haven't clicked the "E-mail me when my user talk page is changed" box, they won't see the bold watchlist entries (saying bold "this is a watched page with unseen changes"). I also cannot see what's wrong with this marking in bold.

b) dewiki has much more changes and more watchlists than the projects that

you've mentioned

c) the projects that you mention have wgEnotifWatchlist enabled, 
   while dewiki asked for wgEnotifUserTalk.
bzimport added a comment.Via ConduitJan 8 2008, 7:42 AM

jeluf wrote:

(In reply to comment #16)

(In reply to comment #15)
> Re #13: Unvisited changes were in bold font on the watchlist, after visiting
> the diff page, the line became none-bold.

Yes. Because it was a designed feature and is correct and wanted behaviour:
when a page is visited _or_ the diff page to the current version, you have seen
the current version (the current version is at the bottom of the diff page).
Consequently the "unvisited" flag is reset.

This should only be the case if wgEnotifWatchlist is set. This is not neccessary for the user's talk page and is an extra burden for the servers.

> Re #14:
> a) The users on dewiki didn't want to have the bold watchlist entries
@ JeLuf:
EnotifUserTalk adds the option to the users, it does not mean, that a user
_needs_ to enable that. Thus, as long as users haven't clicked the "E-mail me
when my user talk page is changed" box, they won't see the bold watchlist
entries (saying bold "this is a watched page with unseen changes").

The properties of my account have "enotifusertalkpages=0", but the watchlist has bold entries nevertheless.

I also cannot see what's wrong with this marking in bold.

That's pretty sad.

Wikinaut added a comment.Via ConduitJan 8 2008, 8:02 AM

The properties of my account have "enotifusertalkpages=0", but the watchlist
has bold entries nevertheless.

I checked your observation on commons and now I do understand, you are right, there is admittedly a small problem.

The watchlist shows an information text in the header "* Pages which have been changed since you last visited them are shown in bold" and has bolded entries (i.e. watched pages with unseen changes) even when all user options regarding email-notification are disabled.

I'll investigate in the module in SVN.

Wikinaut added a comment.Via ConduitJan 8 2008, 8:03 AM

(In reply to comment #18)

> The properties of my account have "enotifusertalkpages=0", but the watchlist
> has bold entries nevertheless.

I checked your observation on commons and now I do understand, you are right,
there is admittedly a small problem.

The watchlist shows an information text in the header "* Pages which have been
changed since you last visited them are shown in bold" and has bolded entries
(i.e. watched pages with unseen changes) even when all user options regarding
email-notification are disabled.

I'll investigate in the module in SVN.

But isn't that a useful feature ?

Wikinaut added a comment.Via ConduitJan 8 2008, 10:34 AM

(In reply to comment #12)

The option has been disabled again, due to unwanted side effects, i.e. the
tracking of unvisited changes on the watchlists. These side effects have to be
removed before this option can be enabled.

coming back to that... in my previous postings to this bugzilla I was wrong, sorry for that, but will give you this further explanation

The "bold marking in watchlists" is a feature which was requested in 2004: to mark pages with unseen changes. The introduction of Enotif allowed for the first time to store last seen page version numbers (only for watched pages) in the database, so that a corresponding mark can be shown in users' watchlists for watched pages having unseen changes.

  1. Especially for this case, in order to all users to reset _all_ these "unseen changes" flags, the additional button "Alle Seiten als besucht markieren" ("Mark all pages visited") was introduced. Please have a look to commons, where Enotif is active and you'll see that button.
  1. Together with this possibility to clear all "unseen changes" flags (i.e. the bold marking in watchlist),

I kindly ask you to consider the reenabling of

Change $wgEnotifUserTalk = false; # UPO
to $wgEnotifUserTalk = true; # UPO

bzimport added a comment.Via ConduitMay 5 2008, 1:40 AM

Wiki.Melancholie wrote:

Did you know that yet there is no email notification, but a web feed notification that can do the same for you (in a much better way)?

Since bug 943 is fixed, there is the possibility of getting notifications by "~email" (if you are using Mozilla Thunderbird e.g.)!

See [[wikt:de:Wiktionary:E-Mail-Benachrichtigung]] (you may use Babelfish (maybe ;-))

Summary:

  1. Create [[Special:Mypage/notification]] (email watchlist)
  2. Link to the pages you want have notifications for when they get changed
  3. Read http://kb.mozillazine.org/RSS_basics_-_Thunderbird
  4. Copy the RSS/Atom feed URL (found in toolbox) of a. [[Special:Mypage/notification]] (do it over [[Special:RecentChangesLinked]]/...!) or [[Special:NewPages]] etc. b. or just of *[[Special:Mytalk]]* (on *history page* ;-) c. or of a whole category content: [[Special:RecentChangesLinked/Category:Esperanto]] -> RSS/Atom
  5. Paste that URL into Thunderbird (or a news reader, or just use Firefox)
  6. Check the box "By default, show the article summary instead of loading the web page" (faster, better for our servers)
  7. Done; solution for bug 1710, bug 3525 and this one ;-)

You can use [[MediaWiki:Watchlist-details]] for letting this know the users, by the way.

bzimport added a comment.Via ConduitMay 5 2008, 1:58 AM

Wiki.Melancholie wrote:

BTW: See also bug 13951 - "Provide all URL parameters for all RSS/Atom feeds consistently"

bzimport added a comment.Via ConduitMay 5 2008, 11:06 AM

Wiki.Melancholie wrote:

BTW: For wikis that are using non-ASCII characters it is important to copy the URL encoded (%) address of a feed, to avoid an URL encoding error message in Thunderbird & Co. It's best to copy the Atom/RSS address URL from the toolbox link(s) by right click!

waldyrious added a comment.Via ConduitMay 5 2008, 11:56 AM
  1. rssfwd.com already provides a service to forward feeds to email, for everyone and not only who has thunderbird or any feed reader;
  2. as stated in bug 1710#c7, the Recentchangeslinked are not a perfect replacement for a true category watchlist. This means bug 1710 is not solved by this, as you state above.
bzimport added a comment.Via ConduitAug 7 2008, 2:38 PM

spacebirdy wrote:

This is fixed, right? At least I can see a checkbox for enotify in the preferences everywhere.

Thanks.

bzimport added a comment.Via ConduitAug 7 2008, 3:00 PM

bugs wrote:

*** This bug has been marked as a duplicate of bug 15031 ***

Wikinaut added a comment.Via ConduitAug 7 2008, 8:41 PM

(In reply to comment #25)

This is fixed, right? At least I can see a checkbox for enotify in the
preferences everywhere.

Not yet on enwiki, dewiki etc. (but it _is_ enabled on commons, metawiki and a few other wikis)
This bug refers to the settings (LocalSettings) of Wikipedia sites, not to the MediaWiki software as such where enotif is built in since a couple of years.

bzimport added a comment.Via ConduitAug 8 2008, 2:35 AM

bugs wrote:

(In reply to comment #27)

(In reply to comment #25)
> This is fixed, right? At least I can see a checkbox for enotify in the
> preferences everywhere.

Not yet on enwiki, dewiki etc. (but it _is_ enabled on commons, metawiki and a
few other wikis)

As you can see from the other bug report, it is enabled on _all_ wikis, except the large ones. It probably won't get enabled for the large wikis (ever) because of the high server load that would come with all of those.

Wikinaut added a comment.Via ConduitAug 8 2008, 6:29 AM

> Not yet on enwiki, dewiki etc. (but it _is_ enabled on commons, metawiki and a
> few other wikis)

As you can see from the other bug report, it is enabled on _all_ wikis, except
the large ones. It probably won't get enabled for the large wikis (ever)
because of the high server load that would come with all of those.

The number of mails to be sents depends only (the upper limit) on the number "foreign" changes on User_talk pages:

enotifs <= number of User_talk pages changes not done by owner.

This number is not very high, was in the range of 1000 per day on enwiki, therefore I ask to reconsider the enabling also on the large wikis, if the number of User_talk pages changes not done by owner allows this with respect to server load.

bzimport added a comment.Via ConduitJul 27 2010, 4:08 PM

bugs wrote:

(In reply to comment #30)

This is desired by a bunch of en.wiki users on an opt-in basis

https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&oldid=375746782#You_have_new_messages

So make a separate bug for the new request.

MZMcBride added a comment.Via ConduitOct 6 2010, 4:34 AM

Added the shell keyword and put this in "Site requests." I don't know of any reason this can't be done. There have been rumors of load issues, but I think they're unsubstantiated.

bzimport added a comment.Via ConduitOct 27 2010, 3:16 PM

FT2.wiki wrote:

Yes please.

Nemo_bis added a comment.Via ConduitMar 13 2011, 12:36 PM

Any news? I see that now even EnotifWatchlist is enabled on big wikis such as nlwiki, and has been enabled on some more wikis recently.

RobH added a comment.Via ConduitMay 13 2011, 11:49 AM

The load issues are a concern and there is active discussion and planning on rolling this out and resolving this bug. (I do not have more information than that at this time.)

tstarling added a comment.Via ConduitMay 14 2011, 10:33 AM

Fixed.

bzimport added a comment.Via ConduitMay 14 2011, 3:01 PM

bugs wrote:

(In reply to comment #37)

Shouldn't it be disabled by default?

Probably not. Most non-power users would want this feature, because they don't always visit Wikipedia everyday and wouldn't know it existed otherwise. (Think about other sites, like Facebook, who make this behavior the default.)

Reedy added a comment.Via ConduitMay 14 2011, 3:29 PM
  • Bug 24598 has been marked as a duplicate of this bug. ***
Kozuch awarded a token.Via WebDec 17 2014, 8:08 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.