Wikimedia Forum

← Discussion pages

Wikimedia Forums

Archives →

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

• About Meta
• Discussion pages
• Request pages
• Policies and guidelines
• Information and statistics
• Categories
• Help pages
• Meta-Wiki discussion page

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} and sections whose most recent comment is older than 30 days.

Is Wikimedia blocking all external HTTP requests?

Tracked in Phabricator:
Task T413570

I'm running an external (non-WMF) MediaWiki site, and I'm trying to use MediaWiki's "upload by URL" feature to import local copies of files from Wikimedia Commons (using the upload.wikimedia.org address, as the wiki seems to think that the commons.wikimedia addresses aren't actually images). I'm aware of InstantCommons and I do use that feature as well, but for many purposes I prefer to host all files locally so that I'm not dependent on Commons potentially deleting or altering them and so that everything is managed in one place. Anyway, recently I have been unable to upload anything via direct URL from Commons, because I keep getting a 429 Rate Limit error telling me to contact the Wikimedia bot traffic address, even though I am certainly not a bot nor running a bot. I've never had this issue until recently, and it keeps happening even on the first attempt after clearing browsing data/resetting the server IP address/etc. Is Wikimedia blanket-blocking all HTTP requests from external sites by default now for some reason? If so, what should I do to bypass this?

Asking this here instead of MW.org because it's not really a software issue I don't think... seems this is specific to something Wikimedia/the WMF are enforcing. Taking Out The Trash (talk) 17:21, 18 June 2026 (UTC)

It looks like this situation is being looked at in phab:T413570. Feel free to subscribe or discuss there. If this situation is different, let us know and we can try to point you to the correct location. — xaosflux ^Talk 17:41, 18 June 2026 (UTC)

That seems like it could be the same issue, but that ticket appears to be from last year, whereas I just started noticing this issue a week or two ago (and I've had the site up and running since January with a previous iteration before that). Just to clarify, the exact nature of the issue is as follows:

• Go to Special:Upload
• Switch the radio button in the first section to Source URL
• Paste in any URL that begins with upload.wikimedia.org
• Configure the file name, description, and license as appropriate/applicable
• Check the "Ignore any warnings" box and submit the form
• Despite having the box to ignore warnings checked, the upload fails with "Upload Warning: An Error Occurred During the HTTP Request (429 Too Many Requests). Please contact bot-traffic@wikimedia.org". This happens even on the very first attempt after clearing browsing data and resetting the server IP address

Doesn't make sense because I am certainly not a bot, nor am I running a bot when performing this specific form of upload (I do use a file transfer bot to move files from my computer to the wiki en masse but that's utilizing a completely different process). Taking Out The Trash (talk) 15:20, 19 June 2026 (UTC)

OK, sometimes issue reoccur. Have you contacted the NOC team at that email address? What did they say? — xaosflux ^Talk 17:20, 19 June 2026 (UTC)

I have not yet, because I assumed it was some sort of technical glitch. Importing content from WMF sites shouldn't make external wikis subject to the WMF's rate limits or other measures. Taking Out The Trash (talk) 21:14, 19 June 2026 (UTC)

They can troubleshoot your connection in ways that we can not, start there. It could be as simple as something wrong with your user agent string. If you find out, and it requires back end fixing, phabricator is the way to go. — xaosflux ^Talk 22:07, 19 June 2026 (UTC)

RFC about AI-generated content in Wikimedia Commons

You are invited to participate in a request for comment on Wikimedia Commons about a policy update for AI content. This may affect files that are uploaded to Wikimedia Commons for use on this project. Thank you. Codename Noreste (talk) 17:11, 23 June 2026 (UTC)

Interslavic classification

Hi, now that Interslavic has been approved, should we add it into "Slavic" section or "Constructed" section in this page: List of Wikipedias by language group? Normally, we should add it into Constructed section since it is a constructed language. However, Interslavic is an a posteriori language with solely Slavic grammar and vocabulary. Thus I'd prefer to add to Slavic section. Any comments? Joseph (talk) 16:08, 24 June 2026 (UTC)

@Joseph, interesting topic. Quick question: are there precedents for other "zonal constructed languages" (like Interlingua) being classified within their natural language family rather than under constructed languages? Would be useful to know how similar cases were handled.

Thanks.

Mutasim Elmahadi (talk) 08:35, 25 June 2026 (UTC)

Interlingua is listed under "Constructed". I don't know whether it was discussed back then. Joseph (talk) 19:38, 25 June 2026 (UTC)

Comparing sourcing policies across Wikimedia projects

Hello everyone,

Following a discussion about secondary and tertiary sources, I became interested in learning how different Wikimedia projects handle sourcing policies.

I would like to ask:

1. How do different language Wikipedias define and apply policies regarding secondary vs. tertiary sources? 2. Are there best practices or models that have proven effective in reducing inconsistencies in policy enforcement? 3. How do smaller or medium-sized Wikipedias adapt sourcing policies to their community needs?

I would appreciate hearing from editors from various projects about their experiences and insights.

Thank you.

Mutasim Elmahadi (talk) 05:08, 27 June 2026 (UTC)

مقارنة سياسات المصادر عبر مشاريع ويكيميديا

تحية للجميع،

بعد نقاش حول المصادر الثانوية والثالثية، أصبحت مهتماً بمعرفة كيفية تعامل مشاريع ويكيميديا المختلفة مع سياسات المصادر.

أود أن أطرح الأسئلة التالية:

١. كيف تعرّف وتطبّق ويكيبيديات اللغات المختلفة سياساتها المتعلقة بالمصادر الثانوية مقابل مصادر الدرجة الثالثة؟ ٢. هل هناك ممارسات أو نماذج أثبتت فعاليتها في تقليل التناقضات في تطبيق السياسات؟ ٣. كيف تكيّف ويكيبيديات اللغات الصغيرة والمتوسطة سياسات المصادر لتتناسب مع احتياجات مجتمعاتها؟

سأكون سعيداً بسماع تجاربكم وأفكاركم من مشاريعكم المختلفة.

شكراً لكم. Mutasim Elmahadi (talk) 05:08, 27 June 2026 (UTC)

Feedback wanted: open-source timeline tool for Wikipedia/Wikimedia topics

Hello everyone,

I have built a small open-source web tool for creating interactive timelines around Wikipedia/Wikimedia-related topics.

Repository and demo: https://github.com/larsgerulat/wicki-age

Documentation: https://github.com/larsgerulat/wicki-age#readme

Bug reports and feedback: https://github.com/larsgerulat/wicki-age/issues

The tool is still young, and I would be happy to get feedback from Wikimedians: Is this useful for article work, education, project pages, GLAM topics, or historical overview pages? Are there Wikimedia workflows I should consider?

I am the maintainer, so this is not meant as advertising, but as a request for community feedback.

Best regards Kogno23 (talk) 13:57, 7 July 2026 (UTC)

A question regarding some user groups

On most wikis, only bureaucrats (and stewards for those without bureaucrats) can grant the account creator and confirmed user groups. On some wikis (English Wikipedia, Wikibooks, Wikidata), admins can grant and revoke those. Why can only bureaucrats can do these by default? Codename Noreste (talk • contribs) 16:34, 8 July 2026 (UTC)

In the long-long ago 'crats took care of "accounts" a lot more than they do now, and these were functions related to account management. "confirmed" was primarily only about captcha controls and has had more and more things tacked on to it overtime (including custom abusefilter rules) and would occasionally be needed when doing certain account management functions. When accountcreator got created there needed to be a way to manage it - and at the time it also was more like flood/bot, another item managed by crats. Keep in mind that most of our hundreds of projects don't use these groups in practice at all. — xaosflux ^Talk 19:09, 8 July 2026 (UTC)

Wikinews pulse?

any updates on wikinews pulse or another project like wikinews? Thank you. BigKrow (talk) 23:37, 10 July 2026 (UTC)

What do you think about a "Simple Wikidata" project?

Hi everyone,​I’ve been thinking lately about how powerful but complex Wikidata is, especially for small applications, light web tools, or new developers who just want quick, straightforward facts without digging through deep ontologies, qualifiers, or multiple conflicting values.

What would you think if there was a "Simple Wikidata" project?

The goal wouldn't be to replace the main site, but to act as a lightweight, human-readable layer (similar to Simple English Wikipedia). It would focus on a single, preferred value per property and use clean, clear text/slugs instead of just strict Q/P IDs for everyday queries. It could be fully automated and synced via bots from the main project.

Do you think this is a feasible and useful idea for the ecosystem, or is it unnecessary given what we already have? Would love to hear your honest thoughts! -- 🐦‍🔥 Aws ^{💬 Talk} 09:44, 12 July 2026 (UTC)

You can't really appropriately describe objects in details if you only have a small number of identifiers to begin with (just like how simplewiki has a few hundred words with which you should be able to describe even complex topics). Sometimes, values cannot be singular (ie. the daily temperature). Sounds like a fairy tale with not much additional value. Wikidata was designed to be machine readable so why would we derive back towards Wikipedia as a humanly-readable interface? Sorry, but this proposal is so far too idealistic. Best, A09|(pogovor) 10:26, 12 July 2026 (UTC)

Hi @A09, you might be looking at it from a human-reader perspective.

​The goal isn't to downgrade Wikidata or limit its expressive power, Complex data and multi-values (like daily temperatures) will always live in the main project.

​Simple Wikidata is about caching static, high-frequency facts (like country capitals, birth dates, or official websites) to serve light apps and local AI models instantly without causing SPARQL timeouts. It’s an optimization layer, not a replacement. -- 🐦‍🔥 Aws ^{💬 Talk} 10:36, 12 July 2026 (UTC)

Think of it as a pre-computed caching layer to stop those annoying SPARQL timeouts by keeping static facts ready to go. It’s also built to be a developer-friendly API so people can actually build apps in minutes without decoding Q/P IDs, and a compact database for small AI models that need to run offline on local devices. -- 🐦‍🔥 Aws ^{💬 Talk} 10:46, 12 July 2026 (UTC)

I don't quite get your idea. How would it be simpler for developers? Least Action (talk) 10:41, 12 July 2026 (UTC)

Right now, if a developer wants to fetch a simple fact like 'What is the capital of Libya?', they have to write a complex SPARQL query, handle dozens of property IDs (like P36 and Q1016), and filter out multiple conflicting values or historical data manually in their code.

​Simple Wikidata flattens all of this. It gives developers a clean, context-aware API with human-readable keys and a single, pre-filtered 'preferred value' ready to use.

​Instead of spending hours decoding ontologies and dodging query timeouts, they get a direct answer in milliseconds. It turns a complex data-science task into a standard, lightweight API call. -- 🐦‍🔥 Aws ^{💬 Talk} 10:46, 12 July 2026 (UTC)

This sounds like a good idea! Least Action (talk) 10:51, 12 July 2026 (UTC)

July 2026 Wikimedia Café meetups regarding Wikimedia governance and options for reform

Hello! There will be two Wikimedia Café discussion opportunities in July. Both sessions will focus on Wikimedia governance, including possible follow-ups to the Movement Charter and options for reform. Participants may attend either or both Café sessions.

This month, to deconflict the Café meetups from Wikimania, the meetups will be held one day later than usual.

1. 26 July 2026 15:00 UTC (timestamp converter), at a time friendly to the Americas, Africa, and Europe
2. 27 July 2026 03:00 UTC (timestamp converter), at a time friendly to Asia and the Pacific

Please see the Café page for more information, including how to register!

↠Pine (✉) 02:49, 13 July 2026 (UTC)

Discussion at Meta Requests for comment: The future of Abstract Wikipedia

 You are invited to join the discussion at Meta Requests for comment: The future of Abstract Wikipedia. qcne (talk) 11:37, 14 July 2026 (UTC)