@RBrounley_WMF can you comment on @Kelson's questions and comments above? How does this workflow interact w/ existing uses of mwoffliner? Are you building scripts that could extend that toolchain? Thanks!

+1 to Joe's and Kelson's comments. Definitely start w the existing and excellent kiwix pipeline where possible.

Metadata editing: it depends on the source. I could imagine people leaving many comments on a talk page, and someone familiar w/ how to update the metadata doing so periodically (once a week?) It's not something that every visitor needs to be able to easily do.

Tgr: Agreed on the importance of this. There should be a canonical space for annotations, which could be a source or other (imagine the entire output of your favorite {{cite}} or {{footnote}} template) -- just as though every cell has a pre-generated footnote for all such details. There is already a common norm of providing an extra source column (or row, more rarely) -- which would still be useful where there is no need to repeat the same source information for each cell.

@Tchanders it may make sense to start with just editing the existing table, but just as important is the ability to add a new element/row with the same structure. Depending on the use case, edits to a given tab file tend to be bimodal: either (editing existing cells) or (adding a new row, never editing existing cells).

@1Veertje Thank you -- I find your tool also useful for working in the other direction: taking an existing spreadsheet and generating a tab file.

This looks amazing, @Tchanders . Thank you :) Just waiting on review?

Another use case for a generalized 'whatLinksHere' -- seeing where a tabular data file is used?

I like this -- with an option for a "time-series" that would take one row as a 'primary key' and pull out only the most recent row for each unique key.

Are these questions answered elsewhere? Seems to not quite fit the phab-task format

This would be great. Wiki policies shouldn't limit tool capabilities esp w.r.t. other tools.

In T220212#5171872, @Joe wrote:

Participants selection should be based on need and not on a fixed quota of participants.

It's extremely sad we can't have a all-technical sit-down of any form with all the interested engineers in the movement.

We also need to bridge the gap between frontend and backend people.

We really need more than 50 participants this year, I would imagine 100 would be better. I would assume we'd select people based on core competencies and relevance to the topics to be discussed, not based on blind-copy essay writing. I would assume teams will choose the people who would represent them best to apply to the conference.

Still an issue in Electron / w the latest PediaPress functionality?

How's this coming?

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.)