Just tested that the pipe character | is also not working, as seen by CD refusing to give a GoToComment wikilink at
https://wiki-twi.1f616emo.xyz/index.php?title=Special:FindComment&idorname=c-1F616EMO-20260524022400-How_about_|some_cute_pipes|%3F.

In T426732#11950410, @Tacsipacsi wrote:

That wouldn’t work in edit summaries, which is AFAIK the only place where the external link syntax is not only inconvenient, but impossible […] links to comments is a fairly common need in edit summaries (e.g. a change implemented in an article based on talk page consensus or a user blocked following a noticeboard discussion), so I’d avoid solving the problem with a magic word if possible.

https://github.com/jwbth/convenient-discussions/pull/117

Ah, my bad. I misinterpreted the said task - it targets re-authentication (e.g. before editing sitewide CSS/JS), not initial authentication. @Catrope: Were there any reasons to not show the button on first authentication?

@Reedy I believe this is a duplicate then. Though it's weird to only show that button if one have signed in with a passkey before. What if a user who uses passkeys switched devices?

@matmarex There are two sub-problems in this issue, all regarding to comment IDs with illegal title characters as of now:

Patch submitted for the first approach. You can test it at:

I have two ideas that would not require modifying existing IDs:

The local configuration of CD is now on ext.gadget.convenientDiscussions as a hidden gadget (no consensus so far on whether to accept it as a gadget, that's why it's hidden).

And note that CD did nothing wrong on the creation of GoToComment links, and in most cases that do work. I'd recommend adding a null check and fallback to FindComment only if GoToComment failed.

In T426732#11935805, @Jack_who_built_the_house wrote:

So, is there no way to generate a Special:GoToComment URL so that it jumps to the comment automatically? For the time being, I replaced the Special:GoToComment/ URL with Special:FindComment + idorname search parameter, e.g. https://test.wikipedia.org/w/index.php?title=Special:FindComment&idorname=c-JWBTH-20260519104400-test%3F_{123}.

I believe mw-notalk is not desired as it should still be treated as a talk message and generate DT anchors, while the reply button should be disabled so that blocked users won't use {{unblock}} over the colon indent (which would cause rendering errors). Should I do this instead:

@Jack_who_built_the_house As seen on https://zh.wikipedia.org/wiki/User_talk:~2026-27770-11#c-1F616EMO-20260517113100-2026年5月, only the texts inside the block template is considered part of the comment, while the whole template should be seen as one. Is it possible to solve it?

Patch applied. Thank you for the clarification.

Thank you for your suggestion. I decide to keep the simple checks while not doing the heavy ones in the worker.

@Jack_who_built_the_house It seems like the use of htmlpaser2 in the worker breaks a lot of the checking logic; for example, nodeName, innerText, classList and matches are not a thing in the supplied node element. How should I deal with that?

Fixed via cd-moveMark. The addition of mw-notalk would affect users using the default settings and would require community input.

Hmm, apparently I did not fix the problem here (and I personally don't think it's a big deal); instead, I went on to fix the DYKN issue and other smaller quirks. Will decide if I should unassign myself or decline this ticket tomorrow.

In progress at Wikipedia:互助客栈/技术#ConvenientDiscussion適配腳本

@Dreamy_Jazz Is it safe to close this ticket?

Re-opening for reverting the item change. I will submit two patches, one for config and one for file, tomorrow.

In T421796#11793377, @Sheminghui.WU wrote:

That makes sense, wouldn't a soft redirection work?

If we have to redirect *.wikinews.org to an external site, it would make Wikinews inaccessible on our side, or at least not on the original domains. I believe this is what it means to delete the wikis if we ever want to do the redirection.

Please note that the revert of logo change on zhwikinews (T420165) will also take place on the same day, planned to be done in the UTC morning backport window (or as early as possible on that day UTC+8, if I have remembered the time wrongly). Please tell me if there might be any conflicts.

I don't have time to deploy in April, and this is nor urgent anyway, so I will postpone the deployment to May as with reverting T420165.

Closing this for now, will re-open when it's about the time to revert.

In T422130#11781814, @RhinosF1 wrote:

In T422130#11781793, @1F616EMO wrote:

Should I expect the coming backport window be cancelled or delayed due to this incident?

Very likely yes. A deployment won't take place unless incident responders are comfortable it won't affect or distract from the incident.

Should I expect the coming backport window be cancelled or delayed due to this incident?

I experienced such errors when diffing and saving edits.

The ArbCom shows slight tendency towards the no-PII patch. I will deploy that one in today's afternoon backport window.

In T420165#11763658, @Sheminghui.WU wrote:

In T420165#11763640, @1F616EMO wrote:

@Sheminghui.WU I have made another pure icon version that's less stretched: https://commons.wikimedia.org/wiki/File:%E4%B8%AD%E6%96%87%E7%B6%AD%E5%9F%BA%E6%96%B0%E8%81%9E20%E9%80%B1%E5%B9%B4%E5%BE%BD%E6%A8%99%E7%BA%AFLogo_Globe.svg

Which one do you prefer?

O, What a coincidence! I think either one is fine. If this version looks better, then let's use this one. It's just a difference between an oval and a circle, and the community shouldn't have any objections.

@Sheminghui.WU I have made another pure icon version that's less stretched: https://commons.wikimedia.org/wiki/File:%E4%B8%AD%E6%96%87%E7%B6%AD%E5%9F%BA%E6%96%B0%E8%81%9E20%E9%80%B1%E5%B9%B4%E5%BE%BD%E6%A8%99%E7%BA%AFLogo_Globe.svg

Note that the day of changing back should probably be earlier than the site's closure, which is on 4 May.

Will deploy the patch once the globe is ready. @Sheminghui.WU: Please ask your community on whether they plan to put up the logo for as long as possible (31 days from the patch), or following the original schedule (end in around 16/4).

In T420165#11760602, @Sheminghui.WU wrote:

In T420165#11760584, @1F616EMO wrote:

@Sheminghui.WU The "pure icon logo" should only contain the globe.

Without 2 as well?

Sent email to trademark@.

@Sheminghui.WU The "pure icon logo" should only contain the globe.

I think we need an icon-only version - see also how it's done on zhwiki: T417240. Please also notify your community for any changes made here.

Should there be a Traditional Chinese version of the special logo?

Seems like the page fixed itself. Probably a cache problem then.

Okay, already done.

I am still in doubt about the access to PII. When it comes to personal information, it is always better to grant less and grant whenever needed instead of granting too much and regretting afterwards. We may grant the access to PII to CheckUsers, which is not a locally grantable group, so sysadmins can still grant that role to local users if that's really needed.

I don't know if this has been raised before, and it seems like it haven't - Any changes we make to the editing process may either be circumvented by using the API (mw.Api), or may block bots from doing their chores. Where will be our sweet spot?

@Supergrey1 In your trial runs, you used different edit summaries for different pages. Per sysadmin advice, you should use the same edit summary to avoid explosion of comment table. It's fine to have the links in-page, as the page content is going to vary anyway.

@dragon-fish, the gadget's maintainer, is intentional here.

I will handle the backport once the patch is ready.

@Novem_Linguae Bump for re-review.

Also I wonder if it is allowed for arbcom_zhwiki local bureaucrats (who are, unlike global stewards, not necessary NDA-signed) to grant a group that contains securepoll-view-voter-pii. TBH I doubt the need of this right, as account creation on the wiki is restricted and we are all trusted users.

Are we missing wgSecurePollUseMediaWikiNamespace and wgSecurePollUseLogging here?

Changes deployed to prod.

Oops, I was busy working on local community stuffs and forgot the window.

In T418710#11664343, @Ladsgroup wrote:

Bots are definitely preferred. The import functionality in mediawiki is not designed for large scale imports and when language committee members try to import from incubator (for new wikis) which is at most like 1,000 pages, they run into issues constantly. Once they had to split it to three small xml files it took them a full day to deal with it.

I have suggested to @Supergrey1 that we may prepare all the pages on a self-hosted MediaWiki instance (or otherwise prepare the XML-formatted documents), then hand over the XML dumps to the Foundation and import all the pages from the backend. That may relieve the stress on the HTTP APIs, allows more flexibility on the technical teams, and therefore speeds up the process. Is this possible, and would this be preferred over bots that use the API?

Sorry, after re-checking my schedules, I have to move it back to the afternoon window.

After checking the windows again, I decided to schedule the last patch to the morning window on Tuesday. Btw, I still consider completely wiping away the group the ultimate goal, but that would not be done in the foreseeable future.

I wonder why we can't grant userrights to all stewards on all wikis via the global user group, if we can allow them to self-promote to local stewardship and essentially gain the same right. No hacks would be needed if we handle everything locally.

Summarization of the #wikimedia-operations discussion:

@Urbanecm raised concern on the cross-wiki complications that may arouse if accountcreator is wiped from a single wiki only. We may have to investigate how the loginwiki is dealt with before we can proceed. Ideally, we will schedule the next deployment on the coming Tuesday.