Wikipedia:Village pump (idea lab)/Archive 66

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:

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:

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)

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 beas 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 meansThe 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

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

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)

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:

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:

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:

${\displaystyle \forall \;person\in Society:FullDateIsNotAnnoying(person)}$

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. GMG^talk 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:

   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. GMG^talk 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

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)

• We certainly need to resist the temptation to overload the opening sentence with details. Mixed opinion on whether dates are helpful or not. Blueboar (talk) 15:56, 2 April 2025 (UTC)
• It's Snow-ing, should this be closed? Aaron Liu (talk) 11:30, 3 April 2025 (UTC)

  Does it need to be? This is the idea lab, not proposals, and no one has bolded a !vote so far. Dr. Duh 🩺 (talk) 12:25, 3 April 2025 (UTC)

  Wikipedia:Manual of Style/Lead section#Biographies' first sentence already says (highlighting added by me):

  • Dates of birth and death (if found in secondary sources – do not use primary sources for birth dates of living persons or other private details about them). If specific day–month–year dates for birth/death are given elsewhere in the article, then a simple year–year range may be sufficient to provide context

  so I'm not sure there is anything to be done, except to remember that this is the rule (and probably has been for a long time?) and actually start applying it. WhatamIdoing (talk) 06:11, 13 April 2025 (UTC)

  That isn't a rule, even aside from the fact that the MoS is just guidance, it explicitly says "may be sufficient" (my emphasis). I'd argue that in the great majority of cases that it isn't sufficient, it's there to allow for situations like "circa March 1890" when explaining the circa and the possible dates takes several sentences. Thryduulf (talk) 07:43, 13 April 2025 (UTC)

  We should consider psychological theories in this field, possibly cognitive ones. A "readable article" is one that is suitable for human minds. The "Occam's razor" is one example. Hooman Mallahzadeh (talk) 07:58, 13 April 2025 (UTC)

  As repeatedly explained to you, occam's razor is completely irrelevant to this discussion (it does not mean what you think it means). As forA "readable article" is one that is suitable for human minds I'm utterly confused about what point you are trying to make - the presence or absence of a full date vs an approximate date does not impact the readability of an article for humans. Thryduulf (talk) 08:10, 13 April 2025 (UTC)

  Yes, I'm sure it impacts. But for proving it, we need some psychological tests.

  In every article, we should first provide "Less but most important" information, and then we should elaborate less important data in other parts.

  This is the psychological idea of "Sketch" or "prototype". Do you disagree? Hooman Mallahzadeh (talk) 08:24, 13 April 2025 (UTC)

  Thryduulf, which of these first sentences do you think would be easier "for human minds" to read?

  • Pablo Emilio Escobar Gaviria (/ˈɛskəbɑːr/;Spanish: [ˈpaβlo eskoˈβaɾ]; 1 December 1949 – 2 December 1993) was a Colombian drug lord.
  • Pablo Emilio Escobar Gaviria (1949 – 1993) was a Colombian drug lord.

  or

  • Catherine de' Medici (Italian: Caterina de' Medici,pronounced [kateˈriːna de ˈmɛːditʃi]; French: Catherine de Médicis,pronounced [katʁin də medisis]; 13 April 1519 – 5 January 1589) was an Italian (Florentine) noblewoman.
  • Catherine de' Medici (1519 – 5 January 1589) was an Italian (Florentine) noblewoman.

  or

  • Frédéric François Chopin (born Fryderyk Franciszek Chopin; 1 March 1810 – 17 October 1849) was a Polish composer and virtuoso pianist of the Romantic period.
  • Frédéric François Chopin (1810 – 1849) was a Polish composer and virtuoso pianist of the Romantic period.

  or

  • Muhammad Ali (/ɑːˈliː/; born Cassius Marcellus Clay Jr.; January 17, 1942 – June 3, 2016) was an American professional boxer and social activist.
  • Muhammad Ali (1942 – 2016) was an American professional boxer and social activist.

  I pick the second version every time. The pronunciations can be put in the infobox. The birth names can appear in both the infoboxes and the ==Early life== sections. And so forth. Obviously, in an under-developed stub, there won't be other places to put this information, but in well-developed articles, I think that simplicity and focus is appropriate. The first sentence shouldn't get stuffed full of everything. WhatamIdoing (talk) 04:27, 14 April 2025 (UTC)

  I find pronunciations very important. You can't really put pronunciations in an infobox as well because often you only need to spell out the pronunciation of one part of the bolded text, and putting it in the body is much harder to find if the subject's common name is not their real name. Aaron Liu (talk) 16:17, 14 April 2025 (UTC)

  I prefer MOS:PRONFOOT as a solution. Schazjmd (talk) 16:33, 14 April 2025 (UTC)

  That also makes sense. Aaron Liu (talk) 16:37, 14 April 2025 (UTC)

  That (MOS:BirthDate) seems rather divorced from the current practice where every single person whose dates are known have the full date spelled out, even the example BirthDate gives (William A. Spinks). Aaron Liu (talk) 15:19, 13 April 2025 (UTC)

  The continued responses here that do very little are why. Aaron Liu (talk) 15:12, 13 April 2025 (UTC)

  Phineas Gage also limits the first sentence to just the years (see Talk:Phineas Gage/Archive 8#Inclusion of full birth and death dates in opening-sentence parenthetical). Personally, I'd include them for consistency's sake.

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:

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:

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:

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.

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)

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:

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)

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)

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)

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.

Gettingimplicit 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)

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" followed by an image caption that says "Cupcakes are sold at fundraisers". 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)

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)

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)

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:

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 thatoccasional 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 saysWikipedia 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)

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)

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

Submission rejected. This draft is contrary to the purposes of Wikipedia. The reviewer(s) who rejected this submission will be listed in the page history. Last edited by Lowercase sigmabot III 9 seconds ago. Ask for advice

Other AfC submission notices

Submission declined. No improvements have been made since this draft was last published. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs The reviewer(s) who declined this submission will be listed in the page history. Last edited by Lowercase sigmabot III 9 seconds ago. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

Submission declined. This draft fails WP:GNG. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs The reviewer(s) who declined this submission will be listed in the page history. Last edited by Lowercase sigmabot III 9 seconds ago. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

Submission declined. This draft does not demonstrate the subject's notability. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs The reviewer(s) who declined this submission will be listed in the page history. Last edited by Lowercase sigmabot III 9 seconds ago. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

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. Submission declined. A decline notice is not supposed to be this narrow. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs The reviewer(s) who declined this submission will be listed in the page history. Last edited by Lowercase sigmabot III 9 seconds ago. Resubmit Please note that if the issues are not fixed, the draft will be declined again. This is apparently an issue with the {{ombox}} template itself. I found out that when I copy-paste the source code of {{AfC submission/declined}} into a sandbox and replace ombox with {{fmbox}}, it makes it wide, but now this box seems a bit wider than the experimental demonstrative red (or, should I say, very light pink) box above.

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:

Submission declined. The reviewer(s) who declined this submission will be listed in the page history. Last edited by Lowercase sigmabot III 9 seconds ago. Please note that if the issues are not fixed, the draft will be declined again.

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:

Submission declined on X Quintillis by N. Clement Weathers (talk). I apologize for the harsh comments left by the previous reviewer, but they do have a valid point about the quality of the sourcing. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by N. Clement Weathers 13 jiffies ago. Last edited by Lowercase sigmabot III 9 seconds ago. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

Prior draft decline notices Submission declined on IX Quintillis by Tertius Magertius (talk). This draft has already been submitted a bazillion times and it still doesn't contain enough significant freaking coverage in independent reliable secondary sources to comply with Wikipedia's general notability guideline. For the love of all things holy, if this half-baked garbage gets submitted without any major changes one more time, I will reject the living daylights out of it under the snowball clause and nominate it for deletion just so (Personal attack removed) won't be able to waste our time anymore. Declined by Tertius Magertius 1 moment ago. Last edited by Lowercase sigmabot III 9 seconds ago. Please note that if the issues are not fixed, the draft will be declined again. Submission declined on VIII Quintillis by Tertius Magertius (talk). Come on, we've been over this for the umpteenth time in a row. You can't just submit the exact same draft with the exact same contents over and over again and expect the outcome to change, that's literally the definition of insanity. What makes you think other reviewers would accept this? This draft does not demonstrate that the subject meets the general notability guideline. Declined by Tertius Magertius 2 moments ago. Last edited by Lowercase sigmabot III 9 seconds ago. Please note that if the issues are not fixed, the draft will be declined again.

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)

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)

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)

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)

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)

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)

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)

• The original proposal seems like a good idea. I think "additional considerations" should be the purple one. Toadspike [Talk] 00:40, 19 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 incubatenew 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)

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)

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)

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)

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:

• 15 April 2021: Wikipedia:Village pump (proposals)/Archive 174 § Move good/featured article topicons next to article name closed as no consensus
  pinging Jr8825 as proposer
• 1 February 2023: Wikipedia talk:Good Article proposal drive 2023 § Proposal 21: Make GA status more prominent in mainspace consensus to have an RfC on increasing visibility
  pinging czar as proposer
• 1 March 2024: Wikipedia:Village pump (proposals)/Archive 211 § Proposal: Remove the topicons for good and featured articles closed as snow keep, article quality important to readers
• 14 April 2024: Wikipedia talk:Good article nominations/Archive 31 § Proposal 10: Finish doing some or all of the things we agreed on last time we did this (lol)
  pinging Thebiguglyalien as proposer
• 11 January 2025: Wikipedia:Village pump (proposals)/Archive 216 § Good Article visibility requesting the topicons in mobile, which is currently being worked on at phabricator:T75299
  pinging Iskandar323 as proposer

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)

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)

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)