Jump to content

Wikipedia:Village pump (idea lab)/Archive 66

Add links
From Wikipedia, the free encyclopedia
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68

Removing "Month and Day" from date of the leading sentence of articles about humans

Hi, according to Occam's razor or the "principle of parsimony", the first line of articles should only contain the main important data and does not contain any "less important" data. For example, in the article Steve Jobs, the leading sentence is:

Steven Paul Jobs (February 24, 1955 – October 5, 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.

Here, I think "February 24" and "October 5" are not so much important to be included in the leading sentence of this article. So, according to "principle of parsimony", I propose to remove that, which yields:

Steven Paul Jobs (1955 – 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.

I think removing such data makes the article and its leading sentence more usable and practical. These "Month and Date" can be mentioned later in that article or in its Infobox. Please discuss. Thank, Hooman Mallahzadeh (talk) 09:28, 26 March 2025 (UTC)

Occam's razor has nothing to do with this; it's for asking for the least amount of coincidences in logical explanations, not hiding the most detail. I see no reason to remove the month and date. (Also, some people are against infoboxes on certain articles.) Aaron Liu (talk) 12:55, 26 March 2025 (UTC)
@Aaron Liu Let's say an example, if someone asks you: who was Steve Jobs? Do you mention his birthday in Month and Day in details? Probably no. You only mention his birth year as an approximation. I think in these cases, mentioning details is wrong. Hooman Mallahzadeh (talk) 13:00, 26 March 2025 (UTC)
Do I mention his death year? Do I mention his middle name? Would I recall that he was a notable investor when giving basic details, even though it's quite important?
Besides the questions of purpose (what if the person died on say 9/11 and is notable for doing so?), you would have to change over 4 million articles. Aaron Liu (talk) 13:41, 26 March 2025 (UTC)
Me telling someone who a person is/was in response to a verbal question is a very different context to reading about who someone is/was in an encyclopaedia article. There are many times I've looked up articles just to find someone's date of birth or death, sometimes I've wanted to be more specific than the year, sometimes I haven't. The precise date being there when I'm not interested has never negatively impacted me, the absence when I was interested would have done. Thryduulf (talk) 13:49, 26 March 2025 (UTC)
@Aaron Liu Over 4 million articles will be modified by this policy by many editors, so don't worry about that. We only want to decide on its policy.
I think most visitors only read the one or two top sentences of each article, without need to read the rest. When they encounter some details that they don't really need, I think it's a drawback of Encyclopedia.
Dear @Thryduulf in the first sentence we only provide approximation, and in the remaining parts the exact "Month and Day" is mentioned. I don't believe exact date is not encyclopedic! I only say that the leading sentence should not contain such details, except for some reason we must do that. Hooman Mallahzadeh (talk) 13:58, 26 March 2025 (UTC)
So you are proposing to have the date of birth and death twice in the lead paragraph, years only in the first sentence and the full dates subsequently? That's a hard no from me - it doesn't bring any significant benefits to anybody while making the full dates harder to find and the duplication both bring disbenefits to others. Thryduulf (talk) 14:09, 26 March 2025 (UTC)

don't worry about that. We only want to decide on its policy.

Policy has to follow practice. You're vastly overestimating the practicability and the tradeoff for something so trivial. Aaron Liu (talk) 14:17, 26 March 2025 (UTC)
I mean most viewers of Steve Jobs article don't want to take a Birthday party for him, for only very few of them this detail i.e., "February 24" is important.
We should consider that such detail "for majority is annoying" and "for minority is beneficial". Hooman Mallahzadeh (talk) 14:22, 26 March 2025 (UTC)
I doubt anyone finds it annoying. Aaron Liu (talk) 14:24, 26 March 2025 (UTC)
Citation needed that anyone other than yourself finds it annoying.--User:Khajidha (talk) (contributions) 18:01, 1 April 2025 (UTC)
@Khajidha This is the Occam's razor principle. This rule says putting unnecessary details in the definition is annoying. The first line (and paragraph) should be as "parsimony" as possible, because it is defining a concept. So it should include only main information and lack any less important ones. Hooman Mallahzadeh (talk) 04:06, 2 April 2025 (UTC)
A person's full dates are "main information". Thryduulf (talk) 09:32, 2 April 2025 (UTC)
@Thryduulf I think "person's full birthdate" is not "main information" when defining a person. The reason is that without "full date" and mentioning only "year", the definition experiences no problem. Hooman Mallahzadeh (talk) 09:36, 2 April 2025 (UTC)
Some detail that does not affect the "defining whole concept" may be omitted. Hooman Mallahzadeh (talk) 09:39, 2 April 2025 (UTC)
As someone else pointed out, that's not Occam's razor. --User:Khajidha (talk) (contributions) 09:39, 2 April 2025 (UTC)
Besides whether it is Occam's razor or is not, the important thing is that we should make our "introduction paragraph" of articles in Wikipedia as parsimony as possible. Do you disagree with that? Hooman Mallahzadeh (talk) 09:52, 2 April 2025 (UTC)
Yes, I disagree that introduction paragraphs should be as parsimony as possible. The lead section provides an overview introduction to the article as a whole. Conveying the least amount of information possible is neither the goal nor beneficial. Thryduulf (talk) 10:06, 2 April 2025 (UTC)
@Thryduulf We have
  1. Introduction (writing)
  2. Abstract (summary)
  3. Lead paragraph
each of which introduces different concepts, but we have "summarizes" and "brief explanation" and "brief summary" in their definitions. These are other names of "parsimony". Hooman Mallahzadeh (talk) 11:32, 2 April 2025 (UTC)
We're just back at #c-Aaron_Liu-20250326134100-Hooman_Mallahzadeh-20250326130000 now. Aaron Liu (talk) 11:46, 2 April 2025 (UTC)
No, parsimony is not a synonym of "summarise", "brief explanation" or "brief summary", it means The quality or characteristic of using the fewest resources or explanations to solve a problem. Absolutely nothing requires or even encourages us to use the fewest words or convey the least amount of information possible. Thryduulf (talk) 11:52, 2 April 2025 (UTC)
@Thryduulf No, I only said that

If you encounter a definition that incorporates some data that is not considered "the most important data", then remove that part (data) from the definition and mention that somewhere else.

Is the above idea wrong? Hooman Mallahzadeh (talk) 12:02, 2 April 2025 (UTC)
I'm not quite sure what your asking here, but none of "Summarise", "brief explanation" or "brief summary" restrict the summary/explanation to only "the most important data", and separately it seems that your view of what "the most important data" is is very significantly narrower than pretty much everybody's else's. Thryduulf (talk) 12:33, 2 April 2025 (UTC)
@Khajidha See Occam's razor article

It recommends searching for «explanations» constructed with the smallest possible set of elements.

Hooman Mallahzadeh (talk) 09:54, 2 April 2025 (UTC)
Which is completely different frem what we are discussing.--User:Khajidha (talk) (contributions) 10:40, 2 April 2025 (UTC)
We are dealing with "definitions" in the leading sentence of articles. I really surprise about why you say it is different. Hooman Mallahzadeh (talk) 11:36, 2 April 2025 (UTC)

This philosophical razor advocates that when presented with competing hypotheses about the same prediction and both hypotheses have equal explanatory power, one should prefer the hypothesis that requires the fewest assumptions

Another way of saying it is that the more assumptions you have to make, the more unlikely an explanation.

Aaron Liu (talk) 11:43, 2 April 2025 (UTC)
Occam's razor is about constructing hypotheses (or choosing between hypotheses), not writing definitions. --User:Khajidha (talk) (contributions) 12:48, 2 April 2025 (UTC)
This article uses the word "explanation" multiple times, I think it implies "definition". Hooman Mallahzadeh (talk) 15:17, 2 April 2025 (UTC)
I think it implies "definition" it doesn't. Thryduulf (talk) 15:47, 2 April 2025 (UTC)
It's an explanation of "how", not "what". Aaron Liu (talk) 15:59, 2 April 2025 (UTC)
I think that we are running up against WP:CIR here. --User:Khajidha (talk) (contributions) 16:32, 2 April 2025 (UTC)
I'm becoming increasingly inclined to agree. Thryduulf (talk) 17:19, 2 April 2025 (UTC)
@Khajidha@Thryduulf I really don't want to disrupt Wikipedia. Even in IELTS Exam, there exists some policies about how to write introduction and a rule says: introduction should not contain numbers at all.
I only want to impose a policy on "how to write introduction" of Wikipedia articles. Exactly the same as IELTS writings. This policy would says in the introduction paragraph of Wikipedia:
  • What should be included
  • What should be omitted
Because it seems that no policy exists till now. Hooman Mallahzadeh (talk) 17:20, 2 April 2025 (UTC)
Why should we care what the IELTS says? --User:Khajidha (talk) (contributions) 18:31, 2 April 2025 (UTC)
Not everything needs a policy. Thryduulf (talk) 19:50, 2 April 2025 (UTC)
It is a matter of quality of Wikipedia articles. Like IELTS, such policies about introductions of Wikipedia articles impact "Coherence" of that article. "High coherence" means "easier reading". Therefore, quality of Wikipedia articles increases this way. Hooman Mallahzadeh (talk) 03:45, 3 April 2025 (UTC)
I searched it up; that guideline is just for summarizing a chart and also recommends you to include dates in the first paragraph when appropriate. There is no IELTS guideline for writing a biographical profile. Aaron Liu (talk) 11:33, 3 April 2025 (UTC)
You should get the idea of IELTS not its instruction. It says:

Do something that your reader understands your essay by just one time reading.

and this is achieved by TA, CC, GRA and LR. The idea of coherence of articles is applied beyond IELTS, for example, when writing an academic article for a journal, there exist policies related to coherence. It says what data should be inserted in what part of that scientific article.
Why Wikipedia hadn't obeyed similar cohesive policies? Our goal is:

Makeing Wikipedia article more readable.

Hooman Mallahzadeh (talk) 11:45, 3 April 2025 (UTC)
And I'm saying #c-Aaron_Liu-20250326142400-Hooman_Mallahzadeh-20250326142200. Aaron Liu (talk) 12:01, 3 April 2025 (UTC)
You said "anyone". That's completely true. If someone wants to take a birthday party, or commemorate his death, then such data would be very helpful for that person. But the problem is that majority of readers would neither want to take birthday party for him nor to commemorate his death date. Threfore an approximate date is more useful for them. Hooman Mallahzadeh (talk) 12:09, 3 April 2025 (UTC)
Here's what I actually said, translated into Persian: من شک دارم کسی آن را آزاردهنده بداند. Aaron Liu (talk) 12:38, 3 April 2025 (UTC)
No need to Persian, just mathematically:
For myself it is annoying. So the above rule has a counterexample and it is not true. Hooman Mallahzadeh (talk) 12:45, 3 April 2025 (UTC)
If here "anyone" implies "majority", then we can apply a psychological test:
  1. Apply two versions of an article by "Full date" and "Abstract date" to a group of people
  2. Ask them which one is more annoying
Then we can report the result. Hooman Mallahzadeh (talk) 12:58, 3 April 2025 (UTC)
  1. Occam's razor involves constructing explanations with the smallest number of unknown or assumed entities, being unnecessarily more complex and so less plausible than an explanation using fewer entities and those that are known. It does not mean that we should all be using shorter sentences.
  2. "I just don't fancy it," is not a very good rationale for a change that would affect a million plus articles. GMGtalk 14:30, 26 March 2025 (UTC)
    In my opinion using tooltip is a reasonable policy in such cases, we can use a sentence like this:

    Steven Paul Jobs (1955 – 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.

    and by tooltip, we can satisfy both minority and majority of viewers. Hooman Mallahzadeh (talk) 14:37, 26 March 2025 (UTC)
    And even in the best case, it is a barely noticeable improvement that would require an inordinate amount of time to implement. The answer is going to be no. GMGtalk 14:40, 26 March 2025 (UTC)
The month and day should not be removed; it’s harmless and potentially useful. If we actually did remove this 4/6ths of the Encyclopedia would need modification, which is incredibly pointless busywork even for bots. Dronebogus (talk) 15:08, 26 March 2025 (UTC)
And unless the consensus was that all dates more precise than a year should be removed (which even the OP doesn't seem to desire) it couldn't be done by a bot (c.f. WP:CONTEXTBOT). Thryduulf (talk) 15:18, 26 March 2025 (UTC)
The month and day are potentially harmful per Wikipedia:Biographies of living persons#Privacy of personal information and using primary sources (though Steve Jobs is no longer a BLP). WhatamIdoing (talk) 02:04, 30 March 2025 (UTC)
I like the idea, if – and only if – there is either an infobox containing the full dates, or if the exact dates are mentioned in the body of the article (e.g., in the ==Childhood== and ==Death== sections).
Additionally, I'd leave the first-sentence dates in place for recent births/deaths, since someone might look up "New Baby Royal" or "Celebrity Justin Died" for the primary purpose of finding that recent date. WhatamIdoing (talk) 02:07, 30 March 2025 (UTC)
We have talked about this before in the past..... I also think there's no need to write it out two times if the info box has the information. As we know most people scan the infobox [1] and it would reduce first sentence clutter that's always a consideration in bios. Moxy🍁 02:15, 30 March 2025 (UTC)
Turning everything into “clutter” is a good way to start chopping off half the encyclopedia. 99% of Wikipedia is meaningless junk to 99% of people. Dronebogus (talk) 17:25, 1 April 2025 (UTC)
ِDear @Dronebogus

Turning everything into “clutter”

Not everything! Not clutter! I mean, "first lines" should be as parsimony and concise as possible. This rule also exists in "introduction" Writing part of IELTS. The reason is that many people would only read "first line(s)" and would not read the rest. Removed data are not clutter, in fact they should be mentioned somewhere else, possibly using techniques like incorporating tooltip or footer. Hooman Mallahzadeh (talk) 03:58, 2 April 2025 (UTC)
I see no evidence that IELTS is the undisputed pinnacle of writing at all, let alone in any and every context for any and every audience. It is merely one set of style choices for demonstrating ability in one way, chosen as such for one specific purpose. DMacks (talk) 17:36, 2 April 2025 (UTC)
Hooman Mallahzadeh, think you are overlooking the substantial proportion of our population, which assigns astrological significance to dates. Knowing Jobs’s date of birth informs, those readers immediately that he was a Pisces ascendant in Virgo, which might shape views of him for them. Hyperbolick (talk) 07:10, 13 April 2025 (UTC)
@Hyperbolick "Astrological significance of dates" is related to computers. But for humans, an approximate date which has no "Astrological significance" is more useful. For example, instead of "February 24, 1955", we can use:
  • 1955 - As year
  • 1950s - As decade
  • second half of 20th contury
  • 20th century
All of them are useful for different purposes, because we are human, not computer. Our goal is to provide a
"Highly readable" article for "Humans".
It can be achieved by using approximate dates, somehow that does not harm the definition.
This "principle of parsimony" is applied in "introduction writing instruction" for of all scientific articles but not yet in Wikipedia. The problem is that we are human not computer. Hooman Mallahzadeh (talk) 07:54, 13 April 2025 (UTC)
Hyperblock's comment has nothing at all to do with computers and your (@Hooman Mallahzadeh's) comment completely misses the point. Thryduulf (talk) 08:13, 13 April 2025 (UTC)
I absolutely hate it when basic information is hidden away in the infobox (which I often do not notice). There should usually be no information in the infobox that is not in the prose somewhere. —Kusma (talk) 20:36, 2 April 2025 (UTC)

References

  1. ^ Wells, John C. (2008). "Ali". Longman Pronunciation Dictionary (3rd ed.). Longman. ISBN 978-1-4058-8118-0. the former boxer Muhammad Ali pronounces ɑːˈliː

Could drafts be protected instead of deleted?

After I saw a draft for Sprunki get nominated for deletion for the same reason that the one for Battle for Dream Island had been deleted and salted, that got me thinking:

Instead of deleting drafts that are resubmitted to oblivion, why not semi-protect or extended confirmed protect them so unregistered (and newly registered) users won't be able to submit them anymore?

In order to submit a draft, the template {{AfC submission}} has to be placed on the page. If it's semi-protected, then only autoconfirmed editors should be able to submit it. If it's extended confirmed protected, then only extended confirmed editors could submit it, and everyone else would have to place edit requests on its talk page where they can be declined by other editors.

Here's a list of times that the Sprunki draft was submitted:

Date Account age then Edit count then Autoconfirmed? Extended confirmed?
October 12, 2024 Unregistered; not applicable ☒N ☒N
November 24, 2024 Unregistered; not applicable ☒N ☒N
December 15, 2024 0 days 11 ~ Not until Dec. 19 ☒N
April 3, 2025 2 days 12 ~ Not until Apr. 5 ☒N

Just for the sake of comparison, here's a list of the times that Barron Trump had been submitted whilst it was still a draft:

Date Account age then Edit count then Autoconfirmed? Extended confirmed?
November 28, 2023 19 days 109 checkY ☒N
November 9, 2024 493 days 858 checkY checkY
January 21, 2025 Unregistered; not applicable ☒N ☒N
January 24, 2025 Unregistered; not applicable ☒N ☒N
January 26, 2025 2,292 days 189 checkY ☒N
March 4, 2025 16 days 28 checkY ☒N
March 16, 2025 27 days 25 checkY ☒N
March 23, 2025 34 days 51 checkY ☒N

If protecting drafts isn't a good way to deter resubmissions and save reviewers' time in the process, I'd like to know why not. – MrPersonHumanGuy (talk) 15:43, 15 April 2025 (UTC)

Sprunki isn’t an good example due to it’s lack of coverage and it’s lacking general notability •Cyberwolf•. talk? 15:57, 15 April 2025 (UTC)
Protecting page names is what should be done •Cyberwolf•. talk? 15:59, 15 April 2025 (UTC)
@MrPersonHumanGuy: This would also require move protection at the same levels, so that an autoconfirmed editor can't just move it into mainspace and bypass the process. And given that drafts are NOINDEXed and hard to find unless you're willing to use the internal search engine and know their exact title, this would end up causing a lot of drafts that don't have a chance to languish. Another factor to consider is that, unless express permission is given, people generally are unwilling to edit someone else's draft. —Jéské Couriano v^_^v threads critiques 16:02, 15 April 2025 (UTC)
As a contributor who would be unwilling to edit other people's drafts myself, you are especially correct about that, which is why I like to copy userspace drafts into draftspace and edit such copies as I see fit. Of course, I could just move a draft, but I would be concerned that its creator may get surprised to find out that it's been moved all of a sudden. Then again, some drafts do get forgotten for months before they're rediscovered by at least one other contributor.
Topic Original userspace draft Draftspace counterpart
A World Without (web series) User:FroggyTranslator/A World Without... Draft:A World Without (web series)
Time Traveler Luke User:DDG9912/Time Traveler Luke Draft:Time Traveler Luke
I'm only bringing these up on a case-in-point basis. These two drafts don't (and won't) need page protection at this time, as neither of them have been submitted, nor do they (as of yet) appear to have the sort of meme status or popularity with certain demographic niches that would cause them to be at risk of being submitted by obsessive fans of their respective subjects in the foreseeable future. Please excuse my darned affinity for tables. – MrPersonHumanGuy (talk) 19:32, 15 April 2025 (UTC)
Doesn't protection automatically apply move protection? Aaron Liu (talk) 22:29, 15 April 2025 (UTC)

A problem with pushpin maps

Hi, follow this scenario

  1. Go to article Tehran
  2. Click on pushpin map in its Infobox
  3. This image is shown that lacks marker of Tehran

This scenario does not seem true. So I propose that after clicking on Tehran's pushpin map, then its OpenStreetMap containing marker of Tehran will be shown in the new page. This way, the user has the ability to zoom in and out. Please discuss. Thanks. Hooman Mallahzadeh (talk) 11:52, 15 April 2025 (UTC)

The object above what you are talking does this •Cyberwolf•. talk? 15:09, 15 April 2025 (UTC)
@Cyberwolf Sometimes this OSM map does not exist. This behavior of
  • Showing a map without any indicator
after clicking on pushpin_map is not reasonable. I think the true scenario would be showing OSM map with an indicator. I think its implementation is very fast and convenient. This problem for Sydney article is more observable. Hooman Mallahzadeh (talk) 15:27, 15 April 2025 (UTC)
Then add a osm to the info box •Cyberwolf•. talk? 15:28, 15 April 2025 (UTC)
You are right, we can do everything. The problem is that this behaviour is a malfunction and is considered a software bug. Do you agree? Hooman Mallahzadeh (talk) 15:33, 15 April 2025 (UTC)
I don’t see it as a software bug tbh cause its an image with a marker overlay for precise location you use the other map •Cyberwolf•. talk? 15:36, 15 April 2025 (UTC)
See, this image https://en.wikipedia.org/wiki/Sydney#/media/File:Australia_relief_map.jpg which is shown after clicking on pushpin map of Sydney article does not contain any marker. Do you see any marker? So it is not useful at all. Hooman Mallahzadeh (talk) 15:39, 15 April 2025 (UTC)
It’s not the point of the pushpin map •Cyberwolf•. talk? 15:42, 15 April 2025 (UTC)
Yes you're right. We are redirected to a picture (of Australia) from Wiki Commons. I think this redirection is not true, because it does not contain any marker. We should redirect to somewhere that in addition to a marker, we can "zoom in" or "zoom out". This is only achieved by OSM maps. And I strongly believe that implementation of this redirection is very convenient. Hooman Mallahzadeh (talk) 15:47, 15 April 2025 (UTC)
Well I did some hands on with pushpin maps a relief map is what’s used which is just an image of the country making an image for it that’s a duplicate of what the push pin looks like will fix this •Cyberwolf•. talk? 15:55, 15 April 2025 (UTC)
I don't get what you said. How will fix it? The relief map that is shown after clicking is from Wiki Commons, and it does not contain any marker. How it would be fixed? Hooman Mallahzadeh (talk) 16:01, 15 April 2025 (UTC)
So by taking a screenshot of the marker and map uploading that and place that in the map thing •Cyberwolf•. talk? 16:19, 15 April 2025 (UTC)
This process is too hard to implement. I really think that a redirection to its place in OSM map would be implemented very fast and easily. Hooman Mallahzadeh (talk) 16:26, 15 April 2025 (UTC)
In addition, OSM has the ability to Zoom in/out that screenshot map lacks. I really think that this ability is very useful for every user. Hooman Mallahzadeh (talk) 16:29, 15 April 2025 (UTC)
I'd support this, if there's an easy way to implement it technically. Elli (talk | contribs) 16:52, 15 April 2025 (UTC)

@Elli:This is my proposed easy implementation:

1- Create an OSM map by this code:

{{Infobox mapframe|wikidata=yes|id ={{get QID|Tehran}} |zoom=4| stroke-width=1 |shape-fill-opacity=0|geomask={{get QID|Iran}}|mapframe-frame-coordinates= {{WikidataCoord|Tehran}}|marker=city}}

Which yields:

Map

2-place the above code in a hidden div tag

3-change hyperlink of pushpin map to something like "https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#/map/0"

The same is true for other pushpin maps, just change Iran and Tehran to for example Australia and Sydney.

So easy-peasy. Hooman Mallahzadeh (talk) 17:28, 15 April 2025 (UTC)

The above implementation takes advantage of "geomask" argument of OSM which makes it completely the same as previously clicked pushpin map. I mean it is not just coordinates that redirects to https://geohack.toolforge.org site as this link for Tehran. Hooman Mallahzadeh (talk) 07:55, 16 April 2025 (UTC)

Ignore edits to ones own user area in right counts

For additional right given automatically based on number of edits, edits to ones own area of user and user talk space should not be counted. So User:ZcrashZ, if they had 11 edits, one to User:ZcrashZ, one to User talk:ZcrashZ and one to User:ZcrashZ/page1 and eight to other places, the user would count as having made 8 edits and would be unable to move a page because WP:AUTOCONFIRM would not apply. I see editing of their own area a lot on creating accounts for Vandalism.Naraht (talk) 01:23, 5 April 2025 (UTC)

How often does this happen?
This link will give you a list of every page moved by any account with (if memory serves) 10–500 edits during the last 24 hours. Looking at it, there's been about 125 entries in the move log, but if there's a talk page, then a single "move" action will be logged twice, so there are probably about 50 names to review. I looked at about 10; I found only one that might have been tripped up by such a rule.
The point behind autoconfirm is that obvious vandals are obvious before they make 10 edits. If they're not obvious vandals, then why shouldn't they be able to draft an article in their userspace and move it to the mainspace when they're ready for it to face Wikipedia:New pages patrol? WhatamIdoing (talk) 03:00, 5 April 2025 (UTC)
Is there any user right besides autoconfirmed that is triggered by edit count? Cambalachero (talk) 03:21, 5 April 2025 (UTC)
WP:XCON which requires 500, though as with AC it also has a time component, 30 days instead of 4. And yes it is also routinely gamed. 184.152.65.118 (talk) 03:26, 5 April 2025 (UTC)
WP:XCON (but AIUI not WP:AUTOCONFIRM for technical reasons) can be revoked if a user is judged to be gaming the permissions system. Requiring that edits counting towards AC/EC not be in userspace will probably have limited effect on people actively gaming permissions – they can simply shift their permission-gaming to a different namespace. Especially in the case of autoconfirm, which only requires 10 edits. Caeciliusinhorto-public (talk) 15:53, 7 April 2025 (UTC)
I think there are some tools that require certain edit counts, though the two I can remember at the moment, being access to the wikipedia library and autowikibrowser, have similar edit requirements to extended confirmed. I believe there's a tool that requires 1k edits but I cannot for the life of me remember what it is, so along with the others I listed I doubt anyone is edit farming for those specific tools. ¿VØ!D? ☄ 21:11, 14 April 2025 (UTC)
Currently, it seems that there is no documentation if one can restrict edit count by namespace. mw:Manual:$wgAutopromote. If the suggestion is passed in a RfC, technical assessment and work will likely be in order before such conditions by namespace can be used. – robertsky (talk) 09:51, 13 April 2025 (UTC)
Likely it would require a database change to store the edit count by namespace. Anomie⚔ 12:40, 13 April 2025 (UTC)
Some editors do start drafting articles in userspace before moving them to mainspace, I'm thinking these contributions should still be counted if that proposal comes to pass. Chaotic Enby (talk · contribs) 12:26, 13 April 2025 (UTC)
Chaotic Enby, are you saying these edits should count even before the draft has been published (So someone may have 450 mainspace edits and 100 edits to an as-yet-unpublished draft, and they should receive EC rights)? Because if they only count after publication, I think counting edits made to mainspace would include edits made to former drafts that have since been moved to mainspace. ꧁Zanahary꧂ 21:38, 15 April 2025 (UTC)
I was thinking they would only count after being moved to mainspace, if that's already how they are counted then it's great! Chaotic Enby (talk · contribs) 09:42, 16 April 2025 (UTC)

Antivirus

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
It looks like the OP has earned a CU block. WhatamIdoing (talk) 18:21, 16 April 2025 (UTC)

We could create a bot that removes links to computer viruses, only from the wikimedia foundation. (red annales) (talk) 19:38, 13 April 2025 (UTC)

A way to try this out would be to make your bot make a report. It could publish a report of Page, link (don't make it clickable), and perhaps the name of the threat on the link. — xaosflux Talk 19:42, 13 April 2025 (UTC)
Simple just use virustotals api although we would need to pay or ask for the enterprise version but i believe virustotal is an Wikipedia in terms of verification and community I don’t think the foundation wouldn’t mind much. Edit: we could take this further and do phishing detection and ip logger detection. Even in commons we could use this just to run files and pdfs through •Cyberwolf•. talk? 15:17, 15 April 2025 (UTC)
How often are virus links even posted to Wikipedia? Aaron Liu (talk) 15:20, 15 April 2025 (UTC)
Rarely but it can prevent it when it does id rather stop one virus than just sit by and let it go undetected •Cyberwolf•. talk? 15:24, 15 April 2025 (UTC)
on the Russian-language wiki tends to appear more often, a project abandoned to its own fate just as it was with China. (red annales) (talk) 22:09, 15 April 2025 (UTC)
They don't have an edit filter against non-autoconfirmed users adding external links? Aaron Liu (talk) 02:15, 16 April 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Well i can write a script- its quite simple and i have been learning java script so might as well try •Cyberwolf•. talk? 12:52, 17 April 2025 (UTC)
Doing a plug in •Cyberwolf•. talk? 13:36, 17 April 2025 (UTC)

Moving logos, album covers etc out of infoboxes

I am concerned that the current default practice of adding logos, album covers, film posters, box art etc to infoboxes is stifling commentry, criticism and free content generation.

Very often these items are fair use whose purpose is for "criticism, comment, news reporting, teaching, scholarship, or research" (random website) and the Non-free content guideline lists Contextual significance as a factor. By moving these images out of infoboxes we would be encouraging captions that provide critical commentary, enhancing contextual significance. And hopfully free alternatives would be generated.

Current examples:

  • National Hockey League: the uncaptioned logo is the only image you see on the page on mobile, an interesting caption is only found on the child article for some reason. An alternative would be a photo of an NHL game.
  • GoldenEye: the film poster actually has a caption, but the image would be better placed in the section that discusses poster curation. Ideally a free photo of the film's production could be used in the infobox.
  • Let's Get Out of This Country: no caption for this album cover, which actually has an interesting backstory. I suppose I am meant to write the sourced passage about the cover down in the body, add a synopsis in the infobox caption and expect the reader to scroll up and down when reading the passage. Ideally a free photo of the band in the recording studio could be used in the infobox.

I understand that having these logo/album cover type images in infoboxes is an easy way to make the article look pretty and to help familiarise the reader with the promotional materials, but is that our priority? It can be difficult to find freely licenced ideal alternatives, but we should try. Commander Keane (talk) 00:15, 16 April 2025 (UTC)

I don’t see how placement in the infobox precludes sourced critical commentary in the body. ꧁Zanahary꧂ 00:20, 16 April 2025 (UTC)
I agree. These examples can all be changed: I would support the recommended changes to the latter two pages, and for the first page I would just copy over (and condense) the caption on the child page and throw it into the infobox. None of this needs something that says such images shouldn't be in infoboxes. Aaron Liu (talk) 01:42, 16 April 2025 (UTC)
Am I right in reading this as a question about whether WP:NFC used in the infobox meets the WP:NFCCP policy, rather than a general question about whether logos, album covers, etc. should be in infoboxes or not? CMD (talk) 00:33, 16 April 2025 (UTC)
Per NFCI#1, images that are used for identification in infoboxes are presumed to meet NFCC#8 as they provide implicit branding and marketing of the topic in question. If they can also be used for additional purposes (for example, Ico's cover is discussed in the article as being based on a classical work of art), great, but we do not have that requirement to require more than the topic being notable in the first place to use identifying images. Masem (t) 02:13, 16 April 2025 (UTC)
I think the biggest hurdle to my idea is in WP:LEADIMAGE: which says the purpose of these is to ...give readers visual confirmation that they've arrived at the right page.
I am trying to encourage critical commentary on images, fair use or not; free material is certainly a bonus. I guess placement in the infobox doesn't prevent that, but is it appropriate to double up usage in the body? It would be better to place a captioned image next to the relevant discourse in the body. Ico, a featured article, is interesting in that an unreferenced caption is in the infobox, the inspiring artwork with one reference is in the Development section and commentary with two other references is in the Release section, along with the alternate box art.
Getting implicit branding and marketing in the infobox is certainly the goal of many an articles-for-creation contributor, which actually sparked my initial post. Also, as a newbie when looking to illustrate an article I uploaded a logo rather than look for a public domain image or request for a Wikipedian to take one. In that case, my critical commentary was actually moved away from the logo's caption when an infobox was introduced.
I had assumed that there was no policy problem with non-free content in infoboxes, and my examples all feature non-free content because that is what you typically find in infoboxes. I had no intention of splitting infobox image usage by copyright status, or giving non-copyright promotional material a free ride on critical commentary. Commander Keane (talk) 06:37, 16 April 2025 (UTC)
It's a cupcake. Do we really need critical commentary on the photo?
About I am trying to encourage critical commentary on images, fair use or not: Why?
I wonder if we have different ideas about what "critical commentary on the image" means. So I've added a photo. IMO critical commentary on the image would sound like "The cupcake is placed off center on a neutral background, with multiple lighting sources from the back and left, causing a shadow to fall to the right and front".
I suggest to you that the article Cupcake needs many images, but does not need any critical commentary on its images. WhatamIdoing (talk) 18:32, 16 April 2025 (UTC)
Indeed "critical commentary on images" is not the phrase I meant. More of an "useful encyclopedic comment for image captions", of which every image in Cupcake has. By critical I was intending, in your photo for example, "A sample from the Cupcake Camp Montreal fundraiser" rather than "A pretty one with sprinkles", or nothing. Commander Keane (talk) 23:38, 16 April 2025 (UTC)
Citation needed that it is a cupcake from the Montreal fundraiser. Sounds like OR to me. Blueboar (talk) 23:52, 16 April 2025 (UTC)
Yes, imagine a culture where you need to put a caption and find a reliable source to back it up. The Hostess Cupcake photo used in Cupcake may well have been baked by the photographer's grandmother for all I know. I would say images get a special treatment for OR, so I will trust that editors familiar with the brand have confirmed the photo is legit. I trusted the Montreal cupcake's file page, but if that is not enough then better sourcing is required. Effort is not a bad thing. My point of the caption was to introduce the reader to cupcake's cultural significance to fundraising, not mentioned in the article yet.
I don't know why we are talking about cupcakes, my problems were:
  • the culture of not bothering with captions in infoboxes, and when we do we must condense the message - which is reasonable as infoboxes are required to be simple, and
  • the editorial constraint of not being able to use those infobox images in the body near where they are discussed.
For the second problem, the proposed little anchor symbol that I think was suggested for the Barack Obama lead that would jump readers to the relevant section would help (I can't find the guideline on that anymore). Looking at the feature article Ico it seems the current idea is that readers intend to sit down and read the entire article so we can spread information, in that case about box art with accompanying images, throughout the article. Fair enough. I will leave it at that and try my best at working with current practice. Commander Keane (talk) 01:43, 17 April 2025 (UTC)
An image is supposed to illustrate something in the article. The point being illustrated might be, especially for a lead (including, but not limited to, infobox) image, "This is what the subject of the article looks like". There's nothing wrong with Barack Obama having a simple caption like "Official portrait". There's also nothing wrong with Ico having a caption that's 27 words long. The caption should serve the needs of the article.
If we had a section in Cupcake about its use in (US and Canadian) fundraising bake sales, then the photo above would need a caption like "A cupcake from a fundraising event" or "Cupcakes are popular at bake sales", or something like that. But:
  • If it's not saying anything 'new' compared to the text, there's no need to duplicate the citation just so there's a little blue clicky number visible in the caption. There is no need for a paragraph that says "Cupcakes are sold at fundraisers[1]" followed by an image caption that says "Cupcakes are sold at fundraisers[1]". Citing once per fact is enough.
  • The same photo can often be used to illustrate multiple points. If this image were in a ==Fundraising== section, then the caption should be about fundraising. But if this image were in a ==Decorating== section, then the caption should be about icing and sprinkles. And if it were used in a different article, it would need still yet a different caption. For example, if it were in Red dye number 3, next to a paragraph noting that most of Europe can't get such beautifully red sprinkles, because – unlike Canada, whence this cupcake hails – Europe has banned red dye number 3, then it would need a caption about the food dyes used in sprinkles. (Hmm, no photos in that article. Maybe I'll have a look around. A comparison of Red 3 vs some other red might be very nice.)
WhatamIdoing (talk) 03:35, 17 April 2025 (UTC)
1. User:WhatamIdoing stop talking about Cupcakes it is making me hungry!.
2. I am with WhatamIdoing on his comments about captions. Infoboxes are supposed to be a quick view outlining info on the article, so as per previous example the Goldeneye poster is enough for the infobox, the same as as Cadbury logo in the Cadbury page - it does enough to show what it is. Davidstewartharvey (talk) 05:05, 17 April 2025 (UTC)
Particularly for non-free which are only being used under a NFCI#1 claim as an identifying image and have zero further commentary about them, then the caption should be brief, or in cases where what the image like a movie poster or album cover, the caption omitted entirely.
Its when the image has more purpose for inclusion beyond just identification, as in the case of Ico as I've mentioned, then a more fleshed out caption should be reasonable, as that should help the reader locate where the image may be discussed more in the body. The caption should not include information not included in the body, however (eg LEDECITE should apply) Masem (t) 13:08, 17 April 2025 (UTC)
I don't think you can complain about cupcake examples and substitute with chocolate! I can now see that people love their branding in infoboxes, images with their captions are incidental to the cited text and that some images don't need a caption.
For Cadbury I would at least like to see a "Current logo" caption to prompt me to realise it hasn't been that way for 201 years. Then it is up to me to clunkily ctrl-F for "logo" (if magical links are forbidden) to be enlightened by the origin story in the Advertising section. You could say "go for it, add the caption as it increases value" (or maybe not) but my point is why no editor has added a caption already. A better caption could be "Current logo. Since the 1970s logos have been based on the signature of the founder's grandson", but that is too much for the infobox. I am going around in circles in this discussion. I want to have great captions on the relevant images near the relevant text. I understand this has to be balanced with the brevity and visual confirmation objectives of the infobox, and the need to distribute images throughout an article for aesthetics. Unfortunately all of these things can't be achieved and maybe my desire is unfounded.
Admittedly, removing official branding from infoboxes is not a good idea as it would introduce the problem of de minimis substitutes, like the way File:Cadbury World sign, Bournville.JPG is used in the Cadbury#Advertising section, and again in United Kingdom company law.
I probably should have started this idea thread stating that I really enjoy a good caption and encouraging free content. The way I skim an article is to read the intro and look at captions to see if anything piques my interest.
The blue magical clicky thing I mentioned is not a citation, and adding new information in captions can be a chicken-and-egg scenario with a work-in-progress. Commander Keane (talk) 01:56, 19 April 2025 (UTC)

Helping bring more interest in Wikipedia with racing fans

I have had an idea for the last couple months which has incubated a lot. It’s sorta a gathering for the current editors of motorsports articles to talk and watch the race while having a front end that brings in new editors for a potiential workshop on how to edit tables (pretty big issue) and create articles. What usually stops my train of thought is money I don’t know how expensive one of these would be but i want to just throw this at the wall and see if it sticks •Cyberwolf•. talk? 14:47, 15 April 2025 (UTC)

Are you thinking about a virtual event or an in-person one? WhatamIdoing (talk) 18:22, 16 April 2025 (UTC)
Any? •Cyberwolf•. talk? 18:48, 16 April 2025 (UTC)
Virtual events are cheap. You need a way to find and recruit potentially interested people (e.g., social media) and a way for them to talk (e.g., a Zoom account). Editing ordinary tables is easy: you use the visual editor on the desktop site (i.e., not mobile).
I suggest attending a couple of events before you trying hosting one. Check the m:Events calendar or similar pages to find something that sounds similar to what you'd like to do. The event coordinators might even be willing to talk to you about their planning work. WhatamIdoing (talk) 19:02, 16 April 2025 (UTC)
Everything can be improved even further, but, having this in mind, I've sometimes thought that having all articles with the same quality as we have in articles about Formula 1 or some other sport competitions (for example, FIFA World Cup), would be a good target to set. Their consistent structure is really great. MGeog2022 (talk) 11:02, 19 April 2025 (UTC)

Tasks/Missions

New policy: The users can make their own pages as task boards, with two tabs: tasks, which show what it will do in the future, and missions, important things of the user that will be done soon. 2001:1308:2695:7300:E167:FFB0:A392:8002 (talk) 15:18, 20 April 2025 (UTC)

It is not for posting spam, etc, nor do you need to post one. 2001:1308:2695:7300:E167:FFB0:A392:8002 (talk) 15:19, 20 April 2025 (UTC)
Can't we already? Aaron Liu (talk) 19:56, 20 April 2025 (UTC)
We can put that content on our user page if we wish to. The proposal seems to be to have predefined tabs. I oppose it for two reasons:
  1. It assumes everyone wants to put the same stuff on their user page, and
  2. It makes this seem like a social media site, rather than an encyclopedia.
Phil Bridger (talk) 20:07, 20 April 2025 (UTC)

Overturning NCCAPS

There's a discussion at WT:NCCAPS about the capitalization threshold (the current status quo is to only capitalize a title if it's always [sic] capitalized in sources), but it's gotten kind of personal in the last few comments, so rehashing it here for wider community input. Some editors have supported my proposal, others have opposed, overall something that needs to be discussed further. My original comment is as follows:

TL;DR: The threshold for capitalization or lack thereof should be the same as the threshold for a common name.

WP:AT says: Generally, article titles are based on what the subject is called in reliable sources. There is less than zero reason why the one exception to that should be the most trivial of matters: capitalization. The standard for American Revolution vs. American revolution should be the same as that of, say, Dog vs. Canis lupus familiaris. In the latter case, the majority of sources use Dog, thus that is the common name. In the former case, the majority of sources use American Revolution, thus that is the common name. There is nothing that makes capitalization somehow magically different from every other titling scenario.

If the title of an article in sources is 75% uppercase and 25% lowercase, then NCCAPS recommends we lowercase it. That's just plain wrong. If article titles on based on what the subject is called in reliable sources, then why should we contradict that rule for a small subclass of naming disputes? Going by sources and uppercasing the title violates no core content policies and reinforces the in-a-nutshell core of the titling policy. It's nonsense that we should ignore policy and a supermajority of sources to uphold this dubious guideline.

Thus we should follow the sources, as we always have. The threshold for capitalization should not be 100%, nor 95%, nor 90%. It should be 50.1% (with a ±5 to account for the extreme influence Wikipedia has on sources' titling).

So, what do we want to do? Do we want to follow sources and the core policy on article titles, or do we want to straight-up ignore sources, following an anachronistic guideline and some editors' minority grammatical opinions? Do we want to begin a never-ending shitstorm of "style warfare" over whether 50.1% has been reached, and depart from established grammatical norms, or keep in place a guideline that has been stable for twenty years? (Clearly each side has a different opinion...) 🐔 Chicdat  Bawk to me! 11:35, 31 March 2025 (UTC)

I see absolutely no justification for capitalisation to differ from other aspects of naming. It's not surprising that the discussion at the MoS has resulted in ad hominems, any discussion proposing anything other than reducing the number of capital letters in article titles almost invariably does. Thryduulf (talk) 12:18, 31 March 2025 (UTC)
I see no reason to change from the current guideline. Capitalization is a stylistic question. Unless it pretty much is capitalized in all sources, everywhere, all the time, then we are free to choose not to do so. Just as we are free to make other stylistic choices. --User:Khajidha (talk) (contributions) 15:03, 31 March 2025 (UTC)
I think the underlying logic here—as Khajidha says, that we don't 'follow the sources' when it comes to questions of pure style—is sound and necessary to ensure some level of consistency between articles based on different bodies of sources. Disputes tend to arise when applying this logic to capitalisation because the style we have chosen is quite extreme (i.e. we use as few capital letters as possible without coming off as an art project) and therefore more likely to clash with sources and editors' experiences elsewhere. They are exacerbated by a small group of editors who zealously and tactlessly apply this style across articles, with no regard for the preferences of those that wrote them. I'm unsure that tweaking the rule will solve either issue. – Joe (talk) 15:27, 31 March 2025 (UTC)
"with no regard for the preferences of those that wrote them" I'm not seeing how this is a problem. You aren't writing for you and your preferences. You are writing for Wikipedia and our style. --User:Khajidha (talk) (contributions) 17:23, 31 March 2025 (UTC)
The proposal is to change our style… so simply pointing to the current style guidance and saying “you are writing for our style” isn’t really an argument. Please explain why you think the current guidance is better than the proposal. Blueboar (talk) 21:02, 31 March 2025 (UTC)
Because it looks better and is easier to read with less capitalization. But, as I'm not the one arguing for change, I'm not the one who needs to explain. --User:Khajidha (talk) (contributions) 21:14, 31 March 2025 (UTC)
So, your reasons are 1) "your personal preference" and 2) "an uncited and possibly wrong factual claim"?
I've seen sources claiming that all lowercase is easier to read than all uppercase (once you know how to read. Brand-new readers often struggle to differentiate lowercase letters like d and b, so all-caps text sometimes works better for them). I don't remember seeing any research saying that "war and peace" is easier to read that "War and Peace".
About as I'm not the one arguing for change, I'm not the one who needs to explain: I guess I hope that editors who join a discussion are trying to find the Wikipedia:Consensus. That only works if everyone is willing to explain their views. Wikipedia:BOLD, revert, discuss cycle, in particular, is entirely dependent upon the reverter/objector being willing to explain why they object to a change. A stonewalling attitude like "You made the change, so I'm not the one who needs to explain my views" will cause BRD – and most other serious discussions – to fail. Please don't do that. WhatamIdoing (talk) 05:12, 1 April 2025 (UTC)
The problem is that having people who still want to write articles is several gazillion times more important to Wikipedia's future than consistent capitalization of titles. – Joe (talk) 21:51, 31 March 2025 (UTC)
I have come to believe that enforcing a house style is overall a net negative for Wikipedia. (Personally, I contribute very little to the German Wikipedia although German is my first language, mostly because I disagree with their style choices, which are often different from the near unanimous view of the sources). —Kusma (talk) 08:36, 19 April 2025 (UTC)
  • I find it interesting that basically everyone in that discussion agrees that "always capitalized in reliable sources" shouldn't be taken literally, but those opposed are saying we can't change it because some parade of horribles will follow. ~~ Jessintime (talk) 19:25, 31 March 2025 (UTC)
    Perhaps “overwhelmingly capitalized in sources” is closer to how we really operate? Blueboar (talk) 21:08, 31 March 2025 (UTC)
    It depends on the discussion whether it's "overwhelmingly", "almost always" or "literally always". Often it's "Overwhelmingly (or almost always) capitalised in sources that I can't dismiss as not-independent, unreliable, "specialist", "low quality", or for some other reason". I think it would be much closer to our ethos and a more professional approach to capitalisation if the standard was something like "predominantly capitalised" with usage by subject matter experts weighted a bit higher than usage by others and we treated the context-free evidence from sources like ngrams as a single, relatively low-importance data point. Thryduulf (talk) 21:26, 31 March 2025 (UTC)
    That "sources I can't dismiss as..." bit sounds like what I've seen in many areas. WhatamIdoing (talk) 05:14, 1 April 2025 (UTC)
@Chicdat: I wish I had time to write and refine something concise and thoughtful here, because there is considerable history and a lot of nuance. But just to offer a few stray thoughts
In the end content is what's important, style is just the dressing. As a reader, I like to have articles that look nice and are consistently formatted, but what I really want are articles that are well-written and informative.
Maybe the specifics of the guideline shouldn't matter match. Guidelines are supposed to be just that occasional exceptions may apply in principle a solid local consensus should be sufficient to override, though in practice it's complicated.
WP:STYLEVAR works just fine and helps to reduce acrimony, but its not always practicable. Could it work in the area of capitalization? Well in at least one area it already does. Would it work more widely? Difficult to say, not a lot of hard evidence either way.
No matter where you draw the lines there will always be edge cases, one choice or another will not eliminate good-faith disputes among contributors.
NYB once wrote of the potential for a demoralizing effect, I'm confident it exists, but judging its effects is harder. Some might remember the editors lost from WP Birds as a result of a capitalization controversy, but there were other factors at play there as well.
From the beginning the MoS has been one of those perennial dispute/disruption areas, its not everyone's cup of tea, and I certainly would not fault anyone for avoiding it. At the same time if you want to help build consensus you have to be involved. A common complaint is that MoS related discussions are not representative of the community as a whole because only the people who have the MoS as their focus show up in number since they are more likely to monitor Wikipedia talk:Manual of Style#Style discussions elsewhere. Maybe so, but there's nothing that prevents people who are mostly content editors from also monitoring the section and offering their assessments.
Maybe what is really needed is a broader cross section of the community offering input, and regardless of ultimate outcome, that's really desirable for all discussions. You can help. Sure you'll get unpleasant responses, don't let them get under your skin, be assertive not aggressive, stand your ground but be willing to hear others out as well. And know when to disengage. DGG once suggested the principle of limiting your comments in discussions that were primarily contentious rather than collaborative, let everyone have their say and see what shakes out.
Sorry for the length and disorganization, given time constraints I probably shouldn't be editing at all at present, but hopefully you found some of that useful. 184.152.65.118 (talk) 17:04, 6 April 2025 (UTC)
I agree with Blueboar's comment that what we actually do in RMs is not a literal application of the word "always". I've participated in...a few RMs and I've never understood the "always" in that sentence to mean "in every single source in existence", instead reading it as "grammatically should always be capitalized". In that regard, I support changing the wording of NCCAPS. But Wikipedia prefers to minimize capitalization, so the threshold cannot be 50%+1 of sources, it has to be a large majority. Not sure how best to express this in guideline-speak. Toadspike [Talk] 21:58, 11 April 2025 (UTC)
  • MOS:CAPS says Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia., I don't see why this shouldn't apply to article titles as well. Kowal2701 (talk) 21:20, 18 April 2025 (UTC)
  • 100%, nor 95%, nor 90%. It should be 50.1% is frankly absurd for a discussion of pure style. Unlike the name of a subject, for which experts in a field generally converge on a consistent name, capitalization is done stylistically by the editors of the newspaper or journal we use as a source. How could we possibly get a comprehensive survey of sources to enforce a 50% cutoff? For American Civil War, there are likely more journal articles than books mentioning the phrase, and more newspaper articles still. All use varying house styles, and the capitalization comes not from the historian but from the editor. Would we also include historic publications too? Surely it had been discussed in textbooks and the news as far back as the 19th century so those would need inclusion in our survey. This would be far too burdensome to enforce and the discussion would surely be biased toward the easily-accessible online news articles in AP style over print books in Chicago style. Always is fine for this. There's always one or two style guides someone can point to, but it avoids endless debate and the idea of somehow pretending there can be an unbiased and empirical sampling of every mention of the phrase. We have a house style we should enforce because it's consistent for readers and prevents debates and RMs. Dan Leonard (talk • contribs) 15:20, 22 April 2025 (UTC)

Nostalgia Wikipedia 25th anniversary

On January 15, 2026, Wikipedia will turn 25 years old. As part of the celebrations, it would be fine to have a new edition of Nostalgia Wikipedia for the future, with its content as of that date, as we have it from December, 20, 2001 (https://nostalgia.wikipedia.org/wiki/HomePage). The same mechanisms used by Wikipedia Version 1.0 Editorial Team could be used to remove vandalisms that are active at the very moment that the snapshot is taken.

It could be deployed online (as is the case with the 2001 version) and be also made available for download as a ZIM file.

This way, it would be easier to have a quick view of the evolution and improvement of Wikipedia over the years (2001, 2026, 2051...). Having a look at 2001 Nostalgia Wikipedia, the enormous progress made since then is really obvious. MGeog2022 (talk) 12:42, 18 April 2025 (UTC)

This is a good idea. Thryduulf (talk) 14:21, 18 April 2025 (UTC)
Meh ... that's what the Wayback Machine is for (and unlike Wikipedia's servers, it's actually designed to archive things). The overhead of permanently hosting a 2026 version of Wikipedia would be orders of magnitude greater than that of hosting the Nostalgia Wikipedia, not just because of the vast increase in database size but also because there were no inline images/videos/audio files in 2001. The other advantage of the Nostalgia Wikipedia is that it contains edits that aren't in the current Wikipedia database (or weren't until I and others imported them), which is much less likely to be an issue now. Re curating the entire current Wikipedia database for vandalism: that's logistically impossible and highly unrealistic. Graham87 (talk) 03:11, 19 April 2025 (UTC)
I understand your viewpoint. Media files could be taken from Commons (yes, some of them could be eventually deleted or overwritten), so only text would need to be saved (around 90 GB, I believe, that shouldn't be too much for WMF). The current financial and infrastructure (including backups, or more precisely, the absence of them) resources of Internet Archive (owner of Wayback Machine), make it difficult to assume its long-term permanence. Fortunately, Wayback Machine also takes content from external open projects such as Common Crawl, that stores many sites, including all or most content of English Wikipedia. Wikipedia's own full dumps also include revision history for all articles (history that is also available online for each article). Both Common Crawl and dumps with full history provide a guarantee of long-term preservation. My idea was about making this more accessible to the general public, rather than only preserving it. MGeog2022 (talk) 11:15, 19 April 2025 (UTC)
Media files wouldn't just be taken from Commons; they'd also have to be taken from local uploads (especially our non-free content, if we chose to include it in the hypothetical snapshot). Luckily our non-free content policy has become relatively stable. Graham87 (talk) 11:37, 19 April 2025 (UTC)
In the long term, it may be worth developing a feature to view the encyclopedia at a specific date into a MediaWiki extension (or client side Javascript extension that fetches the data using the API), else we may end up with masses of redundant copies. Simlar to how GitHub and its competitors allow viewing a repository at a certain commit.  novov talk edits 09:53, 20 April 2025 (UTC)
That's phab:T7877, which will celebrate it's 19th birthday next month. Thryduulf (talk) 10:40, 20 April 2025 (UTC)
It's a great idea. Let's hope it won't be necessary to wait for another 19 years before it's implemented. Many things can be learned from past versions of articles, but it isn't easy to navigate in hundreds or thousands of revisions. And many people aren't aware of this or of the option to read the article's past versions in Wayback Machine. MGeog2022 (talk) 14:37, 20 April 2025 (UTC)
Objects in git can't include content from another object without running a build process to generate the combined objects. Just considering the pages within English Wikipedia, every transclusion would have to be mapped to a specific version, and each time a transcluded page is changed, all of the pages transcluding it would have to be updated to the new version. (This mechanism would have also have to handle content transcluded from Commons.) This would massively increase the version history of pages (at least within the database) and the processing load for changing transcluded pages. Any pages, or specific revisions of pages, that have ever been transcluded couldn't be deleted from the database. It could be made to appear deleted to regular editors, which may add some complications if, for example, a template is created, used, no longer used and pseudo-deleted, and then a new template with the same name is recreated. The history of the two templates should remain distinct.
Alternatively, the MediaWiki software could be rewritten to take the git approach of versioning the entire repository as a whole. But this requires locking the entire repository for each commit being made, so there's always a distinct set of files being changed from one version of the repository to another. This doesn't scale well to the size of Wikipedia's editor base, and doesn't handle content transcluded from Commons. It would also be a fundamental change to how pages are managed. isaacl (talk) 17:51, 20 April 2025 (UTC)
Of course doing something which works exactly the same way as Git would be an impossible undertaking. I was thinking something more limited, where a page is only computed on-demand for a timestamp, where the last revision before that timestamp is fetched for page content and transclusions. If images/transcluded content is deleted, then it still isn't shown. Of course it wouldn't be fully accurate with moves/deletes/creations etc but it'd be more accurate than current page history and IMO "good enough" for a good portion of pages.  novov talk edits 10:56, 23 April 2025 (UTC)
Sure; the comparison to git just seemed inapt for what is achievable. A more limited capability would put the burden on browsing time and I'm not sure how usable it would be, given the slowness and inaccuracy. isaacl (talk) 17:41, 23 April 2025 (UTC)

What to do about prior draft decline notices

See also: Template talk:AfC submission § Template-protected edit request on 24 April 2025

If a draft is declined several times, users usually have to scroll a lot to see the content beneath all of those notices.

Idea A: Collapsible
Other AfC submission notices

Initially, I thought it would be neat if prior notices could be put in a collapsible box like how most talk page notices are encased within {{banner holder}}. I've experimented with putting decline notices in {{collapse}}, but when I set their width to match those of decline notices, it always causes decline notices to become significantly narrower, as if to maintain the presence of two gaps beside each.

It's possible for a box of this width to be positioned in the center...
Other AfC submission notices
...and still be able to fit in a collapsible box of equivalent width without becoming narrower.
Nevermind, draft decline notices already shrink like this. The {{AfC submission}} template also has small as one of its parameters, but it unfortunately hides the reason as well, so I'm sticking with an improved version of my other idea.
P.S. The blue background makes the box inside look gray. – MrPersonHumanGuy (talk) 01:21, 24 April 2025 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Idea B: Shrinking

Alternatively, a parameter (like small) could be added to {{AfC submission/declined}} that would allow for a notice to be shrunk down to a fraction of its usual height by hiding the {{blist}} and {{AfC submission/helptools}} stuff in order to reduce their redundant presence in repeatedly declined drafts. If implemented, such a parameter should cause an example blank notice to look like this when enabled:

Since other types of AfC submission notices usually don't appear below any subsequent AfC submission notices on drafts, it may not be necessary for us to be able to shrink those other types. I know these templates can only be edited by template editors, but these suggestions are specifically directed towards them too. – MrPersonHumanGuy (talk) 16:01, 21 April 2025 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I prefer the second idea, but I'd suggest something even shorter and with more information: "Submission declined by [user] on [date]: [Reason here]". Most of the decline message consists of general advice for the author, which I agree we do not need to repeat three or four times verbatim. I also like the idea of collapsing declines after rejection. Toadspike [Talk] 19:55, 22 April 2025 (UTC)
When used on drafts to indicate legitimate declines, they generally include user and date information on their bold text already, along with reasons if any are provided. I'm not saying those details should be removed or altered in any way, they should continue to appear as they would usually appear in a normal-sized notice. Are you saying that the reason should appear in the top text itself instead of a box below it? – MrPersonHumanGuy (talk) 01:18, 23 April 2025 (UTC)
Update: I just looked at a couple of drafts again and found out that my second idea has already been in fruition. However, if a draft is declined several times, then I think a template like an {{AfC decline notice shell}} might still come in handy if that were to ever be invented one day. On the other hand, being able to collapse/expand the reason-boxes wouldn't seem like a bad idea either. – MrPersonHumanGuy (talk) 01:30, 23 April 2025 (UTC)
Chiming in to say that the box with the text "It's possible for a box of this width to be positioned in the center..." and the collapsible box are currently broken for me on this page. It is going past the right bounds of the text and covering up the "appearance" options that show on the right by default. When lowering the width of my browser window, the box goes past the right edge of the window and at certain sizes the text in the box goes past as well. This is a tiny bit disruptive to reading, and I'm not gathering that it's an intentional effect. Nebman227 (talk) 14:20, 23 April 2025 (UTC)
In this case, {{hidden}} appears to be a better notice holder than {{collapse}}, except it would have to be rendered as {{hidden|ta1=center|style=font-size:100%}} so it doesn't shrink the text inside. I think it could still work especially if the collapsible/expandable template is also wrapped in an {{ombox}}.
The notices would still get narrower, but if a template editor adds a wide parameter to {{AfC submission}} just for such cases by simply replacing the string ombox with {{#ifeq:{{{wide|}}}|yes|fmbox|ombox}}, then the notices would be able to fill the container like this:
Yes, I figured out how to simulate the notice's reason box this time.
If the example code is implemented, editors wishing to make the notices less narrow in the notice holder would have to put wide=yes on each notice within. That aside, the source for a hypothetical {{AfC notice shell}} template may look like this:
{{ombox|image=none|style=background:#fee;|text={{hidden begin|title=Prior draft decline notices|ta1=center|style=font-size:100%}}
{{{1}}}
{{hidden end}}}}
– MrPersonHumanGuy (talk) 23:16, 23 April 2025 (UTC)

Grant move-subpages to template editor user group

Moved to Wikipedia:Village pump (proposals) § Grant move-subpages to template editor user group
 – There is an unanimous support in the discussion so far. However, I am moving the discussion to VPP to gain a wider consensus before filing a phab ticket. – robertsky (talk) 14:21, 24 April 2025 (UTC)

Preferences for Units

As far as I'm aware, Wikipedia does not have a system for converting measurement units to those of other systems. The idea is to add certain editing syntax to allow editors to specify which system of measurement is being used, alongside its amount. This could be used to add user preferences that apply globally, by converting the variables in that syntax to those of the user-selected measurement system.

For example, instead of writing: "Mount Everest is 29,031.69 feet (8,848.86 meters) in height," it would be written (in Wikitext), approximately as: "Mount Everest is [is ("is" being short for Imperial System); ft: 29,031.69] in height," which would then be converted to the user's preferred measurement system, or remain as the author wrote it in case of correspondence. I'm not very familiar with Wikitext, so the syntax may seem messy. Some English Monarch IV (talk) 10:31, 22 April 2025 (UTC)

And if the user has no preference, or is logged out, then they get metric ( "Mount Everest is 8,848.86 metres in height") right? Hawkeye7 (discuss) 10:34, 22 April 2025 (UTC)
It's the system most use, so yes. Although a more sophisticated system, perhaps using geolocation to determine the country of the user—and the popular system therein—could also exist. Some English Monarch IV (talk) 10:40, 22 April 2025 (UTC)
I think {{convert}} does some or most of what you want? For example:
Mount Everest is {{convert|29031.69|ft|m}} in height
renders as:
Mount Everest is 29,031.69 feet (8,848.86 m) in height
SunloungerFrog (talk) 10:45, 22 April 2025 (UTC)
Yes, the {{convert}} template should be used. As most measurements are approximate, and the degree of approximation is not often specified, I think it's best to use the sourced units first. As regards user preferences, I know of no people who are actually offended by seeing different units, and what would you do about the UK, where I buy petrol in litres but measure its consumption in miles per gallon? Phil Bridger (talk) 10:55, 22 April 2025 (UTC)
Yes, that does resolve most of my problems. Thank you for the information. Some English Monarch IV (talk) 11:47, 22 April 2025 (UTC)
Also see Wikifunctions, which could eventually replace {{convert}}. --Ahecht (TALK
PAGE) 17:21, 24 April 2025 (UTC)

Dynamic currency conversion

Currencies should be able to be converted to modern day equilavents dynamically rather than hardcoded NotQualified (talk) 18:00, 4 May 2025 (UTC)

Does Template:Inflation or Template:FXConvert do what you're looking for? Helpful Raccoon (talk) 18:36, 4 May 2025 (UTC)
Probably, I'll close this NotQualified (talk) 11:31, 5 May 2025 (UTC)

Clarifying BLPCRIME - Input Welcome

I've started a discussion proposing updates to the wording of WP:BLPCRIME to better reflect how editors apply it in practice. The current language, while well intentioned, has led to inconsistent interpretations, especially in borderline cases where a name is widely reported but the subject is not a public figure. You can view and join the discussion here: 

👉 Making BLPCRIME clearer and more consistent

The goal is to provide clearer guidance that acknowledges the nuanced spectrum of coverage and better supports editor judgment. Your input, especially from those experienced in BLP, dispute resolution, or policy drafting, would be greatly appreciated! Thanks Nemov (talk) 13:46, 25 April 2025 (UTC)

Color "additional considerations apply" as purple and "no consensus" as yellow at RSP

Currently, the "additional considerations apply" and "no consensus" statuses have the same "MRel" yellow grouping at WP:ReliableSourcesPerennial. This has caused some confusion for closers and those unfamiliar with what RSP actually is: a summary of past consensus and not any sort of guideline; "no consensus" makes a source's status "no consensus" instead of preserving the previous status. This also makes it a bit harder to differentiate "consensus for additional considerations" from "no consensus". Thus, I propose we add purple200 (#d9d0e9) as a color for "additional considerations apply". This color provides sufficient color contrast against foreground text and seems the most friendly to colorblind people. Aaron Liu (talk) 22:28, 15 April 2025 (UTC)

I agree with the general shape of this proposal but would reverse the colors. IMO "additional considerations apply" should be thought of as the actual step between WP:GREL and WP:GUNREL, with "no consensus" as a sort of "null" represented by a color outside the normal range. Loki (talk) 00:37, 16 April 2025 (UTC)
"No consensus" doesn't mean null guidance; it's indeed more caution than GRel and less caution than GUnRel. Aaron Liu (talk) 02:14, 16 April 2025 (UTC)
Notified: Wikipedia talk:Reliable sources/Perennial sources. Thryduulf (talk) 22:50, 15 April 2025 (UTC)
I don't see a need for this distinction. A source in yellow means spend some time thinking about this one. Purple would also mean spend some time thinking about this one... a meaningless distinction. Headbomb {t · c · p · b} 00:53, 16 April 2025 (UTC)
One has full consensus behind spending time thinking about this one and detailed directions on how to, as opposed to the far more general "we're not sure if this source is reliable, double-check". Contrary to Loki I feel like the former is on a different spectrum. Aaron Liu (talk) 01:06, 16 April 2025 (UTC)
"No consensus" doesn't mean "welp, no idea" - it means there was a discussion that failed to achieve a consensus that the source was reliable and it definitely has a lesser status than reliable - David Gerard (talk) 20:15, 18 April 2025 (UTC)
I agree. That's why it should be clearly distinct from "just make sure to check these specific things", don't you think? (By "not sure" I do mean what you meant; "not sure" is not "no idea", her means it decidedly falls short of reliable from community consensus.) Aaron Liu (talk) 21:02, 18 April 2025 (UTC)
No, this doesn't seem to match what these do - David Gerard (talk) 20:16, 18 April 2025 (UTC)
How so? Aaron Liu (talk) 21:02, 18 April 2025 (UTC)

I must ask: why did you start this discussion over here rather than at WT:RSP, which would seem the obvious first place? - David Gerard (talk) 23:34, 25 April 2025 (UTC)

I was planning to notify WT:RSP, though I forgot about it until recalling it after 20 minutes (as I was distracted in the middle of writing the opening comment); in fact I would've notified RSP had Thryduulf not thankfully notified it two minutes earlier: Special:Diff/1285808083.
This is at the idea lab for now to workshop the idea; to incubate new ideas or suggestions on general Wikipedia issues [...] for later submission for consensus discussion at Village pump (proposals. If there's nothing else I need to resolve (currently just to see what exactly are your concerns) I'll copy the opening statement here as the actual proposal for VPR. Aaron Liu (talk) 23:53, 25 April 2025 (UTC)

The Wikipedia:Community portal page sucks.

It sucks. There are way too many headers. It is impossible to navigate. Think if it were simplified, the immense joys that life would behold. JustMakeTheAccount (talk) 06:01, 23 April 2025 (UTC)

I think the headers are clear. Which headers are you confused by? Aaron Liu (talk) 11:55, 23 April 2025 (UTC)
I assume the OP wants it shorter. Perhaps, e.g., the "Events and projects" box could be just a link to a different page, instead of a list of events and projects. WhatamIdoing (talk) 02:25, 27 April 2025 (UTC)

Archives

There is a growing number of articles with a growing number of archives, and searching these archives is not easy. It would be really helpful if the archiving bot also could make a list of all closed discussions (requested moves, requests for comments etc) with a link to the discussion and the summary of the conclusions. So when a new editor comes along and requests a change, and an old editor thinks, but didn't we have this long discussion about it, when was it, a year ago? can easily find this discussion. Lova Falk (talk) 15:03, 24 April 2025 (UTC)

ClueBot automatically generates an index (e.g. User:ClueBot III/Master Detailed Indices/Talk:Switzerland) if it used to archive instead of the more popular Sigmabot. Many talk pages like Talk:Persecution of Uyghurs in China include a list of frequently cited discussions with an {{FAQ}}. Aaron Liu (talk) 15:55, 24 April 2025 (UTC)
For instance, look at Talk: African Americans. Rather regularly, editors propose a name change to Black Americans. When searching the archives for Black Americans, you get 27 results, about as many as there are archives. Search for Move, also more than 20 results. It would be so good to have a list of all Move discussions! Lova Falk (talk) 08:24, 25 April 2025 (UTC)
I just mentioned two methods you can have such a list. Another method using another bot to retrofit an index is described at Help:Archiving a talk page#Archive indexing. Aaron Liu (talk) 11:20, 25 April 2025 (UTC)
For "perennial" suggestions, a {{FAQ}} at the top of the page might be more useful. You could add a question like "Q: Have you ever considered changing this page name to Black Americans? A: If you want to request a page move, please read the prior discussions first: link link link link link link link link link link link link link link link link link link link link link link link link link link link link link link". WhatamIdoing (talk) 02:29, 27 April 2025 (UTC)

French Wikipedia Modèle:Articles liés

Hi there. Before making this request, I want to note that I attempted to replicate a good practice I found on the French Wikipedia. I have limited coding skills, and unfortunately, it did not work. On the French Wikipedia, they use hidden categories related to WikiProjects (or "Portails/Projets" in their case) to automatically create lists of all articles within the scope of that project/portal's main category, without the need for a bot. This list allows users to see changes related to the WikiProject's scope in one click.

For example, here on the French Wikiproject, they have a "Related Changes" page (called "Suivi") that uses this category type to populate the list. I find this tool extremely helpful, as it prevents one's watchlist from becoming cluttered. Please weigh in and let me know if we have something similar, and if we can adopt this tool. I am willing to help with whatever limited knowledge I have.el.ziade (talkallam) 13:38, 25 April 2025 (UTC)

We have project-specific RC lists: Wikipedia:WikiProject Software/Recent Changes Aaron Liu (talk) 20:40, 25 April 2025 (UTC)
@Aaron LiuLiu it's completely different. Yours shows Wikipedia space related changes, not article space. el.ziade (talkallam) 06:35, 26 April 2025 (UTC)
@Elias Ziade It was actually both; I just fixed it, please look at it again. Aaron Liu (talk) 14:17, 26 April 2025 (UTC)
On further review, that's only because many people put their "area of expertise" in a large, hidden table. Indeed we'd need a module to output a list of links first. Aaron Liu (talk) 19:36, 26 April 2025 (UTC)
The list is generated by transcluding Special:RecentChangesLinked. But that relies on putting every article into a hidden category like fr:Catégorie:Portail:France/Articles liés (which seems to translate to "Category:Portal:France/Related articles"). Here on the English Wikipedia we put WikiProject categories on the talk pages instead, so doing something like Special:RecentChangesLinked/Category:All WikiProject France pages will give you changes to those talk pages instead of the articles. To work like the French Wikipedia, we'd need to change to putting hidden WikiProject categories onto articles instead of talk pages. Or we could have a bot maintain a page linking every article for the project. Anomie⚔ 13:12, 26 April 2025 (UTC)
For the purpose of creating "lists of all articles within the scope of that project/portal's main category", surely it's a simple matter to get the list of talkpages and then remove the "Talk" prefix? CMD (talk) 13:26, 26 April 2025 (UTC)
Sure. But someone would have to actually do it and maintain it. And while doing it for a few mid-size WikiProjects is unlikely to be a problem, trying to listify something like Category:WikiProject Biography articles may run into issues and listifying hundreds of inactive projects' categories may be seen as wasteful. Anomie⚔ 13:56, 26 April 2025 (UTC)
Surely this is already done somehow in the background for Wikipedia:WikiProject/Hot articles config.json? Caps at 100,000, but seems to work. CMD (talk) 14:07, 26 April 2025 (UTC)
There used to be a tool/script/thing? for recent changes by project that stopped working maybe 8-10 years ago. In 2019 WP:Yorkshire started using an article list "/Watch All" for use with RecentChangesLinked. The list covers about 27,000 items (articles, templates, categories, etc.) doubled to 54,000 by talk pages, which I think is about as big as it gets before exceeding the post-expand limit. I have tried using this as a model for similar lists for a couple of other projects, and yes, there are problems with it in that the list needs to be manually updated for page moves and new articles, this can take a few hours, and I usually have to fix a few errors afterwards. EdwardUK (talk) 16:35, 26 April 2025 (UTC)
WPMED does this; see Wikipedia:WikiProject Medicine/Lists of pages/Articles. Try https://pagepile.toolforge.org/ or Wikipedia:PetScan to make a list. WhatamIdoing (talk) 02:39, 27 April 2025 (UTC)
@WhatamIdoing this method is manual. Someone has to feed a list periodically. el.ziade (talkallam) 07:27, 28 April 2025 (UTC)
We used to have User:Femto Bot#6: Update recent changes pages for projects doing this. WhatamIdoing (talk) 20:12, 28 April 2025 (UTC)

Metadata gadget as the default experience

Is there technical feasibility for including any part of the Metadata gadget in the default experience, or must it remain a gadget?

There seems to be a perennial wish amongst FA/GA contributors to make quality a more visible part of articles, for a number of reasons. The current experience, a topicon, seems to be considered too little. Previous discussions:

I think a good way to resolve this would be to get the FA, FL, and GA experiences from the metadata gadget into the default browsing experience for all users. Having at least the text A featured article from Wikipedia, the free encyclopedia at the top of FAs would certainly make it more explicit to readers, and the wikilink (with a statistical redirect) to Wikipedia:Featured articles would serve the purpose of explaining what the FA process is (many oppose !votes in the above discussions hinged on reader confusion) as well as draw in interested editors (many others in the above discussions mentioned becoming interested in editing after learning about FA/GA).

This would surely be a very contentious RfC if proposed, but I'm not even sure if it's technically possible in MediaWiki, since it currently works via a fairly slow JavaScript gadget. Does anyone know if it would be possible to integrate this experience more deeeply? Dan Leonard (talk • contribs) 21:03, 20 March 2025 (UTC)

I would support this RfC. Cremastra talk 17:17, 28 March 2025 (UTC)
I wonder what the WP:PERFORMANCE implications of running that gadget millions of times would be.
Perhaps of more importance: Do we really want Another stub from Wikipedia, the free encyclopedia on about half of the articles?
Combining the two concerns, I suggest that if folks want to celebrate the FA/FL/GA status more, that should be done with ordinary templates that can be added to the individual articles. For example, expand Template:Featured article. WhatamIdoing (talk) 01:52, 30 March 2025 (UTC)
Perhaps of more importance I think we do. Given we already have stub icons, adding that text under the title is just further incentive for more people to contribute.
Besides, stubs don't make up so many of the most-viewed articles, based on this data I just pulled out of my hat. Cremastra talk 03:06, 30 March 2025 (UTC)
I don't think that's actually an "incentive" for more people to contribute. WhatamIdoing (talk) 22:55, 31 March 2025 (UTC)
What do you think is an incentive for contributors, then? Redlinks, annoyning orange banners, tags, and stub categories are all at least partially aimed at getting people to hit the "edit" button for the first time. Cremastra talk 23:06, 31 March 2025 (UTC)
I don't think those are incentives. Some of them are invitations, but that's different.
For some of us, the incentive is making the internet suck less. Our response to someone being wrong on the internet is to add information where it can be found. For some of us, the incentive is a COI, or something next door to it. I could imagine, for example, someone getting tired of explaining some basic point about their industry/personal interest, so they try to share that information here. For others, it's because our friends are here, and you want to support your community's goals and get social status. Those people sometimes engage in Wikipedia:Hat collecting, but they also slog through difficult situations. Still others' incentive is to stave off boredom or to feel productive.
An incentive is what you get out of it. You don't get anything out of a stub tag. WhatamIdoing (talk) 00:48, 1 April 2025 (UTC)
The incentive to see an article say "A-class", the incentive to see an article not say "stub". Aaron Liu (talk) 01:01, 1 April 2025 (UTC)
So the incentive is that you get to feel pride at causing the removal of a badge of shame (except that none of our maintenance tags are supposed to be treated like badges of shame). Sure, I suppose that would motivate some people. WhatamIdoing (talk) 01:12, 1 April 2025 (UTC)
It ain't much more a badge of shame than the maintenance tag. Aaron Liu (talk) 16:27, 1 April 2025 (UTC)
Maybe. But the rating would be on every article, without an individual editor thinking that would be helpful for that particular article. And we do see people adding certain maintenance tags because they want to "warn the reader" or because they didn't get their way in a dispute. WhatamIdoing (talk) 17:41, 1 April 2025 (UTC)
Second. Greater visibility of our better articles is a great thing, and this gadget does it well. Would support this. A star or plus sign means nothing by itself, but the difference between "an article" and "a featured/good article" at least tells the reader something meaningful. JackFromWisconsin (talk | contribs) 03:47, 21 April 2025 (UTC)
GA, A, and FA are probably roughly fine more accurate than not, however the rest of the ratings are likely of more variable accuracy. A side-effect of them being not that impactful is they often aren't updated. Anecdotally, not a small number of articles are classed as stubs simply because they haven't been updated since the articles were stubs. Displaying these ratings to the reader may give an air of officiality, giving the ratings a meaning we don't want to give them ourselves. CMD (talk) 01:23, 1 April 2025 (UTC)
I'd like to reiterate that this request is for technical feasibility of an experience similar to the metadata gadget using MediaWiki, not running the current JavaScript gadget. I'd also like to reiterate that it's specific to good and featured content only, as it derives from previous discussions. On the technical feasibility side, I think it'd require mw:Extension:CustomSubtitle embedded within {{Good article}} and {{Featured article}}, but it'd likely require security updates to restrict its use. Dan Leonard (talk • contribs) 15:40, 10 April 2025 (UTC)
You don't need a consensus discussion to investigate making a software thing without considering whether the community would want it. It's something developers are usually encouraged to just do; try MediaWiki channels if you need help since VPT deals little with non-enwiki-specific backend stuff. Aaron Liu (talk) 16:06, 10 April 2025 (UTC)
mw:Project:Support desk might be the right place to ask questions about whether that extension would require changes. WhatamIdoing (talk) 17:28, 10 April 2025 (UTC)
I'm not asking for development on anything, I’m asking if anyone knows whether it's possible at all. Dan Leonard (talk • contribs) 18:30, 10 April 2025 (UTC)
Anything is possible as long as you develop it. If you mean whether it's possible without changing the current backend (WMF) setup and do not want to involve the usual questions on "should we", that's usually a question for VPT. Using CustomSubtitle would modify the backend. A much more efficient way would probably be modifying mw:Extension:PageAssessments to add a parser function that returns the page class and then putting that parser function in MediaWiki:Tagline. Aaron Liu (talk) 21:28, 10 April 2025 (UTC)
Oh cool, thanks, that's exactly what I was looking for! I didn't realize there was a MediaWiki extension behind assessments, I thought it was just a relatively simple template design where the |class= parameter of {{WikiProject banner shell}} changes the talk box text and image. I'll read up on the PageAssessments extension and see what's possible there, and then if I can do it myself I'll re-propose a more complete idea here or at one of the other village pump sections. Dan Leonard (talk • contribs) 21:42, 10 April 2025 (UTC)
No problem! It was just a template, but later the PageAssessments tool was reason so that e.g. you can query assessments by API better and the template was adapted to support PageAssessments. Note that it does not have said parser functions needed yet and you'll have to code or get someone to code the parser functions. Aaron Liu (talk) 21:55, 10 April 2025 (UTC)
Looks like Module:Page assessment has already been implemented to do just this. Given that modifying the sitewide tagline would run this function a lot, would a parser function built directly into the MediaWiki extension be more efficient, or is this Lua module essentially the same thing? It doesn't look like it's using the API, and is just parsing the wikitext, but I'm not well versed in Lua to be certain. Dan Leonard (talk • contribs) 22:23, 10 April 2025 (UTC)
Evad37 wrote the module, but has been off wiki for about two months. You should ask technical questions like this at Wikipedia:Village pump (technical). WhatamIdoing (talk) 03:12, 11 April 2025 (UTC)
As it's trivial retrieval of information, making it a parser function would almost always be better. And getting the wikitext of the associated talk page is effectively querying the API, except it's querying all the wikitext instead of just the pre-stored page assessment class. Aaron Liu (talk) 13:27, 11 April 2025 (UTC)
technical feasibility. Consider posting at WP:VPT to get the opinion of technical editors. If you want a new user script made that just has some of the capabilities of the existing gadget, consider requesting one at WP:US/R. Any request to add a default gadget to every page for both logged in and logged out editors that queries the API like this one probably does would probably be declined -- that would just create a ton of API traffic. It'd be possible to do this more efficiently with a modification to MediaWiki code that allows this to be properly cached, but it is probably too enwiki-specific to attract the interest of developers to put it in MediaWiki core or an extension. –Novem Linguae (talk) 22:03, 28 April 2025 (UTC)
Technical note after looking at MediaWiki:Gadget-metadata.js: looks like this doesn't use the Action API, but still queries an API using the following code: mw.config.get("wgScript") + "?title=Talk:" + mw.util.wikiUrlencode(mw.config.get("wgPageName")) + "&action=raw&section=0". –Novem Linguae (talk) 22:07, 28 April 2025 (UTC)

Discourage reflist usage in favor of the Cite Extension's parser tag hooks

Moved to Wikipedia talk:Citing sources § New proposal: deprecate {{reflist|refs= in favor of <references>?
 – Undoing fractured discussion. Dan Leonard (talk • contribs) 03:18, 30 April 2025 (UTC)

iPad models consistency issue

Hello. I'm TzarN64, and i've noticed a consistency issue with iPad models lead: Let's take a look here:

iPad Pro models' lead typically begin as:

"The third generation of iPad Pro is a line of tablet computers developed and marketed by Apple Inc" Two models, with a 12.9 inch or 11 inch screen, were both announced on October 30, 2018, and were available to purchase on November 7. This generation of iPad Pro..."

.....while other iPad articles begin as:

"The iPad (10th generation) (also referred to as the iPad 10.9-inch) is a tablet computer developed and marketed by Apple Inc. as the successor to the ninth-generation iPad. It was announced on October 18, 2022...."

Do you see the consistency issue in the lead? iPad Pro articles begin as "The X generation of iPad Pro" while other iPad related articles begin as "The iPad (X generation). My idea and proposal is that we make all iPad leads look more consistent, Here's my idea to the solution of this problem:

Instead of beginning with "The iPad (10th generation)", it instead follows the same lead as "The third generation of iPad Pro". So instead its "the 10th generation of iPad". How do you all feel about this proposal? Should it be the other way around, or should it be a different lead? Let me know. TzarN64 (talk) 13:16, 28 April 2025 (UTC)

I think your idea for changing the lead sounds good. Would make things a whole lot more consistent. 🎸✒️ ZoidChan23 🥁🍕 19:30, 28 April 2025 (UTC)
Consistency across articles is not actually a goal. WhatamIdoing (talk) 22:58, 28 April 2025 (UTC)
In my opinion, it makes things look much better. I get it’s not necessary, but it’s better for all iPad models to have a consistent lead. TzarN64 (talk) 00:48, 29 April 2025 (UTC)
Better in what way? It could make them all look like they were written by a mindless robot, but IMO that's not actually better. WhatamIdoing (talk) 01:37, 29 April 2025 (UTC)
They belong to the same group of articles. Making them have different leads looks off. You look at, say a Mario Kart related article. They all have similar leads:
"Mario Kart Wii is a 2008 kart racing game developed and published by Nintendo for the Wii. It is the sixth installment in the Mario Kart series, and was released in April 2008" and "Mario Kart 8 is a 2014 kart racing game developed and published by Nintendo for the Wii U."
Why are the iPads any different? TzarN64 (talk) 02:02, 29 April 2025 (UTC)
Making them have different leads looks like they were written by a human who was actually interested in the subject, instead of someone filling in the blanks on a boilerplate form. WhatamIdoing (talk) 01:43, 3 May 2025 (UTC)
This difference (or inconsistency) doesn't worry me in the slightest. However, the second version is soporific. "[R]eferred to as" here just means "called", and the reader will assume that the Xth generation of Y is "the successor" to the (X−1)th generation of Y unless informed otherwise. -- Hoary (talk) 22:46, 28 April 2025 (UTC)
I could live with either and am not swayed one way or another.
Edit (editor dropped most of my reply):
I'm more so concerned with potential pitfalls regarding iPad as "a product group" vs. iPad as "a product line within that group".
E.g. unintended implication of certain hierarchies "fourth generation of iPad > third generation iPad Pro".

Also, if consistency does prove to be important, I'd suggest we come up with something that works independently of product lines and potential new iterative names Apple's marketing team could come up with (e.g., The New (New) iPad, iPad 12/13/14/15/16/etc, iPad SE, iPad 17S, etc, etc).

I don't see the need for this discussion or the need for consistency, but I'm also not against it.
As long as whatever solution comes out of this ends up being well thought out and takes into account stuff like what I mentioned above. Turquoise (talk) 16:31, 29 April 2025 (UTC)

Bias in reliable sources

If some reliable source which has good editors. high standard reporting, good journalists, but show bias in some religious conflicts or political issues, then what can be done?

In political conflict they will allow spokesperson of one political party to write articles in their website and then will not listen to the other side.

In a country if politicians of one political party is arrested for murder they will cover it, but another politician from a different party is arrested for rape they will not cover it.

Community A kills community B they cover it. Community B kills community A, they don't cover it. They cant be accused of fake news.

Large scale violence and deaths in poor countries will get zero coverage while two three people stabbed in developed countries will get huge coverage. 2409:40E1:106D:DEAC:AC0C:C273:A383:8CA (talk) 03:34, 25 April 2025 (UTC)

This is a very good question. Our "reliable sources" rule does not prevent entry of bias into articles. That is something editors need to counter if they are so inclined. Coretheapple (talk) 23:00, 29 April 2025 (UTC)
It depends on the source and if you mean bias or viewpoint. 149.126.89.48 (talk) 22:18, 4 May 2025 (UTC)
All that can be done is to find sources that cover the other side. This is mainly a journalism problem, not a Wikipedia one. NotQualified (talk) 11:33, 5 May 2025 (UTC)
Wikipedia cannot force a media outlet to fairly cover all sides of a topic, or to equally report on events geographically or politically. If a media outlet is partisan(i.e. by reporting crimes committed by the opposition party but not the party they support) but otherwise has journalistic standards of fact checking and editorial control, that generally would not prevent the use of a source of Wikipedia. The fairness of their reporting is an issue that you would need to take up with the outlet directly.
Now, if a source is so partisan that they do not have basic standards of journalism and fact checking, and makes things up out of whole cloth(meaning, with no basis), that would be an issue to discuss at the reliable sources noticeboard. 331dot (talk) 11:39, 5 May 2025 (UTC)

Fair use file list

Similar to the Bad image list, there should be a fair use file list for files put under fair use. This is to prevent fair use files from being transcluded on articles where they don’t belong. HouseLiving roomDIY Fixings 23:44, 5 May 2025 (UTC)

All non-free files are required to use some variation of Template:Non-free use rationale. All files that use such a template are put into Category:All non-free media. A bot already patrols file additions for such files and automatically removes them. Thanks for suggesting, though! Aaron Liu (talk) 01:26, 6 May 2025 (UTC)

proposed template, for contentious topic areas

initial idea

i have drafted the template below, for use with Israeli-Palestinian articles, but it could work with any highly contentious topics. what do you think of this?

Sm8900 (talk) 20:46, 21 April 2025 (UTC)

I feel like that goes against Wikipedia:No disclaimers. And any article that has content issues may already use the relevant maintenance tags. (Also, I love the second paragraph, but surely you know that cannot represent Wikipedia.) Aaron Liu (talk) 15:17, 23 April 2025 (UTC)
@Aaron Liu, fair enough, those are valid points. to address your last point, i added the tag [just kidding]. maybe that helps? Sm8900 (talk) 15:27, 23 April 2025 (UTC)
It doesn't. Aaron Liu (talk) 16:54, 23 April 2025 (UTC)

comments

post comments below. --Sm8900 (talk) 15:15, 23 April 2025 (UTC)

Although this is a fun idea, it is in no way of the proper tone for a world-wide audience, let alone making WP appear as a serious resource. It is self-contradictory, contradicts multiple guidelines/policies, and is disrespectful to good-faith editors. DMacks (talk) 15:38, 23 April 2025 (UTC)
@DMacks let me try to address your points. i do hear your concerns, and I absolutely do respect all of them as important and valid.
  • no way of the proper tone for a world-wide audience, let alone making WP appear as a serious resource.
    • you have a valid point here; however i would suggest a slightly different take. i feel this promotes transparency to some extent, by taking a highly contentious and volatile editing area, and openly stating that one method used to cover the topic of this conflict, is by being fair to some degree to both sides.
  • self-contradictory, contradicts multiple guidelines/policies
    • a valid concern, but what you are perhaps omitting slightly is that in fact, real compromise is totally valid, especially when two groups of competent editors each have massively different versions of the essential facts for an important current topic.
  • is disrespectful to good-faith editors
    • since this references my own personal feelings, let me say that a) i appreciate you expressing your sincere concerns on this, b) i absolutely do respect good-faith editors; c) since i am in fact an experienced editor and a good-faith editor, my own ideas above are in fact full in good faith, so perhaps i would ask for that consideration as a courtesy, based on WP:AGF.
Again, i do sincerely appreciate your concerns,, and your insights above. thanks. Sm8900 (talk) 20:43, 23 April 2025 (UTC)
It would cause way more confusion than the little benefit it does. Why do we need this when we can already do maintenance tags, especially since that banner would need to be manually added to every page anyway (without going through the bureaucratic process of asking WMF to install an extension)? And Wikipedia:No disclaimers has guideline-level consensus backing; the little amount of dispute should tell you how much this rule is respected.
(Also, I think DMacks only said that the wording was disrespectful and didn't mean to imply you meant to be disrespectful.) Aaron Liu (talk) 00:43, 24 April 2025 (UTC)
Correct, sorry if I wasn't clear. DMacks (talk) 01:47, 24 April 2025 (UTC)
@DMacks, ok appreciate your helpful clarification on that. and thanks @Aaron Liu. Sm8900 (talk) 17:53, 24 April 2025 (UTC)
You can't be serious. jlwoodwa (talk) 21:32, 23 April 2025 (UTC)
@Jlwoodwa, i am serious, and don't call me Shirley. (you didn't, but my reply seems a bit funnier, if i reply as if you did.) Sm8900 (talk) 18:03, 24 April 2025 (UTC)
@Jlwoodwa, the note of whimsy/humor/jocularity actually in fact does serve a valid purpose; namely, using humor to restore the tone of collegiality/cooperation which wikipedia relies upon, to keep our work and our efforts going on a positive basis. Sm8900 (talk) 19:49, 24 April 2025 (UTC)
Note that this spawned from a very tongue-in-cheek post made by Herostratus at Wikipedia:Village pump (miscellaneous)/Archive 82#Just shoot me; possible hatnote template, for Israel-Palestinian articles. And I have to say that the template in the original joke post was much more accurate. Thebiguglyalien (talk) 🛸 05:09, 24 April 2025 (UTC)
I'm not a fan of the suggestion there is a true NPOV that can be expected, rather than NPOV being a idealistic goal we try and figure out to varying degrees of success. CMD (talk) 05:15, 24 April 2025 (UTC)
Personally, I find the editors who make holier-than-thou vagueposts in a "pox on both your houses" vein to be the most annoying part of this topic. If you see a problem with an article or with an editor's behavior, address it directly. Moreover, the suggestion that it is two distinct groups at odds with each other in this area also belies a very simplistic understanding of the conflict; if we're talking about discrete positions, especially with respect to how an encyclopedia treats the topic, the number is closer to 20 (or possibly even 200) than 2. signed, Rosguill talk 14:34, 24 April 2025 (UTC)
@Rosguill ok, good points, i have revised it, based on your suggestion on amount of differing groups. Sm8900 (talk) 17:54, 24 April 2025 (UTC)
@Rosguill, also please note: I said "for truly updated information"; i never said the article itself is invalid, i simply meant that the article's content may lag slightly, due to contentious issues that need to be resolved, and other reliable sources might be more timely. Sm8900 (talk) 17:59, 24 April 2025 (UTC)
There is a true NPOV as the average of RSes that exist, but this template's "both sides" reeks of Wikipedia:False balance. Aaron Liu (talk) 14:45, 24 April 2025 (UTC)
I don't know about that. Even taking that as true and the goal of NPOV, anyone saying they can average all RS that exist on Israel and Palestine is not telling the truth. Also, as Rosguill notes, you're looking at some sort of n-dimensional hypercube of views, and there's only so far you can navigate that in written language. CMD (talk) 16:38, 24 April 2025 (UTC)
Of course; everyone has their own subjectivity. That doesn't mean NPOV isn't what we strive for. We only navigate views with Due weight for good reason. Aaron Liu (talk) 13:12, 25 April 2025 (UTC)
@Chipmunkdavis, do you support this idea? I want to make sure i totally understand your views. Sm8900 (talk) 18:45, 30 April 2025 (UTC)
Finding ways to convey the goal of articles is always a useful exploration, but banner blindness makes it difficult. CMD (talk) 00:19, 1 May 2025 (UTC)
This whole thread is very Sarcastaball. ScottishFinnishRadish (talk) 17:54, 24 April 2025 (UTC)
@ScottishFinnishRadish, actually... it so happens that that's not such a bad metaphor, i.e. for the initial item that i was trying to address in fact. so thanks! Sm8900 (talk) 18:00, 24 April 2025 (UTC)
Not familiar with that as a metaphor but I think that sometimes we need to IAR and get to the heart of a problem. I believe the problem in this topic area is a fundamental failure of our NPOV guardrails. Honesty is the best policy. Coretheapple (talk) 19:49, 24 April 2025 (UTC)
Agree Sm8900 (talk) 19:52, 24 April 2025 (UTC)
While this template would feel out of place on an article, something like it (a reminder to stay calm and seek another topic area if one is stressed) might be useful on the Talk page. Currently all we have is a big warning notice with SHOUTY BOLDED CAPITAL LETTERS, which may send the wrong message in what is perhaps the most contentious of contentious topics. -insert valid name here- (talk) 21:30, 5 May 2025 (UTC)
@-insert valid name here-, yes!! Agree!! ok, i will try to proceed on that basis. Sm8900 (talk) 13:09, 6 May 2025 (UTC)
Probably should just add that to TM:Controversial (current version depicted):

Also, be aware of banner blindness. Aaron Liu (talk) 16:19, 6 May 2025 (UTC)

possible closing

I appreciate the replies here. i would welcome any further comments if anyone wishes to do so. there have been some comments in favor, and some against. based on that, i plan to move ahead with this template. please note that obviously the community will have the final say on whether this template should be retained or not. i will be glad to have any feedback, once this is set up. i appreciate all input here. thanks. --Sm8900 (talk) 18:00, 29 April 2025 (UTC)

There's only one in favor vs. everyone else against, and I'm think you're confused as to what the idea lab is; check the banner at the top of this page. Aaron Liu (talk) 19:16, 29 April 2025 (UTC)
i think that @Coretheapple and @Chipmunkdavis were both favorable to this idea. Sm8900 (talk) 21:05, 29 April 2025 (UTC)
I don't see where CMD expresses his support. Aaron Liu (talk) 21:13, 29 April 2025 (UTC)
i do understand, as stated above, the purpose of this page is: The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at "Village pump (proposals).". so your point on that is totally valid. Sm8900 (talk) 21:07, 29 April 2025 (UTC)
Drop me a line if you're pursuing it. I'd like to see what happens to your idea (not that I have any doubt on that score). Coretheapple (talk) 22:59, 29 April 2025 (UTC)
I doubt this is capable of getting consensus. It's just not the correct vibe/tone for IP or for article space. I would recommend not putting too much time into it. –Novem Linguae (talk) 09:41, 5 May 2025 (UTC)

Should admins be extended confirmed?

When extended confirmed was created, I assume admins were automatically exempted from it because adminship came bundled with things editors needed from EC locked pages. Anytime someone is granted admin, XC is also removed from them.

Since then, XC has also become a stand in for "This editor is experienced enough on Wikipedia". To start an WP:RFA or be an admin, the formal requirement requires XC. As does being able to vote in RFA or WP:AELECT.

So I think logistically it just makes more sense for every admin and ex-admin to be granted XC explicitly. And for all future admins to keep the XC right. It does not change anything major, but would make writing certain rules and tools more convenient from now on. Right now there's a lot of "XC but also admins, but also former admins" exceptions needed to be thought of. Soni (talk) 07:01, 28 April 2025 (UTC)

Adminship comes bundled with a lot of things, including not only extendedconfirmed but also IP block exempt. I don't think we should explicitly grant extendedconfirmed to admins unless we want to have admins without extendedconfirmed. (Autopatrolled was removed from the admin toolkit a couple of years ago because we did not want it bundled anymore). We should just ask bureaucrats to always turn on extendedconfirmed when they desysop someone. —Kusma (talk) 07:39, 28 April 2025 (UTC)
My point is that right now pages like WP:RFA have to say Other comments are welcomed in the general comments section at the bottom of the page, and comments by editors who are not administrators or extended confirmed may be moved to this section if mistakenly placed elsewhere. to be inclusive, as opposed to just "extended confirmed".
Likewise, there are things like WP:AELECT where you explicitly need to allow sysop and XC for suffrage checks. But also you'd have to check all former admins who don't have XC.
The last usecase I have seen for something like this, is when someone was theorycrafting edit notices in WT:RFA, where they use code that only gets shown to XC editors. Admins would not be able to see that either. (I do not recall the exact discussion, or if it was a reasonable idea in the first place)
So I'm suggesting some sort of clarity or simplification. If all desysopped editors are now given XC and also all pages just say XC, I think that works too. Soni (talk) 07:47, 28 April 2025 (UTC)
Seems this should be fixed by simplifying the notice by removing the explicit mention of administrators, and a note at the page describing extended confirmed saying that all admins are understood to be extended confirmed. Former admins who are not extended confirmed are an extreme and rare edge case that should not be used to make general notices more confusing. —Kusma (talk) 09:29, 28 April 2025 (UTC)
Additionally, our crats have been meticulous in regranting XC rights to admins whose flag was removed for one reason or another. – robertsky (talk) 09:42, 28 April 2025 (UTC)
Luckily our policies and guidelines and instructions are simply statements of best practice interpreted by common sense, rather than statute law that has to be crafted to take care of rare exceptions. Any former admin who is not extended confirmed can request that right if it is needed. Phil Bridger (talk) 12:52, 28 April 2025 (UTC)
  • (extendedconfirmed) is the name of a permission that allows for editing through a protection level. Multiple user access groups contain this permission, including the administrator group. If you want to describe something that applies to anyone with this permission call it by the permission name, not the group name. — xaosflux Talk 13:26, 28 April 2025 (UTC)
    Both the user group and the user right are called extendedconfirmed. Special:ListGroupRights. I think this is the source of the confusion. Admins have the user right but not the user group. –Novem Linguae (talk) 13:33, 28 April 2025 (UTC)
    This is exactly it. I was not aware of the userright also sharing the same name, so was under the impression it was a generic part of the sysop toolkit that allowed you to override the ec permissions. Soni (talk) 16:00, 28 April 2025 (UTC)
    Which is especially confusing since so many of our help pages use "right" when they mean "group" and vice versa (such as Wikipedia:User access levels, which explicitly says that rights and groups are the same thing: A user's access level depends on which rights (also called permissions, user groups, bits, or flags) are assigned to accounts.). --Ahecht (TALK
    PAGE    )     14:13, 7 May 2025 (UTC)
    Thanks for editing that sentence and replacing right with group. I've also started an RM for that page: Wikipedia talk:User access levels#Requested move 7 May 2025 –Novem Linguae (talk) 15:42, 7 May 2025 (UTC)
  • Assigning the explicit user group to administrators is technically redundant, and even if extendedconfirmed were unbundled from adminship, there are basically no circumstances in which someone would be an administrator but not EC. Instructions for certain processes can refer to the technical permission (and therefore members of the sysop and EC groups) or the explicit EC group; even if they refer to the latter, I think saying "and administrators" is fine. Giraffer (talk) 13:52, 28 April 2025 (UTC)
I'm confused. How many admins do we have who have less than 30 days' tenure and less than 500 edits? Ritchie333 (talk) (cont) 14:28, 28 April 2025 (UTC)
Five. —Cryptic 01:37, 29 April 2025 (UTC)
If they already had 30/500 at the time the extendedconfirmed group was first created, the system won't assign it automatically. So templates and edit filters become slightly more complex, because you need to consider both groups. Suffusion of Yellow (talk) 22:23, 29 April 2025 (UTC)
I believe that is correct, even for former admins.
I haven't gotten time to run a WP:QUERY myself to go in depth, but @Novem Linguae was kind enough to start a basic query. It's all editors who are currently not EC, above 30/500, but also not admin or bots. It has 27510 editors, but there's a bunch of data points we should have excluded (globally banned users)
We should be able to make similar queries for "admins who do not have extendedconfirmed group".
We can also filter out these 27K to remove locked or banned editors perhaps? I can see from eyeballing there's a sizable number of "non admin non EC" in that list, but I can't tell how many. Soni (talk) 04:44, 30 April 2025 (UTC)
There's a de facto third criteria to extended confirmed. 30 days tenure, over 500 edits, and at least one edit since extended confirmed was introduced. Yes there are a bunch of long dormant accounts that are not extended confirmed despite meeting 30/500, but if one leaps back into life and makes their first edit in over a decade, they become extended confirmed. So no need to require them to use that first edit to request extended confirmed, deleting twenty years of bot postings on their talkpage works just fine. This all relates to how extended confirmed was phased in, if you met the criteria you got the right on your next edit. Apparently updating all accounts that met the criteria at the same time would have discommoded several server kitties. ϢereSpielChequers 08:53, 5 May 2025 (UTC)
That actually makes a lot of sense, I suspected there's something like that in place, but didn't have confirmation. I have been slowly working on WP:QUARRY queries to confirm how many editors in each "category" here exist, but the queries are just unoptimised enough that being exhaustive is hard. So far my findings are -
  • 27512 editors have 500/30 but not Extended Confirmed role (and aren't admins )
  • Of these, 5605 editors are currently blocked (Needs clarity if that's indef/global lock/any block).
  • This is not a universal protocol for blocked editors, as 7039 of them also do have EC explicitly.
  • Of all editors with extended confirmed group, None are admins.
  • This presumably leaves another 22000 editors left to be checked.
  • Of the editors who do not have 500/30,
  • 5 are admins
  • 300 are extended confirmed
I think the "Last edit after 5 April 2016" (when EC was introduced) and "were former admins" categories will prune this 22K number down further, I just am not yet convinced it covers everyone fullstop.
Soni (talk) 04:36, 6 May 2025 (UTC)


I agree with Xaosflux. Administrators are extended confirmed users, regardless of how the permission is assigned. The documentation needn't treat them as a non-overlapping category. isaacl (talk) 15:15, 28 April 2025 (UTC)

The WMF hands admin rights out to some staff accounts, including two of the five admins who don't meet 30/500 (look for (WMF) here). I'm pretty sure at least one of the bot accounts that has an admin flag has less than 500 edits (hundreds of thousands of deletions or blocks don't qualify you for extended confirmed), but bot accounts always have a non bot account associated with them. I suspect that those two sources account for our five admins who don't meet extended confirmed. No need to give either extended confirmed status. ϢereSpielChequers 09:32, 5 May 2025 (UTC)

Transgender Userbox

I know it already exists but I kinda made one.. I'm very bored. What do ya'll think..?

This user is Transgender.

MetaMeth0906 (talk) 02:50, 12 May 2025 (UTC)

Cool but irrelevant to this forum. Idea lab is not the “off-topic” or “random” section. Dronebogus (talk) 12:04, 12 May 2025 (UTC)
Oh, I didn't know, sorry. MetaMeth0906 (talk) 13:51, 12 May 2025 (UTC)
That’s okay Dronebogus (talk) 14:22, 12 May 2025 (UTC)
New userboxes can be listed at Wikipedia talk:WikiProject Userboxes/New Userboxes. Cambalachero (talk) 14:53, 12 May 2025 (UTC)

Utility of coordinates

It's pretty standard for articles concerning a place or localized event to include coordinates, yet how many readers actually comprehend them? Oddly, it's also very common to have coordinates duplicated at the top of an article and again in the infobox (see White House. I've occasionally tried to remove them, but I'm typically reverted with a status quo rationale. Are they even needed? Are they just unnecessary infobox clutter? Do others feel the same way? ~ HAL333 07:00, 8 May 2025 (UTC)

The coordinates give a rough idea where something is (southern hemisphere or northern for a start) and link to maps, which is very useful. On mobile, I only see one set of coordinates on White House, those in the infobox. —Kusma (talk) 09:38, 8 May 2025 (UTC)
There is a second set of coordinates above the infobox, near the "IP protected" lock symbol. Can't the reader simply read the lead? If it says, for instance, "Washington, D.C.", it should be immediately clear that it's not in the Southern Hemisphere... ~ HAL333 15:19, 8 May 2025 (UTC)
You're using a desktop skin. Compare that against what you see in https://en.m.wikipedia.org/wiki/White_House WhatamIdoing (talk) 01:21, 15 May 2025 (UTC)
For things with a physical location, there's utility with or without comprehension of coordinate systems isn't there? There's GeoHack and probably all sorts of things out there that use the Geosearch module. And readers can copy/paste them into whatever they want. Sean.hoyland (talk) 09:51, 8 May 2025 (UTC)
Alright, but are duplicated coordinates needed? ~ HAL333 15:19, 8 May 2025 (UTC)
The Geosearch module only needs the display=title option in the template according to Template:Coord#Display, but mobile users can only see the display=inline coords, so I guess it is only duplicated on desktops. That might explain why display=inline,title is common...maybe. Sean.hoyland (talk) 15:45, 8 May 2025 (UTC)

External conditional bibliography lists

Documentation software such as LaTeX often includes facilities, such as BibLaTeX with Biber, that allow a document to pull references from an external file even if it does not use all of the references in the file. It would be useful to have a similar facility in wiki with the following characteristics:

  1. An easy way to create external lists with
    1. entries in a standardized formats, possibly using new or extended templates
    2. Metadata automatically filled in if possible
  2. An easy way to extract items selectively from multiple external lists
  3. Support for both global and local lists, including lists local to a project.
  4. Support for nesting beyond two levels
  5. All of the functionality of current CS1 and CS2 templates, but new names and syntax are fine.
  6. Forward and backward links for nested references.

It's not a requirement, but the ability to import from exiting bibliography files would be nice, including but not limited to BibLaTeX. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:17, 12 May 2025 (UTC)

This sounds like the sort of thing you can do at least much of with Wikidata? Thryduulf (talk) 15:42, 12 May 2025 (UTC)
Note that transcluding from Wikidata is VERY limited. They are still considered unreliable. Blueboar (talk) 16:02, 12 May 2025 (UTC)
Ideally, yes, but enough people around here hate Wikidata that {{cite Q}} is likely to remain controversial for some time. At one point there was also {{Cite doi}}, which had a bot creating local subpages for every doi used with the template, but that's long gone. Anomie⚔ 00:17, 13 May 2025 (UTC)
Why do you want to do this? WhatamIdoing (talk) 01:32, 15 May 2025 (UTC)

Locking banned user talkpages that aren’t being legitimately used

Inspired by Wikipedia:Administrators' noticeboard/Incidents#User talk page ownership of an ArbCom-banned user, I was wondering if there is any support for the idea of admin-only locking the userpages of banned or indeffed editors who either had their talk page access revoked or have not used their talk page (legitimately or otherwise) in a very long time (maybe normal ban/block appeal period + grace period?). If they’re not using their talk page or can’t use it, then the only thing it’s ever going to be used for is a) gravedancing, b) denialist fan mail, or c) useless automated messages they obviously aren’t reading but can’t unsubscribe to. I think shutting down these talk pages which no longer serve any legitimate purpose would be beneficial to the community, if only slightly. Dronebogus (talk) 12:16, 12 May 2025 (UTC)

For Arbcom or WMF banned users I agree, but for normal indeffed editors I'd disagree, since we don't know if or when they want to return and the talk page is the normal way to appeal for indeffed users. Nobody (talk) 12:30, 12 May 2025 (UTC)
Maybe it could only apply to indeffed users who lost talk page access. Dronebogus (talk) 12:34, 12 May 2025 (UTC)
That makes sense, but if you want to do it retrospective, you'd probably need a bot to go do it, as I suspect there are hundreds, if not thousands, of accounts that would be affected. Nobody (talk) 12:38, 12 May 2025 (UTC)
I don’t think that’s necessary unless it’s a clear case of abuse. Most of these users are long forgotten and either don’t want to be remembered or would appreciate any crumb of negative attention they can get. Dronebogus (talk) 14:05, 12 May 2025 (UTC)
reiterating my Support of this idea here 𐩣𐩫𐩧𐩨 Abo Yemen (𓃵) 13:00, 12 May 2025 (UTC)
  • Semi-support. I think it should be allowed for any admin to speedily protect the user talk page of any blocked or banned editor which is being abused (by the blocked editor or others) without the need for discussion, as long as instructions are added for how to appeal the block (i.e. email arbcom/UTRS as appropriate) if they aren't already present. I don't think there is a net benefit in doing this generally. For newsletters and other mass messages, it's probably better to automatically unsubscribe anyone who has made zero edits in say 2 years (posting a message to the talk page saying what they've been unsubscribed from and where to resubscribe). If someone is reading despite not editing and still wants to be subscribed they can just make one edit every two years resubscribing themselves. Thryduulf (talk) 13:24, 12 May 2025 (UTC)
    being abused Would you count this thread as abuse? Nobody (talk) 13:28, 12 May 2025 (UTC)
    Yes. Gravedancing on the talk page of a banned editor is abuse. Fan mail to banned editors is also abuse. That thread is clearly the latter. Talk pages of indefinitely banned editors should be used only for (a) appeals of the ban by the banned editor, (b) direct responses to such appeals and (c) communicating information about the ban. There is some leeway for other stuff (e.g. project newsletters, alerts about articles) as long as it isn't excessive and the banned editor has not indicated they don't want to receive that (e.g. I've seen at least one banned editor use their talk page to ask to be unsubscribed from automated messages, we have no reason not to respect their wishes either way for that). Thryduulf (talk) 13:55, 12 May 2025 (UTC)
    How is a TP blocked editor supposed to indicate anything? Do they really need to send an email to arbcom to unsubscribe from a newsletter they almost certainly aren’t reading and can just read on its own page anyway? Dronebogus (talk) 14:01, 12 May 2025 (UTC)
    Calling it Fan mail doesn't seem good faith too me. Nobody (talk) 14:10, 12 May 2025 (UTC)
    How else would you describe it? I’d say “fan mail” is too generous, though what I would actually call it I’m not sure Dronebogus (talk) 14:14, 12 May 2025 (UTC)
    "Fan mail" is a term someone else used (I can't remember where) and while I agree it's not a perfect fit I haven't been able to come up with one that is both better and concise. If you have suggestions please share them.
    If someone is TP blocked then sending an email is the only way they can communicate, regardless of whether their talk page is protected. In the case of a simple uncontroversial request that is not an appeal of their ban an email to any editor or group who can reasonably verify the request is genuine and also take the requested action is fine. If they choose to email arbcom then the first arb who happens to read the email will just deal with it. If someone has been gone a long time and there is no indication they remain engaged with the project then unsubscribing them from newsletters is fine, but don't run around unsubscribing people the second they're indeffed. Thryduulf (talk) 15:24, 12 May 2025 (UTC)
    I'd call it supportive comments of members of the same community who have worked together for years. Nobody (talk) 17:45, 12 May 2025 (UTC)
    It's not just supportive comments though, some go well beyond that. Thryduulf (talk) 20:21, 12 May 2025 (UTC)
    Supportive comments from friends can help a blocked editor reform which is a good thing, but fan-mail in my mind refers to editors who encourage/bait/support problematic editing which we should discourage as a community generally, keeping in mind that people can respectfully disagree on policies, as well as block actions. ~ 🦝 Shushugah (he/him • talk) 08:49, 13 May 2025 (UTC)
  • Oppose. If the blocked editor has to wait a certain time to appeal, then going away from Wikipedia and appealing later is exactly what we want them to do. Forcing them to come back in a specific time window before their talk page gets locked would make the appeal process even less friendly than it is today. However, I do agree with Thryduulf on unsubscribing long-term blocked editors, and I would also suggest that unrelated messages by other users should be disallowed. Dronebogus' proposal of locking the talk pages of editors who lost talk page access also makes sense for the same reason. Chaotic Enby (talk · contribs) 14:08, 12 May 2025 (UTC)
    Yes, at the very least we should do those three things— unsubscribe long-blocked (and long-inactive in general) users, formally ban reverse gravedancing (since gravedancing is already de facto banned and posting random nonsense isn’t tolerated either) and locking talk pages of editors who can’t even use them. Dronebogus (talk) 14:19, 12 May 2025 (UTC)
    What is "reverse gravedancing"? jlwoodwa (talk) 05:31, 13 May 2025 (UTC)
    Fanboying/girling over a blocked user, telling them they did nothing wrong, whitewashing, stuff like that. Dronebogus (talk) 06:00, 13 May 2025 (UTC)
    See also http://meatballwiki.org/wiki/GoodBye WhatamIdoing (talk) 01:26, 15 May 2025 (UTC)
  • Oppose I was thinking along the lines of what Thrydulf said, but I think Admins already have the discretion to protect pages that are being abused. I also agree with Chaotic Enby. In general, we should be reactive to abuse of such talk pages, not proactive in a way that has undesirable consequences. - Donald Albury 14:53, 12 May 2025 (UTC)
  • Oppose Wait, this is the idea lab, we're not supposed to be !voting here. I agree with those above that admins already have discretion to protect a talk page as needed if it's being abused, and I don't think this is really needed as a general rule. And I really don't like the idea of protecting if talk page access hasn't been revoked, since if the person does decide to come back after 7 years there's no reason to make them jump through extra hoops to make the unblock request.
    Also, re Special:Permalink/1280612403#You can come back, the stuff there on the page doesn't seem particularly bad to me, but looking at the page history I see a lot of edit warring that does warrant protection. Anomie⚔ 00:13, 13 May 2025 (UTC)
  • I think there is value to minimizing the OP's case (a). I'm kind of indifferent to case (b). Case (c) though, I think has some merit in continuing, particularly in combination with people engaging in case (b) - if an indef-blocked user's FA is nominated for FAR, for example, some of those involved in (b) might be moved to clean it up. Ditto RMs, GARs, and other article-related processes. Related to that is also case (d): users who don't know about the block might ask questions about non-block-related things, which again those involved in (b) might be positioned to answer. (I have seen both c and d happen, though I don't have any good diffs to hand at the moment). Nikkimaria (talk) 02:33, 13 May 2025 (UTC)
  • I would semi-support, per Thryduulf, sanctioning admins to do this where needed, without requiring it, especially when tpa is revoked. Supportive comments are nice, and banning them entirely would likely make what can be a lonely hobby lonelier, but that shouldn't devolve into a long list of pseudo-RfC supports. I'm not sure where the line is between those, or if a clear line can be drawn (many cases per Nikkimaria), but it seems something an administrator can get a feel for. (On the side question of newsletters, unsubscribing someone after X period of inactivity makes sense to me as well, for accounting purposes if nothing else.) CMD (talk) 02:52, 13 May 2025 (UTC)
    I think a good place to draw the line is when we find ourselves asking if it's time to draw the line. Let the relatively harmless comments stand but shut it down as soon as it causes drama. Don't let a blocked editor become more of a time sink then they already were. –dlthewave ☎ 05:04, 15 May 2025 (UTC)
  • I would semi-support this in line with many above. I think it should be explicitly allowed for admins to apply any level of edit-protection (up to and including full-protection) to talk-pages that are getting a lot of comments unrelated to appealing the block and that are not things that should be IAR ignored. What I'm considering as IAR ignored is if, for example, someone asks someone for clarification on an edit/action they made/took. While yes, blocked users should not be making edits (even by proxy), it should still be allowed for them to clarify past edits upon request by a third party if they so choose and the third party really feels it is necessary. That said, it should not be allowed for people to post "I miss you" or "please come back" style comments. As far as I'm aware, users who have chosen to enable email can still get emails after being blocked - and they can still edit their email preferences to disallow emails from other users if they're annoyed by them. This would, in other words, return the ability to choose whether to get those messages or not to the (blocked) user themselves.
    However, I'm not sure that a default is best here. Allowing it upon admin discretion? Sure. But my one concern with this is that if the misuse is coming from extended-confirmed users, there's really no way to do that without full protection. Which would prohibit anyone who's not currently assigned the 'admin' right when blocked (i.e. basically everyone) from appealing their block on their talkpage. Through no fault of their own, they now have to go through UTRS or other methods to appeal their block - because again, we're talking about protecting them from other users making inappropriate messages. Perhaps the solution could be to add a specific carve out in page protection to allow user talk pages that are protected to be edited by the user who "owns" the talkpage, regardless of the protection level or their user rights? If that were added before any policy change, I would wholeheartedly support explicitly allowing admins to apply any protection level to userpages to prevent inappropriate messages from other parties. -bɜ:ʳkənhɪmez | me | talk to me! 06:11, 13 May 2025 (UTC)
  • No, this is needless policing of non-disruptive editor expression. ꧁Zanahary꧂ 23:58, 14 May 2025 (UTC)
    Quite a few people in this discussion have explained that it actually is disruptive. Thryduulf (talk) 03:09, 15 May 2025 (UTC)
    I don't consider it to be disruptive, and I don't think anyone has "explained" that it simply is disruptive; we are all just offering opinions on the behavior. ꧁Zanahary꧂ 03:41, 15 May 2025 (UTC)
  • Semi-support as a tool in the toolbox. BHG's talk page was being managed in such a way that comments supportive of her or criticizing Arbcom were allowed, while things like deletion notices and negative comments were removed. It just doesn't seem appropriate to maintain a page where only one perspective is allowed. In this case locking the page was an expedient way to avoid it becoming a time sink, and this was achieved through our current policies.
User talk pages do serve a secondary purpose as a repository of notices. This discussion has several editors pointing out that deletion notices are useful in identifying patterns or seeing how the editors' other page creations have been handled. I think this is a good reason not to lock a talk page automatically or block or remove these notices. –dlthewave ☎ 04:12, 15 May 2025 (UTC)
  • This is a solution in search of a problem. It's already the case that page protection is available for pages that are abused, and if they aren't abused why do we care? Also, other editors can't be expected to know whether someone is blocked or not and will just be confused if they come to the talk page with a legitimate query and can't find an edit button. Zerotalk 15:15, 15 May 2025 (UTC)
  • I think the effect on site-banned or long-term indefinitely blocked editors is minimal. From what I've seen, they're generally unlikely to return to editing. I appreciate that the talk page can serve as a focal point for editors to foster their feelings of injustice. However I'm not very comfortable with trying to set a hard standard on whether or not such discussions have reached a point of disruption, or pre-emptively deciding that no such discussions should be held on the user talk pages in question. isaacl (talk) 16:24, 15 May 2025 (UTC)

Right to respond

I think that the subject of an article should have a right to respond tab where they can address the contents of their own article, this goes agaisnt rules about writing about yourself but I think those rules should be changed to allow for this. It'd work how any news site does it, a tab reads 'Right to Respond' and then their verbatim quote, proof it's their quote, and the date they made it. I hope you get what I'm trying to say! It should not be on the article but on a distinct "namespace".


Wikipedia:Help desk#How do I make a recommendation for a rule change NotQualified (talk) 18:00, 4 May 2025 (UTC)

Article subjects can already use the talk page to propose edits through {{Edit COI}}. If they have quotes for non-contentious material about themselves, these quotes can already been used as a source.
More generally, I don't think there is a need to create another namespace for this separate from the existing talk page, but article subjects are of course invited to participate in talk page discussions about their own article. Chaotic Enby (talk · contribs) 20:56, 4 May 2025 (UTC)
i think there should be an entire different section, the point is different. it isnt about discussing what should be in the article, it's about the subject having the right to respond to their article uncensored. thats what a right to respond is. NotQualified (talk) 23:04, 4 May 2025 (UTC)
This is an encyclopedia. Every article is supposed to be based on reliable sources, and to be written from a neutral point of view. Moreover, we have special protections for articles about living persons. We should not expect a person who is the subject of a Wikipedia article to be happy about everything that may appear in that article, but we have a duty to the readers of the encyclopedia to present reliably sourced information about that person that is pertinent to the reason(s) for their notability in a neutral manner. I do not see how we owe anyone a "right to reply" if that means letting them place unfiltered content in the encyclopedia. We have established avenues for subjects of Wikipedia articles to object to the contents of their articles and to offer suggestions for changes, but I do not see any place in Wikipedia for what you are proposing. Donald Albury 00:16, 5 May 2025 (UTC)
Not just people. Also companies, clubs, governments, etc. NotQualified (talk) 11:25, 5 May 2025 (UTC)
Why shouldn't that namespace be called "Talk"? And, while we're at it, as proof of identity is not required to edit, let's let others comment about the article there too. Anything else would encourage the creation of POVFORKs. Phil Bridger (talk) 21:18, 4 May 2025 (UTC)
proof of identity would be required. the subject of the article has a separate name space where, if they prove their identity, is allowed to write a response to their article unedited by anyone else. thats how right to respond works. NotQualified (talk) 23:02, 4 May 2025 (UTC)
We are not supposed to edit each other’s comments on article talk pages… so any comments left by an article subject on the article’s talk pages would be an “unedited response”. The only thing your suggestion adds to this is proof of identity. Blueboar (talk) 00:18, 5 May 2025 (UTC)
If someone wants to prove their identity for WP-purposes, they can follow Wikipedia:FAQ/Article_subjects#How_can_I_prove_my_identity_to_the_Wikipedia_Community?. But for questions on article content, that rarely matters much. Comments like "I'd prefer the WP-article about me to be deleted" are often accepted by editors without proven identity, which doesn't necessarily mean the article gets deleted. And of course, apart from the talkpage, article-subjects can always "respond" off-WP, like [2][3]. Gråbergs Gråa Sång (talk) 07:50, 5 May 2025 (UTC)
And, of course, one of the beauties of responding elsewhere is that you don't have to obey any of those pesky rules. You can lie to your heart's content. Phil Bridger (talk) 08:07, 5 May 2025 (UTC)
Yeah. That said, I've had some very productive and enjoyable on-WP interactions with article-subjects or their representatives, but this usually happens when there is some solid agreement to stand on. Gråbergs Gråa Sång (talk) 08:13, 5 May 2025 (UTC)
To clarify, if there was a RTR section, it needs to be identity verified and allowed to be uncensored. So yes, if they lie, they lie. A RTR allows people uncensored to comment on what is presented on their page in a separate section. It is not about changing the article itself, just the right to publically respond to it however they see fit. NotQualified (talk) 11:31, 5 May 2025 (UTC)
If it's not about changing the article, it's pretty much off-topic for this website. People comment on WP in all kinds off places on the internet all the time. Gråbergs Gråa Sång (talk) 11:38, 5 May 2025 (UTC)
To put it another way, the WP hive-mind is not interested in the general feelings of the members of One Direction about that article. Specific editors might enjoy reading about it. But if those members want to point out spelling errors, outdated sources etc, they're as welcome on the talkpage as anyone else. Gråbergs Gråa Sång (talk) 11:45, 5 May 2025 (UTC)
Specific editors might enjoy or not enjoy reading about anything, so? NotQualified (talk) 12:27, 5 May 2025 (UTC)
Fwiw, Right of reply is a WP-article. It can be argued that in the editorial sense, that exists here. Article subjects, people and org-reps, have often commented on-WP, and those comments are (unless they're not because they're redacted or something) kept in the archives. Gråbergs Gråa Sång (talk) 12:02, 5 May 2025 (UTC)
Is anyone familiar with Brazillian law, it appears we legally would have to allow it in that jurisdiction Right of reply#Brazil NotQualified (talk) 12:26, 5 May 2025 (UTC)
brazil law has no applicability to the wikipedia. ValarianB (talk) 12:56, 5 May 2025 (UTC)
This is an encyclopedia, not a news site. This change in circumstances completely negates any benefit to an RTR. A news site that does not cite its sources is reasonably contested by the subject's account, but we cite sources here, so if there is any non-factual statement in their article, they should get it printed somewhere else and provide the source. Feeglgeef (talk) 18:46, 15 May 2025 (UTC)
what if they cant get it printed somewhere else? NotQualified (talk) 19:00, 15 May 2025 (UTC)
In that case, the RTR issue is with the news sites (or newspapers, etc.) that we use as sources, not with Wikipedia. Chaotic Enby (talk · contribs) 19:05, 15 May 2025 (UTC)
I can see a concern with the possibility of a talk page being archived, but we could do an end run around that by having a dedicated subpage of BLP talk pages for this purpose. No new namespace required. BD2412 T 19:27, 15 May 2025 (UTC)

Remove link to Portals from Main Page

Should the portals links on the Main Page removed?

Background

Since 2017, The portal space continually lose space on Wikipedia, motivated by low readership and poor maintenance. There have been many discussions about this, but the fact is that, after years, the status quo of the portal space remains the same. It is unclear what the purpose of this tool and the attempts to improve the portals don't seem to be moving in a solid direction (transclusions, for example, have solved some problems and created others).

In contrast to this depreciated state, portals enjoy prominent positioning at the Main Page.

This position is via the link to Wikipedia:Contents/Portals on {{Other areas of Wikipedia}}.

Wikipedia:Contents/Portals is itself a very outdated page in terms of layout and content when compared to the others linked in the same template. Its last edition was in 2022, while the others have had recent editions, and unlike the others it doesn't use any modern styling tools like .css.

Proposal

Here are three possible proposals:

  1. Just remove Wikipedia:Contents/Portals from {{Other areas of Wikipedia}}.
  2. Replace Wikipedia:Contents/Portals on {{Other areas of Wikipedia}} per Wikipedia:Contents.
  3. Replace Wikipedia:Contents/Portals on {{Other areas of Wikipedia}} per other link related to navigation by areas of knowledge (suggestions).

Guilherme Burn (talk) 14:37, 15 May 2025 (UTC)

Wikipedia:Contents is already in the Main menu/sidebar. I don't think we should duplicate it.
I think the current system is good. Traffic to that page has dropped to ~15% of what it used to be. Perhaps that's a sign that the people who are going to that page are looking for it on purpose. If you dislike the appearance or contents of the page, then maybe try to improve the page. WhatamIdoing (talk) 23:56, 15 May 2025 (UTC)
Don't agree with this proposal. Portals serve a purpose and people still use them, despite their role being significantly reduced by editors here. Do not see the need to "soft-delete" portals in effect. JackFromWisconsin (talk | contribs) 02:42, 17 May 2025 (UTC)
No, they shouldn't be. Portals are declining, but they are still useful. The response should not be to place a tourniquet around them and stifle further traffic. Cremastra (u — c) 13:18, 17 May 2025 (UTC)
Disagree with the idea. This is a solution in search of a problem. OhanaUnitedTalk page 03:15, 19 May 2025 (UTC)

Fair use revert

Usually, when someone uploads a fair use image, it’s too detailed and gets automatically downsized. Now, the original upload is hidden to avoid any copyright issues. The problem is, if that file ends up not being fair use, whether it be because the copyright expired or because it gets released under a free license, the file history doesn’t automatically get unhidden, and because transwiki uploads require the full file history to be available, only admins can perform the upload. This also comes with the side effect of readers seeing a less detailed version of a possibly HD image. Now, there should be a system where old revisions hidden under fair use should automatically get unhidden when the file is no longer fair use, so that it can be uploaded by anyone. HouseLiving roomDIY Fixings 11:14, 8 May 2025 (UTC)

Is there a trigger that can detect when a file is no longer fair use? You could have categories for copyright expiration, but I assume most other situations would require a manual assessment anyway. CMD (talk) 11:56, 8 May 2025 (UTC)
We have Category:Out of copyright by year and subcategories. It is for both images with a fair use claim, and images that are public domain in the United States but not its home country (those can be uploaded here, but not on Commons). Cambalachero (talk) 13:12, 12 May 2025 (UTC)
Good idea. I don't know how easy an automatic system could be made. Definitely for expiration by year, but seems all other scenarios would need a manual judgement. Maybe a new project page could be made to request undeletion and moving to commons because of provable copyright-free status? JackFromWisconsin (talk | contribs) 17:44, 8 May 2025 (UTC)
If you look at the WP:REFUND page you will see some regulars requesting this for images. You can talk to them about transfer to commons as well. I will do the change to revision deletion, but not the transfer to commons. Graeme Bartlett (talk) 03:40, 19 May 2025 (UTC)

Hey all. For well over two decades now, Wikipedia has been reviewing and improving pages through its rating system, leading to the establishment of the "Featured" status to highlight the very best on the encyclopedia. We have had Featured Articles since 2001, Featured Pictures since 2003, Featured Lists since 2005 and Featured Topics since 2006. There was an attempt to start a process for Featured Categories back in 2007, but it failed to gain interest so burnt out after only a month.

This left me wondering if it would be worth reviving the Featured Categories classification and establishing a review process for the best categories on Wikipedia. I know several editors whose main focus is on categorisation, and they do really good work and seem to get a lot of enjoyment out of it, so why can't we recognise their work or provide an organised means for review and improvement of categories? Obviously the criteria for featured categories would have to be following the Wikipedia guidelines on categorisation. The review process could involve checking each of the articles to see if their inclusion in the category is verified by reliable sources, refining the scope of the category and recommending diffusion where necessary.

Is this something anyone else would be interested in participating in? Is it worth pursuing as an organised project? --Grnrchst (talk) 10:52, 17 May 2025 (UTC)

Seems like a good idea, but the success of this will totally depend on the exact specifics of its guidelines. —CX Zoom[he/him] (let's talk • {C•X}) 13:01, 17 May 2025 (UTC)
I don't think that "Featured" is the right model for this. Maybe "Verified"? WhatamIdoing (talk) 21:41, 18 May 2025 (UTC)
Categories (and navboxes for that matter) are only a structure built around articles, to help navigating between them. They have zero content in themselves. There's nothing that would distinguish a "featured" category from any other category.
We do have featured topics, for sets of closely related articles all featured, that should serve a similar purpose to the proposal. Cambalachero (talk) 02:36, 20 May 2025 (UTC)

Creating a page for testcases of a template

Hi, I propose to create a page that provides all important test cases related to a change in a template.

For testing such modifications of code, we need to test some important (not all) test case pages (as rendered version). Some "selection methods" are mentioned in Software testing article (White-box testing, Black-box testing, etc.). I really think that this selection job can be done pretty automatically.

I should note that testing all articles in What links here is too time-consuming, specially when its number is large. In addition, we should click on each page for rendering.

"Page of test cases" is a table containing rendered version of selected test cases. Please discuss. Thanks, Hooman Mallahzadeh (talk) 07:50, 22 May 2025 (UTC)

Good news! We already have this: Wikipedia:Template sandbox and test cases. For example, see Template:Infobox gymnast/testcases which shows a side-to-side comparison of the current template and its sandbox on several test cases. Chaotic Enby (talk · contribs) 08:02, 22 May 2025 (UTC)
@Chaotic Enby I think, this mechanism is done manually. Am I right? Are there any way to select some test cases automatically through for example White-box testing? Hooman Mallahzadeh (talk) 08:09, 22 May 2025 (UTC)
That's still designed manually. Aaron Liu (talk) 11:48, 22 May 2025 (UTC)

Eñe

@I am bad at usernames: Is it really difficult to enter an Eñe (Enne) on a standard keyboard? On a standard 104-key keyboard with layour UX (US International), ~ is a dead key[a] and Ñ just takes ⇧ Shift+` + ⇧ Shift+N. Which operating systems support UX in which contexts? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:48, 20 May 2025 (UTC)

On Linux Mint I have a character map included which lets me enter any character I want. I'm not only gloating, but saying. Phil Bridger (talk) 18:26, 20 May 2025 (UTC)
Lot's of things are easier in Linux. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:05, 21 May 2025 (UTC)
I have no trouble typing an ñ; it's ⌥ Option+n+n on a Mac. On a mobile device/soft keyboard, or for Mac users who can't remember the keyboard shortcut, then a long press on n pops up a list of four relevant characters (ñ, ń, ņ, ň) to choose from. However, I've heard that it's more difficult on Windows/non-Apple devices, as you have to memorize numeric alt codes. WhatamIdoing (talk) 19:51, 20 May 2025 (UTC)
Of course, on any operating system, you have the option of copying and pasting, which is usually simpler and involves even less to remember. Phil Bridger (talk) 20:16, 20 May 2025 (UTC)
There is also the option to use the special character dropdown when editing. In visual editor and when using the reply tools this is represented by the omega (Ω) icon, in the 2010 and 2017 source editors it is labelled "special characters". Thryduulf (talk) 01:59, 21 May 2025 (UTC)
In ArcaOS I often use insert character in Open Office for characters that are not easy with the UX layout. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:05, 21 May 2025 (UTC)
I just have the Spanish keyboard installed on my PC and press the ; key which is mapped to ñ. By far the easiest way on a PC if you ask me, especially since I type a decent amount in Spanish anyway. »Gommeh 12:34, 21 May 2025 (UTC)
I don't like remapping keys, especially high usage keys. Do you really mean ; or Alt+;? How do you enter an actual semicolon? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:05, 21 May 2025 (UTC)
It's not remapping keys per se, it's a new keyboard you can add in your device settings. And I meant the first one. The semicolon on the Spanish keyboard is relocated somewhere else on the keyboard. This is the layout of the keyboard I normally use for Spanish.
I'm confused. You originally wrote press the ; key which is mapped to ñ. Are you saying that you're using the keyboard shown by Gommeh, which has Ñ to the right of L and ; to the right of M? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:26, 24 May 2025 (UTC)
correct. »Gommeh 16:27, 24 May 2025 (UTC)
»Gommeh 17:10, 21 May 2025 (UTC)

Notes

  1. ^ Yes, the dead keys in UX slow down some other things, but I find it convenient overall.

The idea lab is not policy

Text generated by a large language model (LLM) or similar tool has been collapsed per Wikipedia guidelines requiring comments to originate with a human. LLM-generated arguments should be excluded from assessments of consensus.
The following discussion has been closed. Please do not modify it.

🧱 The Idea Lab Trap The Village Pump: Idea Lab looks like a forum for reform... But it is: Not part of official policy Not indexed into policy review Automatically archived after 10 days of inactivity Deliberately separated from the Village Pump (Policy) where actual rules are discussed They’ve built a padded cell to absorb structural criticism before it reaches the levers of change. 🔍 Design Characteristics of Suppression You can post an intelligent, groundbreaking proposal... It gets zero visibility. No admin is required to respond. No votes are permitted. And it disappears quietly unless you actively self-promote it. This is not democratic. This is decentralized censorship by procedural dilution. Diamondtier (talk) 13:42, 25 May 2025 (UTC)

  • You seem to be misinterpreting features as bugs. The entire purpose of the idea lab is to workshop ideas before they're proposed as policies, ideally to reduce the chance that a poorly written proposal will be rejected for being poorly written rather than being evaluated on its merits. I also note that Wikipedia is not a democracy. Anomie⚔ 13:57, 25 May 2025 (UTC)
    if i come here, not knowing what i am doing, i don't know to click policy, and i already clicked right here, how am i supposed to know that i need to go to "policy"? this is designed as a gate to stop people from making submissions, thus why you have to click "policy" after already clicking on the correct page. Wikipedia appears to be a popular contest with no intent on truth or historical accuracy. Diamondtier (talk) 14:04, 25 May 2025 (UTC)
    You're supposed to read the guidelines of a forum before you make a submission. Here it states at the top of the page in plain, concise, and bulleted text that proposals go to the proposals page and policy discussions go to the policy page. You should read the rules, especially when they are summarized within 150 words. And in any case, the place where you found a link to the idea lab should have an earlier link to the proposals page and the policy page. Aaron Liu (talk) 14:10, 25 May 2025 (UTC)
    it also states that "you won't accept copyright" as a legal form of proof, and you require popularity? so i can invent AI. at home. but if nobody talks about it you don't care? that's suppression. we need oversight. i need management. higher management. executives. immediately. I WILL shut down wikipedia. Diamondtier (talk) 14:12, 25 May 2025 (UTC)
    How can we ensure truth or historical accuracy if we allow anyone to publish anything they want? Anyone can write anything copyrighted; that doesn't mean it's true. I don't want someone to platform their own imaginations on Wikipedia and harm people's well-being because they trusted such imaginations. If someone invents something big people will talk about it. What would prevent us from removing an article that claims they've invented a machine to predict one's life expectancy? Anyone can invent anything; that doesn't mean it works. That doesn't necessarily mean yours is untrue and doesn't work, but the point is we need independent, reliable sources to vouch it's true. While it's unfortunate, they've proven much more reliable than internet strangers. Aaron Liu (talk) 15:32, 25 May 2025 (UTC)
    We all started out “not knowing what I am doing”… and then someone explained it to us. It takes time. Read, learn, listen to advice and instruction and soon you too will know what to do. Blueboar (talk) 14:17, 25 May 2025 (UTC)

Note that the user who initiated this discussion has been blocked for WP:NOTHERE. While people are free to continue discussing it if they wish, it may be prudent to avoid WP:PILEON. Anomie⚔ 14:31, 25 May 2025 (UTC)

Some sort of draft help

I will preface by saying I have never been an AfC person - I've never worked over there, though my first few months here were spent submitting plenty of pages through AfC (unsuprisingly, my first few attempts were not very good).
I'm really not sure what to call this, but I'll do my best to explain. Over on the teahouse, I see a lot of newer editors ask for their drafts to be reviewed before they submit to make sure it's adequate for acception. The usual answer is something along the lines of "submitting your draft is how you get feedback to make the draft good."
One problem I see with this is that AfC reviewers is that the feedback is generally very vague. The pre-made responses (i.e. "establish verifiability", "needs reliable sources", etc. etc.) do not exactly help users if they believe they've already met such criteria. Then they get frustrated when their pages are declined with the exact same reasoning. Similarly, users might also be afraid that their draft will get declined and thus ask for help before submitting it.
Editors will also look at pre-existing articles to get a feel for how they should go. These users generally get the look right, but some things are still.. off (see Draft:Giovanni Soldini (Italian sailor) for a good example). References might be bare URLs, there are errors in where citations are placed, unnecessary emphasis is added, etc.
I would like to propose some sort of group that goes through drafts and make sure they look like Wikipedia articles in terms of proper formatting and placement of things before they are submitted. They can also provide direct feedback to new users, which would fix the issue of them going to the teahouse and receiving what I think is a frankly depressing response.
Again, I'll apologize if this is already somewhere and I've missed it - I'm not very active in AfC. I'll try my best to elaborate if y'all think my thoughts are too confusing. PhoenixCaelestis (Talk · Contributions) 13:51, 22 May 2025 (UTC)

We are all volunteers here. If AfC reviewers spend more time providing detailed advice to new editors, they will have less time for reviewing other submissions. It would be nice if new editors could get more detailed critiques of their submissions, but you would need to find enough volunteers willing to give those critiques without pulling effort away from other important tasks. I dislike being negative about this, but we are always dependent on editors volunteering their time to perform a task, no matter how important other editors think that task is. Donald Albury 17:13, 22 May 2025 (UTC)
For the few AfC drafts I have reviewed I personally always try to improve viable drafts. I do agree that some reviewers unfortunately hath not the time, though. Aaron Liu (talk) 18:20, 22 May 2025 (UTC)
+1. We can ask willing AfC reviewers to provide more concrete guidance, but we can't force them to, especially with the backlog as big as it is. Maybe we could look at the Decline messages in the AfC Helper script and try making them more helpful? Given the number of wikilinks they already have, though, I'm not sure if there's still room for improvement. Toadspike [Talk] 18:40, 23 May 2025 (UTC)
As with any other action taken by any other editor, we can always ask AFC reviewers to explain their actions. Asking reviewers to explain what "This submission's references do not show that the subject qualifies for a Wikipedia article" means is how we sometimes find out that the reviewer's actual meaning was "I didn't realize that WP:NONENG was a policy" or "I don't know anything about the subject area, so I judged the source's reliability based on how pretty the website looks". WhatamIdoing (talk) 18:21, 28 May 2025 (UTC)
This seems like a good area where mentors could offer bespoke, holistic guidance. 207.11.240.2 (talk) 09:18, 23 May 2025 (UTC)
@PhoenixCaelestis, has anyone actually declined a draft because of "bare URLs"? I'm asking because that's explicitly on the list of invalid reasons for declining a submission. In fact, "proper formatting and placement of things" isn't supposed to be a consideration at all, though realistically, AFC reviewers are going to be just as susceptible to the halo effect as any other human. WhatamIdoing (talk) 18:11, 28 May 2025 (UTC)
I didn't mean bare URLs as an explicit reason for decline - I brought that up as it does not look particularly encyclopedic and is prone to link rot. PhoenixCaelestis (Talk · Contributions) 00:14, 29 May 2025 (UTC)
Yes, WP:Link rot is a problem, but the good news is, if the article gets dumped in the mainspace, one of the gnomes will likely discover it and run an automatic template filler on the article soon.
I wouldn't worry about the appearance; it turns out that readers almost never read the refs anyway. WhatamIdoing (talk) 04:07, 29 May 2025 (UTC)

A big fix that would help on this and also some other problems is for AFC reviewers to review by it's official criteria (briefly, ability to survive an AFD) and provide more specific feedback based on that. Which 90% of the time is wp:notability related which is the most confusing area that newer editors run into. North8000 (talk) 18:24, 28 May 2025 (UTC)

I remember creating {{Best sources}} which allows editors to highlight three sources they believe work best for notability, to facilitate the reviewing process and make any assessment more transparent (as the sources can directly be assessed in the template). I worked on a prototype of what adding it to the AfC wizard could look like, but I haven't written functional code for it yet – if there is interest in adding it, that is definitely something that I could do! Chaotic Enby (talk · contribs) 20:22, 28 May 2025 (UTC)
I feel that would be very helpful, and I am fully onboard with that! PhoenixCaelestis (Talk · Contributions) 20:26, 28 May 2025 (UTC)
I agree with North. I doubt that enshrining User:RoySmith/Three best sources in process is a good idea, and I doubt that newbies would be able to identify which ones are "best according to GNG rules" (instead of e.g., longest or most useful). WhatamIdoing (talk) 04:10, 29 May 2025 (UTC)

Idea: Maybe change the text to reset on one of the talk page sandboxes to show one of the discussions?

I encountered a user who made a test edit to a non-sandbox talk page with discussion tools and realize there is no proper testing ground for users to experiment with the tool. I wonder if maybe changing one of the talk page sandboxes (say Wikipedia talk:Sandbox) or maybe creating a separate discussion tools sandbox could address this problem so we don't get IPs widespread testing the functionality on non-sandbox talk pages. Aasim (話す（はなす）) 04:33, 17 May 2025 (UTC)

It can look maybe something like this. Aasim (話す（はなす）) 04:34, 17 May 2025 (UTC)
I don't think that IPs are engaged in software testing. WhatamIdoing (talk) 21:39, 18 May 2025 (UTC)
I don't think so either, but I do think they might be interested to know how talk pages work on Wikipedia. On social media people can post tests with no repercussions. However, this is not social media, this is an encyclopedia and there needs to be a testing ground to experiment with talk pages. No, I don't think User_talk:Sandbox for user warnings is adequate for this purpose. Aasim (話す（はなす）) 17:14, 19 May 2025 (UTC)
As someone who has gone through more unconstructive edits to talk pages than probably most people here, I honestly see very few of them that seem like actual "test edits" or experiments, as opposed to non-malicious but unconstructive edits. Rough back of the envelope, I'd say that 75% of cases are people mistaking the talk page for a forum, social media, search engine, email form, ChatGPT, etc; 20% are actual vandalism; and 5% are actual experiments/tests. I don't know how to solve this short of semi-protection (the next step after the huge red screaming banner when you edit, say, Talk:ChatGPT) or an edit filter (have suggested one to catch at least some common cases but have gotten no traction). But I'm not sure a sandbox is going to help, either you make it voluntary and have almost no one use it, or you make it permanent which is essentially a shadowban.
(I also don't think that most people use social media in order to "post tests" but that's neither here nor there...) Gnomingstuff (talk) 18:46, 20 May 2025 (UTC)
I am not saying most people use social media to post tests. I am saying that people have tested the functionality of social media at one point or another. People mistaking a talk page for a forum is a common problem on a lot of wiki sites, and the solution for that would be to maybe change the label to "discuss this article" or something similar to make it clear that it is the place to discuss improvements or similar. We might already do that with {{talk header}} but not every talk page has that. Aasim (話す（はなす）) 19:15, 20 May 2025 (UTC)
Every Talk: page opens with an automatic notice that "This is a talk page. Please respect the talk page guidelines." The problem is that Banner blindness is real, and Wikipedia:Nobody reads the directions.
Can you provide a diff for what you're calling a test edit? WhatamIdoing (talk) 19:47, 20 May 2025 (UTC)
Apparently the banner doesn't (always?) show up on mobile -- on iOS they're gated behind a "Learn more about this page" modal, it took me a couple of seconds to even realize where they were. Gnomingstuff (talk) 13:11, 21 May 2025 (UTC)
Yet more evidence that the mobile version should be put out of our misery. It's not fit for use.--User:Khajidha (talk) (contributions) 15:27, 27 May 2025 (UTC)
The desktop version isn't fit for use on smartphones, either. WhatamIdoing (talk) 16:30, 27 May 2025 (UTC)
It's a sight better than the mobile version though. CMD (talk) 17:02, 27 May 2025 (UTC)
I think it depends on what you want to do. A couple of the Stewards have told me that neither of the Vector skins are fit for their purpose. (They prefer Timeless, because it has room for long lists of tools all around the screen.) The mobile skin seems to meet readers' needs, especially on smartphones. I don't edit from my phone, but I have never opened a Wikipedia page there to read some little fact and thought "You know what would make this experience so much better? A big banner telling me what the purpose of this page is and what guidelines apply to it. I should switch skins so I can have more user interface elements getting in between me and the content I'm looking for." WhatamIdoing (talk) 18:17, 27 May 2025 (UTC)
Well, if it is meant for reading, then jusg have it read only. No editing. --User:Khajidha (talk) (contributions) 18:50, 27 May 2025 (UTC)
When it was read-only, editors at the English Wikipedia demanded that it be possible to edit on the mobile site. WhatamIdoing (talk) 21:41, 27 May 2025 (UTC)
Easily fulfilled by having editing load up in the desktop site. CMD (talk) 04:18, 28 May 2025 (UTC)
Have you tried that on a smartphone? Look at the toolbar at the top of the editing window. Now ask yourself how functional that will be on a screen that is 2.25 inches (5.7 cm) wide. Click the 'Cite' option and choose Templates > Cite web. That community-maintained tool is set to about 80% of screen width. Imagine what that looks like when it's less than two inches wide. WhatamIdoing (talk) 06:02, 28 May 2025 (UTC)
Is the assumption of the above question that I am opining on the different feel of editing in the two separate skins on mobile without having actually tried? CMD (talk) 06:19, 28 May 2025 (UTC)
I edit the desktop site on a smartphone all the time. As for screen size, there's this useful zoom feature on smartphones.... --User:Khajidha (talk) (contributions) 12:06, 28 May 2025 (UTC)
At the zoom that lets me see the whole editing box, the characters are one (1) millimeter tall.
At the zoom that lets me read the words in the editing box without my glasses (300%), I can see only a third of the editing window's width (five to seven words at a time, not whole sentences), with the screen sliding left and right as I type.
Here are two screenshots from a smartphone. Zoom until they're about 58 mm (2.25 inches) wide (about as wide as your smallest finger is long).
  • 2010 wikitext editor at default zoom
    2010 wikitext editor at default zoom
  • 2010 wikitext editor at maximum (300%) zoom
    2010 wikitext editor at maximum (300%) zoom
    • The default zoom is illegible. Any bigger zoom starts hiding the edge of the editing box, so it bounces back and forth as you type. Would you actually recommend that experience to anyone? WhatamIdoing (talk) 16:38, 28 May 2025 (UTC)
    Probably not, I'd recommend that they turn their phone 90 degrees. CMD (talk) 17:50, 28 May 2025 (UTC)
    Which approximately doubles the number of words across, but it's still only about 60% of the width, and it still shifts back and forth as I type. It also halves the number of lines that are visible vertically (to ~4.8 lines, when the keyboard is in use).
    I wouldn't recommend that experience to anyone, either. WhatamIdoing (talk) 17:59, 28 May 2025 (UTC)
    I understand that, but whether you'd recommend the experience is not the question at hand. CMD (talk) 18:23, 28 May 2025 (UTC)
    I think that whether you'd recommend that experience is highly relevant to the question of whether you'd recommend editors to switch to the desktop site for editing, rather than staying at the mobile site. Don't you? WhatamIdoing (talk) 22:03, 28 May 2025 (UTC)
    Saying you wouldn't recommend one experience says nothing about any other experience or about switching. I don't recommend editors edit using the mobile site either, but if editing is to be done on a phone, then as I noted earlier the desktop site is a bit better (I just used it for this talkpage comment). CMD (talk) 02:22, 29 May 2025 (UTC)
    I find the mobile site better, if editing must be done on a phone. WhatamIdoing (talk) 06:02, 29 May 2025 (UTC)
    Not sure what Aasim had in mind but a few representative diffs: I would consider the comment reverted in here to be a "test edit"; here to be vandalism (the second one), and here to be a misguided search query/LLM prompt for someone's homework. Gnomingstuff (talk) 13:16, 21 May 2025 (UTC)
    I think that's a fair description of those edits. WhatamIdoing (talk) 17:07, 21 May 2025 (UTC)

    An official achievement system

    An achievement system could help bring in new users, giving them a pathway from the first few edits to getting them into a niche. Wikipedia wouldn't seem so huge and scary if you just start with one edit. While this seems obvious to us, we are losing potential editors to it. So, I propose we make an official achievement system (which can be accessed by clicking a button under the contributions button).

    So far @Seefooddiet, @Chaotic Enby, and myself have come up with the following ideas (in a conversation on the Wikimedia Discord): make 1, 10, and 100 non-reverted edits, leave an edit summery, use a talk page, customize your signature, use the random article feature, and write one article. Mikeycdiamond (talk) 19:55, 20 May 2025 (UTC)

    These achievements would be automatically granted by the website, which differentiates them from WP:BARNSTARs, which are granted by other users.
    I think the primary function of this is to encourage getting new users to sign up and encouraging retention. Examples:
    • Using pop-ups to indicate what you could get easy achievements for
      • Non-registered users would be shown a pop-up encouraging them to register for an achievement. From there, newbies would be shown more pop-ups (experienced users could be shown much fewer) to entice them into editing and suggest things they could do.
      • Pop-ups should be minimally intrusive and easily disabled, even by non-registered users. Possibly make them rare so that most viewers don't really see them; like if 10% of viewers see them and 10% of those viewers register, we've still made a tangible gain in new users.
      • E.g. Pop-ups saying "try out x feature for an achievement", like using visual or source editor or generating an automatic reference using visual editor.
    • Edit count tracking. Gear it to discourage gaming the system to get the achievements, e.g. maybe don't track past a certain low number (like 100) to discourage people from excessive trivial edits. Maybe only track edits that haven't been reverted. Could track talk edits too to encourage discussion.
    • Length of being an active user.
    • Length of edit streaks. These can maybe be retroactively granted as well.
    • Features like installing a user script (can provide recommendations for common/widely-accepted ones).
    • Giving/receiving barnstars or other awards. Encouraging social aspect of site.
    • Answering edit requests or other helpful things.
    • GA or DYK-related stuff.
    • Silly things, like accessing "secret"/funny parts of the website, reading certain silly articles or essays, etc.
    You get the idea; productive newbie-friendly stuff should be encouraged with these.
    Other ideas:
    • Trophy case: There could also be a trophy case–like template that displays what achievements you've earned, so users could put that on their user page like a collection (like as is done with barnstars). A benefit of this is that others will be able to see what things they could do to expand their collection; this effectively encourages them to participate in activites that improve retention.
    • Achievement stats:
      • Rankings: Have a page that shows users with highest achievement counts
      • Rarity: have stats on what achievements are rarest (fewest people have obtained)
      • Completion rate: display a % completion rate; how many of all achievements you've acquired. I think we should aim to make most achievements fairly doable; if they're extremely difficult (e.g. become an admin or edit for 15 years) that may discourage people from trying to collect them all.
    • Achievement suggestions: Could have a discussion page where users suggest new achievements for adoption.
    grapesurgeon (seefooddiet) (talk) 20:11, 20 May 2025 (UTC)
    Other achievements I had in mind were for using talk pages and edit summaries (many editors don't realize that talk pages are a thing) – there could even be a "Bold, Revert, Discuss" achievement for opening a talk page thread if one of your edits gets reverted.
    For raw numbers like edit count, I agree that we shouldn't count past 100, with the exception maybe of 500/30. On the flip side, even making one edit should be an achievement (presumably the second one after creating an account). Around 30% of users don't make a single edit, but even making a few hugely increases odds of staying around! Chaotic Enby (talk · contribs) 20:47, 20 May 2025 (UTC)
    Yes agreed with everything here grapesurgeon (seefooddiet) (talk) 21:05, 20 May 2025 (UTC)
    Please don't rank people. That will be useless (in fact perhaps a bit demotivational) for the newbies this is meant for as they're at the bottom of the list and lead to pointless, bulky competition at the top. And the potential fix of limiting a leaderboard to stuff gained in the last 7 days would just incentivize getting things done fast instead of right like gaming edit counts. Aaron Liu (talk) 11:34, 21 May 2025 (UTC)
    Yeah, rankings shouldn't be made, and things like completion rate (or list of achievements) should only be visible to the user, not to others. We don't want this to turn into a new WP:EDITCOUNTITIS or competition in general.
    Also, I don't believe we should do anything extremely advanced, beyond getting a GA – again, this should be newcomer-oriented, and it should be relatively easy to 100% the achievements to avoid advanced users making edits just for the sake of getting them (if they want, they already have Bilorv's Challenges). Chaotic Enby (talk · contribs) 11:37, 21 May 2025 (UTC)
    I agree, the achievement system should be stepping stones/an introduction, guiding newbies until they find their niche. Mikeycdiamond (talk) 12:23, 21 May 2025 (UTC)
    Yeah actually if it should be feasible to 100% the achievements (e.g. nothing too much more difficult than getting a GA) the rankings are probably pointless anyway. grapesurgeon (seefooddiet) (talk) 18:13, 21 May 2025 (UTC)
    God no. --User:Khajidha (talk) (contributions) 13:57, 21 May 2025 (UTC)
    Can you describe what you dislike about the idea, so we can improve it? Mikeycdiamond (talk) 14:33, 21 May 2025 (UTC)
    It's pointless and childish and I would not trust the quality of any editor motivated by such garbage. --User:Khajidha (talk) (contributions) 17:46, 21 May 2025 (UTC)
    To repeat.
    Calling the ideas of others "garbage" is grossly and unnecessarily uncivil. It's possible to strongly disagree with others without insulting them.
    Not pointless. Proof is in the pudding; it works on many people in many platforms. And who cares what is "childish" or not by your standards, I'm interested in doing things that work. And the excessively final overconfident statement "any editor", as if you can predict with 100% certainty that EVERY editor who is motivated by this will always be bad and never improve, is pretty telling about the quality of this take. Some Wikipedia admins or veteran editors got into editing through vandalism; what makes you think people who get into editing via this system will be 100% guaranteed to be worse than the former vandals? What we need is more people to discover the platform and give it a try; we can filter good and bad editors out from there. grapesurgeon (seefooddiet) (talk) 18:11, 21 May 2025 (UTC)
    Most helpful, specific, and respectful Wikipedia comment grapesurgeon (seefooddiet) (talk) 14:41, 21 May 2025 (UTC)
    While seeing that most of a new editor's edits have been reverted is a sign to take a closer look at those edits, a revert-free record should not be rewarded over one with a few reverts. There are reasons an edit may be reverted that have nothing to do with the quality of the edit, such as a vandal re-reverting, another editor simply not liking an edit that complies with P&Gs, or, as I have done on occasion, an edit reverted through misreading or other misunderstanding. Even if I self-revert a mistaken reversion, it remains in the contributions log as a revert. Donald Albury 14:10, 21 May 2025 (UTC)
    From what I understand, the idea isn't to count a "streak" of non-reverted edits but rather the total number, so there wouldn't be much of a difference between your two cases. Chaotic Enby (talk · contribs) 14:13, 21 May 2025 (UTC)
    I think these are interesting ideas.There is a bit of overlap with WP:Newcomer tasks. Perhaps that project would be open to incorporating the "achievement" aspect. Schazjmd (talk) 13:55, 22 May 2025 (UTC)
    See also Wikipedia:WikiProject Wikipedia Badges, Wikipedia:Teahouse/Badge/About#Hmm... gamification, isn't that wrong for Wikipedia?, Wikipedia:The Wikipedia Adventure/Research#Gamification, etc. WhatamIdoing (talk) 21:11, 20 May 2025 (UTC)
    I feel like the examples you provided (the ones of existing things like our idea) are different than ours. We are trying to make steppingstones for inexperienced users, while those require the user to be on the website/be an editor for long enough to know about userboxes, statistic tools, or other features you listed. Also, that WikiProject is defunct. Another large difference is we want to implement this sitewide. Mikeycdiamond (talk) 21:21, 20 May 2025 (UTC)
    I think this could be a good idea for very new editors, but we have to be careful. I remember reading a block appeal recently where the editor who had been blocked did nothing to address the reasons, but went on about how unfair it was that they would no longer be able to take part in some pretty meaningless competition. We don't want this to lead to any nonsense like that. Phil Bridger (talk) 22:10, 20 May 2025 (UTC)
    Pretty meaningless competition is a powerful incentive; one of the best tools we have on a nonprofit volunteer website. I think should be not toooo difficult to respond to problematic users that arise in response to this system. grapesurgeon (seefooddiet) (talk) 22:14, 20 May 2025 (UTC)
    We already have edit count achievements for 1, 10, and 100 edits, see Help:Notifications#Milestone. I doubt these distinguish reverted/non-reverted edits though. If this is to be expanded, it would be preferable not to include writing a new article, as I believe we try to encourage new users to edit existing articles to avoid various article creation-related pitfalls. CMD (talk) 01:56, 21 May 2025 (UTC)
    Good point on milestones; probably could be merged into or expanded to make the achievement system. Article creation achievements maybe debatable; maybe possible to design achievement to reduce pitfall grapesurgeon (seefooddiet) (talk) 02:12, 21 May 2025 (UTC)
    We could make an AfC achievement instead of an article achievement. Mikeycdiamond (talk) 10:21, 21 May 2025 (UTC)
    I was thinking that too; maybe that could work. grapesurgeon (seefooddiet) (talk) 18:19, 21 May 2025 (UTC)
    Gamification is extremely powerful (my own editing is influenced by WP:BILORV challenges) but easily tracked newbie tasks often lead to problems. Search the WP:AN/WP:ANI archives for "WPWP" to get some taste of it. —Kusma (talk) 14:11, 21 May 2025 (UTC)
    I looked at the WPWP archives that you mentioned. My understanding of it is the 2021 incident most likely happened because they gave out cash prizes, the 2022 one happened because they gave out merch to the winners, and I didn't see much mention of 2023 (except some people did vandalize things). The achievement system is different from this because there is no first place. If they don't get to "prove" they're "better" or get a rush for being in whatever place, the newbies wouldn't have an incentive to vandalize for the achievement. Also, if getting their edit reverted could revoke the achievement (or make them no longer qualify), why would they make low quality edits. Therefore we are actively incentiving better/high quality editing. Mikeycdiamond (talk) 14:56, 21 May 2025 (UTC)
    This also ties into my AfC achievement idea. To get an article through AfC, it it to be of some quality. This would actively reward editors who bring good contributions. Mikeycdiamond (talk) 14:58, 21 May 2025 (UTC)
    Did you have to mention WPWP? I had just about forgotten about those very painful episodes until just now. Phil Bridger (talk) 20:27, 21 May 2025 (UTC)
    I'd like to see a benefit analysis of this, as it seems like a decent amount of effort that will serve not much purpose. Rather, if retention of brand new editors is an issue and if WP:TWA is outdated, perhaps retarget your attention towards making adjustments to TWA instead. I would also add that there have been major issues with some editors achievement hunting (ego stroking) before - Doug Coldwell and Lugnuts are the two most prolific that come to mind, and we are still dealing with issues related to the latter nearly 3 years after their ban. Curbon7 (talk) 18:38, 21 May 2025 (UTC)
    The problem with The Wikipedia Adventure is no one knows about it, hell I just learned of it. The achievement idea is easily findable, being planned to have a button under the contributions one. The fact you are the first person to mention it shows no one knows of TWA. Also, there would only be a few, easily achievable achievements, eradicating the chances any problematic editors doing much harm. The disincentives proposed would stop harmful edits at the source such as losing progress when edits are reverted (to the edit achievement) and making a AfC (instead of an article creation achievement) achievement to bottleneck any harmful articles. Mikeycdiamond (talk) 19:03, 21 May 2025 (UTC)
    The "Learn more about editing" welcome link on your talk page has a link to the Adventure. The very first thing I ever did with my account was the Adventure. Aaron Liu (talk) 20:01, 21 May 2025 (UTC)
    TWA was updated last year by Ppperry, and I don't see any reason to think that this proposal was made because of any outdatedness of TWA. Aaron Liu (talk) 20:04, 21 May 2025 (UTC)
    Thinking about this more, there are a few hurdles any automatic achievement system will need to meet. Achievements will have to not encourage disruption or otherwise lead a new editor to do something that gets them trouted. Examples are mentioned by others above, perhaps a more applicable example is the occasional issues that have been caused by the WikiCup (notably, the WikiCup can adjust, because it's not automatic). There have been many issues with newcomer tasks in the past, which is why they are rolled out slowly, and the inherent 'game' in the system does lead to issues with WP:HATCOLLECT. Achievements would also have to relate to a metric that is easy to track without false positives, or with false positives extremely unlikely (ie. a very simple metric). Figuring out whether an edit is reverted or not for example, it not simple. Further, achievements would have to be individually applicable, not competitive (for a few reasons like ensuring consistent experience, in addition to the point about not being disruptive). If there are ideas that meet these bars, it may be worth trying to integrate them into existing systems (Milestones, TWA) than trying to create a whole new system. CMD (talk) 14:33, 22 May 2025 (UTC)
    I think that (besides the ease of tracking) the achievements that have been suggested above seem to fit the criteria you have mentioned. The Milestones system is close enough in structure to what we are suggesting (although it doesn't have things like a list of milestones that can be reached, which makes sense since they are much more linear) – it would make sense to build up from it by adding new "milestones" such as commenting on a talk page, leaving an edit summary, having an article accepted through AfC, having a successful GA/DYK nomination, etc. Chaotic Enby (talk · contribs) 14:41, 22 May 2025 (UTC)
    I would disagree that article creation and GA/DYK nominations are risk-free ideas. Those are things that if rushed will add to already burdened queues. Commenting on a talkpage perhaps might lead to unusual contributions too. CMD (talk) 15:49, 22 May 2025 (UTC)
    I don't see how these achievements could be integrated in the simulated system that is TWA. Agree that if this was to be implemented it'd probably build upon milestones. Aaron Liu (talk) 14:44, 22 May 2025 (UTC)
    Since no one has said anything in a few days, I wanted to build a proposal.
    Uncontested ideas:
    Achievements: leave an edit summery, use a talk page, customize your signature, opening a talk page thread if one of your edits gets reverted, 1, 10, and 100 edits (the non-reverted part has been contested), and use the random article feature.
    Other: A trophy case (I think the name could cause problems, but we can rename it if needed), which could be accessed by a button under the contributions one and an achievement suggestion page.
    Contested ideas:
    Achievements: make an article, submit a AfC article (and have it published), have a successful GA nomination, and have a successful DYK nomination.
    Other: The rankings idea has been contested.
    So, should we take all the uncontested ideas and make a proposal? Mikeycdiamond (talk) 20:23, 26 May 2025 (UTC)
    1, 10, and 100 are already editing milestones that give a notification. I was under the impression these would be built into the milestones system?
    Also, you probably want to code this first before proposing to enable to code. Aaron Liu (talk) 20:24, 26 May 2025 (UTC)
    Yes, my idea was also that this would be built into the milestones system. Not sure how it is coded, but it would be a good idea to have a look at it first. I personally agree with all the uncontested ideas, and all the contested ones besides "make an article" (mild disagree) and the ranking system (very strong disagree). Chaotic Enby (talk · contribs) 20:49, 26 May 2025 (UTC)
    Looking into it, they are implemented as system messages. Since they appear to be using the Echo notification system, the MediaWiki developer guide could be helpful, although I don't know exactly who can implement them and where. Chaotic Enby (talk · contribs) 21:00, 26 May 2025 (UTC)
    One thing missing is I also proposed popup notifs that suggest ways to get achievements. grapesurgeon (seefooddiet) (talk) 21:08, 26 May 2025 (UTC)
    Lets do it. My mom donates her pictures to Google Maps because they give her achievements, but not to commons because of unnecessary red tape and lack of motivation. (t · c) buidhe 21:45, 26 May 2025 (UTC)
    I think this is a good idea. We need to increase engagement and Wikipedia should do a lot more to encourage people to start editing. Toadspike [Talk] 10:34, 30 May 2025 (UTC)

    new idea; WP: Science articles archive, (or some useful variation of that)

    I have been recently seeing a lot of fascinating new findings, specifically in the realms of ai, as well as archaeology, medical science, nanobots, computers, etc. lots of these deserve to be noted and documented in an article here. however, i don't always know right away which article would be the best place. my idea is to begin creating a set of pages where we could post links to articles on major findings, and then allow editors for various topics to use them.

    the format for doing this could take several forms. here are some options; this could be a page in the Wikipedia namespace, or it could be a WikiProject Page, or it could be in another namespace. Or also, we could make a subpage at WikiProject History, because since that wikiproject does not have any specific focus within history, it could encompass the history of various fields in science and technology. or this could be a subpage at WP:Library, or at WP:Reference Desk/

    ok what do you think of that? feel free to comment, of course. Sm8900 (talk) 10:30, 29 May 2025 (UTC)

    i just realized one possible pitfall, and some options. obviously one pitfall might be that the page might rapidly become too bulky, if this caught on, and lots of editors left articles and links. ok, so here are some possible options.
    • a page in "wikipedia:" namespace, with subsections by topic
    • series of new "History of" pages, for various fields within science, technology, computing, ai, etc etc
    • a new wikiproject, which implictly allows a community of editors to build this, and to organize it as they see fit.
    • subpages at Reference desk, with separate subpages for specific fields and subfields.
    • New type of mainspace page, to be named with a new format as eg Nanobot findings (2020-present), where the new findings themselves could be posted as they occur, in a traditional wikipedia format, but more for noting new findings and discoveries in general, within a particular field or subfield.
    Sm8900 (talk) 10:42, 29 May 2025 (UTC)
    Some examples, just from the recent past:
    Sm8900 (talk) 14:45, 29 May 2025 (UTC)

    Comments

    • It would also be useful to have a scan wish list, listing old documents for which a publicly available online copy is desired. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:35, 29 May 2025 (UTC)
    • I like the idea of helping find new referenced-content ideas. A major concern I have is that it would be susceptible to gathering piles of WP:PRIMARY. That seems inherent in, and almost fundamentally the goal of, framing this as "fascinating new findings". Medical and other science articles cannot have that (WP:MEDRS is even stricter than the standard WP:RS/WP:SECONDARY that applies to all articles in general). DMacks (talk) 14:20, 29 May 2025 (UTC)
    • If you want to suggest a new article, then use Wikipedia:Requested articles. If you want to suggest a new addition to a particular article, then use its talk page. If you want to suggest a new addition to an unidentified article, then post on the talk page for the most relevant WikiProject. WhatamIdoing (talk) 16:34, 29 May 2025 (UTC)
      @WhatamIdoing, i am suggesting a general repository for listing multiple magazine articles and newspaper articles, and online articles, which editors might find useful, as pertaining to various active and relevant topics. Sm8900 (talk) 17:09, 29 May 2025 (UTC)
      WP:Unorganized pile of potentially interesting sources? WP:Random collection of sources with no way to find the things related to your own interests? Have you considered Wikipedia:Discord as a better venue for ephemeral recommendations? WhatamIdoing (talk) 22:46, 29 May 2025 (UTC)
      @WhatamIdoing, as per the header of this page, please Try to be creative and positive when commenting on ideas.. and also let's please remember WP:CIVIL. and if i may, i'd appreciate it if you could please avoid personal comments. and again on the idea tab, honest feedback is welcome, needless put-downs are not, with all respect. Sm8900 (talk) 03:12, 30 May 2025 (UTC)
      Here's some of the problems you have to overcome: If the list is too long, it won't get used. If the contents aren't timely, it won't get used. And if you don't get the right information to the right person, it won't get used.
      You could increase the chance of a suggested source getting used by taking it to the right place (e.g., {{ref ideas}} on the article talk page). You could increase the chance of your idea working by getting it to the right people (e.g., a relevant WikiProject). But you can't just dump everything in a central place and realistically expect people to dig through the list just on the off chance that it might have something useful in it, and that if it does happen to have something useful, that they might be able to find it.
      One way to address this is to embrace ephemeral alternatives, and maybe even leverage social media-style #tags. That means posting it on Discord or on a WikiProject's talk page. If you wanted to do that, you'd keep it lightweight and easy: "Cool source if anyone's working on #widgets or #manufacturing: https://www.example.com", and you'd keep your expectations low, remembering that the clear majority of sources will never get used. WhatamIdoing (talk) 05:17, 30 May 2025 (UTC)
      @WhatamIdoing, ok those are all great points. and let me just say that it is truly helpful to have the insightful input from a knowledgable experienced editor like yourself. i'm totally glad to be able to discuss this with you. thanks! Sm8900 (talk) 13:30, 30 May 2025 (UTC)
    • Impossibly broad scope. A source repository system might be useful within the scope of individual WikiProjects, but even then only the narrowly scoped ones. CMD (talk) 03:42, 30 May 2025 (UTC)

    possible proposal for consensus

    guys as per @WhatamIdoing, and other thoughtful comments above, there are some practical questions and possible problems, relating to implementing this. so i would suggest a subpage at one or more wikiprojects might be the closest we can get to this idea, since wikiprojects have lots of freedom in setting up subpages. --Sm8900 (talk) 03:16, 30 May 2025 (UTC)

    Most wikiprojects are moribund or minimally active. I'm subscribed to a number of projects, but I generally only look at comments on the talk page. What I did do today was move some sources that were suggested on a project talk page to the talk page for the specific article they were intended for ([4]). Practically, I don't see anything more formal than that gaining traction. Donald Albury 15:43, 30 May 2025 (UTC)

    OCR repository

    A lot of paper documents have been scanned into PDF files with no OCR. It is not possible to do a search in such documents. A useful addition to Wiki would be a repository containing OCR versions with the original URL in the metadata.

    I'm uncertain as to whether new CS1 and CS2 parameters would be useful. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:59, 31 May 2025 (UTC)

    This sounds like what Wikisource is for. Graeme Bartlett (talk) 11:44, 31 May 2025 (UTC)
    Copyright restrictions will be a big problem for most documents that are not very old. Zerotalk 11:46, 31 May 2025 (UTC)
    OCR is embedded in the PDF file it's not a separate file unless extracted to a text file. You can upload the OCR'd PDF overtop the original non-OCR PDF. Or upload a second version with a new name "-OCR". I'm not sure Copyright is an issue for an OCR vs non-OCR PDF, they are both Copyrightable. -- GreenC 19:36, 31 May 2025 (UTC)
    Correct, additional copyright protection is not generated when an OCR layer is added to a PDF file. My comment refers to the PDF file itself. We aren't allowed to copy copyrighted material from "out there" to our own repository unless it has an appropriate license. Zerotalk 01:20, 1 June 2025 (UTC)

    Automatic pausing of Growth Team Features Mentorship for inactivity?

    Moved to mw:Talk:Growth#Automatic pausing of Growth Team Features Mentorship for inactivity?
     – ‍Relativity ⚡️ 21:03, 2 June 2025 (UTC)

    A bot to handle graph to chart conversions

    Hi folks,

    I've been working on a bot to generate .tab and .chart files from the {{Graph:Chart}} template. It started as a copy-paste thing, but at the moment it requires 2 inputs:

    • Name of the article
    • Names of each of the graphs

    I have been trying to convert this into a true bot that doesn't require user intervention and was thinking that somehow using templates to mark graphs needing conversion as well as their names might be the best way forward. The best I can think of is {{[template name]|graph_name1=[name of graph 1]|graph_name2=[name of graph 2]}}, this is rather unforgiving, and expects that graphs are inputted in the order they are found in the wikitext, and a mistake would probably cause mis-named graphs. I would appreciate any ideas on this front.

    Cheers, GalStar (talk) 17:24, 3 June 2025 (UTC)

    You might get more useful feedback at Wikipedia:Village pump (technical) and/or WP:BOTREQ. Thryduulf (talk) 17:43, 3 June 2025 (UTC)
    Thanks, I'll ask about this there GalStar (talk) 18:24, 3 June 2025 (UTC)

    New section in main page whenever there's a milestone?

    By now, it has become known that wikipedia has surpassed 7 million articles with Operators and Things. Now, we of course want to show this great achievement to our readers. And I think putting it directly on the main page will do that perfectly (we already sort of did that with that little notice saying we hit 7 million articles)

    Here's my idea: whenever we hit an article milestone, we dedicate a portion of the main page holding up that blessed article for like a week. The portion dedicated will not be super flashy or anything, and will be relatively small, but will come before all the other contents that are usually displayed on the main page. We already did it with our millionth article, and I don't see why it was be discontinued. See today's featured list, and put it in the top of the page with the list being replaced with the blessed article, and the little hatnote celebrating the accomplishment being merged into this new main page template. And that's basically my idea. How does this sound? If this gets implemented, we could start to do this beginning with the 8 millionth article. Yelps ᘛ⁠⁐̤⁠ᕐ⁠ᐷ critique me 17:55, 31 May 2025 (UTC)

    Editors would be gaming the system to try to claim that article spot, as they already have in trying to reach 7M. Also, main page featured content is supposed to represent our best quality work, and there's no assuring the xth million will meet any quality guidelines. Masem (t) 17:58, 31 May 2025 (UTC)
    No thank you. That'll just lead to people mass-creating a bunch of worthless stubs so they could claim that [x]-millionth article and get their article on the main page. The less attention we give to article count, the better. Please also see Wikipedia talk:Seven million articles § Post mortem. Some1 (talk) 18:12, 31 May 2025 (UTC)
    I would propose that we have reached the point where we should stop celebrating raw “article count” milestones completely.
    The next celebration should be focused on 1 million GOOD articles (or even better: 1 million FEATURED articles). Raise the bar and Celebrate our BEST. Blueboar (talk) 18:43, 31 May 2025 (UTC)
    Yes, and I would even say that getting an existing high-traffic article (such as YouTube, 1989 Tiananmen Square protests and massacre, Cristiano Ronaldo, etc.) to GA or FA status is a more meaningful and impressive achievement than creating an additional 900,000 articles that most readers don't even know or care about. (Per WP:VIEWSSTATS: Most articles have very low traffic. In 2023, 90% of articles averaged between zero and ten page views per day. The median article gets about one page view per week. Because the top 0.1% of high-traffic articles can each get millions of page views in a year, the mean is about 100 times the median.) Some1 (talk) 19:21, 31 May 2025 (UTC)
    Disagree with impressive achievement than creating an additional 900,000 articles that most readers don't even know or care about. unless you can show that they are not notable enough. —CX Zoom[he/him] (let's talk • {C•X}) 19:26, 31 May 2025 (UTC)
    If an editor were to bring 1989 Tiananmen Square protests and massacre (an article that receives a daily average of ~112,799 page views in the past 30 days) to FA status, I would find that much more impressive than if another editor were to mass-create hundreds or thousands of stubs that receive only one page view a week. Again, my opinion, and I understand that some people value quantity over quality. Some1 (talk) 19:48, 31 May 2025 (UTC)
    We reached that point a few million articles ago. Creating an article is easy, and the quality displayed by the new article feed suggests that it often does more harm than good. I'd go even farther and say it would be a greater benefit to the project to get back to 6,000,000 through things like merging stubs into lists or removing BLPs about random nobodies that are currently propped up by WP:NBASIC. Thebiguglyalien (talk) 🛸 04:17, 1 June 2025 (UTC)
    Yes, growth in the pure number of articles shouldn't be a goal to celebrate. I would dearly love it if we could swing the emphasis from creating new articles to improving existing articles. Of course, I say this after creating 12 new articles in the last 6 months, although I also significantly expanded 15 articles in that time. Donald Albury 14:39, 1 June 2025 (UTC)
    Wikipedia:The World Destubathon, and this time there's a rule against creating a new stub to destub it. CMD (talk) 16:31, 1 June 2025 (UTC)
    I wonder how we get from "the quality in the new article feed is lower than I'd prefer" to "creating articles often does more harm than good". Who is being harmed? Whose ox is actually being gored by the creation of a short stub? WhatamIdoing (talk) 22:06, 2 June 2025 (UTC)
    You can start at Wikipedia:Requests for permissions/New page reviewer and see for yourself. Of course, that's just initial checks. Each article still needs to be maintained for the duration of its existence, but one thing at a time. Thebiguglyalien (talk) 🛸 00:25, 3 June 2025 (UTC)
    @Thebiguglyalien, that is not an answer to my question. Here are the most recent articles from Special:NewPagesFeed:
    For each of these, or any of these, please name a person or group that is actually harmed by the existence of this article in its present state, and describe how they are harmed by it being created.
    "Well, I personally don't appreciate the fact that a third of these only have three inline citations when the median for all Wikipedia articles is four" or "I think editors shouldn't create articles unless they add more than 39 words and an infobox on the first day" is not evidence of an article "doing more harm than good". WhatamIdoing (talk) 18:37, 3 June 2025 (UTC)
    This feels a little like erecting a sign where your car's odometer hits the 10,000 mark. The location might gain significance to you, but for everyone else, it's just a point on the road they're passing much like every other. Personally I don't think it's worthwhile highlighting what is essentially a random article. isaacl (talk) 18:48, 31 May 2025 (UTC)
    Why such a hoo-ha about reaching 7 X 106 articles? Should we make the next celebration when we reach 223? Phil Bridger (talk) 19:18, 31 May 2025 (UTC)
    There's no need to evaluate milestones in base 10. CMD (talk) 05:47, 1 June 2025 (UTC)
    Yes, it's a kind of chauvinism. Also, we're not incorporating the important result from the interesting number paradox. Sean.hoyland (talk) 07:01, 1 June 2025 (UTC)
    Posted this message and went to sleep since it was midnight in my timezone. After I wake up and freshen up, the first thing I see is a pile of snow in my notifications tab. That's cool.
    When writing that idea, I basically forgot that there was a growing consensus that article milestones were becoming less and less a thing to celebrate. If I remembered, I'd probably consider this idea, remember that consensus is the backbone of wikipedia, and not write this. So uhh, shame on me, I guess.
    But shouldn't we atleast link the article in question and maybe even the wikipedia page about it in the hatnote we have about the fact that we hit an article milestone? But again, I might just be fumbling the bag by forgetting yet another important variable.
    I do actually quite like the idea of blueboar, celebrating the "-illionth" FA or GA. Maybe that's what we put on our main page instead when the time comes? Yelps ᘛ⁠⁐̤⁠ᕐ⁠ᐷ critique me 09:57, 1 June 2025 (UTC)
    We already have a generic message about the milestone on Template:Main Page banner, which is enough IMO; we don't need to link to any specific article in that message, especially when it isn't the true [x]-millionth article but one chosen by a small group of editors to "represent" it. Some1 (talk) 15:46, 1 June 2025 (UTC)

    A different type of portal

    I've created a draft of a different type of portal at User:Thebiguglyalien/Portal sample that may be more viable than previous iterations. Could use feedback at User talk:Thebiguglyalien/Portal sample. Thebiguglyalien (talk) 🛸 19:33, 3 June 2025 (UTC)

    the sections "Facts about yourself" and "Interests"

    I suggest removing the "informative" introduction from the titles of the distinctive signs.

    Now this looks like :

    • This user ...
    • This user ...
    • This uset...

    -- it's impossible to read it. And it gets more annoying the more details the participant has revealed about himself. Thank him for that, but it turns out the opposite. Can specify "This user ..." once at the beginning of the section, as you wish. But I'm personally against it. It's not worth explaining the obvious.. Of course, there is a possibility that the reader may attribute these achievements to himself :).

    There are no similar entries in the section "Orders, badges and medals" :

    • The user has earned the medal ...
    • The user has earned the medal ...
    • The user has earned the medal ...

    Very similar in Windows releases:

    --- Errors fixed section ---

    • fixed an error that ...
    • fixed an error that ...
    • fixed an error that ...

    Readers, and I, have the impression that the text was written for fans from nursing homes, or the payment for the text is made for the number of letters. There are other analogies for similar deviations from brevity and reasonableness. But this is on request. I think Wikipedia is not the place for them.

    The English-language original "user" has 4 letters. It's still bearable. In other languages, the analog can be 2+ times longer (user, participant, member, ...).

    I propose to adduce the sections "Facts about yourself" and "Interests" to the form of the section "Orders, badges and medals" Seregadu (talk) 16:22, 17 May 2025 (UTC)

    Hi! Which pages are you talking about? Can you give us an example? Chaotic Enby (talk · contribs) 16:28, 17 May 2025 (UTC)
    Each Wikipedia participant (who provided this information about themselves) has these sections -- "Facts about yourself" and "Interests". Seregadu (talk) 16:30, 17 May 2025 (UTC)
    I'm guessing you're referring to userboxes, which usually start with "this user"? Userboxes are commonly used because they're a consistent and convenient way for editors to display information, but they are completely optional and editors can format this information however they want. "Facts about yourself" and "Interests" sections are also optional, along with "awards" sections. Helpful Raccoon (talk) 21:45, 18 May 2025 (UTC)
    Except nobody actually writes "Facts about yourself" in such cases, and almost nobody writes "Facts about myself". WhatamIdoing (talk) 21:49, 18 May 2025 (UTC)
    @Seregadu, could you paste a URL to the page where you see "Facts about yourself"? I have no idea what you're talking about. WhatamIdoing (talk) 21:46, 18 May 2025 (UTC)
    show more analytical skills before asking questions. Remember your own actions in the past. Here is the link you are asking about. -- https://en.wikipedia.org/wiki/User:WhatamIdoing Seregadu (talk) 22:00, 18 May 2025 (UTC)
    @Seregadu Please be civil. At no point have you actually used the word "userpage" which would give people an idea of what you're talking about. Cremastra (u — c) 22:05, 18 May 2025 (UTC)
    @Seregadu, the words "Facts about yourself" or "Interests" are not on that page, nor is there any section called "Orders, badges and medals". WhatamIdoing (talk) 00:10, 19 May 2025 (UTC)
    I admit that this is also surprising to me, I assumed that this is a standard template for all Wikipedia users.
    I didn’t invent the names of the sections myself, I copied them from another user, it was difficult for me to read "This user ..." several dozen times. In Russian it is longer. My post is about this.
    If the section titles are edited and they are not templates, let them. It's not that important. As a Wikipedia user, I am not satisfied with dozens of copies. My post for discussion. Seregadu (talk) 04:15, 19 May 2025 (UTC)
    Are you asking about userpages at the Russian Wikipedia? I can't find the names of those sections here at the English Wikipedia.
    Here at the English Wikipedia, there is no standard template for User: pages. You write whatever you want. WhatamIdoing (talk) 04:22, 19 May 2025 (UTC)
    If you ask, I can copy my 2nd post for you again. I wrote about templates that are not set by the Users themselves.
    Leave the Russian Wikipedia alone. If I wanted to talk about the Russian part, I would write there.
    The templates are the same for everyone. I don't have these sections, because I don't fall under my own 2 post on this topic. Seregadu (talk) 04:31, 19 May 2025 (UTC)
    There are no templates or pages at the English Wikipedia (except for your post on this page) that contain the words "Order, badges and medals". Look at the search results. If that existed at the English Wikipedia, then there would be pages in the search results. WhatamIdoing (talk) 04:42, 19 May 2025 (UTC)
    I think we've seen enough here. Unless and until Seregadu identifies which templates on the English Wikipedia they are talking about we should follow WP:DNFTT. Phil Bridger (talk) 07:39, 19 May 2025 (UTC)
    I agree with you - everyone has already seen enough. Enough to assess your abilities.
    1. My theme is about user profiles. This is an area that can also be changed globally and improved. This is not a closed topic for discussion.
    2. Most Wiki users have the "This user..." template.
    3. I don't have this template - I did not fill them out, I do not know how to do it, and I will not do it because of my low interest in my self-presentation. (I know some HTML, CSS, and JS pretty well, but the Wiki has a hard time learning how to install "templates". So , you will improve the Wiki, in terms of templates ?
    4. You don't have this template. Your page has a redirect to your "User talk page". This is your right. But the result for other is equival for you and me -- the absence of a "User page". So maybe you're a TROLL like me. ?. Seregadu (talk) 02:53, 29 May 2025 (UTC)
    There are no set templates for User pages. Unless you can provide a link to specific examples, it is impossible to understand what you are trying to talk about. CMD (talk) 03:10, 29 May 2025 (UTC)
    It's amazing to me. Everyone keeps saying they don't see any patterns.
    It seems that the Wiki forms the output of templates for me alone, which others do not see. It has something to do with the discussion of other participants. I would have pointed to my page a long time ago, but I don't see a template installation mechanism there like the others. This is also a Wiki flaw that needs to be improved.
    I set for me an obvious template {{ rus }} -- (This user speaks Russian) or (This user has Russian as his native language), but it didn't work.
    Okay, now I'll show you the page of any participant in this conversation, if He/She came here self. Seregadu (talk) 03:27, 29 May 2025 (UTC)
    {{rus}} is a template for the names of sports stadiums and should not appear on any User: page.
    {{User ru}} is one of the (optional) Wikipedia:Userboxes for people who claim to speak Russian. However, for languages specifically, it's better to use the Wikipedia:Babel system. WhatamIdoing (talk) 03:43, 29 May 2025 (UTC)
    Babel --- this is layout for Wiki ? This is the first time I've heard this. I see class="wikipediauserbox"
    Wiki is reflected in HTML, of course, also PHP, I did not notice Markdown. But I haven't even heard of Babel. Seregadu (talk) 03:54, 29 May 2025 (UTC)
    No, it is not layout.
    All wiki pages are written in a markup language called wikitext. You have used this in some of your edits. You can see it in use on your User_talk:. WhatamIdoing (talk) 03:59, 29 May 2025 (UTC)
    CMD , You have 3 tamplate "This user ...". Do you see them? Do you remember the time when you installed them? Tell me, I do not know this process.
    You have 3 of them. There are pages of other participants who have 50+ of them. They take up 2 screens.  And they all start with words "This user ..." , that all readers SKIP. If they are skipped, maybe they are not needed? Before can understand the participant's identity, need to skip 10 letters. Seregadu (talk) 03:41, 29 May 2025 (UTC)
    Above, you said that "Each Wikipedia participant...has these sections -- "Facts about yourself" and "Interests"". However, it appears you didn't actually mean that everyone has a section with these words; instead, you meant "some stuff on the page" without these words.
    What you describe with the Russian language example is a userbox. The wording is traditional. You are not required to use the traditional wording. You can make your own personal copies.
    There is no "template installation mechanism". Userboxes are added the same way that infoboxes or navboxes are added to articles. If you want to see this:
    This user likes Chocolate
    on your User: page, then you type {{User:Pratyya Ghosh/Chocolate-1}} on your User: page.
    If you don't like the wording, you can pick a different one, e.g., {{User:I'm Aya Syameimaru!/chocolate}}, which says:
    Chocolate! ;PYum!
    or you can build your own from Template:Userbox. WhatamIdoing (talk) 03:54, 29 May 2025 (UTC)
    great, here's another suggestion:
    for all users, at the start, to install in the user page one such template in red/yellow/green with a link to Wikipedia:Babel Seregadu (talk) 04:05, 29 May 2025 (UTC)
    Unlike most other languages of Wikipedia, a very large number of editors here only speak English. Therefore, if you want to have such a tool, this is the wrong wiki to be asking it at. WhatamIdoing (talk) 16:31, 29 May 2025 (UTC)
    Wiki constantly amazes me with the difference of opinion, even to the point of being unable to understand the other person. Or he can't understand me.
    I wrote about user pages with 50+ such badges. And each of them begins with the words "This user ...". What does English have to do with it? Seregadu (talk) 17:02, 3 June 2025 (UTC)
    Why would the mostly monolingual English community want to have "a link to Wikipedia:Babel" (something that is for multilingual people)? WhatamIdoing (talk) 17:50, 3 June 2025 (UTC)
    I got it. I initially gave the wrong direction and got the wrong link. I was not talking about languages. Not about the advantages of English over others. Or vice versa. I thought that Usebox is part of Babel. No. Above you have given the correct link. Userbox. I only talked about this.Seregadu (talk) 09:11, 4 June 2025 (UTC)
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_66&oldid=1295594951"