adding Dennis for that tool

wlm-stats and wlm-maps are updated now. Regards!

I got the same error using Flickr2Commons, though apparently it is authenticated correctly.

Yes, it is ok now. Thanks.

My map doesn't show any monuments https://tools.wmflabs.org/wlm-maps/ I guess this bug is related.

Editing is very slow, edits aren't saved https://grafana.wikimedia.org/dashboard/db/wikidata-edits?refresh=1m&orgId=1&from=1502637379598&to=1502647684878

Editing Wikidata is pretty slow for me now.

I have fixed the tiles links. It should be ok now.

@Ricordisamoa Thanks. Then I think I don't have to use it in my code anymore.

I have changed this in my code:

In T171263#3484037, @daniel wrote:

@Emijrp the point is that at least some people should have an eye on bot edits some time, otherwise nobody will notice when a bot goes wrong. Bot edits on wikidata should be marked as such on client wikis too (let me know if they are not), so people can filter them out. But skipping propagation alltogether would mean that wikidata bots effectively run unsupervised. That would not be good.

Now, if we need an emergency way to cut down the backlog, I agree that it's better to drop bot edits than to drop manual edits.

In T171263#3460518, @daniel wrote:

To avoid confusion: dispatch lag is the time that changes sit around before they go into the client wikis' job queue. The time they spent in the job queue is not the issue here! Changes "sit around" because finding the changes relevant for a given wiki, and pushing them to that wiki's job queue, takes time. We are dispatching changes to over 800 wikis.

In any case: one thing we could do is skip old changes. Changes older than a day are unlikely to be seen on the client wiki's recentchanges feed anyway. Or perhaps, instead of skipping, they could go to a slow propagation queue, so new changes are pushed out quickly, but "stale" changes still get propagated eventually.

I think that the current dispatchlag growing is due to ResearchBot academic paper item creation. I say that because some days ago my bot was editing at 60 ed/min and ResearchBot was doing a similar rate. I stopped my bot for a few hours and the dispatchlag kept growing. So I concluded that it wasn't my fault. It is strange because ResearchBot creations aren't linked to any Wikipedia, but I am inclined to think that it is the current cause for lag raising.

In T171263#3480923, @Lucas_Werkmeister_WMDE wrote:

Stalest wiki now more than one day behind again. Median is fine, but as the stalest wiki is enwiki, that’s not a great consolation.

In T171263#3459885, @Ladsgroup wrote:

1 million queued jobs is absolutely normal. Problem lies somewhere else.

I don't know how many server resources are dedicated to Wikidata (CPU, memory, etc), but could be possible to increase them? Setting another job server?

i leave this link here with a discussion about how a full version of this feature could be undesired https://www.wikidata.org/w/index.php?title=User_talk:Emijrp&oldid=522355148#Aliases_on_given_name

@Esc3300 About 3 days (72 hours), at a roughly edit rate of 600 epm, I did 2.5 million edits, more or less. Just a note, my bot edits add descriptions in dozens of languages.[1] I don't know if that makes jobs difficult.

In T159618#3074646, @Lydia_Pintscher wrote:

Anything else we need to do here?

Done. I added a put_throttle = 3 seconds. Anyway I think I will wait for the job queue to go down.

I did something like this back in 2007. My bot copied thumb descriptions from different Wikipedias into Commons.[1] That way you have a lot of work done, though having a review method is better.

All my bots follow the maxlag policy, as defined by default in Pywikibot user-config.py.

In T149049#2778661, @kaldari wrote:

@Neil_P._Quinn_WMF: Hmm, something doesn't add up here. According to @Emijrp's charts, enwiki editors create about 800-900 new articles a day, and they delete about 600-700 articles per day. Thus it seems the survival rate (currently) should be about 25%. Your chart above, however, shows a survival rate of about 75%. Somebody's statistics are way off.

Hello! I just deleted all the files. Regards.

Can you please update the database only handly?

There is something wrong in monuments_all again. SQL queries are sloooow and don't finish. In _tmp are OK.

There is a "monuments_all_tmp" table, btw.

@JeanFred The monuments_all table doesn't exist right now!

@JeanFred Can you change the Russian config from Wikipedia to Wikivoyage? https://phabricator.wikimedia.org/T110665

In T110420#1595026, @Emijrp wrote:

I don't see the Spain monuments in the map yet. https://tools.wmflabs.org/wlm-maps/#9/40.2387/-3.7189

I don't see the Spain monuments in the map yet. https://tools.wmflabs.org/wlm-maps/#9/40.2387/-3.7189

@Emijrp, do note that when/even if I manage to get these countries working as part of the full run, the issues listed in P1940 will persist (I’m thinking of the 277 missing primkeys)

Try changing line 482 in update_database.py from:

Where is the code for erfgoed bot? I want to check it.

So, the namespace error is fixed? What is the new error now? Which countries are affected?

I think that the bot tried to update this page but it failed https://commons.wikimedia.org/w/index.php?title=Commons:Monuments_database/Unknown_fields/monuments_es_%28es%29&action=history

Yay! Is the bot still running? I see some points in Spain map, but there are still many gaps. For example, this list is not parsed yet https://es.wikipedia.org/wiki/Anexo:Bienes_de_inter%C3%A9s_cultural_de_la_Comunidad_de_Madrid

Not solved yet?

It fails with 102, 104... special namespaces. It seems that you have to add them into the family file in families directory?

Mainland Spain is still empty https://tools.wmflabs.org/wlm-maps/#7/37.182/-4.982

I think that Spanish Wikipedia hasn't been updated. You can see data from pt, gl and ca, but not es https://tools.wmflabs.org/wlm-maps/#7/41.034/-4.872