At this point, I urge every to avoid from closing this task before first announcing their intention to do so. Clearly, there are some misunderstandings. As @Ahecht showed in the comment above, it is not resolved. There is a debate as to whether it should be resolved at all. If you really feel like you want to close this task (with any status, may it be Resolved, Declined or otherwise) your next move is to post a comment in which you say your intentions, and wait for others to opine on it.
Fri, May 29
In fact, I think after the patch to wiki is deployed (next week) some additional step needs to be taken (@Ladsgroup described it as "rebuild the interwiki cache" but I am not sure the effort involved) so it may take a bit longer until we can actually test this.
@matmarex here, size matters!
A blocker issue was identified by CUs on their mailing list. Creating a subtask momentarily.
Thu, May 28
Thanks @Lydia_Pintscher is there a patch or diff link you could provide as to how the message was improved?
@Jdforrester-WMF can I use this opportunity to learn the deployment process better? Do I understand correctly that because the patches associated with were supposed to be deployed in the Mediawiki train - American Version window (19-21 UTC today) in which 1.35.0-wmf.34 would be deployed? Given that we are at 21:03 UTC right now and the change is still not seen on Wikipedias, I checked Special:Version on Wikipedias and they are still on MW 1.35.0-wmf.32, is it safe to assume that the issue is that wmf.34 has blockers (i.e. T253022 is still open)? And finally, if that is correct, would it be fair to say that the next time we can expect the patches for this task to go live would be June 2nd?
@Dvorapa I think you added this back in c1eb7709af0b mainly to make it easier for pywikibot developers (like you and me) to run tests. If so, then the correct way was for you to add a tox.ini in your installations with an exclusion rule. I, for one, want my userscripts to also be checked by the linter :)
In other words, I can add a blank tox.ini file in ./scripts/userscripts and that fixes the issue above. However, I think the default should be the other way around: those users who *don't* want this directory to be considered by pycodestyles should add a tox.ini in their userscripts directory that reads: exclude = *
Workaround exists (merging items). Removing UBN.
This impacts a key functionality and no alternative exists, so marking UBN for now.
Of all the ways in which COVID could have impacted us, this was one the most outlandish.
Thanks @matmarex for publishing a fix and including a unit test (perhaps the largest unit test ever).
Wed, May 27
I feel like we had a separate task for it already, but cannot find it.
In further investigation: it happens only when I use pywikibot to query an item on Wikidata that has a sitelink for be_x_old, such as Q4048908. I am not sure why wikidata shows those sitelinks as be_x_old when the link itself goes to a page like be-tarask.wikipedia.or/wiki/foobar but in any case, I don't think fixing it upstream in Wikidata would be a realistic answer here. So my proposal is: when we run into be_x_old in a Wikidata query, we should gracefully ignore that and not show the warning above.
I have been getting this occasionally too. It does not occur every time (indeed, it happens rarely) so I am guessing there is a condition race going on somewhere in the code.
Tue, May 26
Sat, May 23
@Daimona is this doable? I am assuming yes, because AbuseFilter has access both to the wikitext and the parsed output, so presumably, it should also have access to categories in which the old and new page would be, right?
Fri, May 22
I cannot think of a reason for blockautopromote duration to be different per filter. I think a per-wiki config is the correct choice here.
Thu, May 21
Wed, May 20
Mon, May 18
Thu, May 14
@ST47 this, again, raises the issue that API code should reuse functions that already exist in the special pages, rather than have duplicative functions in parallel.
In a bold move, I modified the acceptance criteria of the task after its creation. I hope I did not hit an agile nerve by doing so :)
@Amire80 can I ask you to opine on this?
Tue, May 12
Magically, it got resolved on its own!
@AntiCompositeNumber now it is rotated 90 degrees to the left (well, technically, 270 degrees to the right) everywhere. So we are consistent. Marking it as resolved.
The bigger issue is that ApiQueryCheckUser.php is replicating code that already exists in SpecialCheckuser.php in an encapsulated way.
Mon, May 11
As I thought more about this, I think the issue is really that the langlinks table is being scanned nearly in its entirety. The much shorter query below ends up using filesort.
Judging by the associated patch, this was related to the "sysopnames" feature of bot logins, which we have since deprecated and removed (see T71283). I am going to mark it as Invalid given how much the code has moved forward since this task was created. Can always be reopened if the issue still matters.
Oops. Shortsighted action on my part. Thank you for all the hard work!
All associated patches have been merged.
Fri, May 8
Thu, May 7
Wed, May 6
The solution is to apply this CSS rule: unicode-bidi: isolate; to the <sup ... class="mw-ref"> tags.