Last modified: 2013-04-08 11:02:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T7220, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5220 - Enable email notification on changes to user talk pages also on big wikis
Enable email notification on changes to user talk pages also on big wikis
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Low enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
: 5505 5714 8545 24598 (view as bug list)
Depends on:
Blocks: 13781
  Show dependency treegraph
 
Reported: 2006-03-09 22:55 UTC by T. Gries
Modified: 2013-04-08 11:02 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description T. Gries 2006-03-09 22:55:26 UTC
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
Comment 1 T. Gries 2006-03-29 18:51:12 UTC
(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 ?
Comment 2 lɛʁi לערי ריינהארט 2006-03-30 00:40:36 UTC
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]]
Comment 3 Rob Church 2006-04-25 18:20:10 UTC
*** Bug 5714 has been marked as a duplicate of this bug. ***
Comment 4 Marco 2006-04-25 18:25:22 UTC
I would be happy about a fast change...
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-08 21:44:44 UTC
*** Bug 8545 has been marked as a duplicate of this bug. ***
Comment 7 Kriss Pearse 2007-01-08 21:52:47 UTC
Apologies for the duplicate report. Evidently a popular request.
Comment 8 T. Gries 2007-01-08 23:24:46 UTC
(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
- http://wikimania2006.wikimedia.org
- http://meta.wikimedia.org
- http://commons.wikimedia.org

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

Comment 9 Chad H. 2007-07-09 16:03:26 UTC
*** Bug 5505 has been marked as a duplicate of this bug. ***
Comment 10 JeLuF 2008-01-06 19:27:58 UTC
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.
Comment 11 T. Gries 2008-01-07 18:45:54 UTC
(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)
Comment 12 JeLuF 2008-01-07 19:35:23 UTC
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.
Comment 13 T. Gries 2008-01-07 19:43:43 UTC
(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

Comment 14 lɛʁi לערי ריינהארט 2008-01-07 20:26:44 UTC
(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]]

Comment 15 JeLuF 2008-01-07 21:19:27 UTC
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.
Comment 16 T. Gries 2008-01-07 21:53:21 UTC
(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.
> 

Comment 17 JeLuF 2008-01-08 07:42:04 UTC
(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.
Comment 18 T. Gries 2008-01-08 08:02:19 UTC
> 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.
Comment 19 T. Gries 2008-01-08 08:03:27 UTC
(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 ?
Comment 20 T. Gries 2008-01-08 10:34:47 UTC
(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.

2. 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
Comment 21 Melancholie 2008-05-05 01:40:45 UTC
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.
Comment 22 Melancholie 2008-05-05 01:58:55 UTC
BTW: See also bug 13951 - "Provide all URL parameters for all RSS/Atom feeds consistently"
Comment 23 Melancholie 2008-05-05 11:06:54 UTC
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!
Comment 24 Waldir 2008-05-05 11:56:46 UTC
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.
Comment 25 spacebirdy 2008-08-07 14:38:49 UTC
This is fixed, right? At least I can see a checkbox for enotify in the preferences everywhere.

Thanks.
Comment 26 Casey Brown 2008-08-07 15:00:22 UTC

*** This bug has been marked as a duplicate of bug 15031 ***
Comment 27 T. Gries 2008-08-07 20:41:23 UTC
(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.
Comment 28 Casey Brown 2008-08-08 02:35:15 UTC
(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.
Comment 29 T. Gries 2008-08-08 06:29:14 UTC
> > 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.
Comment 30 xenocidic 2010-07-27 15:39:13 UTC
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
Comment 31 Casey Brown 2010-07-27 16:08:50 UTC
(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.
Comment 32 MZMcBride 2010-10-06 04:34:18 UTC
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.
Comment 33 FT2 2010-10-27 15:16:35 UTC
Yes please.
Comment 34 Nemo 2011-03-13 12:36:40 UTC
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.
Comment 35 Rob Halsell 2011-05-13 11:49:49 UTC
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.)
Comment 36 Tim Starling 2011-05-14 10:33:55 UTC
Fixed.
Comment 37 xenocidic 2011-05-14 14:39:52 UTC
Shouldn't it be disabled by default?

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(miscellaneous)#E-mails_from_Wikimedia
Comment 38 Casey Brown 2011-05-14 15:01:19 UTC
(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.)
Comment 39 Sam Reed (reedy) 2011-05-14 15:29:01 UTC
*** Bug 24598 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links