I wonder if we should kept this task open - release note generator seems to rely on opened tasks.

The non-dialect variants are for built-in language conversion. That is, they are from the same wiki (zhwiki), serving the same contents, but in different writing systems. On the above list, only hak and classical are separated from zhwiki.

Sorry for causing chaos when I CLEANSTART’ed back in 2022. I still have access to the account Emojiwiki; are there anything I should do? (I can claim all mentees with my current account, 1F616EMO.)

If all we have to do is to solve the HTML validity problem, this task can be closed after merging that patch. However, observing a lack of indication between the voted and not-voted list, I wonder if completely separating the two lists is the correct way to go. That is, whether that empty line in the description of T22023 should be taken literally.

In T407042#11388104, @Dreamy_Jazz wrote:

The second image (F70289064) does not appear attached to the task. Can you attach it so others can see it?

Updated the code and it works as expected on REL1_44. (I tested with Citizen skin, but there should be no difference.)

That’s weird. I may try to set up a local testing environment or mess with Patch Demo and inspect the code in a day or two.

May you try again with two voted and two not-voted items? Visual changes are expected (the old code contains glitches that prevent proper display), and your screenshots seems right for only one not-voted, but checks has to be done on more than one not-voted items too.

Any updates on whether this patch can be merged?

In T408632#11338645, @jhathaway wrote:

Spammers set their Return-Path to info@wikimedia.org, which caused their bounce traffic to hit the info queue

@Krinkle, you may be interested in this issue, as you have recently redesigned error pages in 52be01a.

In T405440#11266601, @Dragoniez wrote:

Just to note, the simple condition accountname regex '^~2' can be used to detect temporary account creations, and I think it would be better to file a separate feature request if someone wants a new variable/function that may help with this.

@Lucas_Werkmeister_WMDE Thanks for your help!

If we set user_type to temp, it might be logically awkward, as at the time of the action, the temp actor (the temporary account) does not exist, and the only logical actor is the IP. I'd instead propose an autocreate_type parameter for distinguishing between different types of autocreation, like temp, centralauth, etc.

So now the spacing of the original HTML output is fixed, but the JS simply kills the colon, see https://b40ca3c771.catalyst.wmcloud.org/wiki/Lexeme:L1. I wonder why...

On the earliest patch, some JavaScript was loaded that completely removed the colon, leaving behind just an empty span. My latest patch removed the span tags around the colon separator to fix spacing issues, and I wonder if that fixes the issue, but unfortunately, I do not have time to set up a testing environment locally.

Sorry for misunderstanding the MediaWiki\Page\PageIdentityValue::exists() part. Then I wonder how invalid special pages (i.e., the MediaWiki\SpecialPage\* class does not exist in the first place) are shown red, and we may be able to reuse/hook up to that logic.

It seems like there are no methods for a MediaWiki\SpecialPage\SpecialPage to announce whether what it represents exists or not. It is wrong to let MediaWiki\Page\PageIdentityValue::exists() handle this, as it's said to "always represent proper pages [...] cannot represent special pages" per its documentation. I wonder if we can have one more level of abstraction for both normal pages and special pages (or at least their references), and do the job there.

Got a patch, but I am unable to upload it as I am not a Trusted-Contributors. I will upload it once I am in that group. Uploaded.

Thank you for tagging this task with good first task for Wikimedia newcomers!

IIRC, WhatLinksHere does not care about interwiki usage; instead, Special:GlobalUsage exists to provide said functionality, but for files only. This is not a bug, but a feature that we can discuss.

• We should create a documentation page on MediaWiki asap. For now, it will be an index for all the CA-related documentations on MediaWiki and Meta-wiki.
• After doing the above, we can point the link to the MediaWiki page.
• As an ongoing process, we should rewrite our CA documentation to talk about CA as a generic extension. The rewritten documentations can be moved into MediaWiki-wiki.
• Finally, most documentations will be hosted on MW-wiki. It is totally fine to have some WMF-specific contents staying on Meta. The main documentation on MW-wiki can be rewritten into a full-featured documentation, combining the key points of all other documentations.

Nice, marking this as resolved.

I found a failing post-merge build: https://integration.wikimedia.org/ci/job/mwext-codehealth-master-non-voting/75504/console. Are there anything I should do?

More information: Using <syntaxhighlight> won't cause the problem, but <syntaxhighlight inline> would.

the issue described here seems similar to T397709: Watchlist expiry not set when saving page edit