Page MenuHomePhabricator

Email notification mistakes log action for new page creation
Closed, ResolvedPublic

Description

Author: tracy.poff

Description:
I received a change notification email today. Relevant portion:

"The Wikimedia Commons page Image:Seventh perspective.png has been
created on 16:02, 23 July 2008 by הגמל התימני, see
http://commons.wikimedia.org/wiki/Image:Seventh_perspective.png for the
current version."

However, this was not a new page. Relevant lines from the page history:

  1. 16:02, 23 July 2008 הגמל התימני (Talk | contribs) (uploaded a new version of "Image:Seventh perspective.png": {{Information |Description= |Source= |Date= |Author= |Permission= |other_versions= }}) (undo)
  2. 21:29, 22 July 2008 Sopoforic (Talk | contribs) (2,152 bytes) ({{Information |Description={{en|A view of the decimal representation of 1/7 in rectangular perspective. Each character has a small but finite depth so that the image blends to solid black at infinity.}} |Source=*Image:999_Perspective.png |Date=2008-)"

It is perhaps worth noting that no changes were made (except perhaps for whitespace, I suppose) between the two revisions:

http://commons.wikimedia.org/w/index.php?title=Image%3ASeventh_perspective.png&diff=12997180&oldid=12979455


Version: 1.21.x
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=15646
https://bugzilla.wikimedia.org/show_bug.cgi?id=42752

Details

Reference
bz14901

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:13 PM
bzimport set Reference to bz14901.

A new file was created (uploaded a new version of "Image:Seventh perspective.png"), so that was not really wrong.

Still, it looks like some changes may be needed to handle page history and the uploading of new versions of files.

Component: from Email -> Images.

New version of an image is equivalent to a _change_, not a _new_ page. Notes I've seen elsewhere indicate this may be a problem with other logged/null-edit actions as well as just upload.

This problem is still ongoing, wrong notification texts are sent for cases, where a watched page is _deleted_

Texts like

"Subject: zzzz File:xxxxxx.jpg has been created by yyyy"
"Body:
...
This is a new page."

are sent mistakenly when the watched page xxxxxx.jpg is _deleted_.

It deals with an edit (here: deletion), but the E-Mail notification should not send a subject and a text in the body saying "This is a new page." which is fully wrong.

I also received the new page email notification today, when the image File:Vertical.PNG[1] was deleted from Wikimedia Commons.(enotif_body with CHANGEDORCREATED corresponding to created)

Helder

[1] http://commons.wikimedia.org/w/index.php?title=File:Vertical.PNG&action=edit&redlink=1

  • This bug has been marked as a duplicate of bug 15646 ***

(In reply to comment #5)

  • This bug has been marked as a duplicate of bug 15646 ***

This bug is older than bug 15646.

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

(In reply to comment #6)

(In reply to comment #5)

  • This bug has been marked as a duplicate of bug 15646 ***

This bug is older than bug 15646.

I don't really care either way, but the other one had more relevant technical discussion, which is why I dupped it to that one.

dnessett wrote:

From an architectural point of view, the code that implements the e-notify feature is a bit of a mess. Its appearance suggests several developers worked on it who had different ideas on implementation strategy. The RecentChanges notifyMoveToNew() and notifyMoveOverRedirect() methods are orphans, called nowhere in the code base. RecentChanges::notifyMove() is only called by notifyMoveToNew() and notifyMoveOverRedirect(), so effectively it too is an orphan.

When a page is created or changed, the code registering the change calls either RecentChange::notifyNew() or RecentChange::notifyEdit(). However, when a page is moved or deleted, LogPage->saveContent() calls RecentChange::notifyLog() without going through a context set up method (RecentChange::notifyMoveToNew() and RecentChange::notifyMoveOverRedirect() appear to be attempts to provide context setup methods for page moves. Context setup initializes values in the mAttribs and mExtra attributes). RecentChange::notifyLog() calls RecentChange::newLogEntry(), which initializes mAttribs and mExtra, but that method doesn't know whether the call chain came through a delete or move action. So, it is necessary in RecentChange::newLogEntry() to figure this out using the method's $action parameter. I considered cleaning up the architectural problems, but since that wasn't directly necessary to fix the bug, decided not to.

Fixing the bug is complicated by the necessity of changing some of the text in the languages/messages files. This means a comprehensive fix will not be available until all of the internationalization work is complete.

The attached patches provide the code modifications to fix the bug (enotif_code.patch) and the changes to MessagesEn.php required to support the code changes (enotif_messages.patch). These patches are against 1.16.2. They change the text in the enotify message to specify whether the page was created, deleted, moved, restored or changed (i.e., its text edited). I have modified MessagesQqq.php to document the changes in MessagesEn.php. The MessagesQqq.php diffs are also in the enotif_messages.patch. However, I am unfamiliar with the MW workflow necessary to achieve internationalization of the languages/messages changes. After posting this patch, I will use MediaWiki-Internationalization (per the instructions at http://www.mediawiki.org/wiki/Localisation#Changing_existing_messages) and ask how to proceed.

Finally, I have installed the patches on http://test.citizendium.org. We are an English language only wiki, so we can work with changes only to MessagesEn.php. After sufficient testing, the code there will be moved to our live wiki (upgrading us from 1.13.2 to 1.16.2). Note: our wiki does not allow anonymous users, so I cannot test the patched code for that case.

dnessett wrote:

code patch referenced in comment 9

attachment enotify_code.patch ignored as obsolete

dnessett wrote:

messages patch referenced in comment 9

attachment enotify_messages.patch ignored as obsolete

dnessett wrote:

I contacted the people at MediaWiki-Internationalization. It appears I didn't follow some rules for structuring messages appropriately (e.g., put leading newlines in messages). So, while the patches I supplied work on our test wiki, the messages in the patch can't be translated on translatewiki.net. I will have to restructure the code to eliminate these problems.

This may take some time, since I have a lot of other work to do on our wiki and since they work there, I may not get back to this for a while.

dnessett wrote:

I have changed the code in UserMailer.php and the text in MessagesEn.php so all preceding and trailing newlines in the previous patches to the enotif messages are placed there by the code. I have also patched current trunk, rather than 1.16.2 (per instructions specified on MediaWiki-Internationalization). I have attached the patches as enotify_code2.patch and enotify_messages2.patch.

I have tested the code and text changes on 1.16.2, but do not have the ability to test them against the code in current trunk. I have attempted to eyeball the differences between svn diffs against 1.16.2 and current trunk in order to ensure the current trunk changes are correct. But, that is not the same thing as testing.

dnessett wrote:

code patch

Patch referred to in comment 13

attachment enotify_code2.patch ignored as obsolete

dnessett wrote:

messages patch

Patch referred to in comment 13

attachment enotify_messages2.patch ignored as obsolete

dnessett wrote:

I tried to get some comment on the changes I made to ensure internationalization works OK. I asked a couple times on MediaWiki-Internationalization for some help with what was expected of me, but no one responded. I waited around 45 minutes and then left.

So, I guess if there are further problems with internationalization, someone will have to leave a comment in this bug ticket.

see http://www.mediawiki.org/wiki/Subversion#Check_out how to check out a local copy of "trunk" to a subdirectory "phase3" on your machine ( svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 phase3 ). Then you apply your patches. And you can check whether it works as expected.

dnessett wrote:

(In reply to comment #17)

see http://www.mediawiki.org/wiki/Subversion#Check_out how to check out a local
copy of "trunk" to a subdirectory "phase3" on your machine ( svn checkout
http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 phase3 ). Then you
apply your patches. And you can check whether it works as expected.

I did check out the latest version in trunk. That is how I obtained the most recent patches. The problem is my development machine doesn't have a Message Transfer Agent (e.g., postfix) installed and I don't want to go through all of the work necessary to do that just to test out the forward port of code that works for 1.16.2

(In reply to comment #16)

So, I guess if there are further problems with internationalization, someone
will have to leave a comment in this bug ticket.

Hi,

+ switch ( $this->page_status ) {
+ case 'deleted' :
+ $keys['$CHANGEDORCREATED'] = wfMsgForContent( 'deleted' );
...
+ $keys['$CHANGEDORCREATED'] = wfMsgForContent( 'created' );
+ $keys['$CURRENTPAGECLAUSE'] = wfMsgForContent( 'enotif_current_page_clause' ) . "\n";

+'deleted' => 'deleted',
+'created' => 'created',
+'moved' => 'moved',
+'restored' => 'restored'

Message keys "delete", "created" etc. are way too general. Note that messages are global for the entire mediawiki installation + any and all extensions. So collisions are very possible.

Aside from that, it's also impossible to translate as these words depend on context in many languages. So I would recommend something very specific, and be sure to include a link to these 'submessages' in the /qqq of where they can be used (perhaps create a Template at TranslateWiki).

For example:

+'enotif-changedorcreated-deleted => 'deleted',

dnessett wrote:

(In reply to comment #19)

(In reply to comment #16)

So, I guess if there are further problems with internationalization, someone
will have to leave a comment in this bug ticket.

Hi,

+ switch ( $this->page_status ) {
+ case 'deleted' :
+ $keys['$CHANGEDORCREATED'] = wfMsgForContent( 'deleted' );
...
+ $keys['$CHANGEDORCREATED'] = wfMsgForContent( 'created' );
+ $keys['$CURRENTPAGECLAUSE'] = wfMsgForContent( 'enotif_current_page_clause' ) . "\n";

+'deleted' => 'deleted',
+'created' => 'created',
+'moved' => 'moved',
+'restored' => 'restored'

Message keys "delete", "created" etc. are way too general. Note that messages
are global for the entire mediawiki installation + any and all extensions. So
collisions are very possible.

Aside from that, it's also impossible to translate as these words depend on
context in many languages. So I would recommend something very specific, and be
sure to include a link to these 'submessages' in the /qqq of where they can be
used (perhaps create a Template at TranslateWiki).

For example:

+'enotif-changedorcreated-deleted => 'deleted',

Actually, the keywords 'created' and 'deleted' have been around since at least 1.13.2 (and very likely before). However, it is easy to change, so I will.

dnessett wrote:

I have modified the messages according to comment 19 and amd attaching 4 patches.

The first two (enotify_code3_1.16.2.patch and enotify_messages3_1.16.2.patch) comprise the bugfix patches to 1.16.2. I have tested these and they work. The second two (enotify_code3_Current_trunk.patch and enotify_messages3_Current_trunk.patch) comprise patches to current trunk. For the reasons given in previous comments on this bug ticket, I have not tested these.

dnessett wrote:

See comment 21 - enotify_code3_1.16.2.patch

bugfix patch for 1.16.2. This patch is tested.

attachment enotify_code3_1.16.2.patch ignored as obsolete

dnessett wrote:

See comment 21 - enotify_messages3_1.16.2.patch

bugfix patch for 1.16.2. This patch is tested.

attachment enotify_messages3_1.16.2.patch ignored as obsolete

dnessett wrote:

See comment 21 - enotify_code3_Current_trunk.patch

bugfix patch for Current Trunk. This patch is untested.

Attached:

dnessett wrote:

See comment 21 - enotify_messages3_Current_trunk.patch

bugfix patch for Current Trunk. This patch is untested.

Attached:

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

Just a note that log actions, if the page is a user page, includes also all log actions on the user account (e.g. changing user rights).

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

(In reply to comment #27)

Just a note that log actions, if the page is a user page, includes also all log
actions on the user account (e.g. changing user rights).

And any other possible log action on the page. This is particularly annoying if the page is a translatable page with the Translate extension, because you get an "has been created" notification each time a new revision is marked for translation (which happens almost as frequently as normal edits), while usually the problem happens only in rare cases (reupload, deletion, move, user rights change...).
This doesn't seem to happen for FlagedRevisions or patrol log (at least on [[mw:]]), so perhaps it's not only a problem with the notification system?

This has kind of been said above, but not explicitly - if you block a user you get a 'new page' notification for their user page.

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

It's been noted elsewhere that this bug is particularly disturbing, and a solution would be very appreciated, when the log action on the user is a rename: bureaucrats can usurp your username and you won't even receive an email notification, possibly no being notified at all. :-)
This has happened with some confused bureaucrats on some Wikimedia projects.

From #wikimedia today:

<jeremyb> hexmode: page deletions are also mailed as page creation...
<jeremyb> should be trivial to repro
<jeremyb> i've seen it on more than 10 different wikis i think. with at least

4 different configs. including the big foundation cluster

<jeremyb> just watch a page on meta and then delete it
<jeremyb> (and set the right email prefs of course)

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

This is likely to be addressed in 2012-13 by Project Echo:
http://www.mediawiki.org/wiki/Echo_(Notifications)

That said, given how frequently this is getting reported, and that there appears to be a patch (don't know how current or comprehensive), seems like it's at least worth bumping up to normal priority.

sumanah wrote:

Assigning to Benny Situ; asking him to review the patch and possibly bring it up-to-date tomorrow.

(In reply to comment #35)

Project Echo: http://www.mediawiki.org/wiki/Echo_(Notifications)

Thanks for pointing to that interesting page, (I am watching now...)

(In reply to comment #35)

This is likely to be addressed in 2012-13 by Project Echo:
http://www.mediawiki.org/wiki/Echo_(Notifications)

That will be more of a extension/more generalized notification system, We we really want to fix the under lying email issue since Echo won't replace the email notifications most likely.

This is becoming more annoying now on meta, as the translate tool also uses the log, causing 'new page' emails to be sent out.

(adding blocker to 1.20wmf2, bug (which is marked as duplicate of this one) was a blocker for that)

sumanah wrote:

Benny is working on fixing this bug today.

bsitu wrote:

The patch has been applied and being tested on my local dev. I am still doing some more testings to catch some edge cases, hopefully I will commit it to gerrit today or tomorrow

bsitu wrote:

The patch has been committed in here: https://gerrit.wikimedia.org/r/#/c/7986/, but it needs to be reviewed

Can we leave this open until it's been merged?

Also, what about getting Dan his own gerrit account? or does he already have one? (at least we should set accurate metadata on the commit but it's better for him to commit directly) It's not clear if he's still active because his last comment here was >1 year ago.

dnessett wrote:

(In reply to comment #44)

Can we leave this open until it's been merged?

Also, what about getting Dan his own gerrit account? or does he already have
one? (at least we should set accurate metadata on the commit but it's better
for him to commit directly) It's not clear if he's still active because his
last comment here was >1 year ago.

Thanks for the suggestion, but I won't be able to contribute to fixing this bug because I am heavily involved in other things. The relevant sections of the codebase that relate to this bug have changed dramatically since I submitted the patches almost a year ago, so I would expect they would be pretty obsolete and practically useless now. So, I am happy to leave this to bitsu@wikimedia.org (Benny?).

Since I am on the CC list, I am able to monitor progress.

sumanah wrote:

Dan, there's a new review here: https://gerrit.wikimedia.org/r/#/c/7986/

In order to get email every time that changeset gets a review or update, just get developer access: https://www.mediawiki.org/wiki/Developer_access, log into Gerrit, and click the star next to the title "Change Ibb795374:...".

Bogus page creation e-mail notifications are sent, when a page is actually deleted.

For example, these e-mails:

Hallo User,

die Piratenwiki-Seite „2012-03-21 - Mumblesitzung“ wurde von
NumberFive am 27. Mai 2012 um 17:28 Uhr erstellt.

Aktuelle Version:
http://wiki.piratenpartei.de/2012-03-21_-_Mumblesitzung

Das ist eine neue Seite.

Zusammenfassung des Bearbeiters: Automatische Loeschung nach 14 Tagen
per [[Benutzer:NumberFive/Loeschbot]]: sinnfreie Weiterleitung

Kontakt zum Bearbeiter:
E-Mail: http://wiki.piratenpartei.de/Spezial:E-Mail/NumberFive
Wiki: http://wiki.piratenpartei.de/Benutzer:NumberFive

Es werden solange keine weiteren Benachrichtigungs-E-Mails gesendet, bis
du die Seite wieder besucht hast. Auf deiner Beobachtungsliste kannst du
alle Benachrichtigungsmarker zusammen zurücksetzen.

             Dein freundliches Piratenwiki-Benachrichtigungssystem

Um die Einstellungen deiner Beobachtungsliste anzupassen, besuche
http://wiki.piratenpartei.de/Spezial:Beobachtungsliste/edit

Um die Seite von deiner Beobachtungsliste herunterzunehmen, besuche
http://wiki.piratenpartei.de/wiki//index.php?title=2012-03-21_-_Mumblesitzung&action=unwatch

Rückmeldungen und weitere Hilfe:

http://wiki.piratenpartei.de/Hilfe:Inhaltsverzeichnis

Hallo User,

die Piratenwiki-Seite „2012-03-21 - Protokoll Mumblesitzung“ wurde
von NumberFive am 27. Mai 2012 um 17:28 Uhr erstellt.

Aktuelle Version:
http://wiki.piratenpartei.de/2012-03-21_-_Protokoll_Mumblesitzung

Das ist eine neue Seite.

Zusammenfassung des Bearbeiters: Automatische Loeschung nach 14 Tagen
per [[Benutzer:NumberFive/Loeschbot]]: unsinnige Weiterleitung

Kontakt zum Bearbeiter:
E-Mail: http://wiki.piratenpartei.de/Spezial:E-Mail/NumberFive
Wiki: http://wiki.piratenpartei.de/Benutzer:NumberFive

Es werden solange keine weiteren Benachrichtigungs-E-Mails gesendet, bis
du die Seite wieder besucht hast. Auf deiner Beobachtungsliste kannst du
alle Benachrichtigungsmarker zusammen zurücksetzen.

             Dein freundliches Piratenwiki-Benachrichtigungssystem

Um die Einstellungen deiner Beobachtungsliste anzupassen, besuche
http://wiki.piratenpartei.de/Spezial:Beobachtungsliste/edit

Um die Seite von deiner Beobachtungsliste herunterzunehmen, besuche
http://wiki.piratenpartei.de/wiki//index.php?title=2012-03-21_-_Protokoll_Mumblesitzung&action=unwatch

Rückmeldungen und weitere Hilfe:

http://wiki.piratenpartei.de/Hilfe:Inhaltsverzeichnis

Hallo User,

die Piratenwiki-Seite „Kategorie:AG Transrecht/Protokolle“ wurde von
NumberFive am 27. Mai 2012 um 17:28 Uhr erstellt.

Aktuelle Version:
http://wiki.piratenpartei.de/Kategorie:AG_Transrecht/Protokolle

Das ist eine neue Seite.

Zusammenfassung des Bearbeiters: Automatische Loeschung nach 14 Tagen
per [[Benutzer:NumberFive/Loeschbot]]: umgenannt in
[[:Kategorie:Protokoll AG Transrecht]] entsprechend Namenskonvention.

Kontakt zum Bearbeiter:
E-Mail: http://wiki.piratenpartei.de/Spezial:E-Mail/NumberFive
Wiki: http://wiki.piratenpartei.de/Benutzer:NumberFive

Es werden solange keine weiteren Benachrichtigungs-E-Mails gesendet, bis
du die Seite wieder besucht hast. Auf deiner Beobachtungsliste kannst du
alle Benachrichtigungsmarker zusammen zurücksetzen.

             Dein freundliches Piratenwiki-Benachrichtigungssystem

Um die Einstellungen deiner Beobachtungsliste anzupassen, besuche
http://wiki.piratenpartei.de/Spezial:Beobachtungsliste/edit

Um die Seite von deiner Beobachtungsliste herunterzunehmen, besuche
http://wiki.piratenpartei.de/wiki//index.php?title=Kategorie:AG_Transrecht/Protokolle&action=unwatch

Rückmeldungen und weitere Hilfe:

http://wiki.piratenpartei.de/Hilfe:Inhaltsverzeichnis

There are several more samples like these.

Removing 1.20wmf3 blocker since it has been deployed without this. Although intended to be fixed by then. We're almost done deploying 1.20wmf4 by now.

Since this wasn't a regression, didn't re-schedule for 1.20wmf5.

A misleading "created" message is generated, when a page is actually moved in LiquidThreads:

Subject: translatewiki.net page Thread:Support/About WikiReader:How:license text/en has been created by Nike
From: MediaWiki Mail <noreply@translatewiki.net>
To: Purodha <...@...>

Dear Purodha,

The translatewiki.net page Thread:Support/About WikiReader:How:license
text/en has been created on 13 June 2012 by Nike, see
https://translatewiki.net/wiki/Thread:Support/About_WikiReader:How:license_text/en
for the current revision.

This is a new page.

Editor's summary:  -  

Contact the editor:
mail: https://translatewiki.net/wiki/Special:EmailUser/Nike
wiki: https://translatewiki.net/wiki/User:Nike

There will be no other notifications in case of further changes unless
you visit this page.
You could also reset the notification flags for all your watched pages
on your watchlist.

                         Your friendly translatewiki.net notification system

To change your e-mail notification settings, visit
https://translatewiki.net/wiki/Special:Preferences

To change your watchlist settings, visit
https://translatewiki.net/wiki/Special:EditWatchlist

To delete the page from your watchlist, visit
https://translatewiki.net/w/i.php?title=Thread:Support/About_WikiReader:How:license_text/en&action=unwatch

Feedback and further assistance:
https://translatewiki.net/wiki/:Contents

sumanah wrote:

Update: I've just pinged Roan to ask whether he's working on https://gerrit.wikimedia.org/r/#/c/7986/ to fix this.

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

patch is in gerrit. moving patch-need-review.

(In reply to comment #52)

patch is in gerrit. moving patch-need-review.

can you add a link, please ?

Thehelpfulonewiki wrote:

(copied from my Gerrit review:)

Correct me if I am wrong, but I don't seem to be able to find anything to do with page protection in this patch. When a page is protected, I believe there is a "has been created" email message.

The same also applies to when a user is granted a user-right. A user on Meta self-granted a user right but the log action said they had created their own user page.

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

Here is a case where an article creator got a mail claiming somebody else had created the page:
http://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=524278887#What_the_hell_is_this.3F

The page had actually been reviewed. Reviews are not shown in the page history, and the claimed page creator was not listed anywhere in the page history.

Setting target milestone to 1.21. We're not shipping another major release of MediaWiki with this bug.

(In reply to comment #36 from 2012-05-03)

Assigning to Benny Situ; asking him to review the patch and possibly bring it
up-to-date tomorrow.

Benny: Did you have a chance to look at this?

MZMcBride: In this specific case (six duplicates) I see some reasoning to set the TM to 1.21 (thanks), though it might be wishful thinking and I don't want Mark or me again to have to reset lots of wishful 1.21 TMs again at some point.

I would like to see this fixed. And it looks like there was significant activity on the patch on the 21st. If we can get it tested, then we can certainly support it in 1.21.

Please join me in asking people to review it and merge the code.

bsitu wrote:

(In reply to comment #60)

(In reply to comment #36 from 2012-05-03)

Assigning to Benny Situ; asking him to review the patch and possibly bring it
up-to-date tomorrow.

Benny: Did you have a chance to look at this?

MZMcBride: In this specific case (six duplicates) I see some reasoning to set
the TM to 1.21 (thanks), though it might be wishful thinking and I don't want
Mark or me again to have to reset lots of wishful 1.21 TMs again at some point.

Andre, See my comment on the gerrit patch( https://gerrit.wikimedia.org/r/#/c/7986/ ) from Oct 11

Thanks. Copying it here:

"We could add handling for protect/unprotect/right, but this would not solve the fundamental of this issue. Any new log action about an article attempts to send an email, it would be really hard to catch all log-actions since any extensions could add a new log-action and it's not appropriate to handle them inside the notification code.

Instead, I think we should alter the log to include a send_email param in log_param which checks whether to send emails and leave the email subject/body definition to extensions or the code that creates the log. This would require some time and go far beyond 20% time.

This patch solves the problem to a certain level, which handles: create, delete, move, restore, change. change is the default"

(In reply to comment #63)

This patch solves the problem to a certain level, which handles: create,
delete, move, restore, change. change is the default"

If the only problem with the patch is that i doesn't resolve the problem completely, then I quote Nikerabbit "Let's try to get this in and then improve further as needed".

For this or any future patch: any log action has a name to show on Special:Log which is also translatable (unless there is still some very ugly deprecated method to log), so an easy fallback for the unhandled cases would be to notify something like "An action of type $log_action has been performed on the page" etc.

(In reply to comment #64)

If the only problem with the patch is that i doesn't resolve the problem
completely, then I quote Nikerabbit "Let's try to get this in and then improve
further as needed".

+1

To be clear, resolving the issue with a less than perfect fix would at least provide some momentum for a proper fix when our users have been frustrated with what looks, to them, like inaction.

Gerrit 7986 was just merged. Thanks to all that participated in bringing it where it is now. Patches to improve upon it are welcome!

(In reply to comment #67)

Patches to improve upon it are welcome!

I split the remaining issues/proposals to bug 42457 and 42458.
Bug 34153 and bug 37583 somehow depend on both: translation review enotifs could be removed only with 42458 while thread notifications would be mostly fixed even by 42457; but lines are a bit blurred so I'm leaving this bug as a blocker/tracking bug for them for now.

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

(I am reporting this early; parts of my observation may be wrong or outdated)

See my https://bugzilla.wikimedia.org/show_bug.cgi?id=42941 "Bug 42941 - Enotifs show unresolved variable $CHANGEDORCREATED (version of 08.12.2012)"

Regarding

which aims to fix this bug,

  • users and admins should be informed in release notes that - if they use customised mail templates for e-mail notification - these templates need to be (most likely) changed

to make them correctly working with the new software.

An indication that a change is needed is for example an unreselvod variable $CHANGEDORCREATED in received enotifs.

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

Could someone see why this bug, supposed to be resolved, fixed, closed, still causes lots of notifications being sent to my mailbox ?

See:

https://www.mediawiki.org/w/index.php?title=Talk:Echo_(Notifications)&offset=20131217232014#Too_many_notifications_sent_by_the_Translate_extension_without_any_actual_modification.2C_to_my_mailbox_36981

What's wrong? Has the patch been applied on Meta?

See also the related comment #29, sent after the old comment #21 that did not fix everything and was not really fully tested, and not tested for something like admin tool extensions, or the Translate extension, and not even with the newer MEdiawiki message delivery system (used also on Meta, for example to deliver in Tech News to subscribers).

There's really a need for reviwing how extensions can send notifications, and even more importantly how these notications can be delivered by email (MediaWiki is now being more frequently marked as a source of spams, or its emails are just reaching our Spam mailbox, that we almost never read; or they just get blocked by ISPs of your regular users due to excessive traffic).

This bug *is* nominally fixed, by its subject: now most log actions (by number of types) are mistaken for edits :), but the main log actions (by volume on some kind of wikis) have proper enotifs. The remaining issues have been split to bug 42457, bug 42458.