Wikipedia:Village pump (proposals)

Discussion page for new proposals From Wikipedia, the free encyclopedia

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for 7 days.

RfC: Should we deprecate WP:RfA?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
No previous discussion. And the premise is false, Wikipedia:Requests for adminship/Vacant0 was closed just a week ago Cambalachero (talk) 19:03, 6 February 2026 (UTC)

This process has seen rare usgae, even its counterpart WP:RfB is not even used. Should we deprecate it? ~2026-36939-5 (talk) 15:56, 6 February 2026 (UTC)

Survey

  • Deprecate per my ratioanle. ~2026-36939-5 (talk) 16:47, 6 February 2026 (UTC)
  • Comment in the absence of an WP:RFCBEFORE, this should be speedily closed as premature. It would only be feasible if WP:AELECT were significantly expanded anyway. ~2026-80954-2 (talk) 16:41, 6 February 2026 (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.

Request for community consensus – CentralNotice for Wiki Loves Ramadan 2026

Hello everyone,

I am the Project Lead of the international team for Wiki Loves Ramadan, and the local organizer of Wikipedia:Wiki Loves Ramadan 2026 on English Wikipedia.

I am writing to request community consensus to run a CentralNotice banner globally for Wiki Loves Ramadan 2026.

This year, the campaign includes:

For English Wikipedia, the banner should clearly reflect the writing competition and link directly to Wikipedia:Wiki Loves Ramadan 2026, in addition to linking to the relevant Commons competition pages for participating countries where applicable.

For reference, the detailed CentralNotice plan (including banner structure and implementation notes) is available at: m:Wiki Loves Ramadan 2026/CentralNotice.

Before proceeding further with the CentralNotice process, I am seeking consensus from the English Wikipedia community. Feedback on banner wording, linking structure, targeting, and overall scope is very welcome. Warm Regards, ZI Jony (Talk) 06:38, 26 February 2026 (UTC)

A central notice banner will go a long way to promote the project, Wiki Love Ramadan on English Wikipedia. Tesleemah (talk) 10:41, 28 February 2026 (UTC)
@ZI Jony Please make the central notices compatible with dark mode if you plan to run it on the English Wikipedia. The current designs appear to be very much incompatible with dark mode. Sohom (talk) 16:52, 2 March 2026 (UTC)
@Sohom Datta, our technical team already updated that code, hopefully CN admins will update at thier earliest convenience. Warm Regards, ZI Jony (Talk) 18:00, 2 March 2026 (UTC)
I was going to suggest a different name until I saw meta:Wiki Loves X campaigns, which endorses the current name. My only suggestions are:
  1. Comply with Wiki Loves X campaigns.
  2. Cover any variations among different branches of Islam and among different regions.
  3. Use the Arabic terms with English translations and transliterations.
I don't see any issues. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:14, 2 March 2026 (UTC)
@Chatul, thanks for thinking about a different title, and it does make sense to check how the campaign is positioned first.
Just to ground this in how the project is framed: Wiki Loves Ramadan exists as part of the Wiki Loves X family of campaigns and explicitly carries that name on Meta-Wiki, so sticking with it aligns with Wikimedia branding.
The campaign’s mission is to empower communities to contribute high-quality, freely accessible knowledge about Ramadan and the wider Islamic world, highlighting diverse traditions and practices for broader understanding and heritage preservation. Its vision is to build a comprehensive, multilingual repository of knowledge that celebrates both the diversity and shared aspects of Muslim heritage globally.
In terms of areas of focus, contributions are encouraged across:
  • core Islamic topics - beliefs, practices, branches of Islam and regional traditions,
  • the many facets of Ramadan - fasting traditions, prayers, Eid celebrations, and how it’s observed in different cultures,
  • religious structures, landmarks, figures, and broader cultural expressions like art and cuisine.
Given that, your points about complying with Wiki Loves X campaigns, ensuring coverage of different branches of Islam and regional variations, and using Arabic terms with English translation/transliteration all sit well with the campaign’s goals. I don’t see any blockers either. Warm Regards, ZI Jony (Talk) 06:10, 3 March 2026 (UTC)
Not a Muslim, Love the project. Topic: Ramadan in the Far North/Arctic Circle. All I know is that Canadian towns have different customs. ~2026-14035-61 (talk) 14:04, 4 March 2026 (UTC)
I do not give my consensus. Wikipedia should not be a religious Bleeding Kansas over banners about religious holidays. This site is supposed to be an encyclopedia, not a chapel. ~2026-11404-95 (talk) 13:54, 4 March 2026 (UTC)
To clarify what i mean by "Bleeding Kansas", i am referring to when the Kansas territory turned into a battlefield over slavery. In this instance, the banners would end up turning Wikipedia, which is supposed to be an encyclopedia, into a battlefield for religious missionaries. ~2026-11404-95 (talk) 13:57, 4 March 2026 (UTC)
  • (ec) The only people who are turning this into a battlefield seem to be those predisposed to distrust Islam (i.e., Islamophobes). It has been explained multiple times at the talk page of the project that a) Wiki Loves X is the standard format for projects of this type, and b) anyone is welcome to work to create a Wiki Loves Christmas, Wiki Loves Diwali, Wiki Loves Passover, or even Wiki Loves Festivus. That one project has been launched does not mean other projects are precluded.  Chris Woodrich (talk) 16:09, 4 March 2026 (UTC)
    If they want to plan Wiki Loves Christmas, it should be neutral like "Wiki Loves Holidays". Ahri Boy (talk) 17:44, 9 March 2026 (UTC)
    Not if it is promoting Christmas. If you call it "Wiki Loves Holidays" then it should treat all holidays equally. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:56, 9 March 2026 (UTC)
I am not a Moslem. I've had issues with abusive and aggressive missionaries, but none of them have been Islamic. I see nothing in this proposal that is objectionable or in conflict with the umbrella Wiki Loves X campaigns. In the US at least, Moslems are more likely to be the victims than the perpetrators. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:54, 4 March 2026 (UTC)
While I'm okay with Wiki Loves X campaigns in general, may I suggest that ones focused on a particular religion not run as central notice banners, due to the possibility of it being seen as proselytism? Not saying that they shouldn't exist at all of course, just that it might be more sensitive to not have these particular ones as banners. Chaotic Enby (talk · contribs) 16:05, 4 March 2026 (UTC)
I'm inclined to agree. I am not religious and have no issue with Islam as a whole, but I feel that promoting any particular religion or religious holiday globally is non-neutral and should be avoided for the same reason we don't allow religious promotion in public schools. Articles, discussions, and the project itself are of course perfectly fine since they support information and education without Wikipedia itself appearing to endorse anything in particular. Particularly considering that holidays among various religions overlap, and this would appear to prioritize one above others. ChompyTheGogoat (talk) 05:20, 5 March 2026 (UTC)
There appears to be no intention in this campaign of proselytizing or endorsing any religion or religious holiday over the others. For what it's worth, I also personally fail to see how this campaign is fundamentally different from (say) Wiki Loves Onam which promotes a Hindu festival in Kerala that has been running for the last 3 years without any accusations of proselytization or endorsement of hinduism and appears to already have the silent consensus of the community. If we were to treat this campaign differently due to concerns over the optics of bias and block it, that would actually risk introducing actual bias into the process. Sohom (talk) 05:52, 5 March 2026 (UTC)
I don't mean to imply that it's intended, only that it might be interpreted that way.
Does Onam run a CentralNotice? That's the only thing I object to, not the existence of the campaign. If they do I haven't seen it, and my opinion applies to all religions equally - none should be singled out either by promotion OR suppression. If you were to compile a list of every holiday in every extant religion I'm fairly confident you'd have conflicts on every single day of the year. ChompyTheGogoat (talk) 06:57, 5 March 2026 (UTC)
I don't see a entry in the calendar about Onam so my assumption would be that they did not run a central notice. Sohom (talk) 01:43, 7 March 2026 (UTC)
As a side-note, a hatnote in meta:Wiki Loves Ramadan 2026 linking to meta:Wiki Loves X campaigns would be helpful. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:54, 4 March 2026 (UTC)
  • Oppose any central notice banner that could reasonably be interpreted by readers as Wikipedia showing favoritism to any religion (or irreligion), as per Chaotic Enby and ChompyTheGogoat. BD2412 T 14:24, 5 March 2026 (UTC)
  • Oppose banner per @Chaotic Enby and @BD2412. I agree that this could be interpreted as endorsing one religion over all others. It also puts Wikipedia at risk of actually prioritizing one religion over all others - if there were WikiLoves projects for Hanukkah or Lent that made the same banner request but community consensus was against it, that could set a very bad precedent. PositivelyUncertain (talk) 01:52, 6 March 2026 (UTC)
  • Oppose per BD2412 Andre🚐 02:10, 6 March 2026 (UTC)
  • Oppose I'm in agreement with PositivelyUncertain.--Wehwalt (talk) 02:20, 6 March 2026 (UTC)
  • Meh, whatever decision we make here, we should be consistent and apply that result to other future religion-related Wiki loves X campaigns, because it would be weird if the community denied a banner for Wiki Loves Ramadan 2026, but in the future, approved one for hypothetical Wiki Loves Christmas, Wiki Loves Diwali, Wiki Loves Passover, or even Wiki Loves Festivus (to use Chris Woodrich's examples above). Some1 (talk) 02:38, 6 March 2026 (UTC)
    I'm fine with that. Remind us when such a banner is requested, we'll help vote it down. Wehwalt (talk) 02:42, 6 March 2026 (UTC)
    If I see it, I'll also say so. There is also no limiting principle to such a thing. If we allow this, how would we be able to deny a banner for the Church of Cannabis, or the Church of the Flying Spaghetti Monster? BD2412 T 02:46, 6 March 2026 (UTC)
    I would be happier if we could get a general binding consensus, instead of doing it as a case-by-case basis (which may introduce systemic bias regarding who does/doesn't vote in specific cases). Chaotic Enby (talk · contribs) 09:03, 6 March 2026 (UTC)
    Agreed again. My position applies to any banners associated with any religion, and I think an official proposal to clarify that it applies universally is a good idea to prevent exactly what I'm concerned about. Perhaps there should also be a broader standard relating to banners for any contentious topics, or ones that might be. The individual campaigns are volunteer run so as long as they comply with guidelines I'm not concerned about their subject matter, but the appearance of an official endorsement needs to be considered for banners.

    I'm not familiar with the technical side of things, but perhaps these campaigns that might be disallowed from central banners under such proposals could be allowed to add something just to specific articles they agree are directly relevant? That allows the possibility of multiple running at once. It would need to be limited to ones that are clear such as "Holiday within X religion", not "Holy site significant to multiple religions".

    I don't have much experience with pump - should additional aspects like this be broken down in new sections, or are spurs expected to split off within the initial proposal? It seems to be a somewhat looser format than many areas. ChompyTheGogoat (talk) 09:48, 6 March 2026 (UTC)
    It's a looser format indeed, but (at least at Wikipedia:Village pump (policy) and here) it can absolutely be helpful to break down the discussion into separate clear proposals for people to discuss, while Wikipedia:Village pump (idea lab) is more of a completely open discussion. Chaotic Enby (talk · contribs) 09:52, 6 March 2026 (UTC)
    Wikipedia loved the Jewish Museum in the past, but I don't remember seeing a banner for it. Andre🚐 02:44, 6 March 2026 (UTC)
  • Conditional agree This is, of course, a marvellous idea. However, there is the obvious rider, that this initiative must be balanced by extending the same courtesy to the many other areas that deserve the same consideration. Otherwise Wikipedia would be guilty of crass discrimination. The "Wiki loves Ramadan" initiative needs to be followed by other initiatives such as "Wiki loves Lent", "Wiki loves the Heart Sutra", "Wiki loves Passover", "Wiki loves the elephant goddess Vināyakī"... in fact we are just getting started, there are so many seriously overlooked areas: "Wiki loves black men", "Wiki loves elderly white men", "Wiki loves young brown men", "Wiki loves white boys", "Wiki loves young British working class girls", "Wiki loves cis white men"... Our time will be entirely taken up with all the things Wiki needs to love, and with posturing about how virtuous we are for being so virtuous. I guess there won't be time left for writing an encyclopaedia, but if Wikipedia keeps indulging this sort of stuff, there won't be an encyclopaedia. If Wikipedia is to survive the challenges of AI, it needs to focus on what it would take for Wikipedia to become a gold standard for epistemological reliability or truth so it can be a trusted resource as a core training ground for AI. That's a big ask, but if we can't take up that challenge, then there is no future for Wikipedia, and we may as well let it implode into sectarian ideological dementia. — Epipelagic (talk) 09:51, 6 March 2026 (UTC)
    I think the underlying goal for campaigns of increasing and improving the quality of articles on underrepresented topics is admirable - but splashing a banner across the whole site to point it out is probably less so. ChompyTheGogoat (talk) 10:13, 6 March 2026 (UTC)
I see the potential for future misuse here, by projects whose main goal is simply to display their banner on Wikipedia for several weeks. To prevent that, there should be a clear time limit (around five days), and any future requests should need to demonstrate clear community interest in the project in previous years.Ponor (talk) 10:59, 6 March 2026 (UTC)
@Ponor, it's not in the English Wikipedia communities remit to decide how central notices are displayed on other Wikipedia. There are already multiple policies about central notices and how and when they can be displayed on meta. If you are interested in "further misuse" the correct place to engage is on meta. Sohom (talk) 01:56, 7 March 2026 (UTC)
Where did they say anything about other sites? ChompyTheGogoat (talk) 02:08, 7 March 2026 (UTC)
I interpreted "on Wikipedia" as referring to other language version as well. Sohom (talk) 03:02, 7 March 2026 (UTC)
By "project" I meant all these "Wiki loves X" projecs, not other wikis. Religious, national, or political banners are too polarizing. People under a certain trillionaire's tweets read it as our endorsement. Ponor (talk) 02:08, 7 March 2026 (UTC)
So... you all know that every now and again, we get newbies saying "Why are there all these Featured articles on the Main Page always about subjects I don't care about, and there are never any FAs about subjects that I like? Wikipedia is soooo biased!" And we all tell the newbie that TFAs are based on what WP:VOLUNTEERS choose to write, so if they want an FA on their favorite subject, then they should improve the relevant article, get it through the FA process, and we'll cheerfully run it. We know this is basically impossible for the newbie to do in practice, but I at least don't feel guilty at all for telling them that there's no cabal controlling which articles get turned into FAs.
The same thing's happening in this discussion. Someone's done a huge amount of work, and we're all sitting here saying "Why isn't this banner on a subject I like? It's soooo biased!"
If you want a "Wiki Loves ___" banner on the thing you care about, then go create the program, get it through the CentralNotice banner process, and the CN admins will cheerfully run it. There's no discrimination based on subjects that some people don't feel an affinity for, or that your mother thought was inappropriate for a dinner party conversation – no "well, it's not polite to say anything about religion" or "we can't do anything about a specific nation" (though I don't remember seeing any similar complaints about m:Ukraine's Cultural Diplomacy Month). We've even had contests that combine both religion and national sentiment (e.g., m:Twelve Apostles of Ireland Challenge). For "political" ones, we need look no further than Wikipedia:Wiki Loves Pride, which has run here without objection for a dozen years now (maybe it's only certain religions, certain countries, and certain politics that we can't stomach?). If you want to get Wikipedia's articles improved in a given area, then run a campaign yourself. Just remember that "improved" doesn't mean "favorable to". A "Wiki Loves Incompetent Politicians" campaign could easily result in articles being improved without any of the subjects liking the results. WhatamIdoing (talk) 18:16, 7 March 2026 (UTC)
I doubt that "Wiki Loves Incompetent Politicians". After becoming interested in Cincinnatus, I started a list of honest politicians as a collection of such paragons. They were well-sourced and you can check their merits for yourself as it didn't get to be very long:
More information list of honest politicians ...
Close
Anyway, Wiki didn't love the idea as it was renamed to list of politicians renowned for their integrity. It survived one AfD but not a second and so you now have to go elsewhere to find the details.
So, what does Wiki love? In my experience, its loves include:
  • Wiki loves death – Deaths in 2026 is one of the most popular pages
  • Wiki loves nationalism – it insists on pinning a national label onto everyone as their most important attribute
  • Wiki loves war – WP:MILHIST is probably the most successful project
I could go on but you get the idea. These enthusiasms don't get promotional paeans because they don't need them. A banner that promotes "Wiki loves X" is, in fact, a sign that it doesn't love it so much.
Andrew🐉(talk) 21:05, 7 March 2026 (UTC)
That's an absurd comparison and you should absolutely know better. FAs run on a single page for a single day, and I've never seen one that I would consider to be contentious, although granted I don't pay much attention to them. Plus they're presented as just an interesting topic, no "Wikipedia Loves X" statement which is clearly non-neutral. Ramadan lasts for an entire month and the banner would run on all of English Wikipedia, precluding any others (religious or not). If someone submits a proposal to run one for Purim, who's going to decide whether Judaism or Islam takes precedence? Are you volunteering to moderate that discussion? What if someone starts a "Wikipedia Loves the United States of America" campaign and wants to splash that across the entire site? I know we have many middle eastern editors who do great work, and given the current situation they'd be entirely justified to take issue with what would appear to be endorsement of military aggression. Next thing you know WMF legal is getting involved and central notices get canceled altogether. Let's just head things off now instead of starting down that path, eh? ChompyTheGogoat (talk) 08:52, 8 March 2026 (UTC)
Special:Preferences#mw-prefsection-centralnotice-banners WhatamIdoing (talk) 20:04, 9 March 2026 (UTC)
I also made it clear that I believe this should apply equally to all religious campaigns and in fact all contentious topics, to err on the side of caution, and that a proposal should be started regarding official guidelines to that effect so the community can try to ensure they're as unbiased as possible. Groups of editors promoting subjects they're passionate about is great AS LONG AS it's not at the expense of others. Campaigns themselves can all run simultaneously - banners cannot. ChompyTheGogoat (talk) 08:57, 8 March 2026 (UTC)
As did I, asking to be pinged when a similar request involving another religion was made, so I could help vote it down. I'm afraid the facts get in the way of the prose upthread. The project at issue is free to continue, just without a central notice (though I have noticed WIKI LOVES RAMADAN occasionally on my cell phone over an article). The consensus that was asked has not been given. Will no one close this to that effect? Wehwalt (talk) 14:32, 8 March 2026 (UTC)
@ChompyTheGogoat, what makes you believe that this banner would be precluding any others? That's not how it works.
At the moment, depending on the interface language you select in your preferences and your geolocation, there are supposed to be banners running for tax season donations in three European countries, three Wiki Loves events (Folklore, Africa, Ramadan), two campaigns related to International Women's Day and Women's History Month, and three WMF-sponsored conferences. None of these are preventing any of the others from being shown. There's an established system for limiting impressions (called putting a banner on a "diet"). WhatamIdoing (talk) 20:18, 9 March 2026 (UTC)
So if multiple religions all applied for one at the same time, users would see any and all of them? ChompyTheGogoat (talk) 20:22, 9 March 2026 (UTC)
And how is a Ramadan running one when this clearly isn't going to reach consensus? ChompyTheGogoat (talk) 20:23, 9 March 2026 (UTC)
Wait… there is an option that gets central notices canceled altogether? Where do I sign up? Blueboar (talk) 17:06, 8 March 2026 (UTC)
The correct place to do that is by doing a meta RFC. Sohom (talk) 20:20, 8 March 2026 (UTC)
Tough call. I find some of the opposition arguments above borderline ridiculous, but I'm also unsure myself. For a Wiki Loves X to happen, someone has to organize it. Anyone who wants Wiki Loves [something else] merely has to step up and do the work to make it happen. I'm delighted that ZI Jony and others on the team have coordinated to make Wiki Loves Ramadan possible, and I trust we will get some good photos and article edits for it. The question is about the extent of promotion. CentralNotice is, as I understand it, the most visible possible type of notice. Presumably, as it is in part a recruitment drive, it will be displayed to all users, logged in or not. There aren't very many banners, other than donation banners, which rise to that level of project-wide prominence and folks are right to think about rules. This would be, AFAIK, the very first such notice of a Wiki Loves X about a specific religion, and I share concern about any centralnotice focusing on a specific religion. We have, however, run events about cultures, and the extent to which religion and culture are separate is complicated to say the least. Culture/practices associated with Ramadan basically covers how 2 billion people live their lives, including multiple entire countries [practically], live their lives for a full month out of every year. It's a genuinely tough call. I think I'd have no trouble with a banner based on geolocations in primarily Muslim countries, or banners at the top of relevant articles, but for all of enwiki? I think I land neutral-to-weak-oppose, where I would be for any religion-specific event. Another possibility would be to have a year-long "Wiki Loves Religion" that displays banners at key times for various religions, but (a) that would be a huge amount of work that we may not have organizers for, and (b) Wiki Loves Ramadan is already a thing and already happening. This is a lot of words for a [more or less] neutral, sorry. Rhododendrites talk \\ 01:59, 9 March 2026 (UTC)
Can't we just ask that the organizers of all "Wiki Loves X" campaigns... pick a different slogan when advertising them on banners here? Full disclaimer: I don't like the naming scheme, never particularly have (it's twee and much too artificially kumbayah-ey), so any chance to get rid of it is fine by me. We'd still get complaints about any Islam-focussed campaign, the way we do about fashion designer TFAs and, more recently, Genshin Impact DYKs, but, you know what, you can't make everybody happy. GreenLipstickLesbian💌🧸 06:39, 9 March 2026 (UTC)
"Wiki Documents Ramadan" maybe? Sohom (talk) 06:54, 9 March 2026 (UTC)
  • Wiki Documents Pride
  • Wiki Documents Folklore
  • Wiki Documents Ramadan
  • Wiki Documents Onam
You know what, I like it. GreenLipstickLesbian💌🧸 07:46, 9 March 2026 (UTC)
Personally, I think it sounds a bit more like corporate-speak than I like. If there is consensus to use a different phrase, perhaps something like "Wiki Explores Z", to summarize the reader experience from browsing articles related to Z? isaacl (talk) 15:55, 9 March 2026 (UTC)
I really like Wiki Explores! Maybe Wiki Studies could work too? Chaotic Enby (talk · contribs) 16:02, 9 March 2026 (UTC)
I'd also like any of these!
@ZI Jony, as the organizer, would a change like this be something your project would be amenable to? GreenLipstickLesbian💌🧸 22:52, 9 March 2026 (UTC)
I would support "explores", "documents", "studies", etc. Unless I'm misunderstanding what these "Wiki loves X" campaigns are about, the word "loves" feels too restrictive. If a good-faith editor wants to start a campaign to improve and expand coverage of genocide-related articles on Wikipedia, they couldn't start one under the current naming scheme because "Wiki loves genocide" sounds... well... inappropriate. Some1 (talk) 01:21, 10 March 2026 (UTC)
Also, 'Wiki loves [singer]'… ~2026-68406-1 (talk) 05:24, 10 March 2026 (UTC)
Real " This list is incomplete; you can help by expanding it" energy. GreenLipstickLesbian💌🧸 18:53, 10 March 2026 (UTC)
I don't particularly care that we're running banners for a wiki event on a religious topic, though I will not oppose the broad ban proposed above. I will note that as part of the Foundation's recent update to its banner and logo change policies, they prohibited logo changes (but not banners) for "primarily religious or political" holidays. This provides some precedent for handling these topics differently from others. I also like GLL's idea of changing the name of this type of event.
I do care about keeping the number and frequency of these banners contained. The recent mess with Wiki Loves Folklore (if that link breaks, search for "Let's review"), which had settings so excessive its banners had to be repeatedly reduced by CentralNotice admins, should not be repeated. I unfortunately see no indication of what settings (impressions per day for logged in and logged out users) will be used for this banner campaign on the page linked by @ZI Jony and the CentralNotice request simply says "To be determined by Central Notice admin". I must also point out that the linked page says "Once your local landing page is ready and the banner text is available in your language(s), the CentralNotice banner can be scheduled for your country", which seems to inappropriately presume a 1:1 correspondence between languages and countries. I would appreciate more information on what, exactly, would be done were we to support the proposed banner campaign here: What countries would this run in and on what diet settings? Toadspike [Talk] 10:02, 9 March 2026 (UTC)
Courtesy link to meta:Requests for comment/Religion-focused CentralNotice banners. Chaotic Enby (talk · contribs) 13:22, 9 March 2026 (UTC)
Through excellent arguments in that RfC, I ended up changing my mind, and now support this running as a banner, provided it is made clear that "loves" does not refer to proselytism, but to a love of knowledge, a passion for practices and peoples. I am still open to "studies", "explores", or "documents" as alternative wordings. Chaotic Enby (talk · contribs) 01:03, 10 March 2026 (UTC)
Support. I am invested in this, but more as a cultural push then the religion. Some religions and cultures are so intertwined with each other that there is no way entangle them. Wordings can be updated accordingly if the community thinks that 'loves' is a word to be avoid in this instance, and possibly for consideration for future runs, if any. – robertsky (talk) 05:51, 10 March 2026 (UTC)
I don't like the wording wiki loves x, but any change should be global; as long as the other articles are adhering to that nomenclature, Wiki loves Ramadan should as well. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:01, 10 March 2026 (UTC)
Yep, that would be the ideal way to go at it. Like Some1 showed above, that same "Wiki Loves" issue also applies to other cases beyond religions. Chaotic Enby (talk · contribs) 19:00, 10 March 2026 (UTC)
The global change should be done for future runs. A change for this run will be disruptive not just on wiki but also any outreach efforts off wiki. – robertsky (talk) 04:02, 11 March 2026 (UTC)

Zoom-in for fossil ranges

Quick facts Scientific classification, Type species ...
Palaeotherium
Temporal range: Middle Eocene – Early Oligocene 43.5–32.5 Ma
Scientific classification Edit this classification
Kingdom: Animalia
Phylum: Chordata
Class: Mammalia
Order: Perissodactyla
Family: Palaeotheriidae
Genus: Palaeotherium
Cuvier, 1804
Type species
Palaeotherium magnum
Cuvier, 1804
Other species
  • P. medium Cuvier, 1804
  • P. crassum Cuvier, 1805
  • P. curtum Cuvier, 1812
  • P. duvali Pomel, 1853
  • P. castrense Noulet, 1863
  • P. siderolithicum Pictet & Humbert, 1869
  • P. eocaenum Gervais, 1875
  • P. lautricense Stehlin, 1904
  • P. muehlbergi Stehlin, 1904
  • P. renevieri Stehlin, 1904
  • P. ruetimeyeri Stehlin, 1904
  • P. pomeli Franzen, 1968
  • P. crusafonti Casanovas-Cladellas, 1975
  • P. llamaquiquense Casanovas-Cladellas & Santafé Llopis, 1991
  • P. giganteum Cuesta, 1993

For subspecies suggested, see below.

Synonyms
Genus synonymy
  • Paleotherium Cuvier, 1804
  • Paloeotherium Cuvier, 1804
  • Palaetherium Rafinesque, 1814
  • Paloetherium Rafinesque, 1814
  • Salaeotherium Roulin, 1829
  • Palacotherium von Meyer, 1838
Synonyms of P. magnum
  • Palaeotherium girondicum Blainville, 1846
  • Palaeotherium aniciense Gervais, 1848–1852
  • Palaeotherium subgracile Aymard, 1853
  • Palaeotherium magnum parisiense Gervais, 1859
  • Palaeotherium stehlini Depéret, 1917
  • Palaeotherium franzeni Casanovas-Cladellas & Santafé Llopis, 1980
Synonyms of P. medium
  • Palaeotherium brivatense Bravard, 1843
  • Palaeotherium suevicum Fraas, 1869
  • Palaeotherium möschi Stehlin, 1904
  • Palaeotherium euzetense Depéret, 1917
Synonyms of P. crassum
  • Palaeotherium indeterminatum Cuvier, 1822
Synonyms of P. curtum
  • Palaeotherium latum Cuvier, 1822
  • Palaeotherium buseri Stehlin, 1904
Synonyms of P. duvali
  • Palaeotherium heimi Stehlin, 1904
  • Palaeotherium kleini Dietrich, 1922
Synonyms of P. castrense
Synonyms of P. siderolithicum
  • Plagiolophus siderolithicus Pictet & Humbert, 1869
Synonyms of P. eocaenum
  • Paloplotherium depereti Stehlin, 1902
Synonyms of P. muehlbergi
  • Palaeotherium velaunum Blainville, 1848
Dubious species
  • Palaeotherium gracile von Meyer, 1839
  • Palaeotherium parvulum de Serres, 1844
  • Palaeotherium commune Blainville, 1846
  • Palaeotherium primaevum Aymard, 1853
  • Palaeotherium gervaisii Aymard, 1853
Close

Hi folks! A proposal for providing zoomed-in fossil ranges focusing on a single period, with {{Period fossil range}}, was discussed on Wikipedia talk:WikiProject Palaeontology, which received broad support for being used in specific cases. It would show up in addition to the main range generated by {{Geological range}} (for example in taxoboxes or formation infoboxes). Some editors suggested querying broader input outside of the WikiProject, so I am asking here if anyone has feedback about it!

Here is an example to the right, suggested by User:IJReid! Beyond this one, all 12 possible bars can be found at {{Period fossil range/rangebar}}. Courtesy ping to people in the earlier thread: @The Morrison Man @Hemiauchenia @African Mud Turtle @LittleLazyLass @IJReid @Jens Lallensack Chaotic Enby (talk · contribs) 20:27, 3 March 2026 (UTC)

It feels like a useful inclusion for us at our WikiProject, but there is always the worry that by including additional "technical" details we could oversaturate the infobox with details that are in some way against the interest of informing those who aren't as knowledgable about the geologic time scale. Input on its appearance and intuitive use would be appreciated; does it make sense in the example infobox on the right here how the timescale bars are related among other things. IJReid {{T - C - D - R}} 03:40, 4 March 2026 (UTC)
I appreciate your reasonable concern about oversaturation, but the infobox on the right seems way shorter than the chemboxes that we currently have at pages like Calcium. LightNightLights (talkcontribs) 17:26, 4 March 2026 (UTC)
For the sake of completion I have modified it to include the entire contents, originally it was abbreviated to focus just on the upper region. IJReid {{T - C - D - R}} 17:38, 4 March 2026 (UTC)
(partial-contents permalink) I see; thank you for that! That does change things a bit: still shorter with lists collapsed than Calcium, but still long. We probably should have a mandatory maximum infobox size but thinking about it, that's a discussion for Wikipedia at large, not Wikipedia's taxonomy infoboxes in specific. LightNightLights (talkcontribs) 19:30, 4 March 2026 (UTC)
For what it's worth, Palaeotherium is a bit extreme in having such a long list of species and synonyms. Many fossil genera have only one species and few if any synonyms, and thus have very short taxoboxes. Giving a "see text" notice as with Dimetrodon is also an option when it simply becomes too much, or collapsing the list as at Titanosauria. LittleLazyLass (Talk | Contributions) 19:39, 4 March 2026 (UTC)

Quick facts Scientific classification ...
Horodyskia
The holotype fossil of Horodyskia
Scientific classification Edit this classification
Domain: Eukaryota
Kingdom: incertae sedis
Genus: Horodyskia
Close

Quick facts Scientific classification ...
Primates
Temporal range: 65.9–0 Ma
Early Paleocene to Present
Scientific classification Edit this classification
Kingdom: Animalia
Phylum: Chordata
Class: Mammalia
Clade: Pan-Primates
Order: Primates
Close
I've been playing around with this template in my sandbox and I really like the idea. Is there a plan to add graphical support for the Precambrian? I see that the template documentation says that Periods before the Cambrian are not formally subdivided into epochs or ages, and this template will not work on them, however, I feel like it could be possible to add this support, maybe on a different scale? As an example, I added an infobox excerpted from Horodyskia with the template added twice. The first bar is using the parameter Proterozoic (an eon) and the second bar is using the template Mesoproterozoic (an era). The bar appears to display correctly in both cases (the runoff is expected as the Mesoproterozoic ends midway through Horodyskia's range), just without the graphics. mdm.bla 18:00, 4 March 2026 (UTC)
Yep, now that I think about it, that could also be a great addition! I'll try to see if I can set this up for the Proterozoic as a demo. Chaotic Enby (talk · contribs) 18:25, 4 March 2026 (UTC)
Additionally, not sure of the reason behind this, but the {{All time 250px}} template is wider than the Phanerozoic one (which is 220px). Should they be uniformized, or should I make a separate 250px wide template for Precambrian subdivisions? Chaotic Enby (talk · contribs) 18:32, 4 March 2026 (UTC)
They can probably just be uniformized. Template:All time 250px also appears to display as a larger font than Template:Phanerozoic 220px. mdm.bla 18:40, 4 March 2026 (UTC)
Added a slight fix so the bars wouldn't have runoff, and are instead displayed as open on that side if there would have been some. Chaotic Enby (talk · contribs) 19:36, 4 March 2026 (UTC)
  • In the first example, the meaning is not intuitively accessible from the display. I spent awhile thinking the longer green bar was intended for the upper line of geological periods, as its green bar is very small. Would it work if the second bar is below the zoom in? CMD (talk) 08:17, 5 March 2026 (UTC)
    That could work! Although I'm not sure of the effect of having the more detailed/technical bar first. Alternatively, we could have the green bar on the bottom side of the second bar, or even just space them up by a few more pixels? Chaotic Enby (talk · contribs) 09:24, 5 March 2026 (UTC)
    I believe having it on the bottom of the second bar is what they were suggesting. LittleLazyLass (Talk | Contributions) 14:20, 5 March 2026 (UTC)
    How would that work when there are more than two bars?
    Either some sort of highlight (surrounding circle?) when a bar is narrower than (some amount) to make it more prominent or (probably more difficult to implement) a link between the bars would be clearer imo. c.f. File:Vatican_Europe_Location.svg. Thryduulf (talk) 14:42, 5 March 2026 (UTC)
    From what I understand, there shouldn't be more than 2 bars per infobox if/when this is added to mainspace. mdm.bla 14:47, 5 March 2026 (UTC)
    Yep, that's also what I'm having in mind. The only case where nested bars could be possible is the one to the right (as both the Proterozoic and its eras have bars), but in that case we should just pick the most precise one that fully covers the range (in this case, the Proterozoic as a whole, as the Mesoproterozoic one sees half the range be cut off).
    A link between the bars could also be possible, I'll have to look into it. Chaotic Enby (talk · contribs) 15:01, 5 March 2026 (UTC)
    I mean, theoretically you could have era-level bars for the Phanerozoic as well (see example for Primates with the parameter Cenozoic), but at that point you might as well just also create Template:Era fossil range. mdm.bla 15:11, 5 March 2026 (UTC)
    Honestly, it makes sense for the Cenozoic as its periods are already quite short and you're likely to see ranges overlapping (especially between Neogene and Quaternary), but in that case, you wouldn't want another period-level range below it. Also, given the already broadened scope, I'm open to renaming the template something like {{Detailed fossil range}}. Chaotic Enby (talk · contribs) 15:21, 5 March 2026 (UTC)

Quick facts Scientific classification ...
Palaeotherium
Temporal range: Middle Eocene – Early Oligocene 43.5–32.5 Ma
Scientific classification Edit this classification
Kingdom: Animalia
Phylum: Chordata
Class: Mammalia
Order: Perissodactyla
Family: Palaeotheriidae
Genus: Palaeotherium
Cuvier, 1804
Close
  • For comparison, here's the sandbox version with the zoom-in and the bars on the lower side. Not especially a fan of that alternate design, although if the community prefers it I'd be happy to go with it. Chaotic Enby (talk · contribs) 13:16, 6 March 2026 (UTC)
    On second thoughts, that design is starting to grow on me, especially on a full-width infobox where it doesn't look too busy. Still torn between both, personally. Chaotic Enby (talk · contribs) 16:18, 6 March 2026 (UTC)
    I do think the addition of the zoom-in makes this a favourable version, could help with any confusion as to how the bars relate to one another. LittleLazyLass (Talk | Contributions) 16:32, 6 March 2026 (UTC)
I very much like this template as an idea, and quite like the current implementation. Although the template could use much better documentation. I also prefer the version with the zoom-in and bar on the lower side (can we just call it option 2?). However, in the case of the zoom-in on option 2, I'm uncertain that it is sufficiently visible. Likewise the colors used to demarcate stages and epochs are very close to each other.
  • I could not decipher the Pre-Cambrian sections, but by my count it has the following (very useful) possibilities: 5 period-to-stage level zooms for Paleozoic, 3 period-to-stage zooms for Mesozoic, 1 era-to-epoch level zoom for Cenozoic, and 3 period-to-stage level zooms for Cenozoic as well.
    • Courtesy of Monster lestyn in a convo on Discord: the Pre-Cambrian sections are 2 eon-to-era for the Archean and Proterozoic Eons, and 3 era-to-period for the Proterozoic's eras. That far back, it doesn't need to get more granular.
  • I will note that there are not era-level zooms for Paleozoic and Mesozoic, whether to the better-known periods or the epochs (like Cenozoic has); I do not deal with Paleozoic or Mesozoic paleontology often enough to say whether those who do edit in that area would find those useful.
  • The unofficial, but frequently used, split of the Carboniferous into the Mississippian and Pennsylvanian periods is not treated at all. I have no opinion on whether there should be two extra for these but am mentioning it for others' sake.
Personally, I have an issue with the Quaternary-to-stage bar, because in the Quaternary, the stages are more commonly called the Early/Middle/Late Pleistocene than Gelasian/Calabrian/Chibanian, and the rigorous adherence to having the sections proportionate to the time span means the Holocene doesn't show up at all. I would ask that the names be amended and the sections more evenly proportioned.
Overall, I thank Chaotic Enby for their hard work and support widespread implementation of this template. SilverTiger12 (talk) 22:30, 10 March 2026 (UTC)
I saw this on the WP:Palaeo Discord and overall, I really like the concept! While I do agree that oversaturation could be an issue with it, having it in tandem with the overall timescale is nice. I prefer the second method (the one with the zoom in) because in my opinion it helps connect the two and explain the concept to the layperson. My only gripes really are with the Quaternary period. the ages like Chibanian, Gelasian, and Calabrian aren't commonly used in literature, it is much more common you hear the unofficial terms "Early Pleistocene" = Gelasian & Calabrian, "Middle Pleistocene" = Chibanian, and "Late Pleistocene" (not official recognized, but very commonly used. I really think for the Quaternary, you should have one range that separates into the Early, Middle, Late Pleistocene, as well as the Holocene. Its unfortunately not as neat as the official terminology, but it is much more widely used in literature and by the public. All, in all, I really like the proposal and am more than happy to support it once some of the kinks are worked out --Montanoceratops (talk) 22:32, 10 March 2026 (UTC)
Thanks both of you for the feedback! @SilverTiger12, I can't really change the proportions as the bar length is proportional to the time length. For the stage/epoch demarcation, I've been using the official ICS colors from {{Period color}} – I've been thinking of adding one-pixel dividers between them to make the demarcation more visible.
The Mississippian and Pennsylvanian are a bit of a mess. They're not on the main timeline, so adding them as a zoom-in might be confusing (especially since the Pennsylvanian uses a similar color scheme to the Carboniferous itself), but I'm open to still offering them as an alternative.
For the Quaternary: thanks @Montanoceratops, I didn't know about that! I tried to follow the official one (which is why the L for Late Pleistocene is in italics), and, while I'm worried that the timeline would be visually very unbalanced if more than half of the period was a single subdivision, I could do it if that reflects the sources better than the "official" version. Chaotic Enby (talk · contribs) 01:21, 11 March 2026 (UTC)
Yeah, unfortunately there really isn't a perfect solution since there's a lot of variation in the geologic timescale. While I do think having half of the Pleistocene as one period is a little silly, I would like to definitely prioritize the most common terminology used in scientific literature if possible, since, from my experience, most folks in Quaternary research use/are familiar with the early/middle/late terms over the "offical" ones (based on both my research into formations myself for Wikipedia and my friends' book, as well as my discussions with folks interested in Pleistocene research and paleomammology). And at least for the Chibanian, that's already what Wikipedia redirects to. Unfortunately really no matter how its split there's compromise involved, because there's a lot of nuances in the international timescale, as well as the many, many local scales that sometimes get utilized over the international ones (this is thankfully becoming increasingly rare, except for maybe land mammal ages). Still, I do think this template is really great and it will be a very useful addition to extinct species pages (as well as many straight up geology formation pages which also use the same template). I do hope you add an arrow icon for specific date. For example, if something is exactly 47 Ma, it doesn't display anything, but sometimes dates can get really precise (down to a few thousand to hundreds of thousands of years).
Additionally, I personally think its fine not distinguishing the Mississippian from the Pennsylvanian too heavily. The colors already imply it, and most modern resources usually say Carboniferous first and foremost over Mississippian or Pennsylvanian.
All in all, great work! Montanoceratops (talk) 04:56, 11 March 2026 (UTC)

RfC: Term dates in Infobox officeholder

{{Infobox officeholder}} is not clear about the usage of term dates, which leads to situations such as Kristi Noem, where users have added not only dates in the future, but labels such as "TBD". Wikipedia:Village pump (proposals)/Archive 175#RfC: Interim use of successor in Infobox officeholder implied that Wikipedia should not be including dates that have not happened yet, and precedent supports that assumption, but it leaves open the TBD issue.

Should the term dates in {{Infobox officeholder}} be strictly limited to dates that have already passed, excluding non-specific labels? elijahpepe@wikipedia (he/him) 02:08, 9 March 2026 (UTC)

Survey

Discussion

  • Is this not already covered by "the infobox for an incumbent officeholder should not mention an elected or designated successor, or the end date of the term [emphasis added], until the successor takes office"? CMD (talk) 03:08, 9 March 2026 (UTC)
I am primarily focusing on the TBD label. elijahpepe@wikipedia (he/him) 07:09, 9 March 2026 (UTC)
So when you say "excluding non-specific labels", you're saying that TBD should be allowed - or rather, that it wouldn't be disallowed by this, but still left open for people to debate over depending on the situation?

My concern is that it's still a grey area regarding WP: CRYSTALBALL. A specific date in the future clearly violates it as things can change, but it's also possible that they never take office for various reasons, so TBD is still a prediction. It implies that they WILL and only the date is uncertain. I think I'd prefer to only have it included in infoboxes after the fact, and anything else discussed in body. Infoboxes should only state simple verified facts. And on a contentious BLP we need to be extra cautious.

Additionally, while the formation of a new position means it's technically not a succession per CMD's point, I believe the same standards should be applied consistently. I see they've done the same to Markwayne Mullin, which is a violation - unless you argue that rule only applies to the article for the position itself (United States Secretary of Homeland Security in this case) and that the individuals' pages should have different standards. They are both still incumbent in their prior positions and I think that's what all related infoboxes should show. I'm sure they're will be editors hovering over the publish button to update as soon as the transition takes place. Right now it makes it look like their future position (that may or may not occur) takes priority over their current title and duties. I'm sure this issue must have come up before with elected positions, right? ChompyTheGogoat (talk) 22:17, 9 March 2026 (UTC)
I think there are actually multiple different scenarios and I'm not certain that one rule necessarily fits all, or at least the reasons are not always identical:
  1. The date an incumbent's term is scheduled to end. For example, Donald Trump's term as president of the US is scheduled to end on 20 January 2029.
  2. The date an incumbent has stated their term will end (for example someone resigning with effect from a future date; a politician who has stated they will not seek re-election when their term ends)
  3. The date an incumbent's term will end if the mandate is not explicitly renewed (e.g. a first term US president)
  4. The latest date an incumbent's term can end (e.g. Prime minister of the UK)
  5. The date an appointed or elected person's term will start (e.g. a president-elect of the United States)
  6. The date a person's term will start if they are elected/appointed (e.g. Kamala Harris and Donald Trump in October 2024)
  7. The date a person's term is expected or speculated to start or end (e.g. it is widely speculated about when UK prime ministers in their third or fourth year will call the election, with certainties ranging from "my mate down the pub thinks" to "I've personally seen documents where the PM has explicitly said they will do this")
  8. The date a person's term will start or end relative to an event whose date is not currently known (e.g. X days after an election is called)
As long as context is clear, 1-5 are not WP:CRYSTAL issues. 1, 3 and 4 may or may not be useful to include in an infobox, 2 and 5 probably are useful and I would not object to their inclusion, although possibly with an explanatory footnote.
6 is something that shouldn't be in an infobox imo but may or may not be good in prose where the unknown and known portions can be clearly expressed (If X happens we know Y will follow n days later, but we don't know if X will happen).
7 is pure crystal ball and should not be anywhere near an infobox (reliably-sourced speculation may or may not be DUE in the prose).
8 is something that probably belongs in prose (although probably more commonly an article about the position than an individual biography). Thryduulf (talk) 00:34, 10 March 2026 (UTC)
This perfectly articulates the situation. Historically, I've never seen any of these be implemented, so I'm all for keeping the status quo. elijahpepe@wikipedia (he/him) 02:23, 10 March 2026 (UTC)
It's ALL WP: CRYSTAL because no one here can see the future (afaik), and all of your examples prove why it should only be included in the body where the full context can be explained. You can say that a term is scheduled to end at a certain time, but you cannot guarantee it will actually happen. Maybe they die before then and their term ends sooner - which may affect who succeeds them as well as when, such as a VP being tapped in between election and inauguration. Or maybe WW3 starts and elections/successions are suspended. We just don't know.

Also relevant:
MOS:INFOBOXPURPOSE The less information that an infobox contains, the more effectively it serves its purpose, allowing readers to identify key facts at a glance.
WP:UNDUE Undue weight can be given in several ways, including but not limited to... the prominence of placement. ChompyTheGogoat (talk) 03:05, 10 March 2026 (UTC)
CRYSTAL applies identically in the article prose and the infobox. 1-5 are not CRYSTAL in the exact same way that saying there will be a US presidential election in 2028 is not CRYSTAL. Also, nobody has (to my knowledge) suggesting putting something in the infobox that isn't in the prose, so your quote of INFOBOXPURPOSE is irrelevant. Whether something is something that cannot be determined other than at the individual article level, so again is irrelevant to this discussion. Thryduulf (talk) 03:37, 10 March 2026 (UTC)
It is not WP:CRYSTAL if it is explained based on how it's presented in the sources. The article currently says On March 5, Trump announced that he had reassigned Noem to a new position, "Special Envoy for The Shield of the Americas" and Noem is set to leave her position on March 31. Those are both objective statements of things that have already been said on record, not a claim about what will happen in the future. Including a date or "date placeholder" in the infobox without that context isn't appropriate. I'm not sure whether there's a relevant guideline, but generally speaking I don't think things should be included in infoboxes if they might need to be removed if they don't take place. The in body discussion would still be reasonable to retain even if she never actually assumes the position, but not the infobox section.

I edited the above MOS quote to highlight the specific part I consider relevant. ChompyTheGogoat (talk) 03:57, 10 March 2026 (UTC)
I edited the above MOS quote to highlight the specific part I consider relevant. except it's still not relevant: Stating infoboxes should only contain "key facts" in a discussion that asks (in part) "is X a key fact?" is not helpful.
It is not WP:CRYSTAL if it is explained based on how it's presented in the sources. yes and no. A footnote saying "scheduled [source]" or similar is, in many cases, sufficient explanation.
I don't think things should be included in infoboxes if they might need to be removed if they don't take place. including such things is very common, see for example 2024 United States presidential election, 2026 FIFA World Cup, 2028 Summer Olympics, 2029 European Parliament election, Eurovision Song Contest 2026, etc and countless others. Covid required thousands of edits to infoboxes to account for things that were cancelled or postponed, people just got on with doing that without there being any issues.
I'm not arguing that every future event must be included - I'm saying that in the general case some should not, some could be and some maybe should be. Precise content of a specific infobox is something that can only be decided on a per-article basis. Thryduulf (talk) 04:22, 10 March 2026 (UTC)

CentralNotice banner in Indonesia explaining the recent block on auth.wikimedia.org and linking to ID WP community statement

Background: Indonesian government blocked the login/registration authentication subdomain in Indonesia since Feb 25th.

The communities from Indonesia have written a statement together, and proposed to put up a banner:

I would like to invite English Wikipedia to put a banner as well, to be displayed through March 10, 2026, with Indonesian geolocation (according to stats.wikimedia.org, in February 2026, English Wikipedia has 58 million page views from Indonesia), explaining the restriction and link to the community statement.

Wikimedia Foundation statement can be found in Wikipedia:Wikipedia_Signpost/2026-03-10/In_the_media#Logins_blocked_in_Indonesia

Banner content (feel free to copyedit):

Since February 2026, registration and login access to Wikipedia and other Wikimedia projects has been blocked in Indonesia. At this time, these sites remain accessible to read, and to contribute to as logged-out users.
read more

Cheers. Bennylin (talk) 06:30, 10 March 2026 (UTC)

A banner is probably a good idea to inform editors/users of the situation as it will impact some users, but the second sentence directly communicating with the Ministry does not seem necessary for this. May as well include a link to that Signpost which seems to explain the situation, unless we want to spin up a separate information page. CMD (talk) 07:04, 10 March 2026 (UTC)
Feel free to edit the banner. We were thinking of tagging the ministry in social media and such. Bennylin (talk) 07:22, 10 March 2026 (UTC)
A separate information page wouldn't be a bad idea. It could focus specifically on how it affects readers and editors and what actions they can take, with a link to the Signpost for more information on the background. Thebiguglyalien (talk) 21:12, 10 March 2026 (UTC)
I would combine then with a few tweaks like so, with the signpost link as a placeholder for a specific information page:
Since February 2026, registration and login access to Wikipedia and other Wikimedia projects has been blocked in Indonesia. At this time, these sites remain accessible to read, and to contribute to as logged-out users. CMD (talk) 03:46, 11 March 2026 (UTC)
@Chipmunkdavis maybe this link instead? Wikipedia:Open letters/Official statement from the Indonesian Wikipedia community regarding the restriction of access to auth.wikimedia.org in Indonesia. – robertsky (talk) 04:03, 11 March 2026 (UTC)
I would not link an open letter from another Wikipedia so prominently unless endorsed by the English Wikipedia community. CMD (talk) 05:31, 11 March 2026 (UTC)
I've incorporated CMD's version. We can still discuss where to link the "Read more" to (or none at all). Thanks. Bennylin (talk) 08:51, 12 March 2026 (UTC)
Support. Also in agreement with CMD. – robertsky (talk) 07:11, 10 March 2026 (UTC)
Support. Jack Wylde (talk) 08:30, 10 March 2026 (UTC)
Agree But, as mentioned by CMD, instead of directly urged by "us", should we use the literal translation from Indonesian copy that encourage our readers to do so? Or, is it intentional in English?
So, what do you think if we go with: "Since February 2026, registration and login access to Wikipedia and other Wikimedia projects has been restricted in Indonesia. We [encourage you to] urge the Ministry of Communication and Digital Technology [Affairs] to revoke this restriction so that we can continue to disseminate knowledge together!" William Surya Permana (talk) 13:25, 10 March 2026 (UTC)
I have incorporated your changes. Thanks. Bennylin (talk) 17:31, 10 March 2026 (UTC)
WMF's statement: At this time, Wikimedia projects remain accessible to read and contribute to as logged-out users. should probably be added to the notice too. Some1 (talk) 13:44, 10 March 2026 (UTC)
That would be obvious because they're able to visit that wiki page, no? Bennylin (talk) 17:32, 10 March 2026 (UTC)
Support a banner with whatever wording the community agrees upon. This should be the response when Wikipedia is forcefully censored. It's frightening how common it's becoming, and it's even more frightening that, to this point, a portion of the community has been so resistant to protesting when it happens. Thebiguglyalien (talk) 21:09, 10 March 2026 (UTC)

Explanation of the Proposal Process

You have a sentence or two at the top of this page for where to post for various kinds of topics, but nowhere (accessible) do you have an explanation of the steps in the proposal process or of ways to help shepherd the proposal to approval or even to get an acknowledgement of awareness by people who make decisions on proposals.

The lack of the explanation does not properly acknowledge people's efforts in making a proposal, and it can result in just a waste of time for the proposer and anyone who reads the proposal and especially comments on it. This ultimately discourages people from making proposals to try to improve Wikipedia.

Thank you for your consideration. ~2026-90420-1 (talk) 16:21, 12 March 2026 (UTC)

Proposals are posted here and discussed by those interested in doing so to reach a consensus. For high profile issues, a mass message drawing attention can be sent out, though we try not to pester people, either.
The best thing that someone can do to persuade others to support a proposal is to explain what concern/issue the proposal is trying to remedy and why the proposal is the best way to do that.
I'm guessing you've wanted to offer proposals but have felt discouraged? Please offer one now, if desired. 331dot (talk) 17:02, 12 March 2026 (UTC)
I actually already made a proposal, which did include the reasons for the proposal -- appearance and sustained readability. It was discussed on various points, people went out of their way to contribute some helpful graphics and other things, *there was no controversy to draw many comments*, and then nothing more happened, and it went to archive (227).
My point in this proposal about the explanation is that I have no idea how the proposal is supposed to get the attention of actual decision makers. I have no idea what progress would look like or what the criteria are to help the proposal go in that direction. And then there's no demonstrable justification for the proposal to just fade away.
That comes across as Wikipedia saying, "We just don't care. And we don't care that you put time and effort into proposing something, and that other people put time and effort into noticing it and commenting on it (and more). We just don;t care about the efforts of anyone who was involved in this proposal."
"And given that we don't explain anything about the process ahead of time, we don't care if you waste your time again in the future." I think that Wikipedia probably does care; that needs to be demonstrated. ~2026-15808-31 (talk) 19:10, 12 March 2026 (UTC)
There is not a single Wikipedia voice. The people who make decisions on proposals are you, me, and anyone else who comments. In practice, in order to get anything accepted, it needs someone (who may be the originator of the proposal) to run with it and ensure that consensus is enacted. You, too, can be that person. Phil Bridger (talk) 20:14, 12 March 2026 (UTC)
First, that's interesting information. And as I said, it should be included at the top of the Proposals page.
Second, included in the explanation of the proposal process, what does "run with it and ensure that consensus is enacted" actually mean? How is something enacted? ~2026-15808-31 (talk) 12:41, 13 March 2026 (UTC)
How something is enacted depends on what you're trying to do. If for example your proposal is to modify a particular policy or guideline, then you enact it by making the necessary edit. Athanelar (talk) 16:26, 14 March 2026 (UTC)

Syntax - Mathematical Expression - Coding Examples

More than 15 years ago looking at coding of mathematical expression in Wikipedia with the background of Computer Science (parsers, compiler theory, ...) I perceived the mix of XML-tags for the MATH-tag and LaTeX inside the XML-tag as big technical challenge while the rest had a simple Markdown like notation for the source text editor. Now I can appreciate those decisions:

  • user-centric approach Editors are used to LaTeX for mathematical expression in their work, so for a least a part of the community members it is much more convenient to uses the source code editor even if WYSIWYG editors are available.
  • interoperability - Web libraries like MathJax, TexMath extension for LibreOffice use LaTeX, so it allows interoperability for creative commons content.
  • Code chunks in Wikipedia KnitR package or Jupyter notebook use syntax mix, to create executable code that calculates the values of mathematical expressions while there is syntax highlighting for programming code that shows equivalent code for processing mathematical expression (e.g. numerical analysis)

Now I see a transformation away from the MATH-tags towards a template driven rendering of mathematical expressions. Is there a best practice or are there recommendations/proposals how to keep coding examples and corresponding mathematical expression in MATH-tags in sync with the syntax highlighting tags to be displayed on Wikipedia article?--Bert Niehaus (talk) 09:03, 13 March 2026 (UTC)

This sounds like a topic for WT:WikiProject Mathematics. For the last discussion, see WT:WikiProject Mathematics/Archive/2025/Dec#HTML vs LaTeX. Preimage (talk) 11:45, 14 March 2026 (UTC)

Related Articles

Wikiwand AI