Migration done:

• crontab replaced by scheduled jobs
• webservice upgraded to php7.4

I'm not sure there will be exactly one URL, but there should be only one subdomain (formations.wikimedia.fr). I'm awaiting confirmation from @mickeybarber.

I can reproduce with Firefox 105.0.1.

Lowering the priority as the main issue is now dealt with.

In T304200#7836269, @RhinosF1 wrote:

An unbreak now task should be one where everyone that can is dropping everything to fix it. Does this task really meet that criteria?

I assume by your comment that it's getting 0 WMF resources so the answer is probably not.

We're working on this (as volunteers, so resolution will not be immediate).

Hi! I checked the example (and another one with the Infobox Biographie2), both on web and on the iOS app. It seems fixed. Thank you!

This issue also impacts account recovery when you lost your password, as no email is sent when you try to reset your password.

The issue is not limited to the Cyclists Infobox. It impacts every infobox that uses the module Infobox on the French Wikipedia, including the Infobox Biographie2, which is used in nearly 300,000 articles. I left a message on the talk page of the module. I don't know if this should be fixed in Mediawiki or in the module Infobox, but the priority should probably be higher.

The copy of Denelezh's MySQL data files is 365G. The denelezh schema is 324G. I'm working on setting-up a local MySQL server to restore it (and carefully, as this is the only backup at the moment). One idea is to export only a subset of it, so it will be easier to transfer it to Humaniki's server and to restore it.

On Denelezh, I installed MySQL using Oracle's apt repository: https://dev.mysql.com/downloads/repo/apt/

A project grant was opened to achieve this project. Feedback is of course welcome :)

@Maximilianklein I sent you an email about this topic.

Started to work on this with @Seb35. I should be able to deliver a merge request on Saturday or Sunday.

Just a kind reminder that I reported this issue at Wikimania 2017.

Lighting talk at French WikiConvention (the third one): https://meta.wikimedia.org/wiki/WikiConvention_francophone/2019/Programme/pr%C3%A9sentations_%C3%A9clair_communaut%C3%A9_et_outils

Link to Denelezh Git: https://framagit.org/wikimedia-france/denelezh-core

From @Magnus in Wikidata Telegram channel: "I restarted it, someone please close the phab issue".

Thank you all! :)

Thank you all! Using Wikidata Toolkit, I was able to load the dump generated on 2019-07-04 :)

In T227207#5304615, @Jdforrester-WMF wrote:

Deployed everywhere. Next dumps process will run on Monday 2019-07-08.

@TheDatum @ArielGlenn Thank you for the clarification!

Sorry to reopen this bug, but it seems that the new dumps still have the .not extension:
https://dumps.wikimedia.org/wikidatawiki/entities/20190701/

Thanks for the ping! I don't use RDF dumps at the moment, and I'm fine with this change.

I did not had the opportunity to test the fix before it was reverted, but I totally agree with @Nikki.

Thanks for the ping! I don't use this table either, but it seems a huge and well prepared work. Good luck :-)

Thank you for your replies. A few comments / questions:

• While I understand your point, I fair that isolating some data from the main dump is only a temporary solution to its size growth. Sooner or later, it will weight 1 TB (even compressed), and we'll have to deal with this (as producer or as consumer).
• Will the lexemes dumps contain the P namespace, or will the consumer have to additionally download the other complete dump to get the data about properties?
• Will there be one dump per namespace (one for P, one for Q, one for L)?

Thank you for the reply and for having clarified that this issue has no assignee at the moment.

In T102324#5108986, @matej_suchanek wrote:

Maybe this has been done with T102324#3474167 and it can be continued in T147117.

In T204440#5114469, @GoranSMilovanovic wrote:

• (note @Envlh your comment in T204440#5111313 was of crucial importance for me to figure what went wrong with the overlap data; I was accessing the JSON WD data model incorrectly in Spark; thank you);

Glad my help was useful :) Thank you for your quick fix!

In T204440#5110658, @GoranSMilovanovic wrote:

@Envlh I will also compare your and mine processing procedures. You observe this identifier (P380) on 48,202 items, my code finds 48,232 use cases, while I am using an older version of the dump. Of course, that is empirically possible, but I would normally expect an increase in the usage of an identifier with time.

FYI, I also have very different results for P380 (even though it is data from the dump of 2019-04-08). If you follow the link "Usage history" on Property_talk:P380, you'll see that were no recent major change on the usage of this property.

@thiemowmde Are you still working on this issue?

Hello, I'm also very surprised on how things are evolving here. This task was about changing how dumps generation is scheduled (based on week or on month), not their frequency. The first proposals by @JAllemandou were with 4 dumps generations per month. Now, you are talking about reducing the frequency of dumps generations from 4-5 per month to only 2, on an irregular basis (sometimes with 3 weeks between two dumps, sometimes with 1 week).

@ArielGlenn, As @Melderick, I commented here thanks to @Lea_Lacroix_WMDE's addition in the Wikidata weekly summary a few weeks ago :)

Women in Red rely on Wikidata Human Gender Indicators (WHGI) statistics, which are generated once a week using Wikidata dump. If not already done, you should get in touch with these communities to evaluate the impact of the change.

In T40968#3762249, @Charlie_WMDE wrote:

I'm gonna stall this until the new UI happens.

As a user, it's back to normal for me. Thanks !

Everything seems slow after a few edits: page load, auto-completion, save, etc. It looks like a rate limit is raised by edits and is impacting every request. After a short time without editing, it's back to normal.

Sorry, I didn't see this task as I wasn't added to it. The problem was solved for me a few hours/days later in August. Thanks :)

@Dereckson Thanks! It seems that there is no IPv6 (ping6 does not work, even if I have an IPv6 inside the network). I was also informed that the network relies on two DSL Orange routers; I hope that IPs will not change during the event...

I've at last published a blog post: https://www.lehir.net/the-french-connection-at-the-wikimania-2017-hackathon/

I totally agree with Ash_Crow. Wikidata aims to be the sum of all knowledge which can be referenced, which Wikimedians data is not. A U namespace could be a solution, but only and only if only a Wikimedian can edit its own item.