Last modified: 2011-03-13 18:06:15 UTC
It would be nice if (at least) for pages on the watch list, MediaWiki would store per-user information about what specific version this user last saw. Update of this information might happen if the user specifically requests it, and not every time he visits that page. This would make possible a new kind of watch list view: sorted by the number of times that page has been updated since the user last inspected it. There should be a link on that watchlist page which shows the diff between the stored version number and the current version that at the same time updates the information in the database (see paragraph 2). This would make the watchlist much more useful. For privacy reasons, each user should have to explicitly activate that feature, because the information which version of a page (and thus, when) he visited is sensitive personal information. This depends on bug #181 because the ID of the current version needs to be stored.
This (or at least the "diff to last seen" link) is apparently implemented as part of the "ENotif" patch (see bug 454). Also, note that the privacy issue seems to me a non-issue, since the entire watchlist is only visible when logged in - i.e. nobody but you can see what you're watching, let alone when you last visited it. [Marking bug 454 as a dependency, since that seems the most appropriate relationship available.]
I only want to suggest and to introduce the abbreviation "LVR" or (lvr) which stands for "last visited revision". This would facilitate my further program development (enotif = http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ), in which I can simply(!) add a THIRD link in the recent changes, page history and watchlist views (currently for WATCHLISTed pages only, as Enotif only keeps track of pages in the watchlist of somebody, and of user_talk pages). A suggested slightly modified RC line could look like this example: (diff)(hist)(diff-this-to-lvr) page_title_of_a_watched_page(this revision) pageeditor(talk) ....... (diff-to-lvr) is self-explaining, isn't it ? It shows a watching user(=you) the difference between this revision and your (lvr). Be reminded, that Enotif > 1.32 mails are already(!) sent out with a direct link to the (diff-cur-to-lvr), the difference view between the current (cur) version of a page and your (lvr). So if you are interested in trying this feature, download my Enotif 1.33. This nice feature was proposed to me by Chris Phoenix and it was easy to implement. Tom
I added a link to my two screenshots (RC view and Page History) on one of the Enoitf documentation pages http://meta.wikimedia.org/wiki/Email_notification_versions , so that you can see it without actually installing Enotif now. The screenshots show in reality, not as a mock-up, the so-called "updated (since my last visit)" markers - which tell the watching user what revisions bear new contents. Again: these flags are only shown for watch-listed pages. Thus everyone will understand, that the (lvr) - last visted revision - is just the version *before* the updated marker starts provoking you reyes. (The actual layout of the marker can be changed - this beamy layout is just a beginning). Enotif knows the (lvr) revision and sends you a link with the enotif mail. Everyone can make use of the updated markers, because these are shown *independently* from sending enotif mails to you. For example, you can have all enotif mails disabled in your user preferences (you will never get enotif mails on page changes), but you will see the updated markers for the not-yet-visited revisions of watched pages. Once you visit the current version, the corresponding marker is cleared. A further page change of someone else would trigger again an(one) Enotif mail to you - but only if you have enotif mail enabled - and an "updated" marker is shown again. If you don't want to see the updated markers at all, you can disable these in other user preference option. The markers also work smoothly in the so-called Enhanced RC view. The mechanism and option of Enotif are explained on http://meta.wikipedia.org/Enotif (I repeat myself, pls. apologise). Tom
Created attachment 117 [details] Enotif 1.33 implements this with a beamy "updated (since my last visit)" marker The updated markers of Enotif 1.33 are not only shown in the page history view as in the accompanying screenshot, but are also shown on the recent changes view and the *watchlist*, as suggested in this bugzilla-536 title.
I took over to implement this. Easy (trivial) with Enotif. Tom
(is it okay, that I assigned this to me, and that I put wikibugs-l@wikipedia.org into the CC ?)
Introducing an incomprehensible acronym is not a good idea.
You are too pushy for me, when you simply delete another point of view. Please tell me and the community a better acronym instead of simply deleting my proposal, thanks. We already have (hist) and (diff), so we need a short and better name for such links, which are proposed by very kind and friendly proposers. What is your proposal, I kindly ask. My proposal - now withdrawn - was : (last-visited-revision) or short: (lvr) Any recent page line could have - according to MY PERSONAL POINT OF VIEW - these three links (hist) (diff) (lvr) On any RC page footer, a short explanation would explain even the short-sighted users that (lvr) stands for (last-visited-revision) If you have any better proposal, I am looking forward to it. Any proposal will be better than simply a NO-PROPOSAL by deleting something. I KINDLY invite all members of the wikibugs-list to come up with a CUTE proposal for a shorter name for such links. I fully understand, that I cannot butcher the RC view or other view with a personally introduced name. This is also not my intention, and I and Jens Müller need all your help. So repeated again: Please all native English speakers and others, please contribute a cute and short name for such links (diff) (hist) (YOUR PROPOSAL)
bugzilla536 title addition deleted by the proposer(myself) to avoid any flaming here. I need to work with it today. Again: be courageous and tell me your proposal for a short and concise name for links (in Recent Changes View), which unambiguously describe even for dumb users a link to the "last seen version number" or how I call it, the "last visited revision". (hist) (diff) (??????) Page_title I like both names, but we need something SHORT to be put onto the restricted area of the recent page view page. My ad-hoc proposal: (lvr) plus an explanation on every page, that lvr stands for "last visited revision". If you have a better one: please let me know.
Tom, there are several big problems with abbreviations and acronyms. First, they are confusing for newbies and non-native speakers, to whom the terms may be completely unclear. A little message squirreled away on the page will generally not be read. Second, there's an internationalization issue: these terms need to be translated for each language the interface is presented in. When new ones are added, this creates a maintenance burden as the terms must be translated into many languages. Every language needs to come up with not only a term, but a legible abbreviation of it; there may be significant variations in the length of the chosen translation which affects the layout of the user interface (see next). Third, all this has to be fit into the user interface. Especially when page titles, usernames, or comments are very long, this can end up producing a list that's very hard to read, as text haphazardly breaks and wraps. Adding new things to the output makes it progressively worse. Please don't think that we all hate you personally; rather consider the general problem.
All enotif versions > 1.33 have this implemented: a beamy "updated (since my last visit)" marker The updated markers are not only shown in the page history view as in the accompanying screenshot, but are also shown on the recent changes view and the *watchlist*, as suggested in this bugzilla-536. I can only repeat, that interested users should check out my new Enotif 2.00 for CVS 1.5 see http://bugzilla.wikipedia.org/show_bug.cgi?id=454 (use the latest tgz file in my latest comment. The diff files do not have all additional update files in it, because diff does not store or compare my local files, which were not in the CVS)
( implementation detail for interested readers: because there are no "sticky version" numbers yet which survive delete/undelete cycles - see other bugzillas - its implemented indirectly via the wl_notificationtimestamp in table watchlist, which stores the **time**, when a user has got a notification email for a page change of another user. The version of a page exactly before that timestamp is the "last visited revsion (lvr)" of that page, for this watching user. )
-- this is fixed using a timestamp (not using a sticky version number). COuld be regarded as closed -> close.
I reopened this. There was a recent comment to http://bugzilla.wikipedia.org/show_bug.cgi?id=603 (delete/undelete cycle doesn't preserce old_id) which bug I have overlooked when closing the 536.
I am currently working and have almost finished the implementation of a direct link to the (diff-to-last-visited-revision) short: diff-to-lvr of watched pages. This is just another valuable exploit of my ENotif patch http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ; it requires a new column wl_lastvisitedrevision (lvr) in the database table watchlist. I have already written the necessary conditional database updating code for the updaters.inc module. Implementation detail: the lvr is already retrieved during page views of watched pages and since now stored together with the ENotif timestamp in the new separate database column. People who are interested in this patch can ask me for the diff of my patch. The new (diff-to-lvr) links are only shown for one's watched pages, because only watched pages have entries in table watchlist to cache the "old_id". Old_ids currently do not survive delete/undelete cycles, but this will change at some later time; the patch is working fine as long as the old_id is not changed, which is the case if no delete/undelete cycles are performed. As with ENotif, only "alien" changes influence these links; if there is an "updated (since my last visit)" marker, than a (diff-to-lvr) makes sense and is shown; otherwise none of the latter are shown. It means for a watching user: there are no unknown changes on this watched page. The patch works independently from the user options of enabling or disabling the ENotif mails to be sent. With other words, you might choose never to receive ENotif mails but you see the "updated" markers and (diff-to-lvr) links on not-yet-visited pages you are watching. (Lengthy, but hopefully clear explanation.) Wikinaut Tom
Implementation of this enhancement needs one additional field in table watchlist. ALTER TABLE /*$wgDBprefix*/watchlist ADD (wl_lastvisitedrevision int(10) unsigned NOT NULL default '0'); The patch is short and will be published including the updaters.inc script soon. A third link is shown - in addition to (diff) (hist) links on Recent Changes views - for those pages, which are _watched_. This third link brings you directly to the difference view of the diff(current ./. your last visited revision). It was a long-felt need of many users.
(In reply to comment #1) > This (or at least the "diff to last seen" link) is apparently implemented aspart of the "ENotif" patch (see bug 454). Also, note that the privacy issueseems to me a non-issue, since the entire watchlist is only visible when loggedin - i.e. nobody but you can see what you're watching, let alone when you lastvisited it.[Marking bug 454 as a dependency, since that seems the most appropriaterelationship available.] I think there are plenty of people who will not think that this is a non-issue. The issue we normally look at is not who is *supposed* to have access to this information (security could be better - using HTTPS, for example), but rather whether another person or organisation is collecting the information.
(In reply to comment #17) This is probably the wrong place to discuss this, but just to clear up the previous comment, which was a little confusing... What I meant was: I think there are plenty of people who will think that collecting personal information *is* an issue, even if no humans are supposed to have access to that information. I also mentioned that it would be better to use HTTPS (to be fair, they do have a secure server, but I'm suggesting that certain pages be secure by default without having to manually type in an address starting with "https"). There's also the issue not mentioned before, which is that developers do have access to personal information.
Assumes that rev_id is in order. Due to merges/imports, timestamps are better.
