The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
This is a high-visibility page intended for proposals with significant impact. Proposals that affect only a single page or small group of pages should be held at a corresponding talk page.
Hello everyone, I was told by the Wikimedia foundation email to direct my query here.
Recently I have seen an influx in what I call “dud-articles”, by this I mean articles that people try to make about themselves, their company, their mother etc. and I believe that this wastes our users’ time, declining and reading these pages, so on the Teahouse I suggested a new system, a disclaimer on the account creation page, saying something along the lines of:
”If you are coming to Wikipedia to write about yourself, a family member, business or influencer please reconsider and refrain from making such articles”
Even if that was the deter only one person that would still be an improvement. I did get support for this idea on the Teahouse from other users on this issue.
I'm personally for the harsh wording. being soft about it seems to make the kind of editors that need this warning think they can be an exception to the rules. The amount of times I've seen these WP:NOTHERE types try to argue something isn't technically against the rules because we try to not speak in absolutes is laughable mgjertson (talk) (contribs) 20:28, 8 January 2026 (UTC)[reply]
Cease and desists letters and mortgage letters can certainly be pretty harsh, or intimidating- but I don’t think we want too harsh or too soft, a middle ground half way would be the ideal solution. Mwen Sé Kéyòl Translator-a (talk) 10:10, 12 January 2026 (UTC)[reply]
Anything we say on the sign-up page should be policy-based and link to the policy. Imho a WP:LOCALCONSENSUS here is not strong enough for changing what every new user sees as "instructions" for signing up from now on. I think we could say that it is discouraged, but not that they cannot do it, unless we change policy first, to change 'discouraged' to 'must not' and arm it with some teeth with what kind of sanctions happen if they do so anyway. Mathglot (talk) 03:58, 6 January 2026 (UTC)[reply]
Perhaps something not as harsh, I believe the policy says that writing about yourself is discouraged, and is a COI, so perhaps it could say “Please note, writing about yourself, your company or another close topic to you is discouraged and if you do decide to join to write a page on these please reveal your Conflict of Interest”
Not recommending sanctions at all; what I was trying to say, is that you ought not say a user must not do something on the sign-up page, unless the policy page supports that; the flip side is that if you want to say 'must not' here, then the policy page must be changed first. I wouldn't support that, just explaining what's dependent on what. Hope I am being clearer, but if not, I blame the wine. Mathglot (talk) 10:00, 6 January 2026 (UTC)[reply]
Oh sorry I completely understand you now. I think a good compromise is recommending not to (discourage), that doesn’t stop someone, but one or two people might instead look at the rules, or decide not to write that page on their mum, or their dog, or their favourite TikToker etc. Mwen Sé Kéyòl Translator-a (talk) 10:19, 6 January 2026 (UTC)[reply]
Just saying it's discouraged doesn't stop the kind of people it needs to. Regardless of whether or not it's technically possible, we need to state clearly that they can't do that as they don't have the needed experience to do it to the level needed mgjertson (talk) (contribs) 18:57, 26 January 2026 (UTC)[reply]
I would be opposed to adding any extraneous information or links to a sign-up page that are unrelated to signing up for an account. Once they are signed up, they are automatically assigned a mentor, and often (but not invariably) receive one of the welcome templates maintained by the Welcoming committee. A link to Help:Your first article is present in 23 different welcome templates, including the most popular template {{Welcome}}, which is present on the talk pages of over 600,000 users. Also, the sign-up page disappears after they are signed up, and they lose the link, whereas their User talk page remains, and they can consult the links anytime. Mathglot (talk) 02:49, 8 January 2026 (UTC)[reply]
At face value, this seems like a good idea. But as with any idea, there could be unintended consequences:
Thousands of new accounts are created every day. Most of those accounts never make an edit. Do we really need to show all these people this additional information? Would a scary warning message discourage users who never intended to edit promotionally at all?
Most accounts never engage in promotional editing. By showing everyone a message telling them not to do it, we may give them ideas that they previously didn't have.
If we imply that these people shouldn't create an account, will they simply make promotional edits without an account (from TAs) instead?
I mean in life people are told not to do crime, or “do not steal” or “employees only” signs, and most abide, it doesn’t discourage someone from living their life or going into a shop as they know they won’t do what the signs tell them not to do. I don’t think we would give them ideas, because they would know it will be declined hence the warning, thirdly I do see your last point about TAs instead, but TAs can’t make pages I believe so that cures the issue.
Most don't "abide" because they read a sign that says "Don't steal"; they were never going to steal anyway. Vandals gonna vandalize, no matter what words you add (which they will skip). I question whether there is any point to a wording change at all, especially wording they will see once, and never again. Mathglot (talk) 22:22, 11 January 2026 (UTC)[reply]
I do so what you mean, but perhaps there would be users who simply don’t know that Wikipedia isn’t a sort of LinkedIN or Instagram and would stop when told, like people on the Teahouse who accept their mistakes and don’t continue with the page on themselves, a family member etc.
Has anyone called for any stats (easily done) to find out just how often such articles that people try to make about themselves, their company, their mother etc. actually arrive in the NPP feed or even asked the 800-strong NPP community? They are dealt with swiftly at CSD. There are dozens of other totally worse articles that creep in under the radar of the less experienced patrollers. Kudpung กุดผึ้ง (talk) 14:36, 11 January 2026 (UTC)[reply]
The initial proposal probably doesn't say what the OP intended. The wording of the initial proposal includes "yourself, a family member, business or influencer". It doesn't say "your business", and therefore it includes any business and any influencer – including, e.g., Microsoft and MrBeast.
@Kudpung, I second your idea about getting more information. I sometimes wish for a list of research ideas (e.g., for grad students in search of ideas). I wonder what we would learn if someone contacted the last 50 companies for which articles were created, and said "I'm doing research and would love to know what it took to get your Wikipedia article and if you have any advice for other companies". How many would say "We hired ScammersRUs" or "We just had an intern write it"? How many would say they were unaware of it having been created? WhatamIdoing (talk) 22:54, 11 January 2026 (UTC)[reply]
Apologies for not being clear, I do mean “your business” and not all influencers (as some now warrant a page, like Mr Beast). I may have a talk with the NPP team and see if they have any stats on this matter. Mwen Sé Kéyòl Translator-a (talk) 10:15, 12 January 2026 (UTC)[reply]
You could also ask the approx. 200-strong (and growing) Wikipedia Mentor community. Anecdotally, I see more autobiographies and my-band/my-biz articles on new account User pages (not subpages) than I do appearing in Draft space (marked for submission or not). Besides welcoming new users, I also hang out at thhe WP:Teahouse and often see them there as well. Data is always a good idea, and if you want to measure something, draw up a null hypothesis and a proposal for an A–B test where half of new attempts get a create account page including the text you want to measure (A), and the other half (B) do not, and let them run it for a few months. Later, you can analyze the data and see what happened. Keep in mind that things may not go the way you want: one possible outcome (besides adherence to guidelines) is that A numbers go down, while B numbers stay the same. Then you'd have to argue whether that's a good thing, if A folks who went on to complete registration ended up adhering to the rules a bit better. Mathglot (talk) 00:06, 12 January 2026 (UTC)[reply]
I think that if someone thinks it's harmless fun to create an article about their pet rabbit (real example), they wouldn't have stopped to read a sign-on notice, just like many of us ignore the "terms and conditions" when shopping. If someone is determined for some reason to promote a person, place or whatever, they'll do it in any case. A sign-on notice wouldn't deter them. Also, in general, how much do we think of editors being in a contractual relationship with Wikipedia? If we do think of it that way then, yes, terms and conditions apply. If we think of it more as an informal personal relationship then it's more about assuming good faith, trusting and forgiving, but accepting we'll have to spend time – maybe too much time? – working on the relationship by debating the case for or against every silly or promotional article on a trivial subject. --Northernhenge (talk) 16:47, 14 January 2026 (UTC)[reply]
Yes but a large warning on the sign up page will have to be read, because it’s in your face, not some small Terms and conditions text (which I will admit I’ve never read). I don’t want to dissuade people from editing, but even a polite notice might deter a few who were going to make pages on themselves or what not. Then again most always feel like they are the exception and will try and try and try, so most probably will read the disclaimer and continue on regardless. Mwen Sé Kéyòl Translator-a (talk) 18:03, 14 January 2026 (UTC)[reply]
Gosh there really is a Wikipedia page for everything 😂 perhaps we just need a big flashing words on the screen that blocks the sign up page until you read it fully like that smiling virus thing (I’m joking btw. I wouldn’t go that extreme). Mwen Sé Kéyòl Translator-a (talk) 09:09, 15 January 2026 (UTC)[reply]
They never have let me use blink text on wiki, but we sometimes get to use big red text.
If you wanted to work on warnings for creating articles, then that should appear when you click the [Edit] button. It might be possible to put something into the software itself. Imagine something that triggers if the edit count is <50, and now you have to answer a few simple questions before it will let you proceed. WhatamIdoing (talk) 23:14, 15 January 2026 (UTC)[reply]
Realistically, non-trivial software development requires a budget allocation and then time to actually do the work. It's January now, so the best-case scenario would be to join the annual budget planning process (which is starting now), and to have a team assigned to begin work in July (beginning of the new fiscal year) and then maybe to have something to test next calendar year. But "years" is more likely. WhatamIdoing (talk) 22:38, 17 January 2026 (UTC)[reply]
@WhatamIdoing. This is the fundamental problem when WMF intervention is needed for a just few lines of code on something critically important but because it was a community idea and not their own, they find any excuse not to entertain it. They also appear to have a strong opinion that because they are paid for what they do, nobody among the tens of thousands of volunteers has any technical clue even though some of us have done MediaWiki installations or built extensions ourselves. This comes down to even throwing a simple switch on one of the default prefs on a MedWiki package. AFAIK, the registration page has jealously guarded WMF access only. Kudpung กุดผึ้ง (talk) 05:56, 18 January 2026 (UTC)[reply]
A user project is in the making to address precisely the registration page which by offering a few simple words of very short text in the nicest possible way, would channel new users to through a new route that at the same time would not only prevent the creation of nonsense articles, but also provide much better on-boarding and truly interactive help than the current development at the WMF which is in its 3rd (or fourth?) year with limited success. Kudpung กุดผึ้ง (talk) 22:22, 14 January 2026 (UTC)[reply]
Sounds interesting; can we please get a link to 'project is in the making'? Also, what is the the current development with limited success in its 3rd/4th year? Thanks, Mathglot (talk) 00:22, 15 January 2026 (UTC)[reply]
@KeyolTranslater. Saw your request at WT:NPR. The best place to go for stats is probably Wikipedia:Request a query. I would suggest taking a sample size of a recent month and asking for a breakdown of articles deleted under G1, G2, G3, G10, A1, A3, A7, A9, and A11. These are the WP:CSD criteria, broadly construed, that address your proposal. It's fair to assume that most CSDs are tagged at NPP. You may then have to parse them manually to fit your criteria, but it's something we all have to do when we want to back up our claims with data. It would also be an excellent exercise if you are thinking of embarking on a career as an NPPer. There are roughly 800 rights holders, less than 10% are truly active, and the backlog is in its worse crisis for years, a lot of help is needed. If you were to obtain those stats it would also be really useful on several nascent ideas. Kudpung กุดผึ้ง (talk) 22:13, 16 January 2026 (UTC)[reply]
@KeyolTranslater. @Mathglot. On the premise that G11 and A7 are the main reasons for the majority of deletions, these numbers now need to be looked at from the perspective of two audiences: 1. The creators, 2. The curators (i.e. NPP) and how any change in the wording of the interface might:
Discourage/Deter new users from creating something that is highly likely to be deleted
Provide some relief for the NPPers by reducing the overall number of new articles in the daily feed.
Unless I'm missing something, I don’t see any significant rises/falls in the numbers of deletions over the 3-year sample (G15 is a very new criterion), but what is important now is to see how these deletions correlate to a rise/fall in new article submissions over the sample period and decide if a change in wording would have sufficient impact on the new users and ultimately - which IMO is more important - reduce the workload at NPP.
For reasons I have not been entirely able to pinpoint, despite the strong number of NPP rights holders (now around 800) since the right was created in 2016, the NPP system has been reduced to pattern of backlog drives having become the rule rather than the exception, and why enough interest cannot be generated in patrolling new pages to keep a flat line backlog at a sustainable level. Perhaps the thread at Investigating the cause(s) of backlogs explains much of it and maybe Novem Linguae has some suggestions. Kudpung กุดผึ้ง (talk) 20:09, 17 January 2026 (UTC)[reply]
I was informed that there isn’t a large database for AFC submission declines unfortunately, which would’ve really helped, the statistics above are merely NPP deletions and therefore are by confirmed users who will just publish their article, not new editors (who seem much more likely to make pages on the criteria above). Mwen Sé Kéyòl Translator-a (talk) 08:55, 18 January 2026 (UTC)[reply]
@KeyolTranslater. I don't think declined AfC submissions will skew the results much. It depends on what percentage of new articles in the sample period are received into AfC. There are two types of AfC: ones moved to draft at NPP because they have the potential to reach mainspace if more sources are added or if the text is cleaned up, and articles that are created immediately as drafts which are probably the most likely to be deleted. The latter are possibly quickly dealt with under A7 and G11, while both kinds can end up at G13 (abandoned drafts). If you can get them, it might be interesting see how many drafts get deleted at A7 and G11, but G13 is best left out of the equation as it would be hard work to parse them into different types. Kudpung กุดผึ้ง (talk) 18:20, 18 January 2026 (UTC)[reply]
I would sooner see a sign-up warning about not using your real name than about not signing up to edit in a promotional manner. But frankly, any sort of message like that would discourage people, and we desperately need new editors. Its easy to deal with promotional pages, and in the process teach those people about how Wikipedia really works. With luck, some of them will actually write decent articles or become editors. CaptainEekEdits Ho Cap'n!⚓22:17, 22 January 2026 (UTC)[reply]
Opposed. I have to agree with CaptainEek. Having read and participated here, I am coming down formally as opposed to the whole idea of a sign up page disclaimer. Anything we say that might discourage a new editor from registering is a bad idea. I'd rather see ten new vandals and COI-only editors registering along with one good encylopedia-building candidate, than none of them. As part of my volunteer work as a mentor, I see those ten regularly (and I bet CaptainEek, as mentor #24, does too), and I don't want to lose the one good editor for the sake of making my life easier by not having to deal with some clueless or bad apples. (Also opposed to real name warning.) Willing to modify my position if new information is brought to light, but this is where I stand now. Mathglot (talk) 22:51, 22 January 2026 (UTC)[reply]
I agree with both your and @CaptainEek‘s opinions, however I doubt it would discourage most proper editors, I have seen new editors come and make wonderful pages, or pages they are passionate about. If I saw a banner which said “No promotional editing” (with a proper description of COI editing) I wouldn’t be bothered because I know that’s not what I came to do, however I may be biased in such example, each to their own. Mwen Sé Kéyòl Translator-a (talk) 09:09, 23 January 2026 (UTC)[reply]
I think everyone here is on the same team: we are all working to improve the encyclopedia, and to acquire and retain good editors. Regardless what path is taken, thank you for bringing your concerns and your ideas here for discussion. Mathglot (talk) 19:29, 26 January 2026 (UTC)[reply]
I mostly agree, but some people genuinely don’t know the rules and on the sign up page I believe a disclaimer could make some people change their minds about making a page on themselves, their dog, their company (if it isn’t notable) etc. But like I said earlier I’m happy to hear other’s thoughts Mwen Sé Kéyòl Translator-a (talk) 12:25, 28 January 2026 (UTC)[reply]
I think the following conditions should be met if it is something local yet to be created on WP:
A) They have to be relatively popular within the sub-division of whatever they are from (e.g. Tottenham or Fulham in London is an example of the type of subdivision, or even Telford & Wrekin in Shropshire)
B) If A) does end up being the case, and it is local, GET THEIR PERMISSION!! I feel that if you can request it, whether via email or in person or something, it could help your case significantly, but you may still have it taken down if it isn't noteworthy enough.
C) If it is just some average bloke, don't bother unless they have some actual achievement within a local area, and no, something like being the millionth person to climb the Wrekin doesn't count as noteworthy, as an example
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
baby globe
to celebrate wikipedia's 25th anniversary, a toggleable "birthday mode" has been created. it consists of easter eggs involving baby globe, such as having it scroll a phone in the top right of an article while the reader scrolls down an article. more details can be found on the linked page. if the feature is enabled, by 26 january, administrators can configure the mode through community configuration; and the mode will be public from 16 february to 16 march (an administrator will have to turn on the feature on the day itself).
enabling the feature requires "a consensus from your community", so i have brought it here to ascertain the community consensus. (there was some previous discussion on Wikipedia:Village pump (miscellaneous)/Archive 86 § Easter eggs, but it was archived without further action.)
should english wikipedia enable the 25th anniversary birthday mode, and if so, should it be on by default?
option 1: enable birthday mode, and have it on by default
option 2: enable birthday mode, and have it off by default
option 1 > option 2, oppose option 3. i think it would be a shame if the largest wikipedia did not participate in the celebration. i'd also prefer it to be on by default, as people generally don't change default settings, but i'm fine either way. ltbdl (skirt) 19:19, 17 January 2026 (UTC)[reply]
Support option 1 > option 2, oppose option 3 per ltbdl. This is an excellent feature that our readers will hopefully enjoy. It also fits nicely with one of our goals in recent times, which has been to emphasize the human aspect of Wikipedia. Toadspike[Talk]20:41, 17 January 2026 (UTC)[reply]
Option 2 Per Thilio. Suggest that greater consideration be given to limits on the number of top-of-page distractions we allow. I also wouldn't mind a shorter period.--Wehwalt (talk) 21:10, 17 January 2026 (UTC)[reply]
Second choice is 3. I feel the case can be made that we're being very self indulgent in patting ourselves on the back in ways that do not benefit the reader. Wehwalt (talk) 15:17, 19 January 2026 (UTC)[reply]
Option 1 Agree with Chaotic Enby that this is contingent on having a readily available (and known--e.g., included in banner announcement of easter eggs) method to disable. — rsjaffe🗣️21:13, 17 January 2026 (UTC)[reply]
Option 1 let's have fun for once, 25 year anniversaries don't happen very often. Yes it's quirky, correct some people won't like it, but this is only temporary. Let's celebrate in style and get noticed for it. CNC (talk) 20:09, 18 January 2026 (UTC)[reply]
Option 3 unless we have a lot more information. I wouldn't like to see a confetti-throwing Wikimedia globe appear on the page for some disaster- or genocide-related page with massive viewer numbers. The linked Wikimedia page doesn't inform me sufficiently about what to expect. Fram (talk) 10:32, 19 January 2026 (UTC)[reply]
option 1, it's toggleable by the user and doesn't affect the actual contents of the page (thinking back to the grimace mcdonald's wiki incident) Jaidenstar (talk) 17:43, 19 January 2026 (UTC)[reply]
option 1. No one will notice it if it's not on by default. And Baby Globe is great. It would be a shame not to participate in the birthday celebrations. -- asilvering (talk) 04:27, 24 January 2026 (UTC)[reply]
Option 1 – I was hesitating due to the concerns that Fram raised, but now that @CDekock-WMF has shared the table of different page queries and configurations, I feel reassured that a lot of thought has gone into context-aware presentation of the mascot. ClaudineChionh (she/her · talk · email · global) 22:45, 19 January 2026 (UTC)[reply]
Option 1 - Like Fram, I had some concerns about showing a celebratory globe on pages for horrific actions, but I am confident in the solution provided by the Foundation for that. So, yeah, after 25 years I think we can celebrate for a bit. LightlySeared (talk) 12:21, 20 January 2026 (UTC)[reply]
Option 2 - it's very cute and fun, but I think it's more of a clever Easter egg when it's not available by default -- Easter eggs are by definition hidden. I think it would likely become more popular and talked about if it's "a cool special feature to add" versus "some thing Wikipedia put on pages." People like having agency. Option 1 is my second choice. ✨ΩmegaMantis✨(they/them) ❦blather | ☞spy on me17:50, 20 January 2026 (UTC)[reply]
Option 1 - per above.Option 2 - I'm unsure how this would affect printable versions and whatnot, so I would prefer if it was disabled by default. (It would make it more of an Easter egg as well, per ObserveOwl.) The Wikidata configuration shared above is useful. Also, it's been 25 years, so why not? Jude Halleytalk/contribs13:18, 21 January 2026 (UTC)[reply]
Option 2 Please, please don't put animated stuff on pages by default; it's distracting and makes it much harder for me to focus on the content that I am trying to read. Thanks. --David10244 (talk) 05:48, 22 January 2026 (UTC)[reply]
Option 2. I'd suggest send a notification to users on the website to indicate its now available, or an email, albeit some editors don't link their account to their email. Inpops (talk) 17:11, 28 January 2026 (UTC)[reply]
Option 2: Color and especially movement are distracting and annoying, and the described month-long persistence of the annoyance is beyond the pale. — BarrelProof (talk) 01:38, 27 January 2026 (UTC)[reply]
Option 1: While I wouldn't mind Option 2, I personally would prefer Option 1, especially since the OG should have it defaulted. F1fan00 (talk) 09:44, 28 January 2026 (UTC)[reply]
Option 1 (strong option 1) - We can always use more reasons for the public to feel warm and fuzzy and Wikipedia, and this does exactly that. This is a serious project, but it's also a fun project, and written by volunteers. Letting people have a glimpse of that fun -- reminding people that this can be a silly place -- has value. Just look at the resonance of Depths of Wikipedia, for example. Do it, and deal with issues as they arise. I say this as someone who has been critical of our April Fools antics in the past. Unlike that (or rather, unlike the way that used to be), if you look at the page linked at the top, there are already provisions in place to consider context and set limits for e.g. the confetti globe. Deal with any issues as they come on a case-by-case basis (I'm sure people will let us know if something unintended happens). — Rhododendritestalk \\ 17:13, 28 January 2026 (UTC)[reply]
Option 1 or Option 2. An opt-in process means that very, very few people will end up getting the celebration at all. We can always fine-tune after launching if there are issues, but my preference is to get it up-and-running first. ThadeusOfNazereth(he/him)Talk to Me!13:03, 30 January 2026 (UTC)[reply]
Looking at the documentation, it looks like it will be pretty accessible (pop-up) on mobile, while V22 desktop users will have it in their configuration panel – not exactly hidden, but not the most accessible for new users unfamiliar with the interface.
Regarding distractions, we have several articles with GIFs near the top of the page. Ones you'd expect, like Chronophotography, but also ones you may not, like Swing bridge and Panenka. Those GIFs can't be stopped by the average reader – at least, I wouldn't know how – which is in stark contrast to the cute puzzle globe, which looks like it can be disabled with one or two well-advertised button presses. Toadspike[Talk]21:09, 18 January 2026 (UTC)[reply]
As a reader, the GIFs do distract me from the text. For me, the value they add by illustrating the concept better than a static image justifies the distraction, but it's silly to say there is no distraction. Toadspike[Talk]15:52, 23 January 2026 (UTC)[reply]
Comment. Some thoughts:
Like Fram, I am also concerned that cute (they are) easter eggs will show on serious articles.
If we want to enable the easter eggs by default, then we need to accept that they will show on serious articles or we need to filter which articles they show on. Aside from the scale needed for it, the second option also might go against the community sentiment that Wikipedia is not censored.
Do we know which extension this is linked to? If so, we could raise a patch/file a bug and/or read the code to figure out if there are safeguards against this. Sohom (talk) 11:43, 19 January 2026 (UTC)[reply]
Oh this is Extension:WP25EasterEggs, taking a look at the code it is extremely configurable! We can enable it for a specific set of pages, or enable it globally and not show it for a specific set of page and all of that is configurable through CommunityConfiguration (read through a on-wiki JSON file). Sohom (talk) 12:05, 19 January 2026 (UTC)[reply]
Good job finding it! My concern is that, if we enable it globally, we need to check most en.WP pages if they should be excluded.Excluding categories may help, but I remember an argument against actual policy proposals like inappropriate-image blurring that also apply here: categories are imprecise in a lot of ways (the first thing in my search about it is Thryduulf's 2024-11-06T11:57:00). If we will do categories regardless of that, you will still need to vet which categories are included or not. LightNightLights (talk • contribs) 12:24, 19 January 2026 (UTC)[reply]
Pretty much every pick for which pages will have it disabled or not will be extremely controversial, and more worryingly could be used as precedent for future "hiding" tools, so I don't think that's something we should go through. Going deeper than straightforward things like "have it enabled on the Main Page" and "have it enabled/disabled on X namespace" opens up a massive can of worms. Chaotic Enby (talk · contribs) 12:37, 19 January 2026 (UTC)[reply]
This has nothing to do with NOTCENSORED though. We are not here to deliberately cause offence with unencyclopedic content either. Displaying these easter eggs or not doesn't change the contents of the encyclopedia. Fram (talk) 14:01, 19 January 2026 (UTC)[reply]
I doubt "deliberately" is the best way to put it. It doesn't change the contents directly, but does leave us with a list of "acceptable pages" and "controversial pages", which can absolutely be used as a precedent for making some "controversial" material less visible/prominent. Chaotic Enby (talk · contribs) 14:03, 19 January 2026 (UTC)[reply]
Wouldn't like such a list either, which means this can go on the Main Page or perhaps on user pages but should stay out of the articles in general (with what we now know of what kind of easter eggs we may expect). Perhaps my opinion would change with more info, at the moment it feels too much like writing a blanco cheque. Fram (talk) 14:22, 19 January 2026 (UTC)[reply]
A reader choosing to look at a potentially offensive article does not change the fact that Wikipedia is 25 years old now and we are celebrating that. These are entirely unrelated. Toadspike[Talk]14:39, 19 January 2026 (UTC)[reply]
Not if you display them on the same page, in ways so far unknown. A reader looking in mid-March to our article "US invasion of Greenland" may well be completely unaware that Wikipedia was 25 years old a few months before and that the rightside image is displayed for that reason and not to celebrate the invasion. Fram (talk) 14:50, 19 January 2026 (UTC)[reply]
In my opinion, this is why we should make it clear (e.g. with a banner) that this easter egg is to celebrate Wikipedia's birthday. Incidentally, this also solves the "make it easy to turn off" problem. Chaotic Enby (talk · contribs) 15:02, 19 January 2026 (UTC)[reply]
Your idea sounds good. Maybe we should have text below the globe mascot images in the lines of "Celebrating English Wikipedia's 25th birthday"? It does not suffer from banner blindness and will always appear alongside the cute images, but does not solve the turn-off problem. LightNightLights (talk • contribs) 15:27, 19 January 2026 (UTC)[reply]
That could work! Either that, or making the banner very obviously birthday-themed so readers don't have to actually read the words to understand the context behind it all. Or both! Chaotic Enby (talk · contribs) 15:34, 19 January 2026 (UTC)[reply]
id say, put below the globe thing, put in the normal size, 'Wiki 25', then below in a smaller font, put '25 Years of the Free Encyclopedia', or something along those lines F1fan00 (talk) 10:03, 28 January 2026 (UTC)[reply]
Based on what is already implemented, tThere is going to be a relatively large toggle on the sidebar every page (similar to the dark mode one) that says "birthday mode" but yes, also CE's idea is not a bad idea. Sohom (talk) 15:14, 19 January 2026 (UTC)[reply]
Maybe the "Birthday mode" toggles should be shown above the old ones so that people will see a) most likely see the new ones first, and b) most likely see that something was added in the options menu. LightNightLights (talk • contribs) 15:33, 19 January 2026 (UTC)[reply]
Hello :) My name's Corli and I'm working on this project and want to share a bit more context on how we've tried to solve this very tricky problem of "which articles gets which version of Baby Globe?"
We also concluded that trying to make a "disable" list would be extremely difficult (if not impossible!) to do, especially because what we're building needs to work across all language Wikipedias. So we created a version of Baby Globe that appears "neutral". They don't do much, they stand around, blink and look cute. This version can then show up on pretty much any page and not imply anything particularly positive or negative.
By comparison, the versions that are overtly celebratory (like the confetti one) can be configured to show up on overtly celebratory things (people also turning 25 this year, all “cakes”). This is done using mostly Wikidata items, you can see a first version of this here, which we will be updating with all the versions of Baby Globe later this week.
The configuration setup allows Baby Globe to be configured by each opted in language edition to be blocked on specific pages defined in community configuration (eg. define specific pages where no instance of Baby Globe will appear, not even its default neutral state). So you can very easily override and adjust this default setup.
The longer story is that there are 14 different versions arranged along a spectrum of sorts from very neutral to outright celebratory. You can get a sense for them in the table, which this week we'll update with the actual gifs so you can properly see the vibe :) These can all be individually turned on / off and customised to appear or not appear on specific articles. CDekock-WMF (talk) 16:21, 19 January 2026 (UTC)[reply]
I want to explicitly mention that I think there is a sentiment among editors that Wikipedia is not censored outside of NOTCENSORED, so I avoided saying "NOTCENSORED" at my original comment.LightNightLights (talk • contribs) 14:19, 19 January 2026 (UTC)[reply]
Comment #2. Some more thoughts:
If we decide to hide it by default (option 2), I think a lot of people will not enable it. This may be bad because it would mean that we did not utilise someone's work to the fullest reasonable extent, but may also be good because we probably should not shove it in our readers' faces.
If it's hidden by default, then we might want to run "opt-in now!" messages, and that might be more annoying than just having it visible.
I don't find the "but what if someone's reading serious content?!" argument to be very compelling. AFAICT Google doesn't suppress the Google Doodle if you search for a "serious" subject. I've never seen anyone saying "I was searching for information on how to plan my aunt's funeral, and Google posted a celebratory logo. How dare they!" Have you? And if you haven't, why would you expect readers to accept Google's celebratory logo but not Wikipedia's? WhatamIdoing (talk) 02:26, 25 January 2026 (UTC)[reply]
If it's hidden by default, then we might want to run "opt-in now!" messages, and that might be more annoying than just having it visible. that's absolutely right. What if we configure a default display timer of five minutes? For example, the baby globe would appear on readers’ screens for a maximum of five minutes and then automatically disappear... If a reader closes the browser session and later reopens it, the baby globe would be displayed again for five minutes before disappearing. CONFUSED SPIRIT(Thilio).Talk05:22, 25 January 2026 (UTC)[reply]
Question I assume this would not be available on classic vector? If so, that would be a shame, considering I've strongly preferred classic Vector's enumeration of a page's table of contents and am unwilling to temporarily switch to Vector 22 to experience the joy of birthday mode, but I understand. DrewieStewie (talk) 21:02, 26 January 2026 (UTC)[reply]
This is not the most pressing inquiry for resolving the technical implementation of this feature, but can someone explain to me why a baby was chosen as the mascot to celebrate the project having reached the milestone of 25 years--it seems peculiar to me, if not outright counter intuitive, given that, if you are going to anthropomorphize such an abstract condition, 25 would normally be an age that one might reasonable associate with coming into full adulthood? What am I missing here? If it's not obvious to me after having been with the project for roughly 2/3's of that period, I can't imagine it's any more intuitive for our average reader. Am I overthinking this--was it just an organic selection of the most obvious cutsy mascot that could be adapted from the movement logo? SnowRise let's rap00:27, 31 January 2026 (UTC)[reply]
It's not a baby it's a plushie, which doesn't denote age or lifespan. Despite it's anthropomorphic appearance, as is common with these toys, plushie's aren't the embodiments of humans so I'm not seeing the issue. If it were a greenland shark, at 25 years of age it would still be considered a juvinelle (and shark plushies are quite popular btw). So plushies can symbolically live for upto hundreds of years, thus 25 shouldn't be measured anthropocentrically, even if WP is indeed anthropocentric. CNC (talk) 09:19, 31 January 2026 (UTC)[reply]
Well, I never regarded it as an "issue" so much as a peculiar choice. But I've since found an interview with the artist of the original graphic which clarifies that the unnamed design came first, and people just started calling it "Baby Globe" organically after the fact. I still think this makes for a curious mascot to celebrate this particular threshold, but certainly a curiosity of a "meh" level of significance. SnowRise let's rap07:50, 1 February 2026 (UTC)[reply]
Due to the unblock backlog, many requests are left unanswered only because of a lack of admin manpower. We shouldn't decline requests simply for being stale, especially since the current Template:Decline stale requires blocked editors to substantially reword their request, even if there might have been nothing wrong with the original one besides an unfortunate timing.
However, other requests are stale due to a lack of communication from the blocked user, and leaving these in the unblock queue wouldn't be helpful as there isn't much admins can do while waiting for a response. Focusing the decline's scope on the latter would help a lot in that regards, and I've worked on a simplified wording at Template:Decline stale/sandbox. Should we implement it? Chaotic Enby (talk · contribs) 20:29, 21 January 2026 (UTC)[reply]
Support the change in principle, but why not make it something that the user could remove in order to reactivate their existing appeal, rather than having them write a new one? I'm not sure how that would work, I don't know if we can code a template that changes its appearance based on the presence of a different template inside its code. Ivanvector (Talk/Edits) 19:57, 22 January 2026 (UTC)[reply]
I was thinking about a separate "procedural close" appeal status (separate from "decline" and with a less harsh wording), and that could be a use for it. We can definitely code a template that does this, as it is essentially checking if a parameter is empty or not. Chaotic Enby (talk · contribs) 20:22, 22 January 2026 (UTC)[reply]
See Template:Unblock reviewed/testcases for what this status might look like. Since the reasons for procedurally closing a request will usually be the same (duplicate request, stale request), it could be helpful to also have it take a set of predefined parameter values and adapt the advice to each one. Would save time on both sides. (NB: This status thing is a separate, less concrete proposal, and not a part of the original one being discussed) Chaotic Enby (talk · contribs) 20:42, 22 January 2026 (UTC)[reply]
I don't think increasing the complexity of the template task is a good idea. We've already got your unblock wizard because the base experience is too complicated. Let's not make that worse. -- asilvering (talk) 00:30, 23 January 2026 (UTC)[reply]
Support, refocusing the wording in general. I'm not sure I like the current wording (especially the dangling "only") since I feel like it will encourage folks to rapidly resubmit requests. -- Sohom (talk) 11:44, 24 January 2026 (UTC)[reply]
But isn't that what we want? If they weren't active and didn't respond to the concerns, and then log back in, then having them address the concerns and resubmit their request is exactly the ideal course of action. Chaotic Enby (talk · contribs) 12:09, 24 January 2026 (UTC)[reply]
So, I would do, Procedural decline. This unblock request has been pending for more than two weeks with no response to questions raised during that time. You are welcome to request a new block review after you have substantially addressed the questions raised. My worry is that the older wording encourages people to read it as "just resubmit it dude we will take a look at it" rather than address the concerns and resubmit their request. Sohom (talk) 12:15, 24 January 2026 (UTC)[reply]
This whole discussion is predicated on the idea that there is a "backlog" (as opposed to an ordinary number of requests that are working their way towards resolution in the ordinary course of events) and that it's taking too long to reach resolution. I question that assumption. We block something like seven thousand accounts per month. Most don't request an unblock, but the complained-about backlog is the equivalent of only about 0.1% of the blocks we issued during the last year. That sounds pretty good from where I'm sitting.
I suggest that we consider dealing with the "problem" of this "backlog" by recognizing that it's going pretty well and that this isn't actually a problem. WhatamIdoing (talk) 02:16, 26 January 2026 (UTC)[reply]
The reason why I started this discussion isn't because of the backlog itself, but because of some requests being declined without explanation just because their blocks weren't reviewed on time. Declining an unblock just because it hasn't been processed in X days, without any more explanation being given to the blocked user, prevents them from working their way towards resolution in the ordinary course of events. Chaotic Enby (talk · contribs) 02:35, 26 January 2026 (UTC)[reply]
So: We need a service level agreement, or we need to agree that there isn't one (and to stop issuing procedural declines based on being slow).
In terms of solving the underlying problem, we could probably adapt the Wikipedia:Feedback request service to notify individual admins about unblock requests that are more than n days old, or to flag them at WP:AN once a week or something.
and to stop issuing procedural declines based on being slow. Yes, and that is exactly what my proposal suggests: removing that as a reason for a procedural decline. Chaotic Enby (talk · contribs) 06:55, 26 January 2026 (UTC)[reply]
What do you want to see happen with these? I mean, you're an admin, so you could accept or decline almost all of them. I might be a long day's work, but you probably could get all of the older ones knocked out in a day if just getting them resolved one way or the other was your highest priority. You haven't done this, so obviously something's holding you back. What's the barrier for you? I'm assuming that the desire to get the right answer is one of the barriers, but what else? WhatamIdoing (talk) 08:14, 26 January 2026 (UTC)[reply]
Proposed deprecation of {{Reference page}} and related templates
Support as proposer: WP:Close is an information page that well-documents current community practice with the level-of-detail one'd expect from a guideline, with the exception of the "Closing procedure" section mostly of uncontroversial technical details, but it's not unheard of for guideline pages to include such sections either (e.g. Wikipedia:Signatures#Dealing with unsigned comments). Despite the widespread practice of consensus being the counted supermajority when arguments are of equal weight, this determination is only documented in essays and this information page (If the discussion shows that some people think one policy is controlling, and some another, [...]). An experienced editor in a discussion I closed a few months ago pointed this out to me and thus argued my close should've said "no consensus" instead as a small number of participants !voted oppose. The increased visibility of this page as a guideline would reduce the amount of editors (including newcomers) who aren't caught up on our closing standards.It is my opinion that the practices documented in this information reflect the current community standard, and the situation I mentioned above marks a need for such practices to be included in guidelines. Aaron Liu (talk) 17:22, 26 January 2026 (UTC)[reply]
Support per Aaron Liu. I've long found this a useful guide and personally never had it questioned as only an info page, but I can see the issue of it not being an official guideline as an issue, especially given it's the guidelines that closers follow. It might be worth considering some other pages in this area for review and promoting; Wikipedia:Non-admin closure (widely accepted essay, referenced in hatnote at WP:INVOLVED as guidance on involvement for non-administrator actions - also not a guideline but quasi-advertised as such. Likewise we have Wikipedia:Requested moves/Closing instructions, as a subpage of RM no less, which again is nothing more than an essay, even if widely used as guidance. I think it might be time to start making the effort to categorise certain pages more accurately, reflecting their status quo as defacto guidelines. CNC (talk) 13:30, 30 January 2026 (UTC)[reply]
You're not wrong, "enforced BRD" is referenced in WP:STANDARDSET, whereas BRD is only an essay intended as advise. Given it describes an optional strategy rather than any fixed rules, the categorisation doesn't seem off to me at all. Realistically it's evolved into an infopage as documents the cycle in-depth, rather than pov-led like essays often are.
I'm aware not everything needs a tag, but if there are sets of best practices supported by consensus, then promoting to guideline satus is logical for sake of clarity. Five pillars is otherwise a higher-level summary page, so acts more like an infopage than policy or guidelines. There doesn't appear to any independently crafted policies or guidelines, only references to them. Thus, it's categorised correctly as a page that either isn't confirmed to have widespread consensus, or doesn't require it. CNC (talk) 16:48, 30 January 2026 (UTC)[reply]
Good suggestion, also the notes on that page that are linked need anchors, or ideally resolve the duplicate lists of restrictions. There is one at the base page and the other transcluded to subpages; one with useful links, notes, and a set of other restrictions; and the other without. Hopefully an arb can bring some sanity to that. CNC (talk) 20:19, 30 January 2026 (UTC)[reply]
No, I can't. The Enforced BRD sanction in my userspace is historical and part of the point of STANDARDSET is that it eliminated custom sanctions like the ones in my userspace. ~Awilley (talk)22:06, 1 February 2026 (UTC)[reply]
(Pedantic note: it didn't eliminate custom sanctions. It made them so only a rough consensus of uninvolved admin at AE could do them.) Best, Barkeep49 (talk) 03:08, 2 February 2026 (UTC)[reply]
Great. What's the procedure for getting the committee to stop linking to a page that says it is "one of many optional strategies" (emphasis in the original)? WhatamIdoing (talk) 06:19, 2 February 2026 (UTC)[reply]
I support better documenting the de facto approach to consensus. I do find this sentence weird: The desired standard is rough consensus, not perfect consensus. I understand it’s the de facto approach, but should there be an effort to revise consensus, rather than having a separate guideline that sorta says, “we didn’t mean that page, we mean this page”? Dw31415 (talk) 01:09, 31 January 2026 (UTC)[reply]
AIUI our notion of Wikipedia:Rough consensus is derived from the Internet Engineering Task Force. "Rough consensus and running code" is the goal for their decision-making process. The first half means that it's unnecessary to have unanimity, to have agreement on the details, or to have a formal vote. In the case of decisions made under RFC7282, it literally means that support sounds louder than opposition. They are looking for an absence of significant opposition, rather than strong support. The second half means that the group should defer to the people doing the work instead of someone pontificating about theory. WhatamIdoing (talk) 01:51, 31 January 2026 (UTC)[reply]
I'm not sure why we should expect people to know the IETF's protocol.That said, I think WP:C already appropriately summarizes consensus as Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy. Detailed, further explanation is what WP:Close provides. Aaron Liu (talk) 02:26, 31 January 2026 (UTC)[reply]
I’m not sure about the best solution and don’t want to distract too much from the main question. I just think there’s an odd smell about this (as a guideline) saying we don’t use policy (consensus) we use an essay (rough consensus). If no one else sees a problem with it I’ll defer. Dw31415 (talk) 03:17, 31 January 2026 (UTC)[reply]
Mostly, I don't see why not make clear a series of practices are standard. Your assumption is correct but I don't see why that lessens the argument for clarity, and said editor is someone I usually wouldn't assume obstructionist motivations. Aaron Liu (talk) 21:14, 26 January 2026 (UTC)[reply]
Meta comment: A WP:PROPOSAL is supposed to be made on the talk page of the proposed guideline. I don't think we need to take any action right now, but if this discussion gets long (RFCs on Village pump pages frequently need to be WP:SPLIT to keep the overall page size under control), maybe it could be moved there instead of to a subpage. WhatamIdoing (talk) 20:25, 26 January 2026 (UTC)[reply]
I agree that there should be a guideline on closing discussions, but it might be worth fine-tuning it a bit and getting everything in one place first. Right now it's not as concise as it probably could be. Thebiguglyalien (talk) 🛸22:08, 26 January 2026 (UTC)[reply]
I've finally looked over both; I don't believe there is overlap, other than If the matter under discussion is not contentious and the consensus is obvious to the participants, then formal closure is neither necessary nor advisable. which I don't see a problem with. Aaron Liu (talk) 03:22, 28 January 2026 (UTC)[reply]
Hi Aaron, I boldly added a link to the RfC close template. Feel free to revert if it should get more review. I would like there were more consistency in using the RfC closure template or to have it deprecated. Dw31415 (talk) 14:34, 30 January 2026 (UTC)[reply]
This part of RFCEND strikes me as out of touch with current practice but maybe I’m looking at a controversial subset. Editors are expected to be able to evaluate and agree upon the results of most RfCs without outside assistance. I guess that’s not immediately relevant to this discussion. I support the proposal to make it a guideline. Dw31415 (talk) 03:33, 28 January 2026 (UTC)[reply]
I looked through a handful of consecutive RFCs from November-ish. About two-thirds got a closing statement. However, almost half of those didn't need a closing statement (e.g., Andrew Huberman, Advance UK, Scientology) because the responses were so lopsided. That said, sometimes editors want a closing statement for social/behavioral reasons rather than because they don't know what the result is. WhatamIdoing (talk) 06:00, 28 January 2026 (UTC)[reply]
It helps prevent the (factually incorrect) wikilawyering over "well that discussion was never closed so there's not a true consensus". Katzrockso (talk) 13:54, 30 January 2026 (UTC)[reply]
I don't think I've ever seen that particular claim before, but I'd expect that to be solved by educating the editor about Wikipedia's processes. If that happens a lot (more than a couple of newbies a year), then I'd like to have a few examples (drop some on my talk page? It's kind of off-topic for this discussion), then we should address that error somewhere. Maybe Wikipedia:Tendentious editing#Concerning discussions would be the place for that. WhatamIdoing (talk) 16:02, 30 January 2026 (UTC)[reply]
I'd like to open a wider conversation about the wider practice of including those winter storm names in articles. The storm names are called a "marketing ploy" in that storm article above, and so we should really have something stronger than a silent consensus to back up their inclusion (see background below).
Ideally, coming out of a discussion here we would have either an affirmative consensus of the status quo or a reversal of the TWC guidance. This could also instead act as a WP:RFCBEFORE if a wider discussion is needed.
The on-wiki guidance is at the WikiProject level with WP:TWC. The inclusion of the names within articles does not appear to have been recently tested at any level above a silent consensus and various small discussions on article talk pages. Specifically, TWC says that an "understood consensus" exists that "allow[s] mention of the TWC names within the articles, as long as said names are not part of the article title and that there is a "silent consensus for this method and process".
Meteorological agencies in some parts of the world assign names to winter storms, but in the United States, only hurricanes and tropical storms get official names from the National Weather Service. Since 2012, The Weather Channel has used its own list of names for storms, a move that has been criticized as a marketing ploy. It is calling this one Fern.
I am against using TWC names but they are (unfortunately) widely used in news sources. Since the names are used nationwide and not just locally, support status quo, which makes it clear that the names are unofficial. HurricaneZetaC16:17, 27 January 2026 (UTC)[reply]
Support status quo ante bellum. I see no reason to change how we’ve been handling these with a small mention in the lead. As Zeta said, once you have the names being referenced by media outlets it becomes hard to ignore, and we should not leave it out, as some readers may find it helpful. Zeta made it pretty clear as well, and we should not move the article names to them. MarioProtIV (talk/contribs) 20:18, 27 January 2026 (UTC)[reply]
Support I honestly don’t see what the big deal is. There are many storms with unofficial names like Superstorm Sandy, Snowmageddon, The Beast, etc. Trying to take out one nickname/unofficial name is just a waste of time and honestly sounds stupid to me because it’s just nitpicking for no reason, especially when numerous media outlets use them. ChessEric06:43, 29 January 2026 (UTC)[reply]
Overall I think that this should be treated as a navigation issue and similar to how we treat nicknames for people or organizations. We should include the names if readers might be looking for them (e.g., to make sure that they're reading about the storm that they want to read about). We should consider bolding the name if a redirect points there, under the same rules we would bold a nickname. The approach of explicitly labeling it an "unofficial" name sounds good to me. I think the quotation from The New York Times about a "marketing ploy" is unnecessary, but there's nothing inherently wrong with providing a brief quotation from a paywalled source. WhatamIdoing (talk) 16:11, 30 January 2026 (UTC)[reply]
Support trying to get rid of it because it’s “a marketing ploy” or whatever seems like WP:GREATWRONGS (or at least pretentiousness, as if a for-profit source is too good for Wikipedia), as does mentioning that the NYT considers it as such. As long as it’s not the article title and explicitly stated to be unofficial it’s completely fine. Dronebogus (talk) 01:31, 2 February 2026 (UTC)[reply]
I agree. In particular, when we tell the life-story of a historical figure, we tell it in chronological order, from birth to death. For historical figures it looks plain silly to list their life backwards. As one typical example, we list the ships commanded by Sir William Parker, 1st Baronet, of Shenstone in order from the first he commanded, to his last command. Since all our subjects will eventually become historical figures, and we're in the business of telling history, it makes sense to use chronological order from the get-go. The place where "most recent service" style is relevant is (1) in CV's (for impact, not our role), and (2) in articles about the post, not the post-holder. For a post that's important and ongoing, we need to give prominence to the current post-holder, but usually we do that by labelling them as incumbent in the info-box; the former post-holders are still in chronological order (see Secretary of State for Education for example). Pierre Trudeau's info-box is a really good example of a totally confusing layout because of its most-recent-service style. It's particularly inconsistent when the box is listing multiple posts, with some fully-enclosed in the time-line of another, for example his leader of the opposition, which is entirely enclosed in leader of the liberal party. If the whole thing were chronological, we'd quite intuitively order everything by start-date. Elemimele (talk) 17:15, 27 January 2026 (UTC)[reply]
Also agreed. It's rather confusing to go back in time like that, especially in an example like Trudeau where the first term was so long that it's very surprising to jump from reading 1984 to 1968. Cremastra (talk·contribs) 16:40, 28 January 2026 (UTC)[reply]
Is the proposal that lists may, should or must be as you describe? And are you proposing to order the entire infobox chronologically (irrespective of any order of precedence that might hypothetically be relevant), or just the entries under a single infobox heading (irrespective of where it lies in the infobox)?
Would it not be best to have this put the current or most recent office at the top? That's usually the one people are looking for, after all. WhatamIdoing (talk) 18:53, 30 January 2026 (UTC)[reply]
It depends, though. If the person is currently in office, they're probably looking for the times of the current service. In the Pierre Trudeau example, though, he was last in office some forty years ago: it's more informative to start at the beginning of his first term, as the reader will probably want to know about his tenure overall, not just his most recent stint as PM. Cremastra (talk·contribs) 18:57, 30 January 2026 (UTC)[reply]
Would this be desirable: Within a heading, start with the oldest entry on top. Within an infobox, order the headings with the most recent on top (irrespective of the order of entries inside that heading).TheFeds07:42, 31 January 2026 (UTC)[reply]
. Didn't they go out in 1998? Mathglot (talk) 09:22, 15 January 2026 (UTC)
On Vector 2022...
...and on Minerva Neue
