Wikipedia:Village pump (miscellaneous)

Detailed peer-reviewed analysis of effect of ghost-written, now retracted, paper on Glyphosate article in Wikipedia ==

A new peer-reviewed paper in the journal Environmental Science & Policy discusses at length the effect that a retracted, ghost written paper had on the Wikipedia article about Glyphosate. The paper is quite critical about the ghost-written nature of the paper being "..repeatedly removed or reversed."

The paper is:

Kaurov, A.A. and Oreskes, N., 2025. The afterlife of a ghost-written paper: How corporate authorship shaped two decades of glyphosate safety discourse. Environmental Science & Policy, 171, p.104160.

The paper stated:

Overall, we find that WKM2000 had a significant and problematic influence on how Wikipedia presented the science of glyphosate safety. Not only did Wikipedia editors frequently cite WKM2000 to support claims about glyphosate’s safety, but attempts to add context about its ghost-written nature were repeatedly removed or reversed.

Note: "WKM2000" = Williams et al. (2000), which is the retracted paper noted below.

At the time of its publication, Kaurov et al. (2025) noted that Williams et al. (2000) is also cited in the Wikipedia articles Polyethoxylated tallow amine, Roundup (herbicide), and Glyphosate-based herbicides.

The retraction notice for Williams et al. (2000) is:

Williams, G.M., Kroes, R. and Munro, I.C., 2025. Retraction notice to “Safety evaluation and risk assessment of the herbicide roundup and its active ingredient, glyphosate, for humans” [Regul. Toxicol. Pharm. 31 (2000) 117–165]. Available online 5 December 2025, 106006.

The citation to the, now retracted, Williams et al. (2000) is: Williams, G.M., Kroes, R. and Munro, I.C., 2000. Safety evaluation and risk assessment of the herbicide Roundup and its active ingredient, glyphosate, for humans. Regulatory toxicology and pharmacology, 31(2), pp.117-165.

Articles discussing Williams et al. (2000) are:

Science journal retracts study on safety of Monsanto’s Roundup: ‘serious ethical concerns’ Paper published in 2000 found glyphosate was not harmful, while internal emails later revealed company’s influence. by Cary Gillam, The Guardian, December 5, 2025 Paul H. (talk) 18:58, 5 December 2025 (UTC)[reply]

Glyphosate safety article retracted eight years after Monsanto ghostwriting revealed in court, Retraction Watch.

Oreskes, N., 2025. Cleaning the scientific house: Rebuilding trust in science requires confronting the harms of ghostwriting. Science, 390(6772), p.eaec4187. Paul H. (talk) 20:07, 5 December 2025 (UTC)[reply]

It would be useful to identify which edits were removed or reversed, according to the article quoted in blockquote tags above. Can anyone do so? Phil Bridger (talk) 21:20, 5 December 2025 (UTC)[reply]

THe article, Kaurov et al. (2025) provides specific dates and names of editors for specific edits. I have access to all of the papers and articles, including Kaurov et al. (2025), if someone needs one. You can emails me from my Talk page. Paul H. (talk) 21:51, 5 December 2025 (UTC)[reply]

Some editors have been discussing this at Talk:Monsanto and some bird article I can't remember the name of right now. Katzrockso (talk) 21:42, 5 December 2025 (UTC)[reply]

In the mainspace at the moment, it is only cited in Monsanto and Regulatory Toxicology and Pharmacology, both of which are explaining that the paper was retracted. WhatamIdoing (talk) 03:48, 6 December 2025 (UTC)[reply]

That is true, because of the discussion at Talk:Polyethoxylated_tallow_amine#Williams et al 2000 paper in early October. However it was in mainspace at that time and removed despite at least some critical discussion points arguing to retain it. It was still cited in this version and was removed [1] [2] twice Andre🚐 04:39, 6 December 2025 (UTC)[reply]

I don't edit anywhere near this area, but if this paper was published in a journal that's a reliable source, and it wasn't retracted until 5th December this year, then it seems entirely appropriate to me for Wikipedia to have cited and used it. It's no part of our job to second guess what reliable sources are telling us. Chuntuk (talk) 15:54, 17 December 2025 (UTC)[reply]

Hello! I'm Rae from the Wikimedia Foundation's Communications department. As you may know from previous posts, on January 15, 2026, Wikipedia turns 25 years old. We'll be hosting a virtual celebration on January 15 and plan to run CentralNotice banners to invite logged-in users to join. The event will be live-interpreted into Arabic, Chinese, French, Spanish, and Portuguese. You can view details about the planned CentralNotice campaign on Meta-Wiki. Please feel free to reply here if you have any questions. RAdimer-WMF (talk) 21:55, 8 December 2025 (UTC)[reply]

The voting phase of the December 2025 administrator elections has started and will continue until Dec 15 at 23:59 UTC. You can participate in the voting phase at Wikipedia:Administrator elections/December 2025/Voting phase.

As a reminder, the schedule of the election is:

• Dec 9–15 - SecurePoll voting phase
• Scrutineering phase

In the voting phase, the candidate subpages close to public questions and discussion, and everyone who qualifies to vote has a week to use the SecurePoll software to vote, which uses a secret ballot. You can see who voted, but not who they voted for. Please note that the vote totals cannot be made public until after voting has ended and as such, it will not be possible for you to see an individual candidate's vote total during the election. The suffrage requirements are similar to those at RFA.

Once voting concludes, we will begin the scrutineering phase, which will last for a few days, perhaps longer. Once everything is certified, the results will be posted on the results page (this is a good page to watchlist), and transcluded to the main election page. In order to be granted adminship, a non-recall candidate must have received at least 70.0% support, calculated as Support / (Support + Oppose), and a minimum of 20 support votes. Recall candidates must achieve 55.0% support. Because this is a vote and not a consensus, there are no bureaucrat discussions ("crat chats").

Any questions or issues can be asked on the election talk page. Thank you for your participation. Happy electing.

You're receiving this message because you signed up for the mailing list. To opt-out of future mailings, please remove yourself from the list.

MediaWiki message delivery (talk) 01:06, 9 December 2025 (UTC)[reply]

As can be seen on this page, Google is low-key announcing that Classic Google Books will be turned off and they instruct users to import their existing bookshelves before they're no longer available. Typically, there's nothing on the Google Search Help Page > "Use the new Google Books" about this cataclysmic (to me at least) upcoming event. If you click on the "try new Google Books here" on that same page, you are taken to this page, perhaps a Google engineer's sick joke.

Now, when I search Goggle Books and click on links I'm redirected to the new Google Books domain by default, even though I had long ago set Classic in my preferences. How will this affect the hundreds of thousands of Classic Google Books links already in WP articles? I find it much easier to use the simple, clean urls of the Classic version to copy book urls. I can use Classic urls and they will be redirected, but it's a hassle to derive them from the new default Google Books urls and doing so wrecks my work flow. I hope someone creates a Firefox extension that will restore the Classic view. Carlstak (talk) 19:36, 9 December 2025 (UTC)[reply]

This is why we insist on full citations. If you give me the title, author, publisher, etc, I can (in theory) find another provider which has a copy and losing the linked-to URL in Google Books is just a minor inconvenience. RoySmith (talk) 19:43, 9 December 2025 (UTC)[reply]

I agree. Citations should be to the book, not Google Books. Phil Bridger (talk) 19:47, 9 December 2025 (UTC)[reply]

? Of course I use full citations, I've added thousands to WP. The change creates extra work, because I always include a link to the source page when possible so other editors can easily check verifiability, and Google Books often has the only linked page available. I use archive.org/ links if they have a copy of the work. I never add raw links to articles, and have spent a lot of time, grudgingly, to convert them to full citations. Carlstak (talk) 19:53, 9 December 2025 (UTC)[reply]

This seems like an opportunity for somebody who likes writing tools do attack this problem. It would be useful to find all citations that link to Google Books, verify that they also have full citations, and search for alternate sources. RoySmith (talk) 19:59, 9 December 2025 (UTC)[reply]

I meant to include this comment: "I hope someone will create a Firefox extension to restore the Classic Google Books view." Carlstak (talk) 20:49, 9 December 2025 (UTC)[reply]

Oh, I did. Maybe I shouldn't be trying to edit this page while I'm dealing with an insurance claim.;-) Carlstak (talk) 21:05, 9 December 2025 (UTC)[reply]

Argh I despise the new Google Books, never managed to get it to work, and Classic was no hassle at all. Tercer (talk) 20:24, 9 December 2025 (UTC)[reply]

I think some of the Google engineers are sadists. I might be too if I worked for Google.;-) Carlstak (talk) 20:54, 9 December 2025 (UTC)[reply]

This will be very chaotic on Wikipedia, especially in contentious topic areas like the Balkans, Middle East etc, as the google books weblinks are heavily used in references for accessibility and verifiability - done so as to prevent or dissipate edit wars etc which sadly even with all that still plague those topic areas. Once the google books weblinks go defunct and are not covered/accessible in the new format, an array of editors (or IPs) who may not have liked certain content will wreak havoc. I think this is something the Wikipedia community and the Wikimedia Foundation needs to look into seriously, deeper and prepare for what's coming. If possible the Wikimedia Foundation should contact Google and ask for a timeline as to when its going to happen. Also editors who are into the more technical side, if possible, would need to make a tool or something of the sort that can transfer the classic books urls into the new format while somehow preserving the url link which often is to a specific page or to a term looked up in the book which makes certain pages show related to that term etc.Resnjari (talk) 05:44, 13 December 2025 (UTC)[reply]

When Google introduced "New Google Books" I feared this happening—then I knew they would almost certainly kill off Classic Books, like they did Google Reader, an action that destroyed a whole blog ecosystem. They've done this with many of their projects, and do it with no respect for the users of their products. Yes, the Wikipedia community and IMF should address this consequential event. Carlstak (talk) 16:15, 13 December 2025 (UTC)[reply]

To be clear, the old urls should still work. Andre🚐 20:59, 14 December 2025 (UTC)[reply]

Yes, I mentioned this above where I wrote "I can use Classic urls and they will be redirected". The issue I see, as I also mentioned above, is that "it's a hassle to derive them from the new default Google Books urls". Carlstak (talk) 21:06, 14 December 2025 (UTC)[reply]

Is is trivial to derive them. The id just goes into a specific slot in the new url format. Andre🚐 21:09, 14 December 2025 (UTC)[reply]

It's a pain in the ass compared to using the clean Classic Google Books urls, which is the main point of what wrote in my op. I'm bitching that it will slow down my work flow. It's "cataclysmic, at least to me", as I said above. I know how to derive them, I'm already doing that in generating the refs for the article I'm working on now. Carlstak (talk) 21:22, 14 December 2025 (UTC)[reply]

Citation bot will automatically convert the format I think. Andre🚐 21:30, 14 December 2025 (UTC)[reply]

Hmmm, that's a thought. I'll have to experiment with it. I know from experience that using Citation bot sometimes has unintended consequences and can mess things up, so it has to checked, rather than just blindly hitting "publish", but maybe this would be a solution. Carlstak (talk) 21:39, 14 December 2025 (UTC)[reply]

+1, the new one seems so clunky. Is there an easy way to convert classic urls into the new ones? CMD (talk) 11:29, 13 December 2025 (UTC)[reply]

• Google Books is a commercial product not a library or archive. Previous attempts to convert to non-profit archival sites like HathiTrust and Internet Archive have been widely criticized and shut down, the primary reason is that people prefer the Google Books look and feel. Of course none of the book services are perfect, but Google Books has a lot of problems as discussed at Wikipedia:Google Books and Wikipedia. Enwiki currently has 2.25 million Google Books links, the largest by far (Internet Archive has less than a million by comparison). A large number of those Google Books links right now today are completely or partially broken, with more breakages happening daily, and even more when the Classic service is shut down. -- GreenC 18:24, 14 December 2025 (UTC)[reply]

  My post here was about Classic Google Books being shut down, so I am aware of that. First, Wikipedia:Google Books and Wikipedia is not a policy or even a guideline. Yes, its very first line says, "The document helps explain why we prefer not to use Google Books (GB) where better options exist" and it has a section called "Why Google Books isn't good" It also has a whole section called "Why we use it anyway". We do have a guideline that instructs one how to link to Google Books pages, so I'd say your argument is moot. Carlstak (talk) 19:11, 14 December 2025 (UTC)[reply]

  I did not argue that Google Books should be banned, that would be impossible, and not even wise. You over-reacted ("your argument is moot"). The essay provides arguments why individuals may want to instead consider using non-profit library services that aspire to long-term archiving stability. This episode brings home why ephemeral commercial services are a problem for Wikipedia. It's like linking Facebook and Amazon.com -- GreenC 20:37, 14 December 2025 (UTC)[reply]

  And I didn't say you argued that Google Books should be banned, GreenC. It's not "overeact"-ing to point out that you linked to an essay, an opinion piece, to help support your point, but didn't mention the part with 13 points in it that explains why we use them anyway. Funnily enough, many, if not most of the books digitized on archive.org use Google's digitalization, provided free. That would seem to complicate your point about Google being a commercial website. Carlstak (talk) 21:28, 14 December 2025 (UTC)[reply]

  First off I created that essay and wrote a large chunks of it. Second, the "why we use it anyway" is frankly not much reason for using Google vs. the non-profit archive providers, the reasons for are pretty weak in comparison to the reasons not to use Google. And we actually have a guideline WP:VENDOR (mentioned in the essay) that states: "e-commerce links should be replaced with reliable non-commercial sources if available" and it explicitly gives book websites as an example. All good essays are based on policy and guideline, and provide multiple POVS, and this is no exception. -- GreenC 19:25, 15 December 2025 (UTC)[reply]

  Well, that's a reflection of the limitations of your essay. I agree that reliable non-commercial sources should be preferred, "if available", as you say. As I said above, "I use archive.org/ links if they have a copy of the work" but "Google Books often has the only linked page available". As someone who has spent thousands of hours fact-checking articles on WP, I consider it paramount to include a link to the actual page of a source if one is available for verifiability's sake, so other editors can check my verifification. It is much, much less time-consuming to fact-check an article that has references with links, rather than without. Many of the articles I work on have hundreds of citations. I spend more time finding sources and checking them than anything else I do on WP, so better to have a Google books link, which policy allows, in any case. Is Google Books a non-profit archive provider when is provides digitizations of the books on its servers to archive.org? Carlstak (talk) 20:08, 15 December 2025 (UTC)[reply]

  Google has an algorithm that only allows a certain number of page views per day across all viewers. Thus while a page view may work today, it may not work tomorrow, because other pages have been viewed by other users that used up the quota. They only allow free page views within a certain range of pages, and those ranges can change. They frequently take books offline or move to another ID of remove the full page view access. Internet Archive has similar issues but not nearly as bad much more stable. Google doesn't "provide" books to Internet Archive, those were mostly copied (without explicit permission) by Aaron Swartz because they are in the PD and Google has no case to stop it, other than maybe a site agreement, which they would never enforce for something like that. Most ended up at Haithi anyway, another very good reliable non-profit resource that is underutilized in favor of Google's commercial site. -- GreenC 21:22, 15 December 2025 (UTC)[reply]

  I've acknowledged that reliable non-commercial sources, if *available*, are to be preferred. You don't need to reiterate your point, because I'm going to keep using Google Books links if non-commercial ones *aren't available*, for the reasons I've given above. Yes, anyone can upload pdfs of public domain books on Google Books to the Internet Archive. The Internet Archive Blog says: 'Millions of documents from court cases, and digitized books from other projects such as the Google book program and the Digital Library of India have been uploaded over the years." Google had no beef, as did JSTOR, with Aaron Swartz, who had an unofficial Google blog. It was not endorsed or sponsored by Google, but they hosted it. Tragic story, Aaron was obviously crying for help in so much of what he wrote under that stress, which I read after he hanged himself. Carlstak (talk) 23:12, 15 December 2025 (UTC)[reply]

  PS: Hathi Trust says: "95% of the collection was digitized from print by Google and contributed by member libraries.". Carlstak (talk) 03:07, 16 December 2025 (UTC)[reply]

  Google won Authors Guild, Inc. v. Google, Inc.. The Internet Archive did not win Hachette v. Internet Archive or Universal Music Group v. Internet Archive. I suspect the Internet Archive may be more vulnerable than Google. What would happen if the Internet Archive is made bankrupt by litigation? Presumably it might cease to exist. It is not obvious that the Internet Archive's are more stable than those of Google. James500 (talk) 09:47, 16 December 2025 (UTC)[reply]

  Why do we think the old urls won't work? I believe they will just redirect. Andre🚐 20:59, 14 December 2025 (UTC)[reply]

  "Enwiki currently has 2.25 million Google Books links" - do you know how many of them have an archive url specified? sapphaline (talk) 11:21, 15 December 2025 (UTC)[reply]

  Google Books doesn't archive very well. Sometimes it will work often not. -- GreenC 19:26, 15 December 2025 (UTC)[reply]

  Technically, unlike IA, Google has been blessed to run its Books via the result of Authors Guild, Inc. v. Google, Inc., but because it is limited to books they bought and only snippets of the books, rather than full works. (IA got in trouble because it was offering full books even though they had placed digital restrictions on how many could access it).

  That said, I am not very thrilled with using GBooks results directly as references. I dont care if one actually uses Gbooks to look up what a book says, and references the book without the reference to GBooks, just as, for example, one can use papers published on Researchgate (of questionably copyrightability) without linking to ResearchGate to fulfill a citation. GBooks also seems to use geolocation content services so that not every user gets the same snippets. Masem (t) 00:51, 16 December 2025 (UTC)[reply]

  Using a Google Books link in citation bot or the cite extension in visual editor will usually generate an ISBN and the author, year, publisher, etc., so it is effectively citing the actual book. Andre🚐 01:27, 16 December 2025 (UTC)[reply]

  I normally use RefToolbar to generate citations, but never visual editor (ugh). RefToolbar could use some tweaking. Carlstak (talk) 01:50, 16 December 2025 (UTC)[reply]

  The combination of the 2017 wiki editor + VE in wikitext editor allows you to edit wikitext using the VE cite generator but wikitext. Andre🚐 02:04, 16 December 2025 (UTC)[reply]

• Ask Google to refrain from turning off Classic Google Books. It would be trivial to replace one URL broken by the loss of Classic Google Books. But replacing more than two million URLs is a gigantic waste of our time and energy that we do not want to spend cleaning up a gigantic mess created by somebody else. (And of course the New Google Books has a really, really, really horrible interface that readers and editors will particularly not enjoy being sent to.) The solution is for Google to stop their plan to turn off Classic Google Books. If they don't turn Classic Google Books off, there is no problem. James500 (talk) 22:05, 15 December 2025 (UTC)[reply]

  Who says that any urls will be broken??? They are going to redirect. Andre🚐 23:32, 15 December 2025 (UTC)[reply]

  Where does it say, on their website, that they are going to redirect the existing URLs? All I have seen so far are the words "Classic Google Books will be turned off". Is that promise to redirect the existing URLs? James500 (talk) 00:21, 16 December 2025 (UTC)[reply]

  I don't know that it says that explicitly but it also doesn't say they will stop working. All that is happening is that the classic design is going away and will be replaced by the new one. Andre🚐 00:45, 16 December 2025 (UTC)[reply]

  We have no evidence that they are going to redirect the URLs. Even if they did redirect them, we would still have no evidence the redirects are permanent. Even if the redirects were permanent, turning off Classic Google Books would still have a very negative impact on Wikipedia and its readers: The New Google Books interface is vastly more difficult to use than the Classic Google Books interface, and would make it much harder for editors to write articles, and for readers to look at sources. (I personally find the New Google Books almost impossible to use, and I can see the internet is full of people complaining about how difficult it is to use the New Google Books). It would therefore be prudent to persuade Google not to turn off Classic Google Books before they have a chance turn it off, and the obvious first step is to ask them not to turn it off. James500 (talk) 09:19, 16 December 2025 (UTC)[reply]

  I disagree. I use the new Google Books interface and it works fine. Just get used to it. Andre🚐 15:40, 16 December 2025 (UTC)[reply]

  The new Google Books interface sucks. Google doesn't care about the user experience, they care about Google-izing the web. Down with the broligarchy! Carlstak (talk) 16:38, 16 December 2025 (UTC)[reply]

  Andre, it doesn't matter whether you can use the new interface, because that will not prevent disruption to the efforts of editors who cannot use it. I am informing you that I cannot use it, it does not work at all for me, and I am not capable of getting used to it, therefore my efforts will be massively disrupted. You might as well tell me to "just get used to" weightlifting a thousand pounds. James500 (talk) 23:49, 16 December 2025 (UTC)[reply]

  Nice work on List of digital library projects, James500—I've bookmarked it. This is how things get done on WP. Carlstak (talk) 00:27, 17 December 2025 (UTC)[reply]

  I have never edited that article. The have been 692 editors according to pageinfo, and I am not one of them. I do not see how that list is relevant to this thread. James500 (talk) 00:52, 17 December 2025 (UTC)[reply]

  I followed the link from your user page. Forget it. Carlstak (talk) 01:06, 17 December 2025 (UTC)[reply]

I think what Google is doing with Classic Google Books is a good example of what Cory Doctorow calls enshittification, the degradation of services offered by a two-sided platform. As that article says, he talks about upholding the end-to-end principle, which asserts that "platforms should transmit data in response to user requests rather than algorithm-driven decisions." What they're doing to force-feed their virtual assistant and chatbot Google Gemini on their user base doesn't inspire much hope of that ever happening, though. Carlstak (talk) 01:39, 17 December 2025 (UTC)[reply]

Hi, it recently came to my attention that some infoboxes were recently changed to automatically generate maps without any map parameter in the infobox wikitext or any coordinates stated in the article (they are automatically fetched from Wikidata if not present in the article). I have numerous concerns with this approach, including the following points:

1. The maps appear in the articles without any watchlist notifications to alert editors to their presence
2. It is very difficult for editors to understand why the maps appeared and how to get rid of them
3. This change was implemented by one editor without any broader discussion or consensus
4. Coordinates, particularly those hosted on Wikidata, rarely have a reliable source to support them
5. There is a high likelihood of the maps being wrong or misleading, including the case that I observed this behavior.

I believe that maps should be manually chosen by editors based what format is most accurate to convey the information available in reliable sources without misleading our readers or amplifying original research. I would like to get some more opinions whether generating maps by default in this manner is a good idea. (t · c) buIdhe 16:18, 10 December 2025 (UTC)[reply]

I've been discussing with a few other editors (@User:Viriditas, @User:Odysseus1479) about the issues with maps on Wikipedia. I'm working on a proposal for the pump (or somewhere), but in short, the state of maps on Wikipedia is a disaster of WP:OR and WP:SYNTH that would not be tolerated anywhere else on the project. They fail to follow the most basic cartographic conventions involving symbolization, projection, and sourcing. Many of the maps on the project are making mistakes that the most polite literature would describe as "misleading," and I have citations that point to places maps making these mistakes have lead to public misconceptions resulting in very negative consequences. The gist of the proposal I've been working on is that we need to work to work to improve Wikipedia:WikiProject Maps/Conventions and move them from the project space into Wikipedia:Manual_of_Style#Media_files. When I say improve the Wikiproject Maps conventions, I mean completely overhaul and in many places start from complete scratch. They do not actually mirror the conventions of cartography in the real world, and are woefully incomplete. I would recommend the book How to Lie with Maps to anyone interested in where I'm coming from. GeogSage ^{(⚔Chat?⚔)} 20:06, 10 December 2025 (UTC)[reply]

I think this could be reasonably generalized to most media. We insist (with varying degrees of success) that the article text be backed up by WP:RS, but images and their captions rarely receive such scrutiny. I once objected to an image caption at WP:FAC; it was a photo of a tropical fish and asserted what gender it was. I asked for backup on that and was basically shouted down with "Of course that's a <whatever gender>" but nary a WP:RS to back it up. This sort of thing happens a lot. So, I certainly support improving the situation for maps, but would encourage you to think a little broader if possible. RoySmith (talk) 23:26, 10 December 2025 (UTC)[reply]

Unfortunately, my expertise is pretty limited to maps. I have some graphic design background, and some background in the graphs used in general statistics that comes from experience with spatial statistics, but taking on all images is a bit beyond me. If others want to help expand, I'm all for it. GeogSage ^{(⚔Chat?⚔)} 04:59, 11 December 2025 (UTC)[reply]

This sounds like a reference to maps on Wikipedia in general, not to mapframe rendering?

The mapframe project has been conservative by default, and never enabling that sort of a map when there is an existing map in the infobox already.

Often times, that ends up keeping an old bad map in the article while a more appropriate mapframe stays hidden. --Joy (talk) 08:39, 14 December 2025 (UTC)[reply]

No, this doesn't seem like a good idea, for the reasons you mention. Nikkimaria (talk) 03:58, 11 December 2025 (UTC)[reply]

An additional concern is that there is no indicator that the information is coming from Wikidata. With some Wikidata infoboxes there is an icon next to information to take editors to the relevant Wikidata property, but that does not seem to be the case here. CMD (talk) 09:20, 11 December 2025 (UTC)[reply]

That is actually interesting, because every mapframe does show links to terms of use of Wikimedia Maps and OpenStreetMap, but it doesn't mention Wikidata if it's used. @Hike395 is it possible for us to edit how {{Infobox mapframe}} shows the bottom right label in Kartographer? --Joy (talk) 08:42, 14 December 2025 (UTC)[reply]

@Joy: Not that I know of -- that is under the control of Kartographer and I don't see any obvious parameters to change it. — hike395 (talk) 03:20, 17 December 2025 (UTC)[reply]

• Oh great… yet another problematic use of Wikidata. Will we never learn. Wikidata Delenda Est! Blueboar (talk) 14:10, 11 December 2025 (UTC)[reply]
  • Blueboar, CMD are you just against the generation of maps from Wikidata, or do you also oppose when maps are generated automatically (no parameter in infobox) from coordinates placed in the article? (t · c) buIdhe 01:36, 13 December 2025 (UTC)[reply]

    I'm sure I could be convinced that some maps might be helpful, and to treat Wikidata in a similar way to a template space, but we shouldn't be generating anything out of the control of the page editors. CMD (talk) 03:19, 13 December 2025 (UTC)[reply]

    The inclusion of mapframes in infoboxes is always preferring any local information to that on Wikidata. So for example if an infobox template is set up to go to Wikidata for a coordinates property, if the editor of the article includes |coordinates= in the infobox call, that always overrides any equivalent point on Wikidata.

    It should be noted that the reason why Wikidata can be really useful is usually not the points, but the shapes on maps. Our local mechanisms for showing map shapes are rather difficult to use, so they're very rare. The availability of these OSM map shapes - still modifiable with |mapframe-shape= and similar parameters, mind - has improved infobox map thumbnails in numerous articles. --Joy (talk) 08:46, 14 December 2025 (UTC)[reply]

Does anyone have a link or three to any affected articles? WhatamIdoing (talk) 19:00, 13 December 2025 (UTC)[reply]

[3] Here is where I noticed the problem. It took me quite a while to figure out why the map was showing up and how to get rid of it. Note that the location isn't correct. (t · c) buIdhe 01:46, 14 December 2025 (UTC)[reply]

Why did you not link the previous discussion at Template talk:Infobox civilian attack, where several of these claims have already been disputed at length?

I agree that maps appearing in the articles without any watchlist notifications to alert editors to their presence is not good. I'd have loved it if this visibility was possible. At the same time, this is how template editing works in general - we don't get notifications about any other template edits, either. Also, in that example, we identified over 2,000 of mapframe coordinates being enabled by the template edits, and you found a visual problem with 1. That is not proof of this being a universally bad situation.

I disagree that it would be difficult for editors to understand the situation post res. They can click on the confusing element in the visual editor and learn about the updates with a modicum of effort. If they use the source editor, they see which infobox template is used and they can likewise read the updated documentation.

Any change in every infobox does have to be implemented by a single editor, which is how WP:Be bold works. At the same time, this particular change in mapframes is based on numerous previous discussions collectively tracked at Wikipedia:Mapframe maps in infoboxes. I've made a lot of effort to document the process and that it always includes checking for applicability, updating template documentation, etc.

There is nothing particular about Wikidata coordinates that makes them more or less verifiable. They are equally as supported or unsupported by reliable sources on Wikipedia, too. (In the one problematic example you identified, we actually know that they came from another language Wikipedia.)

There is no proof that there is a high likelihood of the maps being wrong or misleading. We added many thousands of maps, and I've noticed a handful of complaints. Your complaint at the genocide article was about weird zoom level - the map did show the right place, but it was zoomed in too much which made it look like we're describing an event that happened in one specific place, where the original intent was to show the country where it happened, yet that intent wasn't preserved correctly through the conversion of technical attributes.

I think we would be wise to consider this situation in its entirety, as opposed to focusing way too much on one interpretation of one problem. --Joy (talk) 08:35, 14 December 2025 (UTC)[reply]

No, there is no way for me to click on the map frame and figure out that why it's appearing and how I get rid of it. All I see is the map itself.

And no, the coordinates for the gonocide article were not an accurate representation of where the genocide took place. I'm baffled why you continue to insist that this is the case when you seem to have no knowledge about the topic.

The lack of transparency is why you should seek consensus from editors who use templates rather than edit them a lot, before rolling out a significant change that will affect many articles.

If you thought maps were beneficial you could have just added support for map frames, and gone through articles individually where you thought they would be helpful, adding mapframe=yes. You chose to make it appear in a non-transparent way, which is why we're here. (t · c) buIdhe 16:48, 14 December 2025 (UTC)[reply]

I'm astonished to discover that in the discussion you seem to be referring to where the community weighed in on map frames, the discussion was closed by Wugapodes as "mapframes should not be on by default". That's all I'm asking for! (t · c) buIdhe 16:52, 14 December 2025 (UTC)[reply]

We've been over this already over there - that set of coordinates was originally significantly rounded up and zoomed out in order to show just the country, which it did. The later Wikidata bot import failed to account for that. I agree with you that what was shown wasn't an accurate representation of where the genocide took place, and that's why I also fixed both. You've ignored all that and just continued to argue against the notion of including these. I don't think this is productive.

Going through thousands of articles that already have the coordinates parameter and adding an explicit extra parameter is a huge waste of volunteer effort for something that can be done in a more general manner. Also, it might annoy a lot of people if we litter their watchlists with a huge number of automated edits like that.

With regard to the RFC, I interpret no consensus to turn on by default in the site-wide RFC as a site-wide lack of consensus. Why would this have to mean that we're barred from examining each individual infobox situation in context?

So, to be clear, I'm absolutely happy to agree with a consensus at Template talk:Infobox civilian attack about that feature (or indeed any different kind). So far, I've observed one person, yourself, arguing how the feature is a bad idea by default over a very specific set of circumstances that do not match the majority of the use cases of that template. That discussion isn't complete, and we do not have a settled consensus for or against the feature.

In this discussion here, we have a few more people chiming in, but it's not clear that y'all have the same perspective. For example, @GeogSage's comment seems to be a general criticism of the state of infobox maps, not the mapframe option default at Infobox civilian attack. We should figure this out. --Joy (talk) 17:36, 14 December 2025 (UTC)[reply]

?? It looks like you added this mapframe feature as default to many infoboxes, in explicit violation of a discussion consensus that you seem to be aware of, and you refuse to acknowledge that there was any mistake made or course correction needed? I hate to say it but perhaps it's time for ANI. (t · c) buIdhe 18:05, 14 December 2025 (UTC)[reply]

I examined each of these cases individually. In this case, there was no indication of controversy whatsoever, so I tried it out. The RFC was four years ago, and consensus can change - I figured it was time to try it out. And the attempt seemed to be a great success, because if we have over 2,000 new map thumbnails, and you found a bug in 1 of them, that sounds the outcome could be very good for the readers. I have no idea why you find this so objectionable just because of these relatively minor editor inconveniences that we can still iron out. --Joy (talk) 18:54, 14 December 2025 (UTC)[reply]

Yes, the state of maps in our infoboxes is quite dire. My favorite example of this, while we are on topic, is Sudan (pictured). Sudan has border disputes with several neighboring states, and the original map did not include these disputes. The updated map has added them in a light green color, which on the surface seems logical. However, there is no source for how the maps author created the disputed area, no source for the original boundaries, and if you look at the image history on the previous Sudan map, you can see that there have been some major changes to reflect its borders that also do not have any citations. Borders are human artifacts, and not everyone agrees on where they are, thus we ALWAYS need to cite what our boundary source is. Failure to cite is either plagiarism, synthesis, or original research (or all three at once). Even if there is a source somewhere on Wikipedia for the original file, a user should not have to dig for it, and I haven't found one yet. This is one example that highlights this issue particularly well, but it is the state of many, if not most, of our maps. We should not have maps created by amateurs demarcating things like international borders at all, there are plenty of files freely available from reputable sources like the U.S. State Department and United Nations. GeogSage ^{(⚔Chat?⚔)} 18:32, 14 December 2025 (UTC)[reply]

Okay, so you're not arguing against this specific instance of using mapframe maps, rather you're seeing the problem with the big picture. We can address these sorts of problems in a variety of manners. It's rather confusing that it's exactly with Wikidata that there's an inherent possibility to depend on only items that are referenced. Yet Wikidata seems to get a lot of hate from editors despite this. --Joy (talk) 18:59, 14 December 2025 (UTC)[reply]

Yeah, problem is with the big picture. The references need to be transparent, using Wikidata to generate maps without explicitly stating the source Wikidata is using clearly somewhere on the map is a problem. For example, where are we getting the coordinates for things included in Wikidata in the first place? Are users just jumping on OpenStreetMap, selecting the location, and entering the coordinates? Is there a published list of coordinates? Have we standardized where we are capturing the coordinates from (for example, the geographic centroid, the median center, the left corner, etc.). GeogSage ^{(⚔Chat?⚔)} 19:56, 14 December 2025 (UTC)[reply]

Buidhe's complaint about the map was more that it showed a specific point at all, from my reading. A specific point for an event like that will not be accurate. Now, this does not apply to the vast majority of usages of that infobox, and I don't really get why we would be using the terrorism infobox on a topic like genocide. But I also don't think these maps help anything. PARAKANYAA (talk) 16:49, 14 December 2025 (UTC)[reply]

Thank you for recognizing the nuance.

For the terrorist attacks, the majority of usages, if a map doesn't help, does it make sense to have coordinates listed there at all? --Joy (talk) 17:39, 14 December 2025 (UTC)[reply]

Having coordinates attached to an article can be useful for all sorts of tools. For example, meta:WikiShootMe. RoySmith (talk) 17:53, 14 December 2025 (UTC)[reply]

Tools need to be useful to Wikipedia… not the other way around. Blueboar (talk) 18:16, 14 December 2025 (UTC)[reply]

I think the intent was to say that these tools can be useful to readers.

Going back to the original topic of what we get with rendering coordinates with mapframes, when we have that thumbnail in the infobox, a click on it brings up a bigger map screen where the reader can immediately see the button Show nearby articles.

So for example with this sort of an infobox, the civilian attack one, we can have a mapframe at Oklahoma City bombing, and then the reader can click to see the location on that map, and after clicking that button they can see e.g. links to And Jesus Wept, National Memorial Institute for the Prevention of Terrorism, The Heritage and a number of other articles that seem relevant in context, and presumably of interest to readers.

For whatever reason, the default coordinate link to Geohack doesn't seem to enable this functionality for readers. --Joy (talk) 19:15, 14 December 2025 (UTC)[reply]

No, I said it does work for the majority of usages, but there are always going to be edge cases like this. Even if coordinates are helpful, I don't think autogenerating a map always is. PARAKANYAA (talk) 19:33, 14 December 2025 (UTC)[reply]

Okay. Is there any way we could filter for the edge cases, perhaps?

Maybe in case of civilian attacks, the |type= parameter could be used to decide on the defaults, or something like that? Meaning, if we see |type=genocide, we should skip the map rendering by default because of the risk of unfocused coordinates, but if we see |type=mass shooting the risk is lower because the events are typically more localized?

Or, depending on the type, change the default zoom - for genocides, show country-level maps and drop the point marker, but for mass shootings show city-level maps and keep the point marker?

Or, maybe to follow up on your original contention - find every use of |type=genocide and make a list, and then use that to ponder the creation of a separate {{Infobox genocide}} instead? --Joy (talk) 19:45, 14 December 2025 (UTC)[reply]

Personally I agree - if the problem is overstretching the usage of the infobox template into a place it doesn't really belong, maybe we need 2 infoboxes. I think the mapframe can be helpful, but it depends on the article. Andre🚐 21:02, 14 December 2025 (UTC)[reply]

As it happens, I missed the fact that it looks like the Wikidata interaction in particular here is a fresh bug. I've brought it up at Template talk:Infobox mapframe#mapframe-wikidata implicitly on, instead of off? --Joy (talk) 12:13, 15 December 2025 (UTC)[reply]

Hello everyone :)

I'm Carolyn from the Product and Tech Department at the Foundation, sharing this message on behalf of my colleagues across Product, Comms and Brand.

We have been collaborating with various Wikipedia language communities to create an optional short lived campaign feature to celebrate 25 years of Wikipedia. The feature will have surprises and “easter eggs” (visual surprises) for readers of Wikipedia to discover. These fun “easter eggs” will be on the Wikipedia portal page, and any interested Wikipedias – we are writing here to invite you to join the experiment!

The special campaign feature will be live for a month from mid-February 2026. See the detailed timeline here. It will also be available to test on the beta cluster in the first week of January 2026.

It will star a cute birthday mascot, inspired by this drawing that Wikipedian, baduferreira, made for the San Francisco Bay Area User Group’s 2025 Wikipedia Day celebration. Through community configurations, each language Wikipedia community can control where the mascot shows up and if the feature is available on their Wikipedia.

The idea is to create small, fun experiences on Wikipedia to build connections with readers through exploration and celebration. This special on-wiki feature is called “Birthday mode” and when a reader turns it on, the birthday mascot becomes their “reading buddy”.

The feature is opt-in for each language Wikipedia, so far Thai, Vietnamese, French, Italian, Indonesian, Betawi, Madurese and Czech Wikipedia are on board. If you want this cute birthday mascot to show up on your Wikipedia, start a discussion and let us know on the project Meta-Wiki page. If you want to be guaranteed to have the special feature translated for your language Wikipedia by 16 February 2026, we need to know you are interested by 15 December 2025.

• Note that it will still be possible to turn on the feature for other Wikipedias later on (even after 16 February) but we will prioritise translating and deploying the feature to Wikipedias that opt in earlier.
• This feature will remain supported until 16 March 2026, after this we will remove the feature from all Wikis.

If you want this cute birthday mascot to show up on your Wikipedia, start a discussion and let us know on the project Meta-Wiki page as soon as possible! CMadeo (WMF) (talk) 17:13, 11 December 2025 (UTC)[reply]

At first glance I thought that was an Apple logo on the back of the phone, but looking closer I guess it's a puzzle piece to match the puzzle globe? Anomie⚔ 20:51, 11 December 2025 (UTC)[reply]

Seems like it, yeah. Hacked (Talk|Contribs) 20:53, 11 December 2025 (UTC)[reply]

Correct, it's a puzzle piece! Thanks for the feedback that this reads as an Apple logo with a quick glance, we can let the folks working on illustrations / animations know! CMadeo (WMF) (talk) 21:46, 11 December 2025 (UTC)[reply]

Does anyone know if such a discussion page has been created yet? I'm all on board for the idea! Commandant Quacks-a-lot (talk) 03:17, 12 December 2025 (UTC)[reply]

Hello @Commandant Quacks-a-lot :) This local birthday page exists. To our knowledge no local discussion has started about this specifically. CDekock-WMF (talk) 15:20, 13 December 2025 (UTC)[reply]

So the feature shifts the appearance menu down and adds the baby globe gif? Are there any other impacts? Does the gif link to anything in particular? CMD (talk) 04:18, 12 December 2025 (UTC)[reply]

Since it's CC BY-SA, it should link to the file description page to satisfy that license's requirements for attribution and notice of the license. Anomie⚔ 13:00, 12 December 2025 (UTC)[reply]

I also assume that is the default, although there are other ways to satisfy it. However, I asked to check whether this is the intended case. CMD (talk) 14:52, 12 December 2025 (UTC)[reply]

Thank you for your question!

The feature does the following:

• Adds an appearance setting to toggle Birthday mode 'on' and 'off' for each reader
• When the toggle in the appearance setting is set to 'on', only on Article pages and the main page, the appearance menu is shifted down and a gif of Baby Globe appears on configured pages. This gif may be different based on how each participating community configures the feature (eg. they can choose to have a gif of Baby Globe throwing confetti on the 'Party' page in their language)
• If the page where Baby Globe appears is left idle for a defined period of time, Baby Globe 'falls asleep' and dreams, moving the cursor or scrolling 'wakes' Baby Globe up.

Additionally, we are working with members of the Vietnamese community (and other Wikis who are opting to turn the feature on on their Wiki) to create an "Easter Egg" where the phrase 'Welcome to Wikipedia' in a variety of different languages is played upon tapping a gif of Baby Globe playing with a synthesizer (it will be up to each community who turns the feature on to decide which pages this occurs on via Community Configuration). Audio will only play when the user 'taps' on Baby Globe.

Tapping Baby Globe will not redirect readers to a new page. CMadeo (WMF) (talk) 15:34, 12 December 2025 (UTC)[reply]

Alright, so the only change to the normal UI is the birthday mode toggle at the bottom of the appearances menu? I would quibble that the easter egg is this toggle rather than the globe buddy, but that aside these are helpful clarifications. By your party example, is the gif individually configurable for each page then? CMD (talk) 11:32, 13 December 2025 (UTC)[reply]

Fair, @Chipmunkdavis the idea migrated a bit from "easter eggs" and our current use of the phrase relies on a pretty broad definition ;) And yes, apart from the lil globe buddy hanging out in the corner, the only change is the toggle. We didn't want to interfere with people's reading experience, so that's partly why we've kept things fairly limited. We think / hope it's going to be fun to discover which version of Baby Globe shows up on which pages. And yes, these GIFs / different versions are individually configurable per language Wikipedia using Wikidata items. More on the community configurations here. CDekock-WMF (talk) 15:18, 13 December 2025 (UTC)[reply]

What does the "reading buddy" do to assist the reading process? — GhostInTheMachine ^{talk to me} 08:39, 12 December 2025 (UTC)[reply]

Reads with you^[Humor] Killertrant (talk) 14:52, 12 December 2025 (UTC)[reply]

That's maybe not as far-fetched as people might think: School dog#Academic support. WhatamIdoing (talk) 19:04, 13 December 2025 (UTC)[reply]

Thanks for asking! Baby Globe will appear on pages as configured by each Wiki via Community Configuration, the animation of Baby Globe will differ based on the configuration by Wiki. On most pages Baby Globe will appear to be 'reading' alongside the reader, which is why we've playfully referred to them as a reading buddy. Baby Globe will not recommend content or change content on the pages that they appear on. You can read more about the different animations and 'Easter Eggs' on the MetaWiki page. CMadeo (WMF) (talk) 15:18, 12 December 2025 (UTC)[reply]

The above Meta page says On Vector 2022, a “birthday mode” switch will be added under “theme”. Does this mean that the mode will only be implemented on the Vector 2022 skin? or... Will the other skins include it and also have a switch to disable it? — GhostInTheMachine ^{talk to me} 18:03, 12 December 2025 (UTC)[reply]

Thanks for catching this, we will need to update this as it will only be implemented on Vector 2022 and Minerva. It will not be visible or available on any other skin, even if it is enabled on the Wiki level. CMadeo (WMF) (talk) 19:02, 12 December 2025 (UTC)[reply]

Actually, just realized Minerva is shown right below the paragraph on Vector 2022: https://meta.wikimedia.org/wiki/Wikipedia_25/Easter_egg_experiments#Wireframes_of_portal_page_and_mode_toggle. However confirming here that the mode will only be implemented on Vector 2022 and Minerva (no other skins) and not on the mobile apps at this time. This means that if you are using a skin other than V22 + Minerva you will not see Baby Globe. CMadeo (WMF) (talk) 19:04, 12 December 2025 (UTC)[reply]

Good. Thanks — GhostInTheMachine ^{talk to me} 19:39, 12 December 2025 (UTC)[reply]

...What is this? it's lio! | talk | work 15:07, 13 December 2025 (UTC)[reply]

Whatever it is, I don't think it belongs on Wikipedia. Phil Bridger (talk) 16:56, 13 December 2025 (UTC)[reply]

@Osps7: RoySmith (talk) 17:10, 13 December 2025 (UTC)[reply]

It doesn't belong in project namespace. I think it's fine in user namespace though. * Pppery * _{it has begun...} 17:18, 13 December 2025 (UTC)[reply]

I suppose I agree, although I'm still completely baffled at what is going on within the page whoops it's lio! | talk | work 17:25, 13 December 2025 (UTC)[reply]

Now that I've read it several times over, I finally realized that it's describing probably something that happened in real life, as Nablus is a city in Palestine. Dunno how that slipped my mind before. Seems like either a self-promo attempt, a personal reflection, something he considers part of Wikipedia's history, or a combination. Interesting and I'm thankful for coming here before MFD. it's lio! | talk | work 17:31, 13 December 2025 (UTC)[reply]

I think there may have been some translation problems. Wikipedia editors can't delete a stadium. WhatamIdoing (talk) 19:08, 13 December 2025 (UTC)[reply]

Sorry, what? it's lio! | talk | work 19:51, 13 December 2025 (UTC)[reply]

The fifth action listed includes, "unlawfully deleting his stadium". Some Wikipedia editors have the power to delete an article about a stadium, but not a stadium itself. Phil Bridger (talk) 20:13, 13 December 2025 (UTC)[reply]

There are some problems on his User: page as well. For example, he claims to have been "recognized" (by an unnamed party) as the youngest Wikipedia editor at the age of 15, but we have hundreds or maybe even thousands of younger editors. If true at all (no evidence is given), it was probably only true in a narrow context (e.g., youngest in his school, or youngest at an editing party).

If it were at WP:MFD, I'd vote for either deletion or userification. WhatamIdoing (talk) 22:16, 13 December 2025 (UTC)[reply]

If you want to find out what something is, the obvious place to start is by asking the person who created it. AndyTheGrump (talk) 20:19, 13 December 2025 (UTC)[reply]

Should probably be moved to User:Osps7/Case No. 3757/2021 - it was created and edited by that editor, in 2022. But I can't see a section within WP:RM for "Moving an inappropriate article out of Wikipedia space". It doesn't belong in Wikipedia space, but the editor could perhaps have written it up as an article for the Signpost. PamD 19:28, 14 December 2025 (UTC)[reply]

If we want to preserve it then that is probably that right move, but I can't, for the life of me, think why. Phil Bridger (talk) 20:32, 14 December 2025 (UTC)[reply]

Can’t we just Userfy it? Blueboar (talk) 12:58, 15 December 2025 (UTC)[reply]

We could, but I don't think there's any justificiation for this to exist even in user space. I pinged the creator a couple of days ago, with no response. I'll repeat that here: @Osps7:. My take on this is the page isn't doing any active harm so I suggest people give him a couple more days (they've been active on other projects, so I assume they'll see the pings cross-wiki). If still no response, I'd bring this to WP:MfD. RoySmith (talk) 13:54, 15 December 2025 (UTC)[reply]

I suggest posting to their talk page. Not everyone has notifications enabled. isaacl (talk) 23:10, 15 December 2025 (UTC)[reply]

Good idea, done. RoySmith (talk) 23:18, 15 December 2025 (UTC)[reply]

Even better would be for someone to post to their talk page on Arabic Wikipedia, which seems to be where they usually hang out, if you can sort out the right-to-left stuff. Phil Bridger (talk) 23:27, 15 December 2025 (UTC)[reply]

Done using Google Translate it's lio! | talk | work 13:15, 16 December 2025 (UTC)[reply]

Hello everyone, and thank you to @RoySmith for notifying me about this.

In fact, when I created the page Wikipedia:Case No. 3757/2021, it was some time ago. It was not intended to be about me personally, but rather to document a real legal incident that I experienced related to Wikimedia projects. At that time, my English language skills were not yet at a good level.

I understand that the previous text contained a weak translation and some unclear statements, and I also understand that it should have been placed under my personal user namespace.

Thank you for your effective actions, which I truly appreciate and respect.

I will rewrite the topic within my personal namespace in a clearer and better manner. — Osama Eid ^(talk) 06:52, 17 December 2025 (UTC)[reply]

@Phil Bridger, RoySmith, Pppery, WhatamIdoing, AndyTheGrump, PamD, and Blueboar: Seeing as the intent is to provide a historical record of (apparently) a Wikimedia-related legal incident, would this sort of thing have any place on metawiki? it's lio! | talk | work 07:57, 17 December 2025 (UTC)[reply]

That's a question for MetaWiki, not en.Wikipedia. I'd assume though that if it was hosted there, they'd want to see some proper sourcing. AndyTheGrump (talk) 10:36, 17 December 2025 (UTC)[reply]

As there is no source on the page, can we confirm that this is a genuine account of a legal case? BD2412 T 13:05, 17 December 2025 (UTC)[reply]

@BD2412,

There are no sources such as links or news websites; however, there is a case file. I am currently working on preparing it within a personal scope, and I will share it with you as soon as it is completed, along with the supporting documents. — Osama Eid ^(talk) 13:15, 17 December 2025 (UTC)[reply]

If the only sources you have are case files and the like, it almost certainly doesn't belong anywhere on Wikipedia. AndyTheGrump (talk) 13:20, 17 December 2025 (UTC)[reply]

I've opened Wikipedia:Miscellany for deletion/Wikipedia:Case No. 3757/2021 RoySmith (talk) 14:28, 17 December 2025 (UTC)[reply]

Many countries require websites to show clear contact information for legal and safety reasons. For example, in the European Union, contact information is required by Article 5 of the eCommerce Directive. Wikimedia projects have handled this variably (see wikidata:Q4980478 and wikidata:Q4654783) resulting in inconsistencies and outdated or missing details. We have missed court notices due to this.

To fix this, the Wikimedia Foundation has created a single “Legal and Safety Contacts” page, and will add a link to it at the end of each wiki page. This will ensure that everyone has access to accurate and up to date Legal contact information. If wikis have existing “Contact” pages and links, the community should update these to prevent confusion. We will insert the new links to different wikis in stages, based on our assessment of legal risk and necessity; the first six footers to change will be on German, Spanish, French, English, Italian and Polish Wikipedia by 19 December 2025.

For further background, see this Frequently Asked Questions page

–– Phil Bradley-Schmieg Lead Counsel Wikimedia Foundation –– STei (WMF) (talk) 11:58, 16 December 2025 (UTC)[reply]