User:SoledadKabocha/dubious feature requests

These are things I'd like to discuss at VPT/VPR/VPI but might not be worth the trouble.

Automatically enforce WP:HATEXTRA

probably by having hatnote templates emit a maintenance category when wikilink markup is used in parameters where it is undesired

Don't send daily or weekly notification emails if notification was read on web within X hours of event

~~where X is probably 2 at most. Dubious due only to the programming work required~~

~~TODO: Is this already implemented? If so, what is X? (probably 1 at most)~~

~~This feature request should really be, "Provide a link on the (web) notification that the user can click to prevent an email from being sent"~~

Obsolete: "Don't include read notifications in summary emails" setting now exists

Exempt user CSS/JS subpages from patrol system

and their talk pages. Possibly also Twinkle-created pages like CSD logs, but that might not be worth the trouble to implement.

Arguments for: Less work for patrollers? Fewer confused newbies trying to click the patrol links on their own pages?

Arguments against: Patrollers are theoretically supposed to watch for malicious code in such pages; anyone who has the patroller right and/or knows about user scripting should be non-noob enough to know they can't patrol their own pages

So I guess this request should really be "When a user is viewing an unpatrolled page in his/her own userspace, show the unpatrolled status via something other than a clickable link"...?

Automatically place `{{r from move}}` on redirects created by moves

~~The MediaWiki software uses a bare {{r from move}}. It should be changed to the {{redirect category shell}} equivalent (has a proposal already been rejected?)~~

What should be done with redirects to an article without mention

Have a bot post warning messages on the talk pages of the redirect targets

Regarding the 30-day login session limit

~~The login page should link to the part of the WMF privacy policy that justifies this limitation~~
~~Develop a user script that warns the user when the login session is about to expire (bonus points for making it general enough to work on any site with a reasonably recent version of MediaWiki)~~

implementation needs to be rechecked; the limit becomes 365 days for recognized devices?

Uncategorized redirects to anchors
Redirects with non-redirect talk pages (not the same thing as "Talk subpages with redirect parent," because this is not exclusive to subpages)
Redirects that transclude nonexistent templates ("Redirects containing red links" already covers this, but it should probably be split somehow. Perhaps more specifically, redirects transcluding deleted templates? Or perhaps redirects passing redlinked templates into {{redirect category shell}}?)
Blocked users listed as WikiProject participants
User scripts/stylesheets of indefinitely-blocked users (limit to non-skin-related? or limit further to scripts in use by other users?)
Possible redirects to/from regular English plurals that are not yet categorized
Possible redirects from unnecessary parenthetical disambiguation that are not yet categorized
Possible redirects from malformed (misformatted) disambiguation that are not yet categorized (this should be limited to issues that are easy to check robotically, such as missing space before opening parenthesis or unbalanced parentheses)
Redirects with different protection status from their targets
Redirects categorized directly (i.e., with categories not applied by templates)
Redirects with interwiki links (should be "Redirects associated with Wikidata items"?)
Most-linked unprintworthy redirects other than those misspellings which are covered by an existing report
More generally, redirects with any non-template content outside the #REDIRECT markup, regardless of length - this could be helpful to find vandalism/spam, e.g. Url and Electric discharge machining
Links to redirects to anchors where the link specifies an anchor of its own; that is, links of the form [[Foo#baz]] where Foo is a redirect to Bar#baz or Bar#somethingelse
Pages linking to self-redirects
Broken links to talk section anchors from {{dubious}} - preferably separate reports for the default "Dubious" name and custom names
Red links to talk pages from article maintenance templates (i.e., the template says "see the talk page," but no one has created the talk page yet)
Redirects where {{redirect category shell}} contains non-Rcat templates
CSD G14 candidates (separate reports for the two sub-criteria?)

General/unsorted

In reference to [1] :

The "mention" type of notification is rather erratic/useless for following existing discussions because it is inherently dependent on whether one user decides to wikilink the other's username
User:Js/ajaxPreview might be the only way to preview redirect templates successfully ... the official MediaWiki AJAX preview didn't seem to do so when I tried it a few months back (need to reverify!)

(Did I already mention this somewhere?) We ought to conduct a systematic review of redirect templates in terms of printworthiness categorization and namespace restrictions. But first, it might be helpful to categorize the templates by their (existing) namespace restrictions.

Usernames in WP:Notifications items should link to user contributions if the user page does not exist (or always, if a check for the existence of the userpage is impractical to implement). (WT:Notifications could be a suitable venue for this request, but I'm not sure.)

mathJax

User:Nageh/mathJax: When a JS dependency fails to load, the "File failed to load: ..." message is quickly replaced by "Processing math: 100%" which then hangs on screen indefinitely. I know that the official mathJax probably behaves similarly (haven't verified), but is it worth changing this?

~~Speaking of MathJax, could the official MediaWiki software provide a "MathML with MathJax fallback" option?~~

Redirect category/template ideas

R from renamed user
R to bot operator (that is, redirect from talk page of the bot account to a relevant page in the operator's user(talk) space)

Twinkle

...should refuse to operate, with an informative error message telling the user to WP:BYPASS, when a page has been left open long enough to invalidate the CSRF token.