Jump to content

Wikimedia Forum

Add topic
From Meta, a Wikimedia project coordination wiki
Latest comment: 16 hours ago by BAdegboye (EdWH) in topic Upcoming EduWiki Knowledge Showcase, March 2026
Shortcut:
WM:FORUM

The Wikimedia Forum is a central place for questions, announcements and other discussions about the Wikimedia Foundation and its projects. (For discussion about the Meta wiki, see Meta:Babel.)
This is not the place to make technical queries regarding the MediaWiki software; please ask such questions at the MediaWiki support desk; technical questions about Wikimedia wikis, however, can be placed on Tech page.

You can reply to a topic by clicking the "[edit]" link beside that section, or you can start a new discussion.
Wikimedia Meta-Wiki
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} and sections whose most recent comment is older than 30 days.

Proposed mass import of court documents to Chinese Wikisource

[edit]

A longer explaination is available here. In a nutshell: A user proposed to run a bot to mass import Chinese court documents to Chinese Wikisource. This will potentially results in 85 million new content pages be created in Chinese Wikisource. He is asking other Wikimedia community users and WMF opinions on that. This will also have an potential impact on Wikidata, since there is another user running a bot (MidleadingBot) to create an item for each pages, which will result in 85 million new items in Wikidata. GZWDer (talk) 12:58, 6 December 2025 (UTC)Reply

Interesting. I'm curious if personal identifiable information (PII) is planned to be scrubbed before upload? So9q (talk) 04:26, 12 December 2025 (UTC)Reply
The data is from China Judgments Online, which is by China’s court publicity standards, already compliant with China’s privacy laws. That being said, if a court rules that some public documents once published, are no longer suitable and needs further redaction or takedown, we could ask them to file a DMCA complaint, just like what other mirrors of China Judgments Online do (on the internet there are already some mirrors, but most have paywalls; and just as I said in the original proposal, they also takedown documents due to political censorship, which we won’t follow along). SuperGrey (talk) 16:49, 16 December 2025 (UTC)Reply
You didn't answer my question. Will the document you intent to upload in Wikisource contain names, addresses and other PII? So9q (talk) 16:07, 17 December 2025 (UTC)Reply
  1. These public documents don't have a very specific standard on their redaction levels, but from what I observe: names are occasionally redacted; personal addresses are always removed; government IDs are always removed or redacted; phone numbers are always redacted; other PIIs are most likely redacted. The situation above generally follows the Provisions mentioned below.
  2. I don't plan to manually remove or redact PIIs by myself if they are already present on these public documents, except for the following situation: According to the The Supreme People's Court Provisions on People's Courts Release of Judgments on the Internet,

Article 8: When releasing judgment documents on the internet, people's courts shall redact the names of the following personnel:
(1) parties and their legally-designated representatives in marriage and family cases, or inheritance disputes;
(2) Victims and their legally-designated representatives, incidental civil action plaintiffs and their legally-designated representatives, witnesses, and expert evaluators in criminal cases;
(3) Minors and their legally-designated representatives;
Article 9: The redaction of names in accordance with Article 8 of these Provisions shall be handled according to the following circumstances:
(1) Retain the surname and replace the given name with "X" [某];
(2) For the names of ethnic minorities, retain the first character and replace the rest with "X" [某];
(3) For the Chinese translations of the names of foreigners and stateless persons, retain the first character and replace the rest with "X" [某]; for the English names of foreigners and stateless persons, retain the first English letter and delete the rest;
Where different names become identical after redaction, differentiate between them by adding Arabic numerals.
Article 10: When releasing judgment documents on the internet, people's courts shall delete the following information:
(1) Natural persons' home addresses, contact information, ID numbers, bank account numbers, health conditions, vehicle license plate numbers, movable or immovable property ownership certificate numbers, and other personal information;
(2) Legal persons' and other organizations' bank account numbers, vehicle license plate numbers, movable or immovable property ownership certificate numbers and other information;
(3) Information involving commercial secrets;
(4) Information involving personal privacy in family disputes, personality rights and interests disputes and other such disputes;
(5) Information involving technical investigation measures;
(6) Other information that people's courts find inappropriate to release.
Where deleting information in accordance with the first paragraph of this Article interferes with correctly understanding the judgment document, use the symbol "×" as a partial substitute.
Article 11: When releasing judgment documents on the internet, people's courts shall retain the following information of parties, legally-designated representative, entrusted representatives, and defenders:
(1) Except where names are redacted in accordance with Article 8 of these Provisions, where the parties and their legally-designated representatives are natural persons, retain their names, dates of birth, sexes, and the districts or counties to which their domiciles belong; where the parties and their legally-designated representatives are legal persons or other organizations, retain their names, domiciles, organization codes, and the names and positions of their legally-designated representatives or principal responsible persons.
(2) Where the entrusted representatives or defenders are lawyers or basic level legal service workers, retain their names, license numbers, and the names of their law firms or basic level legal service organizations; where the entrusted representatives or defenders are other personnel, retain their names, dates of birth, sexes, the districts or counties to which their domiciles belong, and their relationship with the parties.

The above articles all begin with "people's courts shall", so naturally respecting what they have released is good enough. Still, we should open to their complaints in case they want to mend their mistakes if they found some documents unsuitable to release or need further redaction, as is required by the law.
SuperGrey (talk) 07:06, 18 December 2025 (UTC)Reply
85 million is not a normal scale. This is not what the website is for and likely would completely bring down wikimedia media files. —TheDJ (talkcontribs) 12:15, 15 December 2025 (UTC)Reply
oh wait, I figured these were pdfs, but it seems they are only the OCR'ed content ? That is slightly better I guess. Still 85 million is a lot. It likely requires significant scaling up of the wiki, and moving it to a separate database cluster. And I'm not sure if Wikidata can scale that far as well at this moment. regardless, I think it is up to Wikidata project to determine if they even want that many entries. Even for journals and a few other categories people are already discussing about potentially splitting it off from Wikidata, and the added value of all those entries to them would be near 0. —TheDJ (talkcontribs) 12:28, 15 December 2025 (UTC)Reply
+1, I started a discussion in the main Wikidata telegram channel with this as input. My view: Basically Wikidata has serious problems with scaling and the community and team have not been able to communicate well/effectively for years about it and come up with good solutions. (but this might be changing now which would be great!)
Interesting enough there are few Wikibases in or outside of Wikibase.cloud that have >1000 items what I have heard about.
It might be worth studying why Wikibase is so "slow" to take off despite being freely available and taking only minutes to set up.
Maybe new developments like federated values are needed? So9q (talk) 21:03, 15 December 2025 (UTC)Reply
User:Lydia Pintscher (WMDE) has said multiple times over the past few years that Wikidata can't handle imports on that scale, neither technically nor socially. The query service already had to be split in two because of the extremely large (and, for some reason, still ongoing) import of scientific articles. User:ASarabadani (WMF) has said that the size of the database is problematic as well and can't keep growing at the rate it currently is (d:User:ASarabadani (WMF)/Growth of databases of Wikidata).
I already responded in the Wikidata Telegram group (on the 8th of December) to the user proposing the import saying that Wikidata can't really handle that many new items and Lydia agreed with what I wrote. - Nikki (talk) 05:19, 16 December 2025 (UTC)Reply
I am in that email thread and I support this project and anyone else who has 100,000,000 things to share.
Step 1 is uploading about 10 examples and doing the data modeling. People who do this typically take 6 months for that process. @SuperGrey: is an experienced Wikimedia editor who is obviously here for the long term.
I think it is an error to dismiss a project because of its size without checking what value it can have to build out other Wikimedia content. While I do greatly doubt that the Wikimedia platform can find a use for 100 million legal documents, there are lots of examples of institutions which use Wikibase instances which exchange data with Wikidata. It could happen that we only want ~500,000 of these documents, but a Wikibase holds 100 million, and the data modeling improves Wikidata processes and our Linked Open Data infrastructure by improving modeling of courts, cities, laws, and subject matter of cases.
If anyone says they want to do a big project, then I always support them doing a pilot with 10 examples. Bluerasberry (talk) 16:02, 16 December 2025 (UTC)Reply
+1 So9q (talk) 16:21, 16 December 2025 (UTC)Reply
Thanks for the compliment and ping. I’ll upload 10 sample documents and write a proposal page here on Meta-Wiki. SuperGrey (talk) 16:38, 16 December 2025 (UTC)Reply
what about setting up a separate wikibase in wikibase.cloud and model there?
you can link to commons for example. So9q (talk) 15:58, 17 December 2025 (UTC)Reply
I just want to add that d:User:ASarabadani (WMF) was worried about the size of the db tables because we ran Wikidatas Mariadb cluster at the time of the writing of the report on small commodity servers with limited RAM. We try to store everything in RAM to keep the query servers fast. We had one master and about 10 slave read-only clones back then.
Since then 2 things have happened:
  • Silently WMF/WMDE beefed the servers to match those of the dbserver of OSM. I don't know who made that decision or when, I can just see in Grafana that there is no ongoing issue right now.
  • Elsewhere I have multiple times proposed a revision of the "keep every edit ever made to Wikdiata in one big history table in MariaDB"-strategy that WMDE has been running for years. I have seen no such revision yet. My proposal is to create a new archive MariaDB cluster with cheaper servers for all history over 2 years old. I think this would greatly reduce the memory requirement on the master mariadb cluster. Unfortunately, I have not heard back from anyone at WMDE about this.
So9q (talk) 16:27, 16 December 2025 (UTC)Reply
I encourage WMDE to develop Wikibase further to handle the data the community wants to store in an efficient and scalable way. That's hard to do. But we could start lifting out all the scientific data that the rest of Wikimedia does not need to have in Wikidata because they don't need it for interwikilinks.
I think we need to move from:
  • Just upload to WD because it might be useful to someone
  • Let's just keep and improve the large scholarly graph with overall low quality data that no other Wikimedia wiki needs to link to
->
  • Set up a community wikibase for any new dataset >1000 items that you would perhaps later like to be included in Wikidata
  • Make sure the modeling is solid and approach the Wikibase community if you think other Wikimedia wikis have a need to link to parts of it.
  • If the community judge that part of the collection of items fit in Wikidata, then hooray let's import it after approval. You might end up in a split situation where only some items are welcome in Wikidata.
So9q (talk) 16:33, 16 December 2025 (UTC)Reply
Just here to confirm everything @Nikki said. Lydia Pintscher (WMDE) (talk) 11:04, 17 December 2025 (UTC)Reply
SuperGrey, DMCA is for copyright issues, not for personal rights issues. Also the issue is not PII (a USA concept) but personal data (an EU concept). How well-indexed are these documents? If you search a string they contain, how likely it is to turn up on Google/Bing/Baidu?
There's a risk that we surface personal data which is currently relatively obscure. People mentioned in court rulings in China may be EU residents now, which would entitle them to GDPR rights.
The idea is generally interesting and it's definitely appropriate for Wikisource to host court rulings, though it's perhaps not the best project to provide a comprehensive database of court rulings. I recommend to implement it gradually, so that you can find issues along the way. All projects which tried something like this before have run into issues of insufficient redaction in the official databases (see JurisWiki.it in Italy, Carl Malamud in the USA), so you must assume that the same will happen here and that you will need to be in contact with the source database to help them fix mistakes. Have you already established some contacts with them? Nemo 16:18, 18 December 2025 (UTC)Reply
Most of them are not indexed by any search engines or available in websites searchable by search engines. GZWDer (talk) 14:01, 19 December 2025 (UTC)Reply

Formal proposal

[edit]

Hi everyone! Sorry for the late reply. I had family matters to take care of during Christmas.

Based on concerns raised on Meta-Wiki and in the email thread (scale, privacy/personal data, and Wikidata spillover), I drafted a formal WMF-facing proposal here: China Judgments Online Preservation Program. The program is staged and requires WMF review before expanding each stage; it also keeps Wikidata item creation out of scope and includes a dedicated privacy request workflow.

Comments and suggestions are welcome, here and/or at the proposal's talk page.

Cheers, SuperGrey (talk) 16:37, 12 January 2026 (UTC)Reply

Update: I have received formal community approval from Chinese Wikisource on January 28, 2026. SuperGrey (talk) 08:51, 8 February 2026 (UTC)Reply
Interesting, thanks for the update. So9q (talk) 06:32, 1 March 2026 (UTC)Reply
Does anyone know who/which WMF tech team is in charge of the technical limitations of Wikisource? SuperGrey (talk) 23:05, 15 February 2026 (UTC)Reply
Unfortunately I don't. But what I do know is that there is now sn alternative backend available for Wikidata that scale well beyond the current one. My hope is that we will be able to convince WMF to fix all backend issues in Wikidata within the next 2 years.
Unfortunately that probably means that your import will have to be slowed down to accommodate the limitations of the current backend until we have switched away from Wikibase Suite. So9q (talk) 06:37, 1 March 2026 (UTC)Reply
So where can I request the zhwikisource to be switched to this new Wikibase Suite backend (or be considered in the pioneering batches)? SuperGrey (talk) 06:40, 1 March 2026 (UTC)Reply
No. We already know Wikidata has a well-known problem with its size. But this is about Wikisource, not Wikidata. Midleading (talk) 05:15, 2 March 2026 (UTC)Reply
Update: Created a Phabricator task T418710. SuperGrey (talk) 08:18, 2 March 2026 (UTC)Reply
It seems you got green light from WMF operations. Congratulations! I'll continue to work on a better backend for Wikidata that scales to 1bn entities. So9q (talk) 18:37, 4 March 2026 (UTC)Reply
Thanks! I hope the better backend can come sooner in the future. SuperGrey (talk) 21:57, 4 March 2026 (UTC)Reply

Restricting AI-generated images of people

[edit]

Commons community is considering to revise its acceptance policy to reject some (most?) AI-generated images of living people and dead people. This could mean that images might be deleted when they are AI-generated, even if they are being shown on sister projects, instead of just sitting on Commons. I notify here because this can affect sister projects outside of Commons. Discussions have been ongoing at least since December 2025.

Links:

whym (talk) 10:39, 7 January 2026 (UTC)Reply

An issue of this is that by censoring images of that type, the long-standing pillar policy c:COM:INUSE would start to get exceptions – people can be less and less sure that files uploaded to Commons used in Wikipedia articles or other project sites will remain on Commons instead of getting deleted by arbitrary decisions by the Commons community. This undermines the stability of the project and trust in Commons.
This policy proposal seeks to ban also neutral depictions of real people which are not banned as paintings and also those for long-dead people like ancient pharaohs etc. It's also entirely unnecessary since there already is a policy against files that violate the dignity of real people, c:COM:DIGNITY and people can easily nominate individual problematic files (or many of them at once) for deletion. The question is whether to sacrifice the consistency of two important Commons policies, c:COM:INUSE and c:COM:NOTCENSORED, without any reason in the proposed policy that tries to justify the policy and without any need. This affects all Wikimedia projects. Prototyperspective (talk) 14:39, 13 January 2026 (UTC)Reply
  • I feel all AI content should banned from Wikipedia and related projects without exception. Jusdafax 19:58, 7 February 2026 (UTC)Reply
    This is up to local communities to decide on this matter. A09|(pogovor) 19:59, 7 February 2026 (UTC)Reply
    • It simply is not feasible. Even the term "AI content" creates havoc, as it is not clear. The most used grammar checkers are AI-enhanced, so anything corrected by them is "AI content" – did you mean to include that? If a user asks an AI how to edit a page, and then follows the AI's instructions, is that AI content? If a user asks an AI how to improve a page and then does it, is that AI content? And once you've defined what you meant, there's the issue of identifying AI content. More and more people are spending greater and greater amounts of time interacting with AIs. So much so, that they are picking up new AI-like communication habits, such as manner of speech and writing styles, making false positives more likely when analyzing their submissions. AI is developing rapidly, with their output becoming more human-like, so that it gets harder over time to detect AI submissions. At the same time, AI users are becoming more adept at using AI tools, and expect to be able to use them on whatever they are working on. As with using any tool, practice improves results. If you turn those people away, they'll go make their valuable skills available somewhere else. Last but not least, is AI itself: its ability to produce instant quality articles upon request is improving, while its ability to make instant websites of quality is rapidly progressing as well. This threatens Wikipedia's traffic, and in turn may reduce readers and new editor recruiting to a trickle. For Wikipedia to survive the AI intelligence explosion that is happening right now, it will need to embrace AI and leverage it, much more than it is doing now. The Transhumanist (talk) 02:56, 8 February 2026 (UTC)Reply
    I could see accepting AI-generated pictures as problematic, but non-abusive uses of AI would probably fall under art or satire. The worst applications of AI wouldn't be accepted by Commons anyway. TheObsidianGriffon (talk) 07:22, 21 February 2026 (UTC)Reply

Testing simpler New Account creation

[edit]

New account creation on Android is significantly better than on other platforms. It is just "username, password, repeat password, email" with a captcha after you enter that. On mobile and desktop web, there are 10-20 unnecessary extra lines of text, images, and headers. One has to scroll down the page to find a button to submit. And there are a number of common ways that your account creation request could be rejected (password too short, password too simple) which don't show up as an inline password-strength visual but instead intrude into pageflow as a red error message after you leave a textarea to go to the next.

At an experiment lab we're discussing testing alternate flows for desktop and mobile, testing on Meta. Please share your thoughts and comments here: User:Sj/Design chats/Create account

— The preceding unsigned comment was added by Sj (talk) 11:55, 1 February 2026 (UTC)Reply

Thanks for starting this topic! The WMF Growth team is currently working on a closely related effort focused on improving the account creation experience: Account_Creation_Experiments.
We are planning a series of small, iterative tests. The first experiment, tracked in Phabricator task T415659, focuses on simplifying the interface without fundamentally redesigning the form. In parallel, we are exploring additional improvements, including clearer inline validation and reducing disruptive or poorly timed error messages.
I would appreciate feedback on the proposed approaches, either here or on MediaWiki. Beyond reducing disruptive error states and simplifying the form, which additional improvements do you think would have the greatest impact on the account creation experience?
@Sj, I will follow up directly as well. We are very open to collaborating and exploring ideas from this discussion, provided they are technically feasible and aligned with broader product goals. Best - KStoller-WMF (talk) 03:01, 21 February 2026 (UTC)Reply

Upcoming Wikimedia Café session regarding the Wikimedia Commons mobile app

[edit]

Etherpad is going to be deleted without backup?

[edit]

per Talk:Etherpad, a WMF ops team is planning to delete the etherpad instance at etherpad.wikimedia.org without making a backup, on April 30 2026. Any pads that people want to save need to be migrated to meta or somewhere else. This doesn't seem like a good resolution, though clearly the pads have become bloated with spam. A script that captures the latest revision of all non-spam pages (and filters out obvious spam) would likely reduce the total size of the data by 100x.

To discuss, see also task T415237. –SJ talk  01:00, 24 February 2026 (UTC)Reply

How to see pages without categories

[edit]

I've noticed many pages about research projects and other meta pages do not have categories or only a few generic default ones set. This makes it even harder to find these pages which often have interesting / useful findings and statistical images etc.

Is there a way to see relevant pages that are missing categories?
And since it's probably many, is there a way to return the pages sorted by number of pageviews?

For some types of pages, it would be better to show pages without topical categories / just with default categories – e.g. pages in Category:Completed research projects that only have categories like Category:2019 projects, Category:Completed research projects, Category:Wikimedia Research project (similar to this report on Commons for category pages).
By the way, I have the view that there has been more than enough research by now and it evidently is not read or used much so focus should be on technical development of Community Wishlist items and other issues but to make the resources spent on the research more worth it, it should at least be easier to find these pages/results.

Maybe this is possible using the Quarry query tool or some sophisticated use of a tool like the Massviews Analysis.

If sorting the pages by pageviews can't be done or if it works only if one enters a manually-compiled list of pages, then maybe one could use the search engine for it. So for example -insource:[[Category: shows pages with no category at all. Problems with it include that it does not exclude pages with cats set via templates, that it shows the translated pages, that it can't show pages with just nontopical default categories, etc. The Massviews Analysis would need some maintenance category to be added to pages without categories to be able to show their pageviews.

The same problem also exists on Wikidata where lots of even large meta pages miss their main category or categories at all. Further ideas on this would be welcome. Prototyperspective (talk) 18:08, 26 February 2026 (UTC)Reply

Special:UncategorizedPagesxaosflux Talk 19:04, 26 February 2026 (UTC)Reply
Thanks. These are not sorted by pageviews though and additionally one can't use this also for seeing those with just nontopical default categories. It's not more useful than the linked search and possibly less so (only advantage is that it does exclude pages where the cats have been set via template). Prototyperspective (talk) 19:19, 26 February 2026 (UTC)Reply
The general theory is for maintenance, that all pages should be categorized, so you can use that list to have a place to start working. — xaosflux Talk 00:23, 27 February 2026 (UTC)Reply
Well, it's not what I was asking about and I have more than enough things to do but thanks. And as said having a category does not mean it has a topical category. Prototyperspective (talk) 00:31, 27 February 2026 (UTC)Reply
Another idea about this is seeing pages sorted by number of categories in Category:Completed research projects (and Category:Active research projects maybe too) so at least first of all these are properly categorized and thereby more readily findable and displayed at the place where relevant and where some people may look for the things on the subject. There's already this query for seeing files sorted by number of nonhidden categories and it can probably be modified to do this. Then maybe similar approaches could be done for other subsets instead of looking at uncategorized and undercategorized pages overall. Prototyperspective (talk) 11:28, 1 March 2026 (UTC)Reply

Federated/decentralized Wikimedia Foundation

[edit]

Hello!

I'd like to ask if there has been any discussion previously about federating/decentralizing the administration of Wikimedia projects? Currently all Wikimedia services are hosted and maintained by the Wikimedia Foundation, even though the content itself is produced by the wikipedians etc. In an ideal world (IMO), instead of centralized ownership,the Wikimedia Foundation would be split into different foundations based on countries or geographical areas, e.g. (In the case of Europe) Spanish Wikimedia foundation or the Northern Europe Wikimedia foundation. These foundations would still be a part of an international umbrella organization, the Wikimedia foundation. This would make sense, as operating the country/area-specific services would be done in the areas they represent and also hosted in those geographical locations (Well, ideally. But at least the decision would be made by the residents themselves. I know that at least Wikipedia is already clustered to geographical areas but are still owned by the Wikimedia Foundation, based in the USA).

The state of the world being what it is today, I see this being more relevant than perhaps ever.

What do you think?

With respect,


Lejar (talk) 08:47, 3 March 2026 (UTC)Reply

Event:Celebrate Women/pl

[edit]

I made a nice graphic File:Jestem nowy w Wikipedii i chcę wziąć udział.png for the Polish language version, but I don’t know how to add it. Can someone help? Zwiadowca21 19:02, 3 March 2026 (UTC)Reply

@Zwiadowca21 To confirm, is your graphic a translated version of File:I'm New to wikipedia and I Want to take part! - Diagram.png? If so, as the wikitext for that image on Event:Celebrate Women seems to use {{lm}}, I believe that renaming/moving your file to File:I'm New to wikipedia and I Want to take part! - Diagram pl.png might mean that it gets used instead of that file on Event:Celebrate Women/pl :) Best, ‍—‍a smart kitten[meow] 19:45, 3 March 2026 (UTC)Reply
Thank you for the clarification. Unfortunately, I still do not know how to do this technically — I do not have experience with renaming or moving files in a way that would make them automatically replace the image on the event page. Could you please indicate the exact steps I should follow? Zwiadowca21 21:08, 3 March 2026 (UTC)Reply
@Zwiadowca21 I requested that the file is renamed on Commons. Hopefully, if/when that happens, it should automatically display at Event:Celebrate Women/pl :) Best, ‍—‍a smart kitten[meow] 21:20, 3 March 2026 (UTC)Reply

Wikipedia is the only open site in iran

[edit]

god i wish it was grokipedia Jimbo_Wales Baratiiman (talk) 14:59, 4 March 2026 (UTC)Reply

Baby Globe + Permanent, Decentralized Archive for Wikipedia?🤔🤔

[edit]

HIII!

guys, i was messing around on wikipedia and i see the baby globe mascot and i fall in love, it is so cool! And so i thinking: why not use this insane cute puppet to launch a permanent, decentralized archive for all wikipedia content??

Heres the ""vision"":

- Forever Storage: every article, image, and edit (including baby globe) could be stored on a trustless, decentralized network (think for example project like Arweave Filecoin, or IPFS), ensuring wikipedia remains accessible no matter what, even in 50+ years. - Contributor rewards: Active editors and contributors could earn symbolic, nonspeculative badges or NFT (just for fun and recognition, no trading or financial things) tied to their work. - Community Governance: the most engaged contributors could help and shape the future of the archive, making it a true community driven project.

can be relevant for some reasons: - Preservation: wikipedia’s knowledge should last forever, not depend on centralized servers (actually, some parts of wikipedia database is already on filecoin and ipfs, so like decentralized storage can help keep stuff safe for long time.) - Recognition: volunteers deserve credit for their work, without the risks of speculative tokens. - Innovation: baby globe's viral appeal could help promote a sustainable, ethical approach to decentralized archives no scams or shady things, just real utility!!.

To clarify: This isnt about creating a "coin" or financial speculation. It’s about building a permanent, community owned archive that aligns with wikipedia’s mission open, transparent, and future proof.

what u guys thin? could this be a way to celebrate wikpiedia's legacy while securing its future?


P.S.

WHAT i wrote is just a simple idea,obviously it need to be adjusted in some part, but the structure i think its not that bad. Trying To Contol Everything (talk) 15:35, 4 March 2026 (UTC)Reply

It would be great if people could improve Wikipedia on IPFS. For example, it currently does not have a search function and barely anybody knows about it. See Wikipedia on IPFS (Q138220088). Prototyperspective (talk) 17:40, 5 March 2026 (UTC)Reply

Other non-English Wikipedia articles about Cold War II

[edit]

What to do about other Wikipedia articles about the Second Cold War listed on Wikidata (d:Q17510383)? They are very contrary to the English one (en:Second Cold War), which very much differs a lot from the others that treat the Second Cold War as if it were an event, a series, a period, or whatever makes it apparently an actuality. George Ho (talk) 23:58, 4 March 2026 (UTC)Reply

Something to discuss and fix at Wikidata I think. Prototyperspective (talk) 17:38, 5 March 2026 (UTC)Reply

@The نورا السواباي (talk) 05:19, 5 March 2026 (UTC)Reply

What just happened?

[edit]

Xaosflux and WMF-Office were both compromised? Is reverting the edits helpful or will they be mass-reverted later? lp0 on fire () 17:28, 5 March 2026 (UTC)Reply

See this: [1] SuperGrey (talk) 17:40, 5 March 2026 (UTC)Reply
And this: Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident. —— Eric LiuTalk 01:37, 6 March 2026 (UTC)Reply

Upcoming EduWiki Knowledge Showcase, March 2026

[edit]