A light fix so far — non-nested templates are cloaked when searching for section heading markup. Just non-nested as doing full parsing will be somewhat costly. And rarely sections can really be wrapped in templates. I can add logic for those cases but won't until it proves to be a real use case.

I updated fragments with # to use Special:FindComment with idorname parameter, as with T426732: DiscussionTools produces invalid fragments for topic titles with curly brackets (or other non-wgLegalTitleChars?).

(I implemented the proposed behavior in CD, since I'm less influenced by the completeness constraint of the MIT approach compared to the official thing, but if there are practical examples in Wikimedia wikis, I can reconsider.)

@HakanIST

Some follow-up: CD is one trigger (ruwiki)

Still getting them from CD?

I implemented 2 so far. Please tell after a while whether errors persist or not.

DT's markup is complicating things for CD's parser and 5 years ago, when I wrote this part, I likely assumed that that markup is not involved in scripting when Reply Tool is disabled and went ahead to remove it. And probably it wasn't involved until newer features were rolled out including "Visual enhancements". Now that it is involved and causing errors in DT, I'll have to rethink this.

Yeah, that's what I meant.

Thanks for pointing to errors in how CD handles this.

(Please give me a shout if anything will need to be changed in Convenient Discussions as well)

@1F616EMO Yeah, this could work.

@1F616EMO The problem here is that that template has the mw-archivedtalk class. As a result, CD treats it as a container for an archived discussion. Without this class, the parsing will be correct. If you want to disable the reply button in both DT and CD for this element, add the mw-notalk class instead.

Thanks. This appears to have been fixed.

@1F616EMO Sorry, I'm being silly. There is no Element in the worker scope (and if it were, it'd be domhandler's Element), so you get "ReferenceError: Element is not defined" errors. You'll need to check for 'matches' in node instead of node instanceof Element.

Great compromise.

@1F616EMO In the worker context, node is domhandler's Element with some props and methods I added for uniformity. It doesn't have the matches method. innerText and nodeName I've just added as aliases for textContent and tagName.

Excuse me, how does that work? If for whatever reason this resubmission is unaviodable but deterministic, why not resubmit programmatically and only prompt the user action when the challenge is ready?

I definitely need a better doc here, haha.

Captcha works now, including the new one (see T424598: Update ConvenientDiscussions to use mw.libs.confirmEdit.CaptchaWidget instead of mw.libs.confirmEdit.CaptchaInputWidget).

So, as I see from your commit to DT, mw.libs.confirmEdit.CaptchaWidget works quite a bit differently from mw.libs.confirmEdit.CaptchaInputWidget,

1. requiring separate updating and rendering steps (with mw.libs.confirmEdit.CaptchaInputWidget, calling the constructor was enough);
2. requiring the container to be added to the DOM before the captcha is rendered (whereas mw.libs.confirmEdit.CaptchaInputWidget, on the contrary, supplied you with an element to add to the DOM).

@Dreamy_Jazz I need to support old MediaWiki versions. How will I be able to detect whether mw.libs.confirmEdit.CaptchaWidget is functional already? Or testing for 'CaptchaWidget' in mw.libs.confirmEdit is enough?

In T422073#11908310, @Tacsipacsi wrote:

On the other hand, there are noticeboards where the higher-level sections are <h2>s and individual topics are <h3>s, so the <h3>s should be sorted on them.

An open question: What to do you if there are <h1>s on the page? Sort inside them, don't sort? Sort <h1>s themselves?

So where will the control reside, where will the user preference be? I imagine it will be the kind of preference that you might want to change often and depending on context (the page). Do you see it the same way or differently?

And you need 3 clicks to get to the full preferences. The first challenge is to find CodeMirror preferences at all, the second is to find the full preferences.

editors would definitely benefit from having easier access to copying wikitext link syntax.

@matmarex Is it possible to enforce length limit with your solution (which was one of the reasons to move to separate inputs, based on Ppperry's link)?

I oppose the status quo and oppose any solutions where there is no way to have the full pagename in a single input. @matmarex's solution is quite sound and definitely better than the status quo. The warning just tries to explain away a bad status quo, just like the preview is a superstructure over it.

Site note: If you go with the overflow menu, please make the blocked state of users available anywhere in the JS interface so that other tools (like markblocked gadgets or my Convenient Discussions) could pick that up and reuse it. API requests to get the blocked state are very expensive, especially on pages with hundreds of posters, which is why Convenient Discussions currently only marks temporary accounts with their UserInfoCard icon whereas blocked users keep the usual icon unless the markblocked gadget is also used.

I had an ambition to make Convenient-Discussions (repo) type-safe and undertook a large-scale rewrite. But instead of just rewriting in TypeScript, I rewrote it in pure JS + TypeScript-flavored JSDoc in an attempt to somewhat bridge the gap between the modern web dev and what we have in MediaWiki user scripts, and see what's possible these days.

In T423949#11859503, @kostajh wrote:

We would want this to display next to usernames, like it does elsewhere.

(How do you plan to display it next to usernames given that signatures are free-form and the username is not guaranteed to be there, may have arbitrary appearance, etc.?)

I don't know if this is relevant here, but Convenient-Discussions has an "Improve performance" setting where it hides bottom sections on long talk pages to mitigate rerenders. To not interfere with Ctrl+F, it does the simplest thing — unhides them on window's blur event which is emitted on Ctrl+F along with other occasions. The reason for hiding them is irrelevant while the window is not focused anyway.

I earlier wrote a piece in https://www.mediawiki.org/wiki/Gadget_kitchen#Running_code_on_page_load mentioning this misconception:

• Be cautious about what comes in the $content argument of the handler function. You shouldn't assume it's the #mw-content-text element. It can be a small portion of the page, e.g. when it is previewed.

Note: people unfortunately do get confused by this shorter syntax {{plural:$2|{{gender:$4|$3}}}} as well—in this case, the translator moved $3 inside the curly braces, but only for the last parameter :(

In T423525#11836271, @Tacsipacsi wrote:

if you fear people won’t understand how {{PLURAL}} works in their language (in a lot of languages, it works such that anything more than one is categorized “many”, but Slavic languages indeed tend to be more complex)

If Russian needs it, I guess other Slavic languages (e.g. Ukrainian) are also likely to need it.

Sure. I've translated into Ukrainian.

@Tacsipacsi Thanks for your guidance.

Thanks for filing this.

@BraunOBruno Yep, you're spot on (even though that's a MediaWiki quirk). Fixed as well.

Thanks for the report. I fixed it. (The cause was parentheses in namespace names which I was unwise enough to not escape for regex matching.)

(Also reported here.)

Fixed.

@ScrubbedFalcon I can't reproduce this. Can you confirm CD doesn't load there? It loads for me.

Wait a sec. Just running mw.loader.load('ext.CodeMirror.v6.WikiEditor') on any edit page yields the same effect.

Thanks for the report. Fixed.

(See https://commons.wikimedia.org/wiki/User_talk:Jack_who_built_the_house/Convenient_Discussions#Support_zhwiki_DYKN — we need a configuration file in the MediaWiki namespace of zhwiki.)

The Pashto translation is live!

Fixed, thanks.

Wow, have never seen anything like this 😂 This is most likely due to hidden="until-found" feature of collapsible boxes. I implemented its support in my updated version and don't see the bug in it. I will soon release it to the public.

In T275943#11726706, @Samwalton9-WMF wrote:

The h2 headers at https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2026-2027 have a Subscribe button, but subscribing to any one of them seems to subscribe to everything under the h1 = Prompts =. Is that this issue, or another?