Yes, enwiki is down to 10 hours.

Just wanted to note we're past the previous estimate and the lag is past 25 hours and seemingly getting longer. This is affecting a Quarry query I've been needing to run for literal days and database reports I have aren't keeping current. Any new estimates?

After looking at the option of manipulating CSS to display the image on mobile, and reviewing the source of output on desktop vs. mobile, there's the appearance that the image is asynchronously loaded, thereby making CSS manipulation via TemplateStyles not workable. Or am I missing something? I've fiddled with visibility and display settings, and nothing works.

In T124168#9470724, @Tacsipacsi wrote:

Anything that’s hidden using CSS (rather than removing it from the HTML) can be unhidden using CSS. However, it’s your responsibility to make it readable on small screens if you do so.

@Izno - thanks for the explanation. One of the navboxes I'm concerned with was created mostly by me, so I suppose I could rewrite it to not rely on navbox underpinnings, but I sure don't like reinventing the wheel if I can avoid it. And it's probably not worth it just to get an image to display and remove useless padding.

In T124168#9470292, @Shushugah wrote:

@Stevietheman are you using Desktop mode or Mobile mode on phone? I confirmed with my iPhone SE and iPhone 13 on Safari and Chrome browsers; that navigation template doesn't render. For example https://en.m.wikipedia.org/wiki/Foxconn_and_unions, on the other hand, if you call desktop url (without "m") like https://en.wikipedia.org/wiki/Foxconn_and_unions that does render on both mobile phones.

I've noticed that navboxes do display in the Wikipedia: namespace of English Wikipedia when I look at the page in a wide view (phone turned sideways). It's just that they have extra padding on the top and bottom, and don't display the embedded image (image=). This is my experience using Chrome and Firefox on Android.

Will the changes cover calls by apps like AutoWikiBrowser, like when I set it to "Use MW preferences" for determining if a page I change is watched?

I had asked for the Thanks link to be added to RC pages. I'm wondering if the study maybe doesn't take into account whether most of the user base even knows this feature is now available, as it was conducted right after implementation.

Thank you especially NRodriguez!
(I'd award a token to you but I don't know how)

Looks like I was on hiatus when this feature was implemented, so I didn't have the opportunity to say "thanks!".

Any recent progress on this? I recently came back from a hiatus, and I'm still having to manually regenerate a list of all a project's pages for project change patrol purposes. It would be nice to no longer have to do that.

At the very least, it would be useful if a few more time period options were added. I'd like to see a (3 day / 72 hour) option as a default for articles I edit.

As a former software developer, I take great umbrage at the phrase "computer freak" to describe folks who develop software.

In T123866#3291673, @MGChecker wrote:

Yes, but Notifications are private as well.

In T123866#3283219, @MGChecker wrote:

I think notifying watchers instead of creators is much more effective and useful.

In T164178#3245629, @Niharika wrote:

@Stevietheman I can't find a reference for it now, but the pageviews API does do caching on their end so caching on our end might not be as big a speed boost as it looks.

#4 sounds like it could be done in a fairly straightforward manner, using a temporary indexed database table.

@Samwilson I ran 'All' for my own account, and all the entries looked familiar and highly likely to be correct. Thank you for your work!

I might be the person who said it should work like a watchlist (private), and this is indeed to prevent negative responses as discussed above. I'm willing to wait for it being done this way.

On second thought, I guess it would be a little tricky as some entries' number of edits would be tied with others.

I was just taking a look at this again, and wondered why the entries don't have counting numbers (1-100). Is there any particular reason why this can't be there as well? I would think it would communicate that there are 100 total entries and a user can better mentally picture a slice of the list (say, Top 10 or Top 40).

Thanks. The secret stops here. heh

Is this available for user review (beta) anywhere?

OK, so I'll open a ticket wherever these API developers are. Have a link?

So, let's open a ticket and they will set it as low priority. As long as it's documented in the system would be fine with me.

This was discussed above. You had said that the APIs you use to fix a dead link using an archive didn't return the title from the archive page. Would it be prudent to request that they do?

Would it be reasonable to open a request to have a particular API that is used return the page's title?

It can be argued that way, but with "Archived copy" sticking out like a sore thumb, it calls for addressing, and therefore, additional time is spent, when the bot could have in theory inserted this.

Is editors' time manually correcting titles taken into account in the cost-benefit analysis? The idea of a bot creating new work doesn't seem quite right.

Although I'm in no position to mentor, I'd like to help with brainstorming ideas too. I personally like the simplicity of the dashboard on Discogs.com (seen if you have an account).

There are still popular pages listings going empty, with examples Anarchism, Louisville, and Kentucky. When is the bot scheduled to fill these (and presumably others) in?

Please close this ticket as a duplicate of T160721. I had meant to create this as a subtask.

In T156857#3107265, @Niharika wrote:

This ticket was only to build a basic bot from my understanding (3 story points). It's covered way more than that. If there are any other things the older bot did and you don't see them in the current bot, please file new tickets for them. It'll make our job easier. If you don't want to do that, I can file them, just list them here. Thanks.

In T156857#3107624, @kaldari wrote:

New ticket for leaving headers and categories alone when updating the report: T160683.

In T156857#3107444, @kaldari wrote:

Do you have any idea why geography WikiProjects have adopted this practice? In other words, why do folks not want to either define the Louisville group as an actual task force or give it it's own banner? Having it as both simultaneously is confusing and doesn't work well with PageAssessments.

I know there was a push a few years ago to standardize the names of WikiProject banner templates, but apparently this didn't take into account WikiProjects that were piggybacking as task forces. Perhaps there could be another clean-up drive to fix these. Any thoughts on that? This isn't strictly necessary to get Popular Pages bot to work for them, but it's going to be a recurrent problem for any software we build for WikiProjects (which I would like to do more of).

If I have a suggestion for improvement, should I open a separate phab ticket? I would like to see a "Top edited pages" list that shows the top 100 pages from all namespaces together.

Note that I now see the ticket for handling the redirects.

Also, I'm unsure why this is marked as "resolved" as the bot doesn't yet do all the things the previous version did.

Issues I see:

Kudpung, I don't see how comments like yours are constructive, much less advance this along. There are big ideas I'd like to see happen too, but I would not use a strategy like yours. Unless you chill, I have nothing else to say here.

This proposal didn't make the top 10, thus it's not a core Foundation priority, but I think being at #14 makes it appealing for developers to take on. Also, I don't think we should ever assume that something could have been done in a certain time period because many other things have been developed in that time frame, and there's only so many active developers to go around. If one thinks this should be prioritized higher, one should make that case.

I'm thinking this should apply to major editors of a page as well. I regularly run into articles tagged for deletion where the creator is long gone, but editors who touched it quite a bit along the way are still around. The current approach of maybe sometimes the creator being notified (like if Twinkle is used) has led to charges of our delete processes being sneaky. See https://bbs.boingboing.net/t/40-of-wikipedia-is-under-threat-from-deletionists/95250

I was thinking of Muhammad Ali as a good example as well. Thank you for your quick response. I do agree this should be incorporated into results, for sake of fairness in comparative results.

Something related to this just occurred to me. The previous bot was stated to "aggregate the views for all redirects to each page." I assume this meant that views to each page would be counted whether directly viewed or arrived at by a redirect. Is this applicable in any way to what is being worked on right now?

I'll just chime in to say that I'm comfortable with where this part is heading. Thanks everyone.

I haven't looked at this ticket for a week, and it looks like a lot of discussion has flown past me. Anyway, as a former programmer, JSON is simple for me to update, but most Wikipedians aren't programmers.

In T156856#3024025, @Niharika wrote:

Ah, I mistook that to mean that we use the bot to display the Top 10 viewed pages of a wikiproject on the project main page.

I don't see how a different list entry affected another one, but oh well. Thanks.

Note that there's no consensus to deviate from having a "number of pages" field, and I would oppose deviating from that. It would be unfair to the many WikiProjects not represented in this discussion, for starters.

In T156856#3022460, @Niharika wrote:

In T156856#3022280, @Stevietheman wrote:

On this point, I was hoping to be able to produce a second shorter result for a WikiProject I work on, basically a Top 10 list I can show on the project's front page. Things like this add to the project's public showcase.

Feel free to create a ticket and tag it with Community-Tech. We'll look at it in our next sprint meeting and see what we can do. :)

On this point, I was hoping to be able to produce a second shorter result for a WikiProject I work on, basically a Top 10 list I can show on the project's front page. Things like this add to the project's public showcase.

Technically, doing that would simplify things, but I don't believe the issue was computational expense. I think some WikiProjects simply wanted shorter lists. I can't speak for all WikiProjects on this, so I don't know if everyone would agree to a top 1,000 list.

'Number of pages' is the number of top-viewed pages the wikiproject wants ranked. So if they select 1000, they want to see the Top 1,000 viewed pages from their project. (1,000 was the upper limit in the previous incarnation of this tool)

I appreciate the deference to keeping it the way it is, but the on-wiki config works for me, although if anyone jumps up and down and wants a lookalike to the previous GUI, I won't object as the GUI was well-designed. I think a server-side process for handling errors and perhaps messaging someone who made a mistake in the wiki table is perfectly reasonable. I think those tending to request these pages will be editors with reasonable wiki know-how.

The vector skinning image looks pretty good, although I might have expected the stars to be a bit smaller to fit into the lines better. I can't really speak well to the class/ID matters - a bit over my head, although matmarex's point looks accurate. Reuse sounds good, but if you have to contort code for such, maybe it's better to strike out with some new classes/IDs specific for this purpose.

I'm probably stating the obvious that everyone already knows, but this should exclude spider and bot visits. If we compare to the Massviews interface, we would be selecting 'User' for the Agent. We're only concerned with human visits.

Thank you @Sn1per for your excellent work. This design works for me overall. I just have a couple thoughts:

I'd go with B. I don't see any hard reasons for tinkering with the display of log entries in this context.

@mforns Real-time data, isn't a concern as these are monthly-generated pages, except at the point of producing them. It's certainly better for performance that readers are loading flat pages than running the real-time data grab every time. Why push the servers when we don't have to? If people want to do specific queries on visits, they can use Massviews.

@Anomie, I edited my response to you above for (hopefully) clarity.

Now, I guess we have a different discussion with regards to 'Hide my edits' and 'Hide minor edits', the former being a non-problem in my view, as if one has made an edit to a page, they have cleared/visited it, so there's no point in seeing a recent edit behind it. I think. :)

@JEumerus - that sounds right. I just wonder if there ''are'' any bots using undo instead of rollback for directly preceding edits. If not, this two-pronged fix seems like it will be enough to drive a complete solution.

@daniel, If an approved bot does a rollback or an undo of directly preceding edits, I assume it's performing an approved task and the edits reverted (either way) will therefore not be of interest to the watchlister. If this assumption is not true, I would like to read of a scenario that makes me go "hmmm, wait".

OK, I'm trying to understand. At this point, I don't understand why a rollback would be different from an undo of the directly preceding edit(s), for our purposes here.

Pardon my ignorance, but what does 'Blocked' mean?

I wouldn't distinguish any revert from any bot. Whatever a bot reverts should be taken as bot edits to hide. After all, I believe the user that is hiding bot edits is seeking to see the latest non-bot/non-bot-reverted edit that occurred since they last visited the page.

As for improvements, Niharika's ideas look useful to consider, and I also had one from March 15, 2015 that I submitted and didn't get acted upon. It's basically to show changes from month to month for each entry like how Billboard charts do it. Obviously, the first monthly generation wouldn't show these changes.

I also concur with DanielPenfield's comments in the 2016 Community Wishlist Survey proposal.

I think it should stay on WikiProject subpages, generated monthly as it is now (I think that's what survey voters expected to keep, not have this product changed into something else, noting that changes in the program that generated it probably don't matter to the casual reader). A key to this report's value is its production _for_ WikiProjects. And I want to be able to point people to a page in projects I work for, not a separate tool page.

In the 2016 Community Wishlist Survey, a proposal for fixing this wound up at #47 (tied for #45) out of 265 proposals.

See my sandbox, where I have a template call to "citation needed" followed by one to cn, a shortcut. They both render the same in HTML. The background processing may be different, of course, but what the reader sees and the browser receives is no different in any possible way.

I wonder, though, if bypassing stub template redirects is seen as more important than bypassing template redirects in general. Is using the correct stub template seen as especially critical?

The feature isn't being retained as such, though. It's being highly restricted. One has to jump through technical hoops to use it, and therefore, it's totally the decision of the AWB user when they use it. This really isn't different from deciding to do the same thing manually. And as always, the specific editor is responsible for their edits.

I can confirm this issue with respect to an IP user I am watching. I can't get rid of the block log entry in my watchlist, and I don't want to use the "nuclear option" unless all of my watchlist reviews are completed.

The wishlist proposal related to this issue is listed at #9 out of 265 proposals (technically, tied at #8).

The wishlist proposal related to this enhancement requested is listed at #40 out of 265 proposals (technically, tied at #39). There is clearly at least moderate interest in this.

So, on point, should I (or someone) create a blocking task?

Oh, then it was new to me then. :) I don't think I've used it until just yesterday.

Perhaps. The user UI includes transclusions by default, I think. One can decide to hide them.

I haven't worked with the API, but there is a special page for it here. Perhaps it's a new one.

Note that "What transcludes page (all NS)" works. But my point was that a WLH on AWB doesn't work the same as WLH on the wiki (as accessed from a browser).

Yes. Transcluded userboxes.

Note that this is appearing as a proposal in the 2016 Community Wishlist Survey here.

If this indeed fixes intitle searches too per Wikipedia:AutoWikiBrowser/History, that's great, as I was going to open a ticket for that.