Thank you!

In T421581#11828648, @Escargot_rouge wrote:

I cannot get https://abstract.wikipedia.org/wiki/Q90 to properly load. I always see "Reached max retries. Try again later."

It used to work fine for me before rate limiting was enforced.

Closing this as invalid since the category has been properly populated as expected without needing any additional change.

I understand it’s rate-limited but should I really be hitting them after more than an hour (or after eight(!) hours? If so, perhaps it would be possible to distinguish between requests originating from Wikifunctions?

Blindly blocking ‘high-risk’ actions would not work for small wikis and could even complicate fighting vandalism (as in the case of blocking the use of CheckUser). Even for some of the larger wikis, interface administrators might not always know what they are doing (and could be copying over code from other wikis, having been elected because a more qualified person was not available or interested) and there might not be another IA to review their work, or another IA could be just as clueless. You cannot really stop people intentionally adding code they don’t understand with the proposed mechanism. I do realize that this feature request seems to be aimed at stopping the misuse of compromised accounts but I think 2FA should be satisfactory in that regard unless the WMF actually wants to go through all the trouble of configuring auth very differently for all the Wikimedia wikis (which doesn’t seem warranted).

I am also seeing this with tests that should be failing: Z28056 should be failing (see Z28051) but it’s passing according to the UI. Rerunning the tests does not help.

Boldly closing this since Wikinews is being shut down.

Done.

This is the kind of edit that prompted this: https://hr.wiktionary.org/w/index.php?title=Predložak:crveni_karton&curid=5233&diff=270750&oldid=20359

I can't remember what prompted the creation of this task or when I fixed this (or was this never accurate to begin with?) but this has not been correct in a long time, apparently.

Seems to warrant UBN

Why not pair this with a function that would allow modules like the one linked by @Pppery to work: perhaps something like mw.removeAllCategories() or mw.removeCategory() (usable thanks to mw.categories())?

Sorry, the cause of the error wasn't what I remembered it as being; I noticed this with incorrectly indented Python code.

T415882 and T420294 would make this largely unnecessary, and since Wikitext differs with HTML5 in important ways, this should not be pursued.

With that MR, it is no longer possible to fix multiple lint categories at once, which I feel is better since editors can now see unambiguous edit summaries from the bot. That can be changed once T416792 and T416068 are both resolved.

We would like to display complete translation tables, derived words, etc. on bnwiktionary using data from Wikidata Lexemes, and the lack of this feature is blocking that,

Done with https://gitlab.wikimedia.org/toolforge-repos/delintbot/-/commit/50ba71eaea146499c89e41460e82c5732398d685.

The query needs to be changed so the lint_template = '' check is not added for lint category 11 (multi-colon-escape).

Done with that MR, https://gitlab.wikimedia.org/toolforge-repos/delintbot/-/commit/8d6c47c4eae0ba13cbfc9dfc518a94bd4e72aa8a, https://gitlab.wikimedia.org/toolforge-repos/delintbot/-/commit/511687b3d8f14deb203012c0116ef510cd2efc81 and https://gitlab.wikimedia.org/toolforge-repos/delintbot/-/commit/030f771583973c33d5dcd4938fb4d61cb72b3046.

Oh, sorry, I have moved the code for lint replacements to https://gitlab.wikimedia.org/toolforge-repos/delintbot in the meantime. The code should go in delinter.py (either inside the delint() function or outside). Apologies for the trouble caused.

That MR made disabling the fix for the night-mode-unaware-background-color error possible but it's not enough to close this task.