Not a dev, just a regular 'pedian (en:User:Swpb) who sometimes reports software bugs. My apologies if I make a misstep.
- User Since
- Dec 15 2014, 9:19 PM (442 w, 2 d)
- LDAP User
- MediaWiki User
Tue, May 16
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?]
Feb 2 2023
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.
Sep 16 2022
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.
Feb 22 2022
Jan 24 2022
Dec 15 2021
Jan 30 2020
Nov 11 2018
Feb 2 2017
Jan 31 2017
Jan 26 2017
Please prioritize this bug - it has been a complaint of several editors.
Sep 21 2016
Jul 15 2016
Jul 8 2016
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?
Apr 11 2016
Issue seems to be resolved.
Feb 24 2016
Feb 8 2016
this discussion has raised the usefulness of a degrees-minutes-seconds datatype for angular information.
Nov 10 2015
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?
Oct 20 2015
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.
Jun 15 2015
May 27 2015
May 21 2015
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.
May 19 2015
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.
Mar 13 2015
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.
Mar 4 2015
Dec 22 2014
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.
Dec 19 2014
Automatic messaging of the page creator is also broken.
Dec 18 2014
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.