Sorry, I'm not quite sure I follow - I'm not hugely familiar with the internals of XTools, so please forgive my ignorance! Are those contributions then counted twice? If I understand correctly, they aren't - they're shown in the non-automated list, but count towards the (semi)automated counter, not the non-automated counter. That seems like strange behaviour - but it's more than possible that I'm completely misunderstanding!

Nuh, hadn't seen that. Duplicate indeed, closing!

In T256758#6270952, @Jdforrester-WMF wrote:

To be clear, we're talking about making a change for all thousand Wikimedia-hosted wikis, plus the tens of thousands of public and private MediaWiki sites hosted by everyone from NASA and the CIA to Fandom and the W3C. I'm not sure the views of enwiki alone are the right venue for this kind of decision, sorry.

In T256758#6270826, @Jdforrester-WMF wrote:

I vaguely remember that Apple fixed it upstream for us (in the contenteditable context). Note that we found and chose to reject the "fix" of adding a format-detection to every page in MediaWiki precisely because this would disable the functionality on all read pages. If consensus is that this should never be used on any page, we can carry on with that trivial patch, but I'm not sure how we'd determine whether that's the right way to go.

In T256758#6268777, @Demian wrote:

Possible solutions might be to hack around it with JS

Date ranges are best written with endash: https://www.thepunctuationguide.com/en-dash.html
Matching dates and replacing - with – or – would be a workaround for that Safari bug and semantically more correct.

This is the way that the web is headed in general from what I can see, whether we like it or not. Edge and IE11+ on Win8+ like to do the same thing, and whilst some are confused by it, it's been there for a while and doesn't seem like there's any much momentum to remove it - especially as the mobile web becomes more dominant.

It's not clear to me that the fix in T55315 was deliberate - rather, it seems to have been a case of "something that happened fixed it", as there's no associated patch (although I could very easily be wrong on that, @Jdforrester-WMF will know more!)

Currently held up by issues with parsing links out of LinkHolders and into actual HTML links in the generated data attributes for the captions - see T236810#6261511.

Hi folks, I see mLinkHolders is now private, and that Parser::replaceLinkHolders has a deprecation tag in its comment. Is there at this stage a recommended alternative for parsing linkHolders in a string that an extension has? If not, is there any other way to go about doing so, without having to re-parse the entire content within which the links are held?

I've also seen this issue when I've tried using AWB with Wine. I'm using Manjaro Linux with wine-5.9 and the latest AWB version.

I've started a discussion on the enwiki Village Pump about (eventually) implementing my extension to categorise pages from their talk pages - which would be a way of resolving this issue - to try and gather consensus at this early stage. Comments and feedback would be appreciated. You can find the discussion here at VPT.

Hi, of course!

I'm making an extension which will hopefully make this work. This is the first time I've done any hacking of MediaWiki itself, though, so I can't promise it'll be perfect!

A change seems to have been made to vector's menu markup, which is what's causing the issue here - some of the bits have been put into a <div> tag.

The password manager filled the form for me, I didn't even touch it, so I don't think it was that - I'm far too lazy to actually copy and paste generated passwords in! 😛

Cheers, that worked! Why this happened in the first place is beyond my ken... but anyway, it's all working now :)

Yep, unfortunately, nothing there - neither in the spam filter, nor in
the main inbox. Even looking directly through the mail logs of my mail
service provider for the relevant domain, I can't see any email received
from anything related to Wikimedia.

Hey Andrew, thanks for the response! Still no joy, sadly - no password reset email seems to be coming through as of yet. I've tried filling in just the username field, just the email field, and both - none produce an email in my inbox.

The edge channel is designed to be used with the latest passing master build, which is currently what's happening. There's a beta channel, which you could connect beta releases to, and the stable channel obviously for stable releases. You can use Travis conditional releases to do this, by simply modifying the example .travis.yml in the Snapcraft documentation - if you like, I can see if I can make a PR that does that when I get some time.

I wouldn't suggest doing that, as that would mean that every time a new commit gets published to master, snaps might start updating with that new commit. Unless the master branch is set up so that every commit is designed to be related to a release, and work towards a release goes on in other branches, it's probably not a good idea.