Stop the (program internally) linked watchlist treatment of normal pages and
their corresponding talk pages (not: user_talk pages).
In the current MediaWiki version pre-1.4, if a user adds a page X or the
corresponding talk page talk:X page to the watchlist, the other page (talk:X or
main page:X) is also watch-listed. However, the program treats them internally
as ''one'' database entry and applies logical operations on namespace
identifiers to achieve the wanted combined watch list handling. For the normal
program flow this is not a problem, but when introducing email notification (see
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ), a clearly separated
treatement is needed to store the timestamp of sending the notification mail
separately for every page.
It is now proposed to stop the linked (program-internally) treatment using
logical operations and instead to treat both kind of pages *separately*,
namely to add ''two'' entries to the '''watchlist''' table:
if a user adds a page:X , the program needs to add automatically both page:X and
the talk:X page to the watchlist to (have the same action as in older versions).
This is necessary to allow a clear separate treatment of memorizing when a user
visits one of the pages - it could be that only the talk:X page is visited,
whereas the normal page is still waiting for the user's visit. Remark: visiting
a watched page clears its notification timestamp which is used for suppressing
notification mails if one is already sent.
The last paragraph describes the modified handling *with the enotif patch*:
The described changes are partially done for
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 (enotif) in version 1.4 in
that sense, that the pages are treated separately. This also means a small
limitation/drawback when having the enotif patch applied, namely that a user
must explicitely add each single page (non-talk, talk page) he/she wants to
watch to the watchlist - which differs from previous program releases. The
limitation/drawback is planned to be released in further enotif versions.