In T263617#6561887, @Tgr wrote:

I don't think the login code has changed since 2015. Maybe it's due to the browser failing to log out of the bot session? Logout problems were mentioned above. (In which case, either the Selenium code does not check for logout success status, or the API gives it incorrectly; either way it's a bug, although one only triggered in unusual circumstances.)

Well, I’m getting that error from the API (action=login). It seems to happen when the session was already logged in (i. e., the first browser test that tries to login succeeds, the second one fails). Is this a new restriction? These browser tests run each day and I haven’t touched the login part in months.

I can log in in the browser now; the AC/DC browser tests fail (Travis build) with a different message:

I just got the same problem, and noticed it because the AC/DC browser tests failed (Travis build). But the tests run each day and only started failing today, so it’s a bit confusing to me that this problem was already reported back in September…

Another parameter from action=edit which the Wikibase APIs don’t have is watchlist (nochange, preferences, unwatch, watch). Something like this parameter would probably be required to resolve the issue of QuickStatements watchlisting created/edited items – I haven’t seen anyone call for a new API parameter yet, but I assume that’s how @matej_suchanek’s comment that “each tool should give users ability to control the watchlist” would be implemented.

I tried to fix the item issue at least, but that doesn’t work out so well when you can’t query WCQS from localhost due to the OAuth requirement.

Although templates don’t really work for items either. Example query:

I think I just realized why it’s not working (after failing to figure it out earlier today): the template query for ?username returns strings, but the query service UI currently only supports item variables in templates. You’d probably get the same error on WDQS if you tried to use strings in templates (but there would be less of a need to use strings in a Wikidata query, I guess).

It’s still the case (as of commit 7fb0b72ee6 according to Special:Version) – you can use this API sandbox link to try it out (adjust the title and click “auto-fill the token” at the bottom).

I notice the special page is called Special:CreateZObject. Is there a precedent for CreateSomething as the name in other extensions? Because in the Wikibase universe we have Special:NewItem, NewProperty, NewLexeme, and NewEntitySchema; for editors already familiar with (some of) those pages, I worry that Special:CreateZObject might be a bit harder to remember.

Upstream pull request was merged, but the next release might take a while…

Fix submitted upstream in https://github.com/pygments/pygments/pull/1559.

The editing UI also gets a bit confused:

CCing @Xxmarijnw who seems to be the developer on GitHub.

(Side note: the IIIF integration in the Wikidata Image Positions tool is mostly by @tomcrane, see D1122: Demo of wd image positions as IIIF annotations.)

(I still don’t understand Differential, but I figured I should leave a link to the Diffusion commit that this ended up in, R2422:b9477eb9139d: Demo of wd image positions as IIIF annotations. For some reason it’s credited to @JohnLewis, who has been globally banned since 2016??)

Note that KrBot only updates statements pointing to redirects after a certain time has passed (a week, I believe). This is by design: otherwise, it would be more difficult to “untangle” bad merges, since after undoing the merge on the item itself, you could not distinguish between statements that should now point back to the original item and statements that always pointed to the other (merge target) item.

I tested the above fix with the following Python script:

Seems to be fully recovered now. 🤷

Web cluster seems to have recovered, analytics still lagging (though with similar “oscillating” behavior).

It looks like the replag is oscillating? If I reload the tool a few times, sometimes the s8 lag on the web cluster vanishes completely, while at other times it’s still at 9 hours. (On the analytics cluster, it seems to be more stable, at some thirteen and a half hours.) Maybe there are multiple servers behind web.db.svc.eqiad.wmflabs, and only some of them have stopped updating? (The Wikidata-Query-Service sometimes exhibits similar behavior.)

In T231334#6449779, @Alicia_Fagerving_WMSE wrote:

Posted an edit request to the template and the Mwe-upwiz-campaigns-wlm-se-fornmin-id strigs.

Note to self (or anyone who's first), update https://commons.wikimedia.org/wiki/File:G%C3%B6teborg_100_-_1.jpg with correct template once it's been edited.

In T191182#6354229, @valerio.bozzolan wrote:

What I'm saying here is that we have a powerful tool and that may be appreciated by the community.

Issue migrated to GitHub (there’s no appropriate tag for this on Phabricator, and I don’t think it makes sense to create one): https://github.com/lucaswerkmeister/RicochetBot/issues/2

(Maybe this should be tagged VisualEditor-MediaWiki-2017WikitextEditor instead? Since I’m still editing wikitext, not really visually.)

VisualEditor worked on MediaWiki:Gadget-HotCat/zh-hans but then broke again on MediaWiki:Gadget-ImageMapEdit/zh-hans.

Ah, @JJMC89 was faster ^^

Looking through the Desktop Improvements board, this might be related T257518: [Bug] Max-Width Layout: Sidebar overlaps footer when its height is longer than the content height. (Also, I hope I used the right tag, but I’m not sure.)

In light of the upcoming GitLab migration, I suppose this task might ultimately become declined or invalid… I can only hope that GitLab will come with self-serve repository creation out of the box.

We ended up merging this without any formal deprecation period or announcement.