Is the mapwarper data backed up anywhere?

When the 'next' link is used to go to the next page in the queue, it makes a request to the pagetriagelist API endpoint with the below parameters. It overrides offset and pageoffset to match the current page's creation date and ID respectively, but all other parameters come from the current filter values.

WIP: https://github.com/wikimedia/WhoWroteThat/pull/50

I think wrapping adjacent same-token spans in new elements is a great idea, and it could be just once done when the tokenized HTML is inserted couldn't it?

Sorry, good point.

Might be of interest for this task: English Wikisource has a highlight-on-hover system that uses a set of separate elements to introduce the color, rather than just background-color on the inline spans. This avoids the gaps between lines. It's defined in https://en.wikisource.org/wiki/MediaWiki:PageNumbers.js

Maybe this can be fixed as part of T226746.

The only other issue I've found was that links in edit summaries in the revision popup weren't opening in new tabs. Note that section links, even if they go to an extant section on the current page, will also open in a new tab. I think this is the only sensible way to handle these, because they don't always go to a valid section (even if we were to link them to the revision in question, there's no guarantee that the section exists; this is how it's done everywhere else edit summaries are shown, I think).

Created: https://phabricator.wikimedia.org/project/view/4275/

I've added a scroll-correction, to prevent section headings being obscured by the WWT info bar. Not sure if that's desired, but it was annoying me. Happy to remove it if it's no good.

Another cool thing is that tag-filtering will soon be available for .ics feeds as well: https://github.com/paviliondev/discourse-events/issues/40#issuecomment-530327726

The filtering can already be done, it's the links that are not correct. For example, these both work as expected, with the tags parameter:

How about links to edit sections (the ones next to section titles)? They still work at the moment.

Would it be worth adding some debug output for the next button? (See patch above.)

There's nothing left to review here I think. Work has started on T231357.

Merged.

Okay, the last patch (I shouldn't jinx it) is merged and this is ready for QA again.

Coming events can now be browsed on a map at https://discuss-space.wmflabs.org/c/events/l/map?tags=wikiclubwest

The default width (which we're using) is 320px.

I've created a cronjob to dump the logs to a publicly-accessible place: https://tools.wmflabs.org/wsexport/logs/ (one file per year; the job runs weekly).

I advice the developers: overflow-wrap: break-word ;)

A couple of things I've been wondering about:

There seems to be an issue with filtering by date with the calendar API. For example, this is supposed to work: https://discuss-space.wmflabs.org/calendar.json?start=2019-08-01&end=2019-08-30 but events outside of August are still returned. I'm not sure it matters for the first draft, because we probably most commonly want to be able to list events by tag rather than date range. It's probably just me misunderstanding the API.

I've created a repo request at https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests

Yes. I think a custom Discourse extension is the way to go.

The link text of 'Close Who Wrote That?' with a tooltip of 'Deactivate Who Wrote That?' might be redundant, and also on my screen the "Close" makes it wrap to two lines and so jumps upwards.

This bug was annoying me while working on T231359, so:

Sorry, I got the last patch wrong; it didn't handle all the badges. Fixed in the above patch.

Which wiki are you using it on, and which template are you trying to insert?

Sorry to hear it's not working smoothly!

@ifried I think this is going to be a bit of a long-winded job; can you advise how much should be done?

Re-migration complete.

Another idea: once T230851: Improve map and calendar filter function is resolved, and we add past meetups to Space, they could all be browsed on the map there.

PR for fixing the import: https://github.com/wsexport/tool/pull/200

It's not a massive thing, and it'll always rankle if we don't fix it up. I'll fix up the import script.

@Aklapper the date input field in your example is a custom OOUI one; the one being implemented in this task is a browser-native HTML5 one, i.e. <input type="date" />. These built-in date pickers are not customisable, and browsers are supposed to display the user's preferred date format — however lots seem to only use m/d/y, or treat any en-* locale as en-us. It's a bit of a mess.

I am sure I tried to do drop it myself before creating this task! I think I didn't try hard enough. Sorry to waste your time. :) Thanks for sorting it out, and thanks both of you for the information about Quarry access. (For the wsexport tool, we'll build custom reports of the data.)

Sorry about this bug, I should have thought of it. The reason for it is that I wanted to be able to re-start the migration process if it failed, and so it's checking for the existence of a row before inserting it. Duplicate rows are not considered. The fix would be to extend the migration script to check for duplication and confirm that the same number of duplicates exist in the target database.

Pointer bit is merged.

I've been trying to get some tests written and to understand the various places that need to be changed in order to implement this. But it's taking time, mainly due to the test system not being very easy to use (partly because we have application logic in the API classes, so we have to do internal API requests in the tests for those, which makes things more opaque). I'm happy to carry on, and of course will get there in the end, but is it worth it? How much time should be spent on this?

The pending animation is also missing for the category select widget in UploadWizard.

Or alternatively, we could add maps to the WMAU wiki events: https://wikimedia.org.au/wiki/Toodyaypedia_Stage_3_celebration

I suggest this is created as https://commons.wikimedia.org/wiki/Data:WikiClubWest.map – that way, we can all add to it easily.

I'm a bit confused here: Parser::getTitle() has for a long time been able to return null; the recent change was just to document the fact. That change hasn't introduced any new behaviour, it didn't change any code at all.

Before being opened, the pop-up will already have access to: username, userId, revisionId, revisionTime, and score (authorship percentage of the page).

I think progress here is waiting on feedback from WMUK.

The pointer bit is ready for review.

The OAuth URL has been switched to Commons (on both staging and prod); is this issue solved?

Ready for review.

PR for this is https://github.com/wikimedia/WhoWroteThat/pull/34

What colour should the 'contact us' link be? It's blue at the moment:

This is a great idea, but unfortunately has some complications. See T188200 for details.

And are we aiming to find the next number in sequence, or just the first available one?

This isn't a question about the Graph extension, but about the GraphViz extension. @Mitchell316 if you're still having problems, could you open a new issue please and file it against GraphViz? Although, that extension isn't working with MW1.33 yet; see T226616 for more (maybe yours is a duplicate of that task?).

Just as another example of an existing template that provides this sort of functionality: the {{wdl}} (or 'wikidata link') template on English Wikisource takes a Wikidata ID and optional link-text, and links to the first-found: Wikisource, Wikipedia, Commons, or Reasonator. See it in action, for example, on Letter from T.H. Barker to his wife Mary, 12 December 1903.

Migration complete. There are a few things I still want to clean up in the prod tool (old symlinks etc.) but everything about the switch to mariadb is done (both for prod and staging).

Should I just go ahead with it? Am happy to.

Sorry, this is still waiting for review (PR184). I should have made sure it was in the right column.

Would it be worth adding a good-for-use-in-presentations (or something) website tag to WikiApiary, similar to being tagged "semantic mediawiki of the month"? e.g. https://wikiapiary.com/wiki/Special:RunQuery/Website_by_Tag?Website_by_Tag[Tag]=semantic%20mediawiki%20wiki%20of%20the%20month&wpRunQuery=true