See also
https://phabricator.wikimedia.org/T182351 (the standing request for HTML dumps)
https://phabricator.wikimedia.org/T133547 (for a requested generation process)

See also: https://phabricator.wikimedia.org/T210413 for maintaining an IPFS-friendly dump (which could be generated from an unzipped HTML dump)

Is there a more recent umbrella for this + other conversion issues?

MaxSem, thanks for the patches. DannyH: Indeed ! Warm thanks to every cool head.

Pubpub is experimenting with inline discussion (in addition to sidebar discussions). Discussion threads are all linked to either {page as a whole} or to a paragraph. Editors can choose to embed a [summary view] thread inline

A most important task! thanks for working on this.

Perhaps priority​ can be raised again, too. This should be a big deal :) Any reason not to implement now? Are people waiting on new input from Commons?

In T54141#1568572, @Neil_P._Quinn_WMF wrote:

Today, the visual editor corrupts pages far less often than it did when this bug was filed two years ago, which makes me think that the benefits of these magic words would be small. Are there other reasons for having them?

Thanks Erik.

Current thoughts on this? I still would like to refer to these stats a few times a year. Nemo, did you figure out if this is something that could be run effectively on a mirror? I could get my local library to do this.

Finally, lag varies significantly w/ the same computer setup (mem free, no complex processes running): the initial page reported now has only a 5s delay at the bottom, not a 15s one.

Update from further testing (on a faster cnxn w/ 2ms latency):

• Not noticeable on Safari. Noticeable on Chrome and (less so) on Firefox.
• Per-character lag depends on how far down the page the cursor is. Chrome: Fast at the top, slow at the bottom. Firefox: on one page, fast at the bottom, slow at the top...
• This happens on long pages w/ less interesting markup, but much less noticeable. Test page:

https://en.wikipedia.org/wiki/1918_Birthday_Honours?veaction=edit
At the start of this page, in Chrome, lag is ~1s for a full sentence (waiting for the final letter to be typed after hands up). At the end of the page, lag is ~4s for the same sentence. (In FF, 5s at the start, 0s at the end.)

• Lag is cumulative, adds up with every keystroke. Not with every character entered — Ctrl-V counts as a single keystroke for arbitrary blocks of text. Despite the growing lag, characters appear on the screen in bunches, not one at a time.

Super nett. Can you use Schnittserver for mp3 files as well? cf. https://phabricator.wikimedia.org/T45149

Hello all, catching up. This thread was being downfiltered in my mail client (speaking of email quirks!)

Echoing Risker - what alternative measures do you propose, given that the current community is not used to technical hacks?
Abuse filters are tricky to use. Is PageTriage easy to localize now into Swahili?

Ah, you're right. Wiki-commons.png does seem to be the right size.
And it is better than what is currently in the corner, even though it is not perfect.

Glaisher - does that look good to you? Do you need a different logo generated from the SVG?

Here is an improved png from Tuvalkin:
https://commons.wikimedia.org/wiki/File:Commons-logo-en.png

Is there a separate bug for Blender files? That would still be awesome as well. Talking to Bassam K today, it sounds like writing a simple sanitizer came up on blender forums & shouldn't be hard.

I support implementing this request, for page creation. Possibly as a trial, revisiting it in 6 months for another community chat informed by before/after data. (We need better data and should actively run more experiments like this on individual wikis: currently limited in part by the small range of wikis that want it to happen.)