Wikimedia Bugzilla is closed!

Nope.

Although, there could be some addition of some of the mono modules for apache, but it's not worth the hassle, and causes a dependancy nightmare.

It would require something written in JS or PHP to be integrated with MW itself...

Do we know what it's actually doing? As it should be trivial to do....

(In reply to comment #2)
> Do we know what it's actually doing? As it should be trivial to do....

Is it me, Reedy?  It seems like I'm hearing mixed msgs.  You say "Nope." and you appear to feel the implementation would be way off the charts.  Then you return and give me the impression that it would be very easy to do?  From the perspective of the user, the program adds little checkboxes to the watchlist.  Once an item is read it stays on the list normally, unless the checkbox is clicked and checked.  Then that particular edit vanishes from the watchlist.  The edited article remains on the "watchlist list", so that the next time someone edits the article, the new edit appears on the watchlist.  So the only enhancement is the little checkbox and the user's new ability to check that box and drop that edit off the watchlist.  Does that sound doable?

I was meaning in it's current implementation it's unfeasible

have a look at [[mw:Manual:Page change notification]]

(In reply to comment #5)
> have a look at [[mw:Manual:Page change notification]]

That link just sends me to the Bad title page, a (non-existent) Special page on Wikipedia.  <g> Gave me about a 7 or 8 on my WS-o-meter, tho.

http://www.mediawiki.org/wiki/Manual:Page_change_notification

seems like the checkbox would be an "easy" javascript enhancement to the existing bold/non-bold display.

and while it would be a likable innovation to drop the checkmarked items off the list entirely, just the ability to readily see a previously checked-off item as already read would be an at-a-glance enhancement.

(In reply to comment #8)
> seems like the checkbox would be an "easy" javascript enhancement to the
> existing bold/non-bold display.

also, not sure what is meant by bold/non-bold display.  I see no diff in boldness, that is nothing is bold when I first view my Watchlist, and nothing changes after I view an item.  So, am I missing something?  Do I have to add something to a .css file?

(In reply to comment #10)
> (In reply to comment #8)
> > seems like the checkbox would be an "easy" javascript enhancement to the
> > existing bold/non-bold display.
> 
> also, not sure what is meant by bold/non-bold display.  I see no diff in
> boldness, that is nothing is bold when I first view my Watchlist, and nothing
> changes after I view an item.  So, am I missing something?  Do I have to add
> something to a .css file?

It depends on the configuration of your Wiki. Some wiki's are configured to bold entries that you havn't looked at yet. Either $wgShowUpdatedMarker (Although comments in the wm config files seem to indicate $wgShowUpdatedMarker might be broken) or $wgEnotifWatchlist needs to be set to true in order to see bolding. This is the case for some wikis in Wikimedia land (like commons or meta), but is not the case for enwikipedia.

oh, darn.  so.  if the little checkmark boxes are relatively easy to encode, but the code to make the selections drop off the list is a real pain, then it would certainly help to at least have those little boxes to check off when we've read an item.  That would give us an at-a-glance aid to see where we've been and don't have to go again, isn't that so?

(In reply to comment #12)
> oh, darn.  so.  if the little checkmark boxes are relatively easy to encode,
> but the code to make the selections drop off the list is a real pain, then it
> would certainly help to at least have those little boxes to check off when
> we've read an item.  That would give us an at-a-glance aid to see where we've
> been and don't have to go again, isn't that so?

Making a checkmark box and making things drop off the list (esp for watchlists which are customized per user) are about the same difficulty

The code which keeps track of what you've already looked at hasn't been touched in a while, and is a little bit scary...

(In reply to comment #13)
> (In reply to comment #12)
> > oh, darn.  so.  if the little checkmark boxes are relatively easy to encode,
> > but the code to make the selections drop off the list is a real pain, then it
> > would certainly help to at least have those little boxes to check off when
> > we've read an item.  That would give us an at-a-glance aid to see where we've
> > been and don't have to go again, isn't that so?
> Making a checkmark box and making things drop off the list (esp for watchlists
> which are customized per user) are about the same difficulty
> The code which keeps track of what you've already looked at hasn't been touched
> in a while, and is a little bit scary...

Fear is not an option. <grin>

Will this be assigned soon? or no.

(In reply to comment #15)
> Will this be assigned soon? or no.

Bugs (and especially feature requests) are not normally assigned to people per se (unless they are very high priority things), more if an interested developer sees it, that developer assigns it to him (or her)-self to do.

I changed the title to better reflect what I think this is requesting:
*Option to hide read entries from watchlist
*Add check boxes to explicitly mark entries as read.

Since a read vs unread feature is already implemented by having unread entries in bold, and read entries in normal font weight (although not enabled on enwikipedia if that happens to be where you're checking these things) I'm assuming that is not part of the bug request.

Please make sure my change in bug title correctly reflects your feature request.

(In reply to comment #15)
> Will this be assigned soon? or no.

Realistically, at this point, it is more up to you at this point to get something done about your feature request.

You have a few options:

* implement it yourself and provide a patch,
* persuade a friend to implement it for you and provide a patch,
* join in #mediawiki on IRC and persuade someone there (preferably someone with commit access), that your request is easy, straight-forward, and undeniably a good thing to implement, or
* Since this particular request could be implemented in JavaScript, you have a larger choice of people to choose from (see [[Category:User js]]) to ask script it up and then you could put it in [[Special:MyPage/skin.js]]

I recommend the last option, but if you do that, please come update this bug once you have a solution.

(In reply to comment #16)
> (In reply to comment #15)
> > Will this be assigned soon? or no.
> Bugs (and especially feature requests) are not normally assigned to people per
> se (unless they are very high priority things), more if an interested developer
> sees it, that developer assigns it to him (or her)-self to do.
> I changed the title to better reflect what I think this is requesting:
> *Option to hide read entries from watchlist
> *Add check boxes to explicitly mark entries as read.
> Since a read vs unread feature is already implemented by having unread entries
> in bold, and read entries in normal font weight (although not enabled on
> enwikipedia if that happens to be where you're checking these things) I'm
> assuming that is not part of the bug request.
> Please make sure my change in bug title correctly reflects your feature
> request.

Yes, that's a good change.  Thank you, Bawolff, and you, too, Mark!  I'm going to see what Java can do and then get back to you.

I can't seem to interest anyone to write out a Javascript that will do this.  There was a suggestion that this would be better if put on the server, so here I am, back again to see if this can be made to work.  I had a thought that rather than just change everything for everyone, perhaps this could be added to the Watchlist preferences tab as an option to turn on or to leave off?