Thanks for the reminder. I just updated the page now. Let me know if I missed anything.

@Jack_who_built_the_house Yeah, you're right; I misread your post. Thanks for the correction

Wikimedia generally doesn't retain old dumps. I think the threshold is 10 or so dumps. For example, I usually wouldn't look at anything that's not listed on https://dumps.wikimedia.org/ruwiki/ where the oldest is currently 2017-01.

@Nemo_bis Fair enough: I misunderstood your comment. It seems this task is about creating static .html files, such as those in the compressed archives at https://dumps.wikimedia.org/other/static_html_dumps/. I was more focused on a full HTML dump with an XML / SQLite / JSON format. In other words, something comparable to the current xml datadumps at https://dumps.wikimedia.org/backup-index.html, except in an HTML format.

@Nemo_bis Thanks for the clarification. I agree that there really isn't a clear use-case for a directory of HTML files, particularly since the Wikimedia API allows users to get any HTML for any page. Full HTML dumps are much more useful, as there is no real bulk facility to get all this data (i.e.: get all the HTML for every page in English Wikipedia)

The use case for the HTML dumps would be similar to the use case for the current XML dumps: to provide Wikimedia content in a universal and easily accessible format (XML, JSON, SQLite). Wikimedia already provides a regular dumping service for the XML dumps. I think it's safe to say that most users of these XML dump would want HTML dumps as well. Does it matter whether or not the use case is clarified to be development or research or something else? The demand still exists, and has been demonstrated in this thread by three commenters.

I don't have anything valuable to add, but for what it's worth, I think the new look is fine. I think it is more visually appealing and modern. So, from me.

Hi Nemo. Thanks for adding me as a subscriber.

Hi Alex. I think this is due to the recent changes to incorporate UCA / numeric sorting for many wikis.

I'm saying that using static HTML pages seems to be a zero-effort on virtually all platforms

I wasn't able to reproduce the issue. I ran wget for 6 big files between 9 AM and 11 PM EDT. No failures or hiccups. See below.

Nope. Seems to work now. From above:

It would be very helpful if you could give me a date tha you know downloads were working, and the earliest date that you know they were failing for large files.

Yup. I think we're good. Thanks again for looking into it. Let me know if there is anything else (should I be the one to mark it resolved?)

The latest dump looks good. I'm running it through my XOWA parser now, and have not seen any issues. I'll post a quick message to the mailing list now. Thanks again for the follow-up!

Thanks! I pulled down the latest dump and it looks good. The Module count is up to 3163 and individual spot-checking looks good.

Cool. Thanks for the explanation on revision deletion.

Ah! Thanks for the explanations. I don't have much to add, but just some minor points

Well, here are some comments and questions. Hopefully they aren't too obtuse, and might be of some utility.

As per https://lists.wikimedia.org/pipermail/xmldatadumps-l/2015-July/001149.html, I also observed the same behavior in multiple Swedish wiki dumps, as well as the Spanish Wikipedia dump. I excerpt the relevant portion below.

@ArielGlenn Cool. Didn't know that it would just be 3 more lines. If only all changes could scale as nicely as that. :)

@ArielGlenn Thanks. I think 5 rounds would be better, especially in comparison to the original 2 round proposal.

Can the stub dumps be extended from step 29 [1] to either step 30 [2] or even 31 [3]? This would generate usable dumps early in the cycle and help mitigate the staleness factor that DCDuring brings up.

@GWicke I think this is great. I took a look at a few articles in http://dumps.wikimedia.org/htmldumps/dumps/simple.wikipedia.org.articles.ns0.sqlite3.xz and it looked fine. I particularly like how these dumps includes other small details like category, indicator and alt text. Very nice work.