I used https://quarry.wmflabs.org to test those queries on enwiki_p.

I was thinking mainly of this example and the fact that community discussion is not requested for the addition, unlike the withdrawal.

@Dzahn Sorry, my message was not clear. I know how adding blogs is done on metawiki. What I meant to say is that the banned user just had to create a disposable account to index his blog https://meta.wikimedia.org/wiki/Special:Contributions/Blogdukiwi. It would probably be useful not to accept all these requests almost automatically, rather to filter the requests. For example according to the seniority of the user who made the request or that of the blog (in this case both were new).

Hi @Dzahn, thanks for removing.
As this could happen again, it might be better to start by not allowing this kind of disposable account out of nowhere https://meta.wikimedia.org/wiki/Special:CentralAuth/Blogdukiwi to be automatically indexed on request.

There is a similar problem with https://dumps.wikimedia.org/frwiki/20170401/
frwiki-20170401-stub-meta-history.xml.gz is 22.2 GB whereas is should be around 9 GB. A simple script using this file to count user contributions report largely inflated numbers. After digging a little, there are several dumps in the same file, for example rev id 100000000 appear 4 times with the same data.

or delete_redir like move_redir

+1 This would be very useful for stats.

This bug affects a lot of articles and should be easy to fix.

The problem seems related to images with a larger height compared to width :

The problem is not directly related to dump but come from the revision table :

@Akeron: yes, sorry, Erik's totally right here. That data has spiders filtered out, but doesn't have the breakdown as you requested it.

In T112956#1838690, @Milimetric wrote:

We do have dumps in the same format as the old ones available here: http://dumps.wikimedia.org/other/pageviews/ [1]

The per-project hourly pageviews are available back to May. They're not split up by spiders vs. non-spiders, but that's something we can provide if the demand justifies it.

Hi, thank you for the API, interface is very nice and pageviews stats without spiders are very helpful.

PageImage is actually used on mobile version for search, try searching "Drapeau de la France" on https://fr.m.wikipedia.org/w/index.php?search= the wrong image will be displayed in the pop-up menu.

Another obvious example on Flag of France : https://fr.wikipedia.org/wiki/Drapeau_de_la_France
PageImage choose https://commons.wikimedia.org/wiki/File:Royal_Standard_of_the_King_of_France.svg instead of https://commons.wikimedia.org/wiki/File:Flag_of_France.svg
This is strange because the chosen image is very far from top and the English article doesn't have this problem.

The request use "GROUP by rc_user", so all IP ( rc_user=0) are merged and counted as a single big user.

I confirm this 2 bots do not always use the bot/flood flag of the RC table, this is intended because they are not flooding RC and its useful to see some of their modifications in watch lists.

https://meta.wikimedia.org/wiki/Research:Tech_support_satisfaction_poll/Target_lists/French contains 2 bots (with flag) and 1 IP address (with only 1 edit).

Same problem with https://fr.wikipedia.org/wiki/Margarethe_Stonborough
Pageimages choose https://commons.wikimedia.org/wiki/File:Wittgenstein_haus.jpg instead of https://commons.wikimedia.org/wiki/File:Margaret_Stonborough-Wittgenstein_by_Gustav_Klimt,_1905.jpg