I have created a proposal to implement this in watchlists and RC pages at the 2016 Community Wishlist Survey. Voting started today.

With javascript enabled, as long as there is an immediate way to undo, there shouldn't be a confirmation. We don't have to confirm when we watch/unwatch a page on its page, so it shouldn't behave differently in the watchlist itself.

As of April 2016, the diff popup features "send thanks" as an action. I'd prefer to have this on each line of RC per my request, but at least this gadget update is useful.

Which version of AWB are you using? It has gone through changes since April that may affect this issue. If you aren't using the current version, you will have to manually download and install it, as Sourceforge made changes that rendered previous versions' updater unusable.

T55525 seems like a similar idea.

The link classifier script has helped me out a great deal with identifying redirects on the "Edit watchlist" page. I assume red links are already red without using this script.

Something has fixed this issue in the meantime. A particular page where I had this problem isn't demonstrating the sluggishness I saw before.

In T133326#2586956, @kaldari wrote:

@Stevietheman: The bug already exists: T141154.

I thought this was the bug. Also, what would my bug state and where would it go?

It has been over 4 months since the most recent popular pages updates, and the pages in projects in which I'm a member are getting stale. Is anything being done to resolve this?

In T143182#2561436, @ori wrote:

I can demonstrate this. Try typing into the textarea of each of the pages below in one of the affected browsers (Firefox, Chrome 51, etc.):

This problem happens to me with Chrome 52 or Firefox 48 on Windows 10. I tried the following but none of them helped the problem:

As a workaround, I've written F&R entries to revert placement of the underlinked tag.

What are the current development needs of this tool? I'm really missing its output in projects I'm associated with. (note that I'm not committing to anything at this point.)

To clarify, will this WhatLinksHere link only show those categories just added or removed?

The bottom line is a user needs a way to know exactly which pages were added or removed. If those are lost in a longer list, that would be only marginally helpful. We shouldn't make users hunt these pages down.

In T117122#2011491, @Dispenser wrote:

I built transcluding changes should be good enough until its implemented in MediaWiki.

Jonesey95, that issue was marked as invalid because it's already implemented. When this feature was rolled back a few hours ago due to a database issue, the filtering was taken out too. Once this is all up and running, you will have the filtering.

Urgent/Non-urgent (Alert/Notice) seems to make the most sense, although I would recommend letting users set which types of notifications fall into either (maybe someone wants a Thanks to be urgent :) ). Of course, start out with a default set of how notifications fall into each category that seems to make the most sense per consensus. Also, don't assume I've "read" (or dealt with) everything because I've looked at the list of alerts/notices -- let me tick those off somehow.

I think this would be a useful module for WikiProjects. I've been tempted just to manually create a list of the newest WikiProject-wide topics (editorialized to keep out not-so-useful ones), but I would probably have to update this on a daily basis. Is there any way to create such a list with any current wiki technology outside of my using RecentChangesLinked on a list of talk pages and plus cut-n-paste of topic title/links?

I'm surprised the Wikidata people didn't create a "MetaWikidata" for these purposes.

I as a user would like to know precisely which pages were added and which ones were removed. How that is accomplished is open.

I modified the above as the first change actually didn't make sense because 'all' shows all.

Why can't this be as simple as doing the following on Special:RecentChangesLinked/Category:WikiProject_Foo_articles?

OK, my bad. I assumed those associated with this software update would understand what I was describing and could comment on that. Oh well. Happy Thanksgiving!

I understand that we don't want to create two duplicate named refs if one is inside a template, but in the case of the William Harding Mayes article, all the refs in question are inside the same template, and duplicate names are being generated.

T119712 created to address this because my question is being ignored.

I am asking a question about why it works this way. Opening a ticket is about logging an issue. I would like to understand why it works the way it currently does before deciding whether to do that.

Apparently $wgUseRCPatrol isn't enabled on the English Wikipedia, so that won't work as a workaround. Also, that wouldn't work per the feature request anyway, as:

1. a change reviewing (or more specifically, vandalism hunting) user wouldn't be able to tag another user as trusted so they wouldn't see their edits in the first place.
2. it would assume that there would be active-enough patrol of edits per $wgUseRCPatrol to keep the edits to review under control to the extent desired by the change reviewing user.
3. it would assume that the change reviewing user has 'patrol' user rights so they could hide patrolled edits.

It looks pretty solid on MediaWiki.org, but I saw where in cases where two pages were added to a category, it doesn't say what the second page is, using "and one page" instead. How would a user find out what the second page is?

So, with the English Wikipedia running 1.27, this feature is now live, and all I have to do is watch a category to see what members are added or removed?

If that is indeed, up to date, it would seem that we should be marking the fix as minor, not a major one is the correct course of action.

In T117300#1788541, @Reedy wrote:

You can, of course, ignore/skip these pages manually.

In this case, the reader sees no difference, so that makes it minor in that sense, IMHO.

Was the settings file I uploaded run? This is an outright bug where a duplicate name is generated for two separate but identical references. I obviously can't save such changes.

Running based on the settings file I uploaded should show the problem.

I'm glad this wasn't closed yet, because I have gotten it to repeat, and it occurs with a basic settings file:

I've found another article where this is happening: Virginia Tech -- AWB is trying to create a duplicate named reference "Virginia Tech Foundation".

Here's the settings file. It's pretty basic.

I don't think that has anything to do with what I saw. The ONLY change on the page was the removal of the excess pipe.

I have tried to distill a test case, but this issue doesn't show itself if isolated. I am convinced this happened, though, because this was the only fix made on the page, and it was supposed to be skipped.

In T117300#1771002, @Magioladitis wrote:

@Stevietheman You can check the manual http://en.wikipedia.org/wiki/WP:AWB/GF for which fixes we consider "minor" and which we consider "MoS".

I guess I jumped the gun on asking for this process to be threaded (not having looked at the code). If performance can be tweaked without doing that, all the better.

In general, WikiProjects needs better project-specific tools (notifications, newsletters, SuggestBot, identifying potential members, organizing members, etc.) and possibly changes in MediaWiki itself to accommodate WikiProjects. One example is we need a more automatic way to do change patrol across the included pages of a WikiProject. "Related changes" doesn't accommodate this without the periodic manual creation of a watchlist page.

Alternatively, this could be called "Copy as piped list" if you prefer more programming-like language.

I hadn't noticed 'Dash' because I keep my list sorted.

Per Josve05a's mention, this example returns a typographical dash (--) in the list as well.

These issues seem to be the same, as the example in the other one returns a typographical dash as well.

OK, got it. Thanks!

Will this fix appear in the next release? I don't see it on this page: https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/History

I just tried this option, and it still does not work. I'm not sure why this is closed.

Let's review.

That's right.

Why would anyone want the list to re-alphabetize after a stop even if "Keep alphabetized" is checked? Let's look at this from a "use case" perspective.

OK, I will try that in my next run. I don't think that would resolve the issue, though, because I really don't expect the list to re-alphabetize upon stopping. Maybe that's the issue?

What I'm saying is that if I Stop, the replacement entry (the redirected-to file) either vanishes or moves to a different position in the list.

That is correct. They are replaced.

Thank you. This fix right here will relieve my night terrors. :)

Works great! Thanks! I'm using red for deleted and blue for added with white font colors. My eyes can't miss these. I just wish it wasn't so subtle to begin with.

I have simplified settings to a small file to demonstrate the issue.

I'm sorry I haven't responded with further info. Instead of providing my entire settings, which is huge and distracting at this point, I will try to distill the issues in a simple settings file. Give me a few days.

I would also add that remembering the column widths would be very useful as well.

What's funny about this issue is that I've been noticing it for a long time, but it didn't dawn on me what aspect of AWB was the likely cause. I've been frustrated on many occasions by particular F&R changes not happening when I expected them to occur.

This may also be useful for watchlists, although there it is more difficult to see a cluster of work by an editor one may wish to thank.

I am going to try and explain why this is needed for article cleanup.