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)

Instructions

Hello to all!

I am new here. I am translator EN->EL with medical specialization. Are there any guidelines on how to get started with translating?

Thank you! Eleniper (talk) 17:27, 19 July 2026 (UTC)

Reflections from Around the Puzzle Globe

Bernadette (Wikimedia Foundation CEO) has shared her reflections from around the puzzle globe (split into 3 pages), based on the discussions she's now had with over a thousand people. For those joining Wikimania she'll also be hosting a session around these observations. Quiddity (WMF) (talk) 09:26, 20 July 2026 (UTC)

Upcoming DCW Conversation Hour on Wikipedia Admin & Patrol Tools

Hello! You are invited to the 43rd DCW Conversation Hour on 26 July 2026 at 3:30 PM UTC, featuring Sohom Datta. In this session, we will be breaking down the advanced tools, automation scripts, and moderation systems that administrators and editors use to maintain quality and security on projects like Wikipedia. Please see the session page for the registration link and more information. Musical starlight (talk) 19:30, 23 July 2026 (UTC)

@Musical starlight: That sounds like an excellent discussion. I hope to watch the recording later. By the way, on Template:Main Page/WM News, I reversed the order of two announcements so that the start times are chronological from top to bottom. I would prefer for us not to have DCW Conversation Hour times overlap with Wikimedia Café times, but given Wikimania this month there are scheduling pressures that we don't have in other months. I'm happy to have discussions about schedules in August forwards, so that we try to avoid overlap in the future. Regards, ↠Pine (✉) 20:01, 23 July 2026 (UTC)

@Pine: Thank you for your interest! The recording will be uploaded, and updates about it will be sent via the mailing list. I also really appreciate you taking the time to reorder the announcements on the Main Page, thank you for catching and fixing that! Regarding August, we haven't received the date and time confirmation from our speaker just yet. Once we do, I'd be very happy to connect with you to discuss the schedule so we can ensure we avoid any overlaps in the future. Musical starlight (talk) 14:16, 26 July 2026 (UTC)

Request for comment (the future of Abstract Wikipedia)

You are invited to voice your opinions in a request for comment about the future of Abstract Wikipedia. Thank you! Kowal2701 (talk) 12:24, 24 July 2026 (UTC)