Looks like it was discussed about a year ago at
Template_talk:Time_ago. I don't think anyone has volunteered to add this feature, nor is it the result of anyone's previous work causing it, more like a design question than a bug, best way to say "now". Could also try
WP:TEMPREQ for help. --
GreenC15:49, 19 July 2024 (UTC)reply
"Today" isn't the same day everywhere in the world. "0 days ago" indicates less than 24 hours ago, which could include "yesterday" in some time zones.
WhatamIdoing (
talk)
05:30, 20 July 2024 (UTC)reply
I've no objections to that, and I suspect that if you posted the code in an edit request on the template's talk page, then it would be accepted.
WhatamIdoing (
talk)
05:17, 27 July 2024 (UTC)reply
Even current template allows doing that via undocumented trick (although that produces a warning) - just add /section to the movie id. Example:
test at
IMDb.
What PrimeHunter said. The template clearly states it's usage is for the EL section and it as they've pointed out, IMDb is not a RS to usage as a reference. Either find a RS to source the content, added a {{Citation needed}} tag, or remove the content.
Gonnym (
talk)
08:08, 29 July 2024 (UTC)reply
Does the community still want moved pages to be unreviewed
When discussion has
ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Back in 2017, the community decided in
this RfC that moved pages should be unpatrolled.
The feature was stuck in Phabricator purgatory and was never actually implemented.
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented.
Extraordinary Writ (
talk)
08:00, 21 July 2024 (UTC)reply
I have seen cases (e.g. recently at AT
CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like
CBS This Morning, or from requested moves like
(709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks.
Aszx5000 (
talk)
09:36, 21 July 2024 (UTC)reply
@
Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in
T370593. The default behaviour is to not unpatrol page that are moved.
Sohom (
talk)
10:00, 21 July 2024 (UTC)reply
I think the RfC should be respected. Yes,
WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change.
Nickps (
talk)
12:32, 21 July 2024 (UTC)reply
Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways.
Hey man im josh (
talk)
14:49, 21 July 2024 (UTC)reply
FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with
916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload.
RoySmith(talk)15:33, 21 July 2024 (UTC)reply
Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better:
7068 page moves starting in mainspace, 13519 mainspace page curations. —
Cryptic16:55, 21 July 2024 (UTC)reply
Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and
redirect autopatrolled groups, including administrators).
DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —
TechnoSquirrel69 (
sigh)
17:50, 21 July 2024 (UTC)reply
Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged
WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. –
Joe (
talk)
21:35, 21 July 2024 (UTC)reply
Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @
Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place.
S0091 (
talk)
19:39, 22 July 2024 (UTC)reply
not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –
Novem Linguae (
talk)
23:58, 28 July 2024 (UTC)reply
??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example
Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (
talk)
20:28, 22 July 2024 (UTC)reply
Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. CFA💬22:15, 28 July 2024 (UTC)reply
Adding a slight speed bump to slow down revert wars.
There's a editor's notice right now on a really contentious page: "You must follow the bold-revert-discuss cycle if your change is reverted." My reaction was, "Good idea. Reverting a revert never seems to end well. Maybe that rule should apply to all pages."
Yes, I know, that's not going to happen. But we can nudge people in that direction. How about a feature detects this and makes the user confirm that's what they want to. "We see you want to revert a revert. This is often viewed with antagonism. Please consider using the
BOLD, revert, discuss cycle instead."
There is an opt-in script (preference?) (although I can't remember where to find it) that asks you for confirmation before actioning a rollback. The intent of this is to avoid accidental rollbacks, IIRC there was a discussion that rejected making it opt-out because it hinders vandal fighting and similar activities, although this was quite a long time ago and consensus may have changed with the rise of tools like huggle, etc
Thryduulf (
talk)
15:48, 23 July 2024 (UTC)reply
That is legitimately a good idea in my opinion, although it should be noted that
WP:BRD is only an essay and technically optional.
Wikipedia:Edit warring, which is policy, could be a better basis for a reminder if a revert-of-revert is detected, and I don't object to the text itself mentioning BRD if it is clear that it's optional (but encouraged).The functionality itself might need some MediaWiki software tweaking to be implemented, but I'm not a specialist.
Chaotic Enby (
talk ·
contribs)
15:51, 23 July 2024 (UTC)reply
You must follow the bold-revert-discuss cycle if your change is reverted. Is that a thing? Or it's just an ordinary editor writing that?
Selfstudier (
talk)
16:52, 23 July 2024 (UTC)reply
I'm concerned about how this would impact anti-vandalism, especially when you can't seem to get ahold of an admin to block or protect. It won't matter to a vandal if it takes an extra click and five or ten seconds to re-deface a page; it will matter if takes longer to revert them. Slowing down fights over content disputes is all well and good, but not when the
WP:WRONGVERSION is one full of profanity. —
Cryptic17:49, 23 July 2024 (UTC)reply
Although I am an admin, I do not particularly focus on antivandalism, and in my experience, before I turned on requiring a confirmation prompt for a rollback, I was accidentally rolling back edits far more often than I used rollback for vandalism. In fact, when I do have to revert a lot of edits I still prefer to verify that each edit is indeed vandalism. I think that the 'requiring an affirmative prompt before rollback' setting should be optout rather than optin.
Donald Albury18:08, 23 July 2024 (UTC)reply
This seems like a good idea, and I'm not concerned about its impact on anti-vandalism. It isn't the end of the world if vandalism is reverted a few seconds later; and it will help cut down on accidental or over-zealous reverts.
Cremastra (
talk)
00:20, 25 July 2024 (UTC)reply
What does vandalism have to do with this idea? I'm not talking about making it harder to revert other people's edits. I'm talking about making it harder to do a double revert.
Isaac Rabinovitch (
talk)
11:32, 25 July 2024 (UTC)reply
1. Vandal replaces the lead image of a highly-viewed but not-currently-protected article with a freshly-uploaded dickpic at some time after most US admins have gone to bed and before most European admins have woken up. 2. Cluebot immediately reverts. 3. Appalled bystander immediately tags the image on Commons for speedy deletion and asks for the vandal to be blocked at
WP:AIV. 4. Vandal makes the same edit, which is a revert of Cluebot; it's slow because of the new revert-of-a-revert feature, but he doesn't mind. 5. Entire group of appalled bystanders try to revert the vandal; it's slow because because of the new revert-of-a-revert feature, and Cluebot doesn't intervene because it doesn't re-revert the same page. 6. Entire group expands their futile pleading for help to
WP:RFPP and
WP:ANI. 7-20ish: repeat steps 4 and 5 and occasionally 6 until an admin intervenes.The problem here is that it's making step 5 slower, no matter how large the entire group of appalled bystanders is or how quickly they react. —
Cryptic14:12, 25 July 2024 (UTC)reply
This exact scenario? Never, because we don't have this exploitable misfeature you're proposing that makes reverting vandalism arbitrarily slower. Non-exactly-repeated vandalism that persists for dozens of reverts before an admin puts a stop to it? All the time. Try searching the ANI archives for, say, AIV backlogged. —
Cryptic14:33, 25 July 2024 (UTC)reply
@
Cryptic I'm a bit confused, because I don't see a proposal to implement a cooldown timer. Steps 5 and 6 would be "5. Entire group of appalled bystanders try to revert the vandal, get a message asking them to confirm, and hit 'OK'. 6. Entire group moves on with their lives." --
Ahecht (
TALK PAGE)15:32, 25 July 2024 (UTC)reply
This can't be done in a client-side javascript "Are you sure?" popup like the existing, optional ones for rollback links. There needs to be a roundtrip to the server to find that the attempted edit is a revert, and that at least one of the edits it's reverting was itself a revert, and then kick it back to the user. Besides, the last sentence of the proposal - but at least we've slowed down the madness a tad - makes the goal explicit; if it's not appreciably slowing down a vandalism rerevert, it's not accomplishing its stated purpose anyway. —
Cryptic15:41, 25 July 2024 (UTC)reply
Although I agree with the spirit behind the idea, I can't help but think that the existing policies rules and guides are sufficient. If an editor is intent on BRRD, for example, there is not much to be done about it except to take it up in talk, if an editor were continuously making use of BRRD to try and force through their view, then that's a behavioral problem and should be dealt with as such. One could ask an admin to impose
WP:CRP if the issues were causing disruption. And so on.
Selfstudier (
talk)
16:12, 25 July 2024 (UTC)reply
Bot to restore long-term protections after shorter-term higher protections expire
A recurring issue with
page protection is that long-term protections are sometimes overwritten by shorter-term protections at a higher protection level. When the shorter-term protection expires, administrators need to manually restore the previous lower protection level. For example,
Beyoncé is indefinitely semi-protected due to vandalism and was recently fully protected due to edit warring. When the full protection expired, semi-protection needed to be restored manually by an administrator (more examples: 162794559, 162856607, 162974964, 163272356, 163337925). In addition to this happening after full protection due to edit warring, it also happens with ECP being applied to previously semi-protected articles.
Right now, administrators need to remember on their own, set a reminder, or rely on someone submitting a reprotection request on
WP:RFPP. Unfortunately, disruption can be the result when the restoration of protection is delayed too long. Also, concerns about timely restoration can influence administrators to choose an approach other than protection when protection would have been their first choice in some situations.
The bot will not take any action if the duration of the higher protection level extends beyond the prior protection's expiration date, or if the protection level is the same or lower.
I'm definitely not the first person to have the idea. After I starting looking into this, I found more than a few previous discussions (which also helped me iron out some details), such as
this proposal for a bot in 2017. Starting with this task, I'm hoping to alleviate some of the drudgery I've experienced as an administrator helping out on
WP:RFPP.
Daniel Quinlan (
talk)
08:56, 24 July 2024 (UTC)reply
I agree this would be useful functionality. I'n not sure implementing it as a bot is the right approach (but I won't oppose the idea either).
T194697 covers the same idea for blocks; all the reasons given there apply equally well to page protections.
RoySmith(talk)12:05, 24 July 2024 (UTC)reply
I feel like this has been raised before and went nowhere, though I might be misremembering. In any case, yes, this is functionality that should exist, whether as a bot or part of the protection interface.
Vanamonde93 (
talk)
17:59, 24 July 2024 (UTC)reply
This would be useful functionality. May I suggest that the bot also drop a templated message about its actions at the user talkpage of the (non-bot) admin who most recently protected the page, so that they can undo/adjust the bot's page-protection if needed?
Abecedare (
talk)
02:29, 25 July 2024 (UTC)reply
I agree. There should be some kind of automatic mechanism for reinstating the previous protection (like for example, an article already semi-protected gets bumped up to extended confirmed, and then when the EC protection expires, there should be some automatic mechanism to reinstate the semi-protection)
West Virginia WXeditor (
talk)
20:02, 30 July 2024 (UTC)reply
Blame and Wikiblame have the same goal, but they're separate tools/separate software code. Someone might want to have access to both tools, but they should be side by side in the list.
On the other hand, Wikiblame should not be in the list with Wikidata, Wikinews, Wikibooks, and other sister projects. But Commons and Wiktionary should be in the list of sister projects, and I don't see them.
WhatamIdoing (
talk)
05:24, 27 July 2024 (UTC)reply
@
WhatamIdoing. Hopefully I haven't given off the impression that I am offering an exhaustive overview. Commons and Wiktionary are just as welcome. My main focus was on getting some relatively hidden tools to be accessible via 'Analysis'.
Infogiraffic (
talk)
08:32, 29 July 2024 (UTC)reply
As a proof of concept, I think it's fine. I wouldn't personally find it very useful, because I'd rather type than look for anything in a menu. But others, especially those less familiar with MediaWiki software, likely have the opposite preference.
WhatamIdoing (
talk)
16:29, 29 July 2024 (UTC)reply
Should it be permitted to list short names/aliases in the documentation pages for maintenance templates?
Many templates have shortcuts; e.g. {{citation needed}} can be invoked by typing {{cn}}. This produces the same result, and saves a great amount of time for editors by eliminating pointless busywork (especially those with
arthritis,
RSI, bad keyboards, mobile devices, or other impairments).
It improves the project for people to tag uncited statements, even if they do so without a perfect understanding of template syntax. The same is true of all inline maintenance templates (e.g. {{dubious}}, {{failed verification}}, et cetera). Indeed, while tagging articles is necessary and vital, many people who do it
don't know how templates work at all, and just type <sup>[citation needed]</sup> -- I have an AWB task to fix this. This is fine. We want people to help out even if they are not programmers. This is why templates have documentation pages, which explain how the templates work and what to type into the edit box. Typing {{dub}} instead of {{dubious}} saves time for volunteer editors (which we already have a shortage of), and it is good and proper to tell them they can do this.
These shortcuts are made possible by "template redirects": a non-intuitive MediaWiki hack where "
transcluding" a redirect is equivalent to "transcluding" its target page.
Template:Cn is a redirect to
Template:Citation needed, the same way
United States of America is a redirect to
United States. This behavior is an idiosyncratic quirk of the MediaWiki software, and there is no reason to think it would be obvious to someone unfamiliar with how the backend works.
The only way to get a list of these redirects is a very complicated, obscure set of actions that don't clearly indicate their outcome. Users must:
Know about this unorthodox feature of MediaWiki in the first place (that a "redirect" is a shortcut when it's a template)
Pick one of nineteen options in a "Tools" dropdown, which is not in any way labeled to indicate it is a list of redirects, and has no clear relation to it (
Special:WhatLinksHere)
There's no option to list redirects, so you have to create a list of redirects by exclusion, by clicking on two separate selection boxes for unrelated things, not indicated as being related to redirects ("Hide transclusions" and "Hide wikilinks")
Select these and reload the page a second time
Since this is an extremely time-consuming and inconvenient task involving counter-intuitive workarounds, most editors are not going to be aware that it's possible, and they are definitely not going to be doing it every time they look at a template's documentation.
Nevertheless, because it saves a significant amount of time to be able to use these shortcuts, many commonly-used templates explicitly list them in their documentation. For example, since at least 2013 (see
Special:Permalink/562463167), the documentation for {{citation needed}} has featured a section listing redirects/shortcuts. However, after I spent a couple hours adding lists of shortcuts to other maintenance templates (like {{dubious}}, I was reverted, and a request made for formal consensus that template documentation pages are allowed to list shortcuts.
I propose that the documentation pages for inline maintenance templates be allowed to mention their shortcuts, either by listing them (e.g. with a collapsible {{list redirects}}) or by mentioning them in a hatnote.
Support Shortcuts like that are huge time-savers for me. Becoming aware of others that aren't currently mentioned on their doc pages will be useful. Using citation-needed as an example, that tiny box listing its shortcuts demonstrates that providing that helpful information doesn't unnecessarily expand the doc page.
Schazjmd(talk)19:21, 26 July 2024 (UTC)reply
@
JPxG, it appears that you're talking about a list of
WP:REDIRECTS, and that this doesn't have anything to do with
WP:SHORTCUTS. Please consider a quick copyedit to replace the word shortcut with redirect in your long comment above, so that editors are less likely to vote against you because they think you're talking about things like WP:V and WP:NPOV instead of typing {{fact}} when you want {{citation needed}}.
WhatamIdoing (
talk)
05:29, 27 July 2024 (UTC)reply
Oppose See
permalink for an example. The fact that DUB redirected to {{Dubious}} should not feature in documentation because it adds bloat and confusion. What is an editor to make of that list of 19 alternatives? A doc page is not the place for a database of what links where. Instead, a doc page needs to tell readers what they have to do and what is the recommended procedure.
Johnuniq (
talk)
00:10, 27 July 2024 (UTC)reply
The problem is that
WP:RFD accepts just about any redirect that someone might want to use on the principle that redirects are cheap. That means redirects that are not really useful are kept and they accumulate. I am not going to lose any sleep if someone wants to add {{Dub}} to an article instead of {{Dubious}} but there should be a reason to promote Dub rather than the fact that it exists. It might be helpful if someone wants to set up a page with a master list of all template redirects that are used in more than, say, ten articles. Template documentation could link to that master list. But there is no benefit from the churning that would occur when one editor adds {{Dub}} to save typing four characters and another changes it to {{Dubious}} to make the wikitext comprehensible.
Johnuniq (
talk)
02:31, 27 July 2024 (UTC)reply
As a general rule, I think that template doc pages should include the more popular and less obvious redirects. If there are more than about three, I don't necessarily see value in listing every single one of them, especially when the variations are just adding or removing a space or a hyphen. If an editor regularly finds it onerous to use
Special:WhatLinksHere on the template page, then I point out that a whole URL (e.g.,
/info/en/?search=Special:WhatLinksHere?target=Template%3ADubious&namespace=&hidetrans=1&hidelinks=1 ) could be added to the doc page in some unobtrusive spot, perhaps saying something like "
Full list of redirects". Also, pinging
User:Gonnym, who has recently been removing all of this from multiple template /doc pages.
WhatamIdoing (
talk)
05:36, 27 July 2024 (UTC)reply
Comment There's a lot of hyperbole going on in that description of the "problem". Personally I think people would be more surprised if redirects to templates didn't work as they do.
Anomie⚔12:18, 27 July 2024 (UTC)reply
People with 10K+ edits would. Contrariwise, there are people literally typing [citation needed] into articles (if anyone wonders, it is nearly 100% accurate use of the tag, just zero understanding of how templates/markup work). jp×
g🗯️21:25, 27 July 2024 (UTC)reply
Sure, people who don't even know how to use templates won't know what a template redirect does either (people like yours, and the ones I come across sometimes who think they have to copy-paste the template's wikitext). But once someone knows how to use a template, and knows what a redirect is, I think they'd be surprised if the two didn't work together in the obvious way.
Anomie⚔22:55, 27 July 2024 (UTC)reply
The current practice of using {{tsh}} with a small number of shortcuts (as exemplified here) is better than listing all redirects. It seems excessive to add all this to a documentation page:
I also don't see how the behavior of redirects is unintuitive. (Just as you can link a page via its redirects, you can insert a template (transclude a page) via its redirects.) Nor would listing redirects on the documentation page help people typing [citation needed] (who will not have occasion to visit the documentation page).
SilverLocust💬22:18, 27 July 2024 (UTC)reply
Oppose. This is needless bloat to the documentation. A documentation of a template is meant to explain how the template works and any quirks that it needs to address. More complicated templates, need longer documentation. A list of redirects does not add to understanding how a template works, it's purpose, or really anything. All it does is make the documentation page longer (bloated) and harder to navigate and read. When something is added to a page and placed in hidden or collapsed sections, that's usually a sign it really isn't needed (see
MOS:DONTHIDE). A list of redirects can be found in the "what links here" page for anyone that wants to view them.
Gonnym (
talk)
07:47, 29 July 2024 (UTC)reply
Well, a doc page is meant to explain how to use the template, and letting people know that they can type {{fact}} instead of having to spell out {{citation needed}} every time is "how to use the template".
WhatamIdoing (
talk)
16:34, 29 July 2024 (UTC)reply
Support only for popular redirects, oppose others. It's certainly fine to have a note in the {{Citation needed}} documentation that the commonly used shortcut {{cn}} redirects there. But noting in the documentation that the misspelling {{Ciation needed}} redirects there adds nothing but bloat. I worry that if this passes without qualification, it'll lead folks to start adding bloated lists of every single template en masse. I understand the temptation to use {{list redirects}} to automate the process, but we're not ready for that until {{list redirects}} is made significantly more capable so that it can distinguish between common redirects and uncommon ones. Sdkbtalk17:55, 29 July 2024 (UTC)reply
Moot: There's no policy/otherwise forbidding this to begin with. Get consensus on the template's talk page that a redirect is worth mentioning, and then mention it. Headbomb {
t ·
c ·
p ·
b}22:08, 29 July 2024 (UTC)reply
Afd to Prn/Pcn
Can we rename Articles for deletion to Articles for checking/Reviewing notability which will give a positive impression than the present one.
103.66.169.3 (
talk)
19:36, 26 July 2024 (UTC)reply
I think this is one of the perennial proposals, and the answer is "not necessary" (at any rate, it would require rewriting thousands of lines of active software, and moving half a million pages). jp×
g🗯️22:15, 26 July 2024 (UTC)reply
The French Wikipedia did this, perhaps two years ago. AIUI they thought the communicative value (e.g., that we are here to check notability, not necessarily to delete the page) outweighed the one-time hassle. (Also, you don't have to move the prior pages; you can just move a few key pages, like
Wikipedia:Articles for deletion itself, and leave the old ones alone.)
WhatamIdoing (
talk)
05:39, 27 July 2024 (UTC)reply
It was indeed a huge undertaking; no, we do have to move a huge amount of pages (as my major work 'bot did); and as
JPxG points out there is more in place nowadays that is hardwired to the page prefix (from the templates that we invented at the same time, to people's private add-in scripts) than there was back then. Moreover we are not checking notability. We are deciding whether an administrator hits a delete button on an article, for those cases where it isn't obvious on sight that the article should be deleted and 1 person alone can safely make the decision to press that button. It's a very clear name for the very single purpose that it is there for. Stuff outwith the decision about whether an administrator hits a delete button or not is intentionally left to the editorship at large.
Uncle G (
talk)
02:08, 28 July 2024 (UTC)reply
I'm also old enough to remember the VfD days. Anyway, AfD has its problems. What it's called is not one of them. Let's worry about stuff that matters.
RoySmith(talk)02:25, 28 July 2024 (UTC)reply
I agree with Uncle G, the current name has a clarity that said replacements would not have. Even if the new name is somewhat less intimidating to newcomers, it's better to be upfront about what's happening. ― novov(tc)06:14, 28 July 2024 (UTC)reply
Rename to Articles for Discussion?, in line with the other XFDs. I had a similar query and sometimes feel uncertain about nominating articles when I'm on the fence if they should be deleted/merged/redirected. The 'AfD' acronym is also maintained.
Svampesky (
talk)
23:11, 30 July 2024 (UTC)reply
I see the new Dark Mode but can we also get a 3rd "Dim Mode"?
Pretty self explanatory, but for folks like me who find that Dark Mode is too dark to be readable on most apps, Twitter got it right with a 3rd option of "Dim Mode" which is not as dark as their "Lights Out" Mode, the equivalent to Dark Mode everywhere else.
Wikipedia is the website that I do the most reading on, it would be awesome if you implement options for folks with various visual impairments.
I believe that
Wikipedia:Pokémon test would be better marked as a historical page. It is not really about an editor's viewpoint, but about a former argument used in Articles for Deletion that lead to a mass deletion of Pokémon related articles. The article is still used in AFDs, but only when referencing this time period.
(Oinkers42) (
talk)
21:39, 29 July 2024 (UTC)reply