Notes from this afternoon's discussion about this extension at Wikimedia-Technical-Conference-2019 (not wonderfully cleaned up, so do ask for clarification about anything, and don't take things as certain):

Etherpad dump:

https://etherpad.wikimedia.org/p/small-wikisource-things

https://github.com/wikimedia/WhoWroteThat/pull/90/

PR: https://github.com/wikimedia/WhoWroteThat/pull/88

One solution here might be to create a small PHP web service, external to MediaWiki, that renders the graphs so they don't have to be added to the wiki. It seems like the idea of rendering the graphs into the images/ directory (the patch I linked above) and serving them directly from there is no good for people using the AWS extension (and other file repositories).

Yes, I think so!

So it looks like the translations for the name and description don't carry through to the actual extension page. For example, this is what it looks like for French:

Thanks!

I just updated wsexport prod to the latest master (which includes the DB timeout of 2 seconds).

In addition to T236226#5618192, current status of this is:

All sorted now I think. I've updated the WMAU wiki.

I wonder if uptimerobot is actually responsible for more visits to the wsexport homepage than anyone else — most users probably come via direct export links on Wikisources.

The extension should be called "WhoWroteThat for Wikipedia (BETA)"

No worries.

Ah, good point!

Keep it italic and bold in the welcome popup?

This is (sometimes!) reproducible with by launching the extension in Firefox with

A few things about this...

The two patches waiting for review here are:

• Change string-built HTML to jQuery objects: https://github.com/wikimedia/WhoWroteThat/pull/72
• Move HTML out of i18n messages: https://github.com/wikimedia/WhoWroteThat/pull/76

@MBinder_WMF is there something strange doing on with the above Herald rule?

Is 540220 the patch that's ready for review? It's commit message says WIP. Or do you mean the underlying two patches for that one?

The add-on descriptions on the Chrome/FF pages could have the link as well (both to meta, and directly to f-squared.

I've made a patch for removing HTML from the message files: https://github.com/wikimedia/WhoWroteThat/pull/76

I've done a bit of work on the blocks (added a preview function) and changed the Commons embed format to use Structured Data captions where available. The latter uses the 'language' bloginfo key to get the caption in the right language, so should work on multisite as well (maybe... I'm not really sure how this should work, and it'd also be nice to have a proper language fallback chain rather than just English).

It doesn't add anything to the media chooser in WordPress, but I have a plugin that embeds Commons, Wikipedia, and Wikidata URLs in posts: https://wordpress.org/plugins/embed-wikimedia/

One smallish task that might be interesting to discuss is the existing docs in MediaWiki core. There are a bunch of files there that could probably be removed after having their content moved to mediawiki.org (where it could be translated etc.).

Assets can now be built within the assets Docker image, e.g. docker-compose exec assets npm run assets

It sounds like there should be some coordination with adding region boundaries to OSM. I'm not working on doing that at the moment, so unassigning myself.

This looks to be working now.

For me, it retries up to 4 times. Possibly an off-by-one error? I don't think this is a major problem.

PR for fixing the string-built HTML: https://github.com/wikimedia/WhoWroteThat/pull/72

Sorry, yes, of course! After a weekend of not thinking about all this I totally forgot where I was up to. :)

The beta add-on is now available, and although there are more issues to solve, the basic system is in place for releasing new versions. We've all got access to do it, and there is documentation. I think the main QA here is to make sure it can be installed in Firefox.

I think I'm correct in thinking that there's already a way to add documentation for arbitrary projects to https://doc.wikimedia.org/ (i.e. not just API docs, but also general user or admin documentation), by using JSDoc and the wmf theme for it. I wonder if one day this could become similar to Read the Docs for Wikimedia tools etc. — e.g. if a Gerrit repo contains a .jsdoc.json file then it's documentation is automatically built and made available online.

Are 3rd party hosting issues in scope for this track? For example, I'd be interested in a discussion around the MediaWiki upgrade process (core, but probably mainly extensions), from the point of view of developers and of sysadmins. Mostly, we assume that people will either track a branch of a Git repo (trunk or a release branch) or download manually from ExtensionDistributor — which works great, but we also have version numbers (in Special:Version via extension.json, sometimes Git tags, and extensions' pages on MediaWiki.org) that look like they'd be useful info when upgrading, but actually don't really come into it.

This looks like it was an issue with AEDT (and probably ACST if I was right in T199606#5087299). I've upgraded the timezone data and everything seems to be working correctly. I was able to edit an event to use AEDT times.

I think the issues we were seeing 15 hours ago were maybe because the released version 0.3.0.0 predated the changes to jquery bundling. Because that was just an experiment with releasing, I didn't tag it — sorry! So I've just tagged the latest master with 0.4.0, and released that. Now at least we're in a known position (even if it's actually the same one).

Could this have been related to the bundled jQuery? I can't reproduce it with current master (which is now without jQuery).

I totally agree.

PR62 merged.

Patch to remove the ext- from message and class names: https://github.com/wikimedia/WhoWroteThat/pull/62

The Firefox add-on reviewer has replied:

This PR switches to using config data to construct the WikiWho URL: https://github.com/wikimedia/WhoWroteThat/pull/61

No, I was right before: the promo doesn't go in manifest.json (or in the repo), it's a manual upload to the extension's profile at https://chrome.google.com/webstore/developer/dashboard

I've also invited the translatewiki Github user to have write access to the https://github.com/wikimedia/WhoWroteThat repo.

Oh yes! Oops, I knew that. :) I got confused because it seemed to conflict on Firefox. I'll make a new PR.

I've created its page: https://translatewiki.net/wiki/Translating:WhoWroteThat%3F

Logo PR: https://github.com/wikimedia/WhoWroteThat/pull/60 (already merged, while I was writing this).

The other graphical element we need for the browser stores (required for Chrome; optional for Firefox) is a screenshot. Any preference for which wiki, article, revision, etc. to use?

This might be wrong, but I've made it scroll down when the content is in the bottom part of the screen, as well as when it's completely off-screen. This is because I found a couple of diff views where it was just a few pixels within the viewport, and it didn't scroll, but you also couldn't see the content. We can changte this to some other threshold, or just do it when the content is out of sight.

I think the only remaining thing to do here is to scroll down to the content when activating WWT on a diff page.

Support for the block editor is pretty buggy still, and not yet ready for use. But my idea is still to have separate blocks for each project, because we can have much more control over how it works (e.g. at some point add extra options such as custom captions).

Merged. Ready for QA.

Yes, I've been trying to figure out the miniatlas thing. It seems to boil down to the fact that it creates HTML like this:

This issue is proving annoying to work on, because failing on the first load seems to be much less frequent now than it was a couple of weeks ago.