Superseded by T347628.

We don't just need the ability to set the TOC as fully collapsed or fully expanded, we need the ability to cause TOC sections to expand one level at a time, as described here: [https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements/Archive8#Could_we_default_to_(or_at_least_allow)_default_collapsing_of_level_3+_headers_in_TOCs?]

There is also a need for an option (I think it should be the default) to expand sections one level at a time. Currently, when a level 2 header in the TOC is expanded, all the sub-headers are shown, no matter their level. This runs counter to traditional TOC UI design, in which only the next level down is expanded. It is particularly unhelpful on long disambiguation pages, which rely on scanning the TOC level by level to narrow down one's search, but the problem is not limited to dabs. It's exacerbated by the lack of numbering or vertical lines for following the indentation level, for which I believe there are separate tickets - but in most cases, one-level-at-a-time expansion would go a long way to mitigating the visual level-tracking problem.

To clarify, the ExplicitCapture checkbox works in the regex tester, but is not saved to the rule when changes are applied, as can be seen by checking the box, closing the regex tester with changes applied, then re-opening the regex tester - the box is unchecked again. The regex tester is the only place ExplicitCapture can be selected.

It doesn't necessarily have to be added to the basic "Find & Replace" tool, it could just be added to the "Replace Special" tool and the AWB Regex Tester. Anyone using patterns complex enough to want to use the x option probably isn't using the basic F&R tool for those patterns.

Please prioritize this bug - it has been a complaint of several editors.

It's been 15 months since this request started, with no apparent action in over a year. Why is no priority given to community-requested changes?

Issue seems to be resolved.

this discussion has raised the usefulness of a degrees-minutes-seconds datatype for angular information.

I noticed that pages like this one are appearing on NewPagesFeed (as redirects) after being un-redirected, but with the date the page was originally created. Could we simply list these pages by the date they are un-redirected?

This is still a problem on NewPagesFeed, although the message does not appear under the "Info" button on the pages themselves. The opposite condition should ideally be flagged instead - if a disambiguation page does have citations, it's a problem.

To add to this, it would be especially helpful for the "Hide my edits from the watchlist" preference to be applied on mobile.

Please make a user option to include dab pages in "random page" - some editors use "random page" to find pages needing work, including dab pages.

That seems like a less-than-ideal prioritization strategy, no? Does level of community interest in seeing a fix play any role?

Ok, but that didn't really answer my question - how long do these sorts of resolutions typically take? Two months is already far from what I would call "quick". I know there's a big backlog and not enough people to do the work, I'm just wondering how things are kept from falling through the cracks indefinitely. Of course I read EBernhardson's comment; I'm looking for clarification.

Is there any change to the status of this patch? I'm not familiar with the mediawiki development workflow; what is a reasonable time frame for resolution of this kind of ticket? I'm not trying to push--clearly, there's a lot in the backlogs--I'm just curious.

Fair point; I carried that over from the earlier ticket, but it doesn't really apply at this point.

That's a good point, and one I'm glad you made explicit; that's a different consideration from the one I meant. I was talking about pages that had content, were subsequently redirected, and have been reverted to their former content. Such edits should be reviewed, so it's good that the filter catches them, but I think it would be stretching the consensus to treat them as "new" pages.

The issue is not entirely fixed. Proposed deletion still reports "Tag subst:prod is missing required parameter" when the parameter has been provided. I have not confirmed all the other functionalities.

Automatic messaging of the page creator is also broken.

Ok. I'll get the filter created first, then create another task if necessary. Thanks for your help!

On Special:NewPages and Special:NewPagesFeed, along with the strictly newly created pages that are shown there now. In addition, on Special:NewPagesFeed, there should be a new search filter, like the ones already present, to include or exclude these pages. Would that fall under the project MediaWiki-exensions-PageCuration?

Assuming, then, that an edit filter is created locally, where do I address the matter of showing those pages on the special pages? Is that a software matter?

Where, then, is the right place to request this? It seems like a software matter.