Wikidata:Project chat

Wikidata project chat

A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

• Frequently asked questions
• Requests for deletions
• Merging instructions
• Report a technical problem
• Requests for protections, undeletions and other matters requiring administrator attention. To report vandalism, click here.

For realtime chat rooms about Wikidata, see Wikidata:IRC.

Start a new discussion

• Afrikaans
• العربية
• беларуская
• беларуская (тарашкевіца)
• български
• Banjar
• বাংলা
• brezhoneg
• bosanski
• català
• کوردی
• čeština
• словѣньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
• dansk
• Deutsch
• Zazaki
• dolnoserbski
• Ελληνικά
• English
• Esperanto
• español
• eesti
• فارسی
• suomi
• føroyskt
• français
• Nordfriisk
• galego
• Alemannisch
• ગુજરાતી
• עברית
• हिन्दी
• hrvatski
• hornjoserbsce
• magyar
• հայերեն
• Bahasa Indonesia
• interlingua
• Ilokano
• íslenska
• italiano
• 日本語
• Jawa
• ქართული
• қазақша
• ಕನ್ನಡ
• 한국어
• kurdî
• Latina
• lietuvių
• latviešu
• Malagasy
• Minangkabau
• македонски
• മലയാളം
• मराठी
• Bahasa Melayu
• Mirandés
• مازِرونی
• Nedersaksies
• नेपाली
• Nederlands
• norsk bokmål
• norsk nynorsk
• occitan
• ଓଡ଼ିଆ
• ਪੰਜਾਬੀ
• polski
• پنجابی
• português
• Runa Simi
• română
• русский
• Scots
• davvisámegiella
• srpskohrvatski / српскохрватски
• සිංහල
• Simple English
• slovenčina
• slovenščina
• shqip
• српски / srpski
• svenska
• ꠍꠤꠟꠐꠤ
• ślůnski
• தமிழ்
• తెలుగు
• ไทย
• Tagalog
• Türkçe
• українська
• اردو
• oʻzbekcha / ўзбекча
• Tiếng Việt
• Yorùbá
• 中文

Edit

On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2026/01.

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 7 days.

Proposal for changing RFU process

I believe the current process for appealing deletions is no longer functioning well.

Appellants are currently encouraged to contact the deleting admin first, with the intent of resolving issues efficiently and allowing appeals to be refined. In practice, many appellants do not do this, and when they do, the arguments rarely improve as a result.

Final appeals brought to WD:AN are frequently verbose, poorly structured, misapply notability policy, or characterize sources inaccurately. This has significantly lowered the signal-to-noise ratio on that noticeboard.

At the same time, undeletion discussions are getting less and less engagement. Meaningful community input is now the exception rather than the norm. Many threads are simply closed due to inactivity, which experienced editors may interpret as a tacit decline, but which is understandably confusing for newcomers.

I propose:

• Create a dedicated “Requests for undeletion” (RFU) noticeboard
• Encourage responders to indicate their position explicitly using !votes
• Close RFU threads explicitly, rather than by inactivity
• Permit rapid closure of repeat requests that don't bring new evidence
• No longer instruct appellants to contact the deleting admin first

My goal here is to centralise undeletion requests into a single, clearly-scoped venue with more predictable participation and clearer outcomes, improving transparency for appellants and reducing diffuse, low-signal discussion elsewhere.

A similar idea has been proposed in the past, but did not gain consensus. I generally oppose new fora because we are a small community with a limited supply of volunteer attention. My view on this has changed in response to the flaws observed in the current process. Bovlb (talk) 23:00, 15 December 2025 (UTC)

 Support Good idea. I saw RfUs flooding admin talk pages. I think in the process, RfU templates should also be able to (1) linking the RfD cases related and (2) cc the deleting admins immediately. One question appeared, if the deletion happened in bulk, could the RfU be done in bulk, or there will be kind of selective undeletion for bulk deletion case. —Yamato Shiya^{大和 士也} (Talk • Contribs) 16:10, 16 December 2025 (UTC)

Thanks. I deliberately didn’t propose templates at this stage. There are three different cases to be made for undeletion, based on our three notability criteria, and the evidence can be complex. That makes them a poor fit for rigid templates, especially given that many appellants already struggle with wikitext. My hope is that a separate venue, clearer responses, and explicit closures will solve a lot of our issues, and we can always add more structure later.

Linking to the relevant discussions and pinging the deleting admin are all things that should happen. Given that many appellants struggle even to link the deleted item, I don't feel we can realistically make it mandatory. A dedicated page will allow us to provide better instructions at the top.

As for bulk deletions, the real question is whether a single request can actually address all of the cases. Responding admins can choose to be selective if not. Bovlb (talk) 17:14, 16 December 2025 (UTC)

• Notability in Wikidata is not a matter of votes, it can in most situation be inferred pretty much deterministically from the conditions found in the item page and additional evidence in case that was missing from the item page. There is some minor leeway in terms of the assessment of the “seriousness” of sources, but with some experience even that is not difficult. Please let’s avoid making these decisions a matter of votes. We are not Wikipedia.
• Many of the recent undeletion requests on WD:AN have the same problem: a wall of text is presented with plenty of promotional weblinks. The items in questions do in most situations obviously not need to be restored. We just need to be more straigtforward in terms of closing these discussions, but more admins would be really helpful as always.
• Do we need another theater for such discussions? Unclear to me, I am not yet convinced that this would make us more efficient.

—MisterSynergy (talk) 18:42, 16 December 2025 (UTC)

I completely agree that notability is not a matter of votes, and I did not intend to suggest otherwise. For the avoidance of doubt, by "!vote" I mean an explicit signal of position (restore, keep deleted, comment, question) with the expectation that the issue is determined by policy and the strength of evidence and argument, not by a tally. (cf en:WP:NOTVOTE)

The major issue that I'm trying to solve here is that appellants are genuinely confused by our current process. They submit their appeal expecting a clear resolution, accept or reject. Instead they get comments pointing out flaws in their arguments, which they don't know how to interpret or respond to. In practice, they tend to repeat the same claims, continue to defend their misreading of policy, and make unsubstantiated claims about their evidence. Only occasionally does this result in new evidence that actually changes the outcome.

I'm suggesting !votes here because I think it would communicate the nature of the discussion more clearly: We're accumulating responses based on the evidence provided. It would also lower the social barrier for community participation, which I think is something we sometimes lack at WP:AN. That input is often valuable for determining borderline cases.

When the discussion dies and is auto-closed, appellants commonly don't perceive this as a resolution, which can lead to further disruption. Explicit closures are intended to make the outcome clearer and eliminate one source of confusion.

As I said above, I'm not a fan of adding new discussion venues, given our limited volunteer time, as I feel we're already bad at servicing the array we have now, so any new board needs a clear justification. I'm making this proposal reluctantly because I think we can make WD:AN work better, while also making things less confusing for appellants. Bovlb (talk) 20:29, 16 December 2025 (UTC)

IMO we need to be more strict with these promotional appellants. There is simply no point in lengthy discussions with them, as they only accept a "restore" decision which is just not on the table. It would not help them if non-admins told them that they do not have a point. Based on the recent discussions on WD:AN, they often even ignore multiple rejections from different admins.

That said, we have seen fewer than 700 page restorations (all namespaces) in 2025 so far (xtools). That amount is low, particularly compared to the number of deletions (almost 163k). Since many of the RfUs are still being processed effectively on admin talk pages, I would expect this to be a very quiet venue. I really do not see the need for a separate noticeboard, neither in terms of process development nor volume. —MisterSynergy (talk) 22:12, 18 December 2025 (UTC)

I don’t disagree. These self-promotional requests for undeletion generate a great deal of disruption for very little benefit. At the same time, in the absence of a clear pattern of abuse, blocking is usually not appropriate, and appellants do deserve the opportunity to have their case heard, even though the vast majority will be rejected.

I’ve added another top box to Wikidata:Guide to requests for undeletion in an attempt to better realign expectations. Experience suggests that such guidance has limited effect for motivated appellants, but it may at least forestall the common complaint that the act of discussing and rejecting an appeal is itself harmful. Bovlb (talk) 22:53, 18 December 2025 (UTC)

"WD:AN are frequently verbose, poorly structured, misapply notability policy, or characterize sources inaccurately." You aren't speaking to the user doing the appeal. You are speaking to the LLM they are using--Trade (talk) 05:25, 17 December 2025 (UTC)

That’s often true, but humans are also capable of all of this; LLMs simply make it cheaper, introducing an asymmetry of effort on the reviewing side. LLMs are not the core problem here, and banning them would not only be neither appropriate nor feasible, but it also would not address the underlying issue.

Your comment made me realise there’s an elephant in the room that I haven’t stated explicitly: Almost all undeletion requests are related to self-promotion, and almost all of those fail. In such cases, we are not dealing with a disinterested truth-seeker, but with a motivated reasoner. This explains why feedback so rarely leads to a change of position or to the production of new evidence, whether LLMs are involved or not.

In that context, a process built around extended discussion without clear response signals or an explicit resolution is a poor fit for the dominant use case. The predictable result is ongoing low-grade disruption of an important noticeboard that also needs to be able to respond quickly to genuinely urgent issues.

My proposal is intended both to make WD:AN function better for its core purpose and to reduce confusion for outsiders who do not yet understand how the project works. Bovlb (talk) 16:59, 17 December 2025 (UTC)

Could also just more aggressively block spammers and self-promoters. The majority of these requests are from accounts that are never seen or heard from again when their Hail Mary undeletion request is rejected. —Xezbeth (talk) 17:19, 17 December 2025 (UTC)

I agree that self-promotion, whether in item creation or in undeletion requests, is a source of disruption to the project with no obvious upside, and it’s very tempting to use blocks to protect the project from that disruption. However, it’s not clear to me that the current blocking policy permits this in the absence of a demonstrated pattern of abuse.

A pattern would include repeated recreation of deleted items, repeated undeletion requests without new evidence, or venue abuse. In the absence of such a pattern, deleting the item or declining the request seems more appropriate than immediate sanction. Bovlb (talk) 18:15, 17 December 2025 (UTC)

 Comment before it gets too long: do we need separate RfU page or not? @Bovlb reasoning still stand. RfU for RfUs, WD:AN for highly escalated issue, and blocking requests.—Yamato Shiya^{大和 士也} (Talk • Contribs) 23:11, 17 December 2025 (UTC)

I'm in favor of a separate page for RFUs per Bovlb's proposal. As much as I dislike the low quality undeletion requests, they deserve to have their requests reach a conclusion instead of being auto archived due to inactivity. That and a dedicated page would have space for a header to give a little more guidance/instruction on what format on what their requests should include. William Graham (talk) 02:48, 18 December 2025 (UTC)

I support the proposal for a separate RfU page. The AN page gets sometimes flooded with long threads (thanks to LLMs) of undeletion requests/discussions which isn't ideal when the rest of the page is mostly just short block or revert requests. As an admin I feel like the current system sometimes discourages me from deleting items because I know my user talk page could soon after get lots of long, often poorly justified undeletion request which I would have to handle by myself. A RfU page would allow admins to do the job more collectively. This proposal would also make the undeletion process simpler for the users whose items have been deleted, and they could get responses more quickly. Samoasambia ✎ 16:14, 18 December 2025 (UTC)

 Support separate RFU page. This should probably be an RFC though (this is a major communication channel but not the only one and people comfortable in other languages might not watch this page). ArthurPSmith (talk) 17:09, 18 December 2025 (UTC)

An RFC would be premature at this time. I wanted to share these ideas and get initial feedback before deciding whether a more formal proposal is warranted. Bovlb (talk) 19:26, 18 December 2025 (UTC)

As you point out, the relentless stream of low-signal appeals discourages admins from marginal but policy-correct deletions. That is not a healthy outcome for the project.

My proposal removes the expectation that appellants first engage the deleting admin privately. That step was intended to encourage constructive discussion and help appellants to refine their case. In practice, appeals rarely improve, new evidence is seldom produced, and the same misunderstandings of policy are simply restated, often accompanied by new complaints.

A single, public discussion in a clearly-scoped venue is a better fit for how undeletion requests actually function today. Appellants get a chance to be heard, but the disruption is minimised. Bovlb (talk) 19:17, 18 December 2025 (UTC)

I do ot have strong opinion, we can proceed with the current workflow, or we can open a dedicated page. I must say though that talk page appeals are very annoying, and at some point I simply stopped deleting item which I suspect would trigger the creator coming to my page arguing until exhaustion.--Ymblanter (talk) 20:12, 19 December 2025 (UTC)

A related idea: we should add an abuse filter that would prevent creations of Main namespace and Lexeme talk pages for deleted Items or Lexemes. I've noted that sometimes undeletion requests are posted there and almost nobody will ever find them. I'll add this filter if this idea gets support. Samoasambia ✎ 13:13, 21 December 2025 (UTC)

Actually this appears to be impossible. Abuse filter doesn't support this kind of filter :( Samoasambia ✎ 13:56, 21 December 2025 (UTC)

Thanks to all who have commented. For those who have expressed concerns: To some extent, the five parts of my proposal are separable. Which of them could you agree with? For example, could we all agree to forgo recommending the initial appeal to the deleting admin and just point them straight at WP:AN for a single, final appeal? I don’t think we need consensus to start marking !votes or making more explicit closures, although we may need to tweak the “section resolved” message to discourage reopening. Bovlb (talk) 18:31, 21 December 2025 (UTC)

I have made a specific proposal for an alternative section closed message at Template_talk:Section_resolved#Add_option_for_firmer_message. Bovlb (talk) 18:16, 26 December 2025 (UTC)

"Serious and publicly available sources" and self-promotion

It's beyond time for us to reevaluate this criterion of WD:N. Our de facto criteria have become stricter than just this, as illustrated by the numerous items deleted for lack of notability. We really ought not to have items on things that are not content pages on other projects or are structurally needed for items on such projects, whether directly or indirectly.

Perhaps the other problem is that we de facto now disallow the creation of items by entities (people, organizations) on themselves, but this is not articulated clearly. There have been some cases of ChatGPT or other chatbots suggesting people to create items on themselves, only to have them deleted, creating extra work for us and disappointing/frustrating the users. We need a better way to document these practices. Jasper Deng (talk) 10:30, 20 December 2025 (UTC)

Our notability requirements should not be defined by other projects (I assume you mean those in the Wikimedia community). Its entirely fine to add new items not mentioned elsewhere if they are of similar notability to the baseline of items we already have, and to reject items that lower that standard. Vicarage (talk) 14:28, 20 December 2025 (UTC)

@Vicarage Our notability requirements should not be defined by other projects. IMHO other (Wikimedia) projects notability criterion had impact on Wikidata's. In my experience in editing, Wikidata had more larger and more general scope than (and encompassing of) that is Wikipedia. It could contain many things, but not everything. CMIIW.

Our interpretation of notability criterion also could be influenced by facts that certain projects handled by the local Wikimedia communities and/or funded by the Foundation, I saw some of this cases previously (case A, case B.) —Yamato Shiya^{大和 士也} (Talk • Contribs) 11:11, 21 December 2025 (UTC)

I have many thoughts about notability, self-promotion, and LLMs, but I’ll follow the lead here and restrict myself to improving N2. This short bullet currently packs a lot into very few words, and it’s perhaps not surprising that it’s widely misunderstood in practice. I think we could help both editors and admins by adding some clarifying text that makes explicit how N2 is applied, without significantly changing its scope. I t’s too early to get hung up on wording, but as an illustrative example:

It refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references.

• a) Identifiers: The subject is associated with one or more identifiers that are assigned or curated by an independent authority, and that meaningfully distinguish the subject from others. Identifiers that are self-assigned, automatically generated, or can be obtained without editorial review (such as typical social-media profiles) are not sufficient on their own.
• b) Sources: The subject is the topic of substantial, independent coverage in serious and publicly available sources. Routine listings, directory entries, brief mentions, or being quoted in an interview about another topic do not constitute substantial coverage. Self-authored descriptions, official websites, and marketing or promotional material are not independent sources.

This is not intended to materially change N2, but to flesh it out in light of how it is already applied in practice. Bovlb (talk) 21:57, 20 December 2025 (UTC)

This please. Great proposal! —MisterSynergy (talk) 22:12, 20 December 2025 (UTC)

I  Support @Bovlb proposal. Could we also give "structural need" more explanation?. Thanks. —Yamato Shiya^{大和 士也} (Talk • Contribs) 11:08, 21 December 2025 (UTC)

I have thoughts about N3, but I think that deserves its own thread. Bovlb (talk) 18:38, 21 December 2025 (UTC)

Section #2 is almost impossible to grasp for an outsider, so it needs to be more verbose with examples, particularly of what does not contribute towards notability. Make the change suggested by Bovlb. Infrastruktur (talk) 13:46, 21 December 2025 (UTC)

 Support I think Bovlb has elegantly captured here how the general experienced wikidata community understands N2. Thanks! ArthurPSmith (talk) 22:37, 21 December 2025 (UTC)

Conditional  Support as long as Infrastruktur (talk • contribs • logs)'s concern is also addressed. I suggest turning this into an RfC as we should have a community-wide consensus about it.--Jasper Deng (talk) 04:10, 22 December 2025 (UTC)

Is it a requirement for both a AND b to be satisfied or just a OR b. See this earlier related discussion https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2025/09#h-Do_items_have_to_have_external_identifiers_to_pass_Wikidata_Notability_criteria-20250930083100 Piecesofuk (talk) 10:22, 22 December 2025 (UTC)

Yes, N2 is a single criterion with two parts, both of which must be met. That's not changing in this proposal. Bovlb (talk) 17:00, 22 December 2025 (UTC)

 Oppose Since there should be no requirement for items to have external IDs which was the conclusion reached by the community in the discussion I cited above. Piecesofuk (talk) 17:26, 22 December 2025 (UTC)

This seems more like an opposition to the current wording of N2. All I did here was to clarify the two parts. Bovlb (talk) 17:48, 22 December 2025 (UTC)

No, because the current wording of WDN2 makes no mention of external IDs Piecesofuk (talk) 17:55, 22 December 2025 (UTC)

Ah, so you're drawing a distinction between an entity being identifiable in principle and the item having identifiers. I thought you were asking whether both parts of N2 have to be satisfied.

As I've said before, there's a wide range of information that can help to identify an entity beyond technical identifiers, such as addresses, co-ordinates, and positions held. Unfortunately these tend to be weak identifiers and do not really help to establish notability by themselves.

Wikidata is increasingly accumulating poorly-represented items of questionable notability that add little or nothing to the project. Given that, policy needs to be clear about what we expect from contributors in terms of minimal item creation. While admins should exercise judgement in marginal cases, it's not helpful to encourage contributors to rely solely on weak identification. Bovlb (talk) 18:48, 22 December 2025 (UTC)

 Support Sounds reasonable. This could help ensure that Wikidata remains the best structured open source database of notable companies on the one hand, while on the other hand not getting drowned in a flood of AI-generated spam or hoaxes. It is also worth noting that this spam mostly violates Wikidata:Disclosure of paid editing. Jklamo (talk) 10:13, 23 December 2025 (UTC)

 Support I love this clarification. So9q (talk) 10:14, 28 December 2025 (UTC)

Just a quick note: I've been having initial conversations with people about the biggest issues with the notability policy and how to reform it. I am in the process of turning them into an RfC to get initial clarity on a few big open questions. I hope to have that out before the end of the year still. I'm happy to have help if anyone if you wants to get involved. Lydia Pintscher (WMDE) (talk) 10:18, 22 December 2025 (UTC)

Thanks for the heads-up. I look forward to seeing the pre-RfC discussion here on Project Chat.

I don’t think the prospect of a broader RfC should prevent us from workshopping concrete clarifications to N2 here. Narrow improvements and broader reform aren’t mutually exclusive, and having more concrete text to react to would likely be helpful input to any later RfC. Bovlb (talk) 19:00, 22 December 2025 (UTC)

I agree. So9q (talk) 10:14, 28 December 2025 (UTC)

@Bovlb: I have now published it at Wikidata:Requests for comment/Notability policy reform. I have not added the specific wording suggestions from here. Please someone feel free to add them. Lydia Pintscher (WMDE) (talk) 13:44, 30 December 2025 (UTC)

• automatically generated in the (otherwise excellent) prose above is going to cause problems. For example both LCCN and VIAF, the premier identifiers for people in the library and publishing world are technically automatically generated. algorithmically generated is a better phrase here. Stuartyeates (talk) 19:08, 23 December 2025 (UTC)

  Good point. Bovlb (talk) 19:15, 23 December 2025 (UTC)

  I agree. @Bovlb would you be willing to post an updated clarification as an RfC now that it seems to have wide support? So9q (talk) 10:16, 28 December 2025 (UTC)

  I would love to, but I am busy with family all this week. I don’t think it would serve the community for me to rush something out and then be unable to support the discussion. Please feel free to use my suggestions. Bovlb (talk) 16:06, 30 December 2025 (UTC)

  The new year is also not a great time to maximize community engagement due to vacations and festivities, so I have been waiting as well. Jasper Deng (talk) 21:49, 30 December 2025 (UTC)

List of ID's

Is there accurate list of ID's related to music? I know there are somewhere lists divided by organisation ID, creative ID etc. but they aren't that accurate. Eurohunter (talk) 22:17, 20 December 2025 (UTC)

Wikidata:WikiProject Music list various IDs used for item music. —Yamato Shiya^{大和 士也} (Talk • Contribs) 00:10, 21 December 2025 (UTC)

@Yamato Shiya: I know this list but how I can easly track new ID's? Eurohunter (talk) 23:26, 25 December 2025 (UTC)

Unless someone is checking every issue of the Wikidate Weekly Summary and makigng a lost? No. Hell, tracking a classifying non-ID properties has been abandoned years ago despite how obviously relevant it is. Circeus (talk) 02:31, 2 January 2026 (UTC)

Adding NAAC grades to a college

How do I add NAAC grades National Assessment and Accreditation Council (Q3522862) to a college on Wikidata item Laxminarayan College (Q16894033), they provide credits in letters (ex. A+, A, B, B+ etc.) ? Rocky 734 (talk) 02:53, 22 December 2025 (UTC)

You could use accredited by (P5514) National Assessment and Accreditation Council (Q3522862) in the item, with qualifiers start time (P580) and end time (P582) for validity period. For grades, I do not find any showcased example. Please refer to this page for more information.—Yamato Shiya^{大和 士也} (Talk • Contribs) 05:33, 22 December 2025 (UTC)

Thanks, where to request for creating that property for credits given by NAAC. Rocky 734 (talk) 06:10, 28 December 2025 (UTC)

I would not recommend them, due to the the availability of accredited by (P5514) and ranking (P1352). @Pigsonthewing and @ArthurPSmith are people I know experienced in property, could you help us with your opinion? Apologize for tagging you. —Yamato Shiya^{大和 士也} (Talk • Contribs) 08:47, 28 December 2025 (UTC)

The correct property is not ranking (P1352). That's only for position within an ordered list. I believe the general property you're thinking of is rating (P4271). Circeus (talk) 02:28, 2 January 2026 (UTC)

Is there a bot or something that can fix the incorrect use of given name (P735) Anne (Q564684) on men?

There's a male gendered name Anne (Q47860848) which would seem to be more appropriate. There's over 200 of them, see https://w.wiki/HC8c Piecesofuk (talk) 19:34, 25 December 2025 (UTC)

You can build a Template:Complex constraint. Jklamo (talk) 19:40, 25 December 2025 (UTC)

Thanks, not sure I want to do that, seems to be overkill to run daily reports to list them. Probably just a one off fix would do. Piecesofuk (talk) 21:57, 25 December 2025 (UTC)

Here's a query https://w.wiki/HCub - I get 230 results. It seems like QuickStatements could be used to remove the "wrong" Anne and add the right one Anne (Q47860848), perhaps in multiple batches. Are you up for that? - PKM (talk) 22:06, 26 December 2025 (UTC)

PS Please also make sure it's the name that's wrong and not the sex or gender before we begin. - PKM (talk) 22:12, 26 December 2025 (UTC)

Yes, that's a good point, I think I'll just go through the list and manually update as necessary Piecesofuk (talk) 06:42, 27 December 2025 (UTC)

presented by and hosted by

How to add presented by Forix (Q68630052) and hosted by Autosport (Q776358) to 6th Gear (Q137586682)? Previously added "presented by" and "hosted by" turned out to be incorrect presenter (P371). Eurohunter (talk) 21:20, 25 December 2025 (UTC)

I think the property for the relevant meaning of "hosted" is organizer (P664). Can you confirm? Circeus (talk) 02:21, 2 January 2026 (UTC)

Wikidata:Bot_requests#Request_to_connect_unconnected_disambiguation_pages_to_wikidata_items_by_a_bot_(2025-12-26)

Hello, please see

• Wikidata:Bot_requests#Request_to_connect_unconnected_disambiguation_pages_to_wikidata_items_by_a_bot_(2025-12-26)

@MisterSynergy, Mike Peel: for information. M2k~dewiki (talk) 14:20, 26 December 2025 (UTC)

Request for review of new Wikibase backend architecture

Project overview

wikibase-backend explores an alternative Wikibase backend architecture with a focus on:

• Immutable entity storage (S3 / object storage)
• High-throughput metadata and indexing via Vitess
• Strong auditability through immutable snapshots
• Decoupling MediaWiki from core storage concerns
• Scalability targets up to billions of entities

The repository primarily contains architecture documentation, conceptual models, and early implementation ideas rather than a drop-in replacement.

Feedback I’m looking for

I would especially value feedback on the following areas:

Architecture & design

• Does this approach make sense for alternative Wikibase backends?
• Are there known architectural pitfalls or constraints I should consider?

Compatibility with Wikibase / Wikidata tooling

• Potential issues or opportunities when consuming data from this backend
• Assumptions made by existing tools that might conflict with this design
• Ideas to improve interoperability with the current Wikibase ecosystem

So9q (talk) 21:49, 26 December 2025 (UTC)

Please no to the first point. S3 is notoriously unindexed and a pain to search. It would not at all fit the concept of editable (so mutable) data. I do not think that makes sense at all for Wikidata. Revisions already serve the role of immutable snapshots. Lastly, you have not identified any significant problem that would be solved by this. Let's not solve a problem that does not exist. This is a solution in search of a problem. Jasper Deng (talk) 02:13, 27 December 2025 (UTC)

Interesting reaction. From what I have observed (I could be wrong) we have scaling issues with mariadb since 10 years and the system is almost at at point where no further items can be added. The current WMDE policy and development plan (correct me @lydia or @mohammed if I'm wrong) is to mitigate the scaling issues by "Ontology Federation" and thus effectively force the community to divide and use federation as the golden path forward. I disagree with this policy and thus we need a backend solution that scales better than the current one.

> S3 is notoriously unindexed and a pain to search.

I agree, that's why the architecture plan includes a Vitess database backend which can be scaled horizontally and is possible to query. S3 is immutable revision JSON storage and nothing else. So9q (talk) 09:53, 28 December 2025 (UTC)

Do you have a link to your project? As an ignorant user, a summary of how much scaling you think would be possible, in terms of increase in numbers of possible items, statements and revisions, and query speed, would be useful, and what extra hardware might be needed to achieve it and hardest to estimate of all, how many developer years of effort? Vicarage (talk) 11:06, 28 December 2025 (UTC)

At least 5bn items is my current target. It's just a matter of resharding if we need more.

Statements: as many as you want. Items >1MB is not a problem for the backend, it's all just JSON.

Query speed is dependent on the query engine of WDQS. My backend rewrite emits RDF changes that can be consumed by any suitable query engine.

Edit speed at least as today.

RDF diff computation will be limited to items <1MB, above that the downstream consumer will have to calculate the diff themselves (open source libraries exists and it is trivial)

Unknown years of dev effort, but the backend MVP is mostly done and getting closer every day.

Hardware requirements are currently unknown, but that has never been the main issue behind the scaling. Main issue is unsustainable evolution of architecture (WMDE/WMF have not revised the initial architecture as WD has grown way beyond what Denny and his team envisioned and planned for).

I think 100-200 commodity servers in a kubernetes cluster is a good start.

The first version of Gmail was built on 300 old pentium servers at Google that nobody wanted to use. :)

I don't know how many flink workers are currently deployed for the streaming updater. Perhaps the Wikidata platform team can answer that? Anyway that also scales horizontally.

The only bottleneck will be how fast the downstream RDF consumers can ingest the diffs. Edits to huge items are more costly to compute so that's why I decided to leave that to consumers.

Today the infrastructure is set up outside of Kubernetes with manual pooling/depooling of a cluster of mariadb servers. My backend can be run in Kubernetes and is cloud native.

Vitess (open source) on Kubernetes supports:

• Horizontal sharding
• Online resharding
• Automated failover
• Read/write splitting
• Schema migrations
• Zero-downtime upgrades

Same for S3 backend e.g. on Ceph (open source).

No more read/write bottlenecks on mariadb. No more out of memory issues on mariadb master/slave servers. So9q (talk) 12:51, 31 December 2025 (UTC)

The only issue I choose not to solve is the search issue.

A WD with 100M+ scientific items, 100M+ roads, 100M+ stars, 100M+ chemicals, etc. are going to be a pain to search with the current setup.

We need better filtering based on subgraph or better yet per WikiProject.

Recently an improvement helping to search items/lexemes/properties was added and that is a step in the right direction, but it is not sufficient if you ask me.

So when Wikifunctions contributors try to find an item for a verb/adjective they don't get a lot of scientific items that clutter the drop down and make it a mile long.

This is something the Wikidata Platform team could focus on if/when the new backend gets adopted and work as expected. So9q (talk) 12:56, 31 December 2025 (UTC)

This is a great overview. @So9q: But then how do you address revision deletion and GDPR requirements that may require us to hide revisions? Does that count as mutation of those revisions? Jasper Deng (talk) 04:28, 1 January 2026 (UTC)

We could add any metadata fields to entities in the Vitess table. Ie hidden=true/false, etc. I'm not digging in to that until the MVP is done.

First we solve the scaling issues, the rest is rather trivial in comparison. So9q (talk) 17:33, 1 January 2026 (UTC)

It's not. The assumption of immutable revisions is a huge one. Something that is immutable is hashable and can be stored in a distributed hash table. You can't do that when something is mutable. Suppose I hide a revision; will that change the S3 key, and if so how will we maintain coherency? I still do not think we should use any proprietary software or platforms like S3 in principle.

Also, how do I read an item's history this way? Does Vitess store a linked list of some sort that allows me to quickly traverse item history? If so, then how do I quickly access older revisions faster than linearly traversing said linked list? Jasper Deng (talk) 23:12, 1 January 2026 (UTC)

You should've mentioned that Vitess database clearly as the way items are to be looked up with.

I would much prefer we use our own in-house DHT than S3, since using a third-party company's backend opens up serious privacy and compliance concerns (plus, I don't agree with Amazon's stance on many current issues).

It's laudable to make MediaWiki not the core backend for storage but then how does this interact with revision deletion/suppression? And CheckUser relies on the revisions table to generate its entries. These are all nontrivial issues that need to be addressed. Many tools rely on the concept of a revision so the same interface would need to be exposed. Jasper Deng (talk) 20:00, 29 December 2025 (UTC)

I hear you regarding S3. I'm referring to the S3 open source implementations, not the canonical AWS one. Ceph and other open source tools exists to store huge amounts of files/data effectively and cheaply in buckets. They can be sharded too which is what enables horizontal scaling.

Revision deletion/suppression: This is something that could be implemented once the MVP is done. To iterate fast I sidestepped the whole user auth quagmire for now. Focus right now is on a MVP that scales, not full feature compatibility.

There are indeed a lot of tools that rely on MediaWiki standards/APIs and that will need to be handled. The user database can be kept in mariadb and the frontend can access both that and the backend I'm writing. Or the whole thing could be ported to Vitess. So9q (talk) 17:31, 1 January 2026 (UTC)

I added a few economic cost estimations for the architecture at 1bn items. See https://github.com/dpriskorn/wikibase-backend/tree/ttl-builder/doc/ECONOMIC-ESTIMATIONS

These are based on 10 edits/sec (today showed ~5.6 edits/sec), and these calculations of mean number of revisions/JSON bytes per revision based on 300 random items and AWS costs + 10% for WMF overhead. So9q (talk) 19:23, 1 January 2026 (UTC)

Best practices for creating Wikidata items for modern commercial vessels (technical and operational data)

Hello,

I would like to ask for guidance regarding the creation of Wikidata items for individual vessels, specifically modern commercial and tourist vessels (e.g. passenger catamarans, excursion boats, hybrid or electric leisure vessels).

My interest is purely data-modelling and documentary. In professional maritime contexts, certain vessel-level data is widely used and publicly verifiable, such as:

type of vessel and use shipyard / builder year of construction flag state(s) propulsion type (diesel, hybrid, electric) basic dimensions (length, beam) identifiers already in use elsewhere (e.g. IMO where applicable, MMSI, call sign)

I am aware that Wikidata does not establish notability and that items should be based on independent, publicly available sources. My questions are therefore about scope and structure, not promotion.

Specifically:

What is considered an appropriate notability threshold for individual commercial vessels that are not historically famous yet, but are well-documented and operational? Are there recommended properties or data models for representing propulsion type and energy systems on vessels in a consistent way? Is it preferable to start with minimal items (core identifiers and facts) and expand later, or to wait until broader coverage exists before creating an item at all?

Thank you very much for your time and for maintaining Wikidata’s standards.

Best regards, Oceanvoyager82 Oceanvoyager82 (talk) 05:09, 27 December 2025 (UTC)

You might like to look at Wikidata:WikiProject_Ships, but beware that for some time I've been posting thoughts in the discussion area and getting no reply, and I'm interested in military, not commercial vessels. But generally ships don't have notability issues, but small boats would, and we have one entry for the lifetime of the hull, irrespective of changes of owner and use. I've found the key details for ships are their names (and there are complications about how to model that) and launch date (modelled as a significant event, not inception), and IMO number, and with those we can link to all the other databases. Technical data is best put in ship classes and inherited. Vicarage (talk) 07:13, 27 December 2025 (UTC)

As a general guideline, applicable for all topics, it is not preferable to start with minimal items as they are less useful in queries, connects less to the general graph and is easier to mix up with other items (although core identifiers would be helpful mitigating the last one). Ainali (talk) 08:46, 27 December 2025 (UTC)

mul and fallbacks

Now we have labels in the "mul" language and every language without a custom label uses the value of mul as a fallback. So, in Special:Diff/2428240470, Contribs/VGMaintenanceBot removed all labels with the value "Minecraft" from Minecraft (Q49740). Unfortunately that includes zh-TW, which is now using its fallback, which is not mul and is, I guess, either zh-CN or zh, both with the value "我的世界". So now zh-TW is "我的世界" instead of "Minecraft". This is the second time I run into this problem and I hope it could be solved. If it cannot be solved, I hope the bot operators would change their settings and intentionally leave this kind of labels. --魔琴 (talk) 18:37, 27 December 2025 (UTC)

I'm a little confused. So the bot removed a non-zh word from zh-TW and the fallback is working as intended? — Huntster (t @ c) 19:32, 27 December 2025 (UTC)

zh-TW should be "Minecraft". Now it's "我的世界".

lang	Expected	Now
zh	我的世界	我的世界
zh-CN	我的世界	我的世界
zh-TW	Minecraft	我的世界 (converted from zh)

--魔琴 (talk) 05:21, 28 December 2025 (UTC)

So the convention in Taiwan is to refer to Western computer games by their Latin names, but this is not true in China? That level of local knowledge is going to be tricky to model, as I can imagine for other products transliteration is the norm. A rule that mul tidying bots do not fiddle with non-Latin languages would help, but it does leave a burden on users in those countries to enforce their conventions. Vicarage (talk) 09:53, 28 December 2025 (UTC)

There are some special cases. eg. cs have fallback to sk, but in certain case of Wikidata (Q2013) is cs label = mul label = Wikidata, but sk label = Wikiúdaje. Some universal solution for these cases is needed. JAn Dudík (talk) 15:07, 28 December 2025 (UTC)

Note that this and other issues with outright label removal have been documented in Help:Default values for labels and aliases#Am I free to remove redundant labels and aliases?, so that it doesn't have to explained over and over. (Anyone feel free to improve the wording.) --Matěj Suchánek (talk) 13:14, 31 December 2025 (UTC)

The language fallback chain for taiwanese is at the time of writing: "zh-tw", "zh-hant", "zh-hk", "zh", "zh-hans", "en". Just for clarification, am I correct in assuming that for most words that doesn't have a taiwanese (zh-TW) label should fall back to using chinese labels, except for western/latin proper nouns?

IIRC someone mentioned in the "mul" RFC that the chinese "transliteration" of Burger King (proper noun) was actually a translation where they used chinese ideographic letters. So, I guess the taiwanese follow the western approach for western proper nouns then?

Please ping the bot operator (User:A_particle_for_world_to_form) on reply. Infrastruktur (talk) 20:23, 28 December 2025 (UTC)

"Wikidata also provides support to many other sites and services beyond just Wikimedia projects!"

Is there a list of these other sites and services and what support does Wikidata provide? Piecesofuk (talk) 19:31, 27 December 2025 (UTC)

This page showcase Wikidata use beyond Wikimedia Projects —Yamato Shiya^{大和 士也} (Talk • Contribs) 04:28, 28 December 2025 (UTC)

Thanks! Piecesofuk (talk) 04:58, 28 December 2025 (UTC)

Is it worth making the statement link to the page, then? Where is it located, by the way? --Matěj Suchánek (talk) 10:04, 31 December 2025 (UTC)

Im not sure what do you mean by statements in your question, but the page is located at Wikidata:For developers/Showcase. —Yamato Shiya^{大和 士也} (Talk • Contribs) 10:47, 31 December 2025 (UTC)

The statement in question is: Wikidata also provides support to many other sites and services beyond just Wikimedia projects!

I was wondering where one can find it (as @Piecesofuk did not indicate it). I could have probably searched for it myself, and although I didn't see it there, it's actually on the main page.

So now I wonder if the page should be linked to from the main page. --Matěj Suchánek (talk) 13:02, 31 December 2025 (UTC)

Ah, I see, in that case I agree. —Yamato Shiya^{大和 士也} (Talk • Contribs) 13:50, 31 December 2025 (UTC)

Constantine tramway

I am confused about how two entities relate to each other:

• Constantine tramway (Q2748642) - tram system (linked to Wikipedias)
• Constantine to Ali Mendjeli tram service (Q136684437) - tram service (used in frwiki for the route map)

Note: in my confusion I have added a label to one. Commander Keane (talk) 06:53, 29 December 2025 (UTC)

The French label in Q136684437 is "ligne 1" and there is Q136684437#P1671. en:Constantine tramway: "A second route, running to El Khroub via the airport, is currently planned". Peter James (talk) 13:26, 29 December 2025 (UTC)

Ahh, thanks - the French label was hidden for me. So the service is part of the system, and it looks like a line number has been assigned to the only line in anticipation of new services. I have updated the English label for Q136684437. Commander Keane (talk) 08:20, 30 December 2025 (UTC)

what is up with Wikidata and Scholia?

Scholia is not usable at the moment.. "Service load too high, please come back later" eg Kristina Gjerde Thanks, GerardM (talk) 14:39, 29 December 2025 (UTC)

There is a relevant issue open on GitHub: Scholia unavailability #2727 William Avery (talk) 17:10, 30 December 2025 (UTC)

Dank, GerardM (talk) 08:53, 31 December 2025 (UTC)

Wikidata weekly summary #712

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2025-12-29. Missed the previous one? See issue #711.

Discussions

• Open request for adminship: Ppolar bear - RfP scheduled to end after 3 January 2026 13:40 (UTC)
  • QubeCubeBot - Task/s: Continue import of Swedish Parliament documents inline with the modeling work in Wikidata:WikiProject Sweden/Swedish Riksdag documents.
  • AinaliBot 3 - Task/s: Continue import of Swedish Parliament documents inline with the modeling work in Wikidata:WikiProject Sweden/Swedish Riksdag documents.

Events

• This month's Scholia hackathon has moved Scholia closer to its planned switch to a QLever backend. Beta testers can assist by exploring the interim QLever-backed Scholia instance and reporting any issues.
• Upcoming events:
  • SWAT4HCLS 2026. Amsterdam, March 23-26, with a "Wikidata in healthcare and life sciences" session and Prof. Hannah Bast as one of the keynotes

Press, articles, blog posts, videos

• Videos:
  • (Indonesian) Introduction to Wikifunctions presented by NikolasKHF (Niko). In this session, Niko introduced Wikifunctions project, how to edit a function, how to add an implementation and test, and demonstrated them. This is the first Wikifunctions training in Indonesian. Slides are available on Commons.
  • (Indonesian) Wikidata for Academician presented by Wikimedia Indonesia's Data and Technology team. They introduced Wikimedia Indonesia, and then explained Wikidata, its underlying concepts and a glance to its history, how to add statements and references, how to query with Wikidata Query Services, Wikidata and its potential in research fields, Wikiprojects and Wikidata:For development resources. Slides are available on Commons.

Tool of the week

• WD-NearbyItems : browse Wikidata Items nearby
• Quizicle is a daily quiz/puzzle game that's not really a quiz and not really a puzzle. Deduce the answer from crossword-style clues with hot/cold feedback.

Newest properties and property proposals to review

• Newest General datatypes:
  • random page URL (link to random page or item on website)
  • specimen classifier (person who assigned the identification to a specimen)
  • collection date (date-time or interval during which a specimen or object was collected in the field)
  • land degradation (amount of land that is degraded by an object, mainly for infrastructure projects)
  • Hong Kong fire alarm level (Hong Kong fire alarm levels classification system)
  • page offset (difference between external page number printed on the work (P304) and the actual page in digital file (P7668))
  • logical implication (axiom or conjecture that this axiom or conjecture implies)
• Newest External identifiers: ‎survivalhorrors.com ID, ‎VGChartz ID, ‎Adventure Game Hotspot game ID, ‎BoomerShooterDB game ID, ‎Vandal game ID, GoFundMe fundraising ID, Adult Film Database director ID, S1 No.1 Style actress ID, ‎MetroidvaniaDB game ID, EAGER game ID, EAGER developer ID, ‎Games.cz game ID, ‎4gamer.net game ID, ‎GOG tag ID, ‎Yaba Sanshiro ID, ‎Games for Change directory ID, DLSite work ID, ‎DLSite person ID, ‎DLSite doujin circle ID, ‎Fight-A-Base game ID, ‎DeVuego game ID
• New General datatypes property proposals to review: Erdős Problem number (Erdős Problem number)
• New External identifier property proposals to review: PixelatedArcade genre ID, BRAHMS identifier, LegiStorm person ID, Game Boy Database game ID, NHK Archives Program ID, Wendingen object ID, Wendingen person ID, RetroCollect games ID, FIP.IT basketball player ID, Lenta.ru person ID, Polski Petersburg encyclopedia ID (Polish version)., Télérama film ID., Bercail ID, Panoramax picture ID, InterSportStats athlete ID, Before I Play game ID

You can comment on all open property proposals!

Did you know?

• Showcase Lexemes: turn (L3568) - English verb (tɜːrn) meaning "to rotate", "to change direction", or "to transform"

Development

• No development happened in the past week as the team are on holidays. Happy new year everyone!

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

• Add labels, in your own language(s), for the new properties listed above.
• Contribute to the showcase Item and Lexeme above.
• Govdirectory weekly focus country: Czech Republic
• Summarize your WikiProject's ongoing activities in one or two sentences.
• Help translate or proofread the interface and documentation pages, in your own language!
• Help merge identical items across Wikimedia projects.
• Help write the next summary!

· Previous issue · Full report · Unsubscribe . JosefAnthony talk ·MediaWiki message delivery (talk) 16:11, 29 December 2025 (UTC)

Merge request

Can you please merge The Surf House Byron Bay (Q130426019) and Byron Shire Council Chambers (Q137636527)? - Chris.sherlock2 (talk) 03:33, 30 December 2025 (UTC)

I think these two item are separate different concepts. The Surf House Byron Bay (Q130426019) is a hostel/hotel, located in a historic building. Byron Shire Council Chambers (Q137636527) is a historic building. So logically The Surf House Byron Bay (Q130426019) part of (P361) Byron Shire Council Chambers (Q137636527). You could modify statements instead. Change the instance of (P31) value to give clarification, one is a historic building, other is a hotel inside the historic building. —Yamato Shiya^{大和 士也} (Talk • Contribs) 04:40, 30 December 2025 (UTC)

End cause of Kasuga's pre-SUL username

I added Wikipedia:Unified login/Finalisation (Q13365854) as the end cause (P1534) of Kasuga (Q66447598)'s Wikimedia username (P4174). However, Wikipedia:Unified login/Finalisation (Q13365854) is not an occurrence (Q1190554), key event (Q2245405), etc. What should I do to resolve the error? 1F616EMO (talk) 03:45, 30 December 2025 (UTC)

A separate page needs to be created for either SUL finalisation or Single User Login as a concept, as it done for e.g. Wikipedia:Stub (Q4663261) and Stub (Q124303111). Circeus (talk) 02:11, 2 January 2026 (UTC)

New RfC: Notability policy reform

There is a new RfC to help improve the Notability policy waiting for your input: Wikidata:Requests for comment/Notability policy reform. Lydia Pintscher (WMDE) (talk) 13:45, 30 December 2025 (UTC)

Genre for Kandinsky's works of art

Hi, I am no expert, so I don't know which genre should be given for Kandinsky's works of art, when they are not completely abstract, e.g. Q137606594 or Q137603467. This property is required: An entity with Google Arts & Culture asset ID should also have a statement genre. Thanks, Yann (talk) 16:07, 30 December 2025 (UTC)

@Yann: genre (P136) is no exact science. See Wikidata:WikiProject sum of all paintings/Top genres for an overview. Sometimes it's provided in the source and sometimes it's obvious. When you get to the more recent works of art, it become harder. For when we really don't know, we have figurative art (Q1622217) (used on Study for the Cover of Der Blaue Reiter Almanach (Q137606594)) and for Lady Sitting on the Grass (Q137603467) I would say landscape painting (Q191163). Multichill (talk) 14:23, 1 January 2026 (UTC)

Template modernization

Per discussions here, may we update Template:Unblock, Template:Unblock declined and Template:Unblock granted to match current design languages? This entails 2 tasks: update the icons used in the templates, as well as make the templates display better under dark modes.

My rationales would be the same as those who filed the original proposal. And for technical issues (what icons to use etc.), my solutions are also the same. What we need to do is to figure out if they're suitable here for Wikidata, and if so, roll them out. 🐠 _{formerly U.T.} 04:02, 31 December 2025 (UTC)

What is the scope of Fandom article ID (P6262)

I recently did a revert removing this property from Jenin (Q374748) on the grounds that it linked to a wiki that is not about the entry in reality, but after saying the usage examples of the property I have been second guessing myself. Are links to creative writing wikis appropriate for this property? -- AccountimadetohidemyIP (talk) 07:43, 31 December 2025 (UTC)

Broadly you are asking whether we should have links to the representations of places in fiction, as all places diverge to a certain extent from reality. I think links should be stored under that fictional work using narrative location (P840) etc. And if the complete work is contained at a URL, then qualifiers to sub-URLs for elements of the work should be very selective. Otherwise we run the risk of conflating fiction with reality.

So for your example, a place in a alternate world described in a Fandom wiki, no for the place, and only within the work if its utterly key to the plot. Vicarage (talk) 08:16, 31 December 2025 (UTC)

Q25550691 vs Q137628541

I noticed Q137628541 was very recently split off from city hall (Q25550691). The distinction seems to be based on whether it concerns the administrative seat of a non-city municipality or of a city municipality, gemeentehuis and stadhuis respectively in Dutch. This would be analogous to distinguishing between town/municipal hall and city hall in English. Is this enough reason for separate entries? --HyperGaruda (talk) 08:25, 31 December 2025 (UTC)

@Mondo Courtesy ping (please do this yourself next time) Sjoerd de Bruin (talk) 08:46, 31 December 2025 (UTC)

@Sjoerddebruin Thanks for the ping. 🙂

@HyperGaruda On the Dutch Wikipedia it was pointed out by a very knowledgable colleague that there is a clear distinction between the two meanings, hence the separation. Now sure, one could argue that it's unneccesary, but then again, we also have things like Q543654 for German municipalities. I know it's not a one-on-one comparison, but I'm just trying to say that we do make distinctions for local usage. Mondo (talk) 10:19, 31 December 2025 (UTC)

Got it. Meanwhile, I've noticed the "partially coincident with" list of similar cases at city hall (Q25550691). I feel this is getting messy (particularly from a multi-language project point of view, like Commons's), but it is not a can of worms I am willing to open all the way at this point. @Mondo, the French hôtel de ville (Q15020931) looks like a neat way to make said distinction, perhaps you would like to complete Q137628541 based on that? --HyperGaruda (talk) 07:43, 1 January 2026 (UTC)

@Mondo: How similar is Q137628541 to town hall (Q112818750)? — Huntster (t @ c) 10:15, 1 January 2026 (UTC)

@HyperGaruda, Mondo: Maybe good to start with some background. Before the Netherlands had municipalities, we had cities ("stad"/"steden" until 1851). For the traditional cites (see list at nl:Lijst van Nederlandse plaatsen met stadsrechten) we say "stadhuis" (literal translation: city house) and for the others we say "gemeentehuis" (literal translation: municipal house) or "raadhuis" (literal translation: counsel house). Every stadhuis is a gemeentehuis, they're all together in nl:Categorie:Gemeentehuis in Nederland.

So Haarlem (Q9920) (a city) has Haarlem City Hall (Q2587792) and Amstelveen (Q9898) (not a city) has Q62397926

I would create an item for "gemeentehuis" (the one in the Netherlands) and update Q137628541 to be a subclass of that. Both should be updated to be part of the subclass tree. Multichill (talk) 10:12, 2 January 2026 (UTC)

Thanks for adding the background information. 🙂 There are a few exceptions, of course, such as Almere, which does have a stadhuis, even though it's not a traditional city. But other than that, it seems to be in line with what HT said on the Dutch Wikipedia, and I agree with making stadhuis a subclass. Mondo (talk) 10:19, 2 January 2026 (UTC)

Pairs of eyes needed: merge candidates

Would merge myself if not unsure:

• Alfredo Serri (Q131677709) – Alfredo Serri (Q43136972)
• George Aitken (Q112546491) – George Aitken (Q19414356)

More can be found Wikidata:Database reports/Same humans. --Matěj Suchánek (talk) 15:15, 31 December 2025 (UTC)

The Serri ones seem easy, since one have Wikipedia article and others not, so I am sure it is duplicate.

The Aitken ones is hard, they had 3 separate VIAF entry. The ISNI probably contains duplicate too.

There you go, thanks, I will check the database ^{Happy New Year 2026!}Yamato Shiya^{大和 士也} (Talk • Contribs) 05:56, 1 January 2026 (UTC)

End causes of war participation of KIA military personnel

"Pin" (Q137647203) and "Water" (Q137647204) were killed in action (Q210392) in the Russo-Ukrainian War (Q15860072). I am filling their end cause (P1534) of war participation. Which one, death (Q4) or killed in action (Q210392), should be used? 1F616EMO (talk) 17:47, 31 December 2025 (UTC)

Q23538 and Q112580028

Hi,

The existence of two separate items for the Equator (Earth) and the equator (geometric concept) has resulted in a "spaghetti mix" of wikilinks across different languages.

I propose swapping the current scopes of these items so that Q23538 is dedicated to Earth's equator and Q112580028 to the mathematical definition.

My reasoning is that the terrestrial equator was the original concept intended for description on Wikidata and represents the vast majority of existing sitelinks. As such, it should retain the lower item number (Q23538). Swapping the scopes will reflect this hierarchy, align with user expectations, and significantly improve data clarity.

We should therefore reassign the sitelinks to each item accordingly. Simon Villeneuve (talk) 18:20, 31 December 2025 (UTC)

equator (Q23538) existed earlier, and from the identifiers and properties, seem to represent earth equator, Earth's equator (Q112580028) is a (probably) duplicate, created at a later period, the interwiki links in it seems contain redirects. We could repurpose Earth's equator (Q112580028) for equator as mathematical concept. While I will try to move the interwiki links, could you (1) describe the concept more, and probable similar/same concept, since the mathematical equator you describe is really similar to diameter (Q37221), and (2) if indeed what you describe as mathematical equator is separate, stand alone concept, please provide external identifiers (page in Britannica, or Wolfram Alpha) that describe them as independent concept. Thanks. ^{Happy New Year 2026!}Yamato Shiya^{大和 士也} (Talk • Contribs) 05:34, 1 January 2026 (UTC)

Interesting, frwiki and ocwiki seems to have two separate article for equator as mathematical concept (and labelling them with paronym and synonym template) while enwiki, cswiki, skwiki, and the rest are putting earth equator inside equator concept/article. ^{Happy New Year 2026!}Yamato Shiya^{大和 士也} (Talk • Contribs) 05:45, 1 January 2026 (UTC)

For now, I removed the redirects on Earth's equator (Q112580028), the rest is ocwiki and frwiki. I do not know what should I do with them. Feel free to revert my edit if you see this wrong. ^{Happy New Year 2026!}Yamato Shiya^{大和 士也} (Talk • Contribs) 05:49, 1 January 2026 (UTC)

They don't have separate articles, one is a disambiguation page. The different article titles are because it has the same name as Ecuador (Q736) in those languages. Peter James (talk) 13:02, 1 January 2026 (UTC)

So do you have suggestion on what we should do? Delete the item since its only disambiguation page? Delete or merge?^{Happy New Year 2026!}Yamato Shiya^{大和 士也} (Talk • Contribs) 13:12, 1 January 2026 (UTC)

Q23538 and Q112580028 are not disambiguation pages, but the sitelinks don't prevent merging if they are about the same subject. Disambiguation pages are Q250035 and Q1209541; both are instances of Wikimedia disambiguation page (Q4167410). Q23538 was created for (and still is) Earth's equator, making Q112580028 a duplicate, but some uses (such as Q405#P2120) are for the concept, not the instance. Peter James (talk) 14:00, 1 January 2026 (UTC)

Ah, okay, I will try to merge equator (Q23538) and Earth's equator (Q112580028). For the rest of usage of equator (Q23538) in other items, such as what you point out in Moon (Q405) i.e. (Q405#P2120), I cannot investigate further, I am not that far in the subtlety of data modeling in Wikidata. Thanks. ^{Happy New Year 2026!}Yamato Shiya^{大和 士也} (Talk • Contribs) 14:28, 1 January 2026 (UTC)

@Yamato Shiya: Please wait until we have a clear plan. Many of the issues we are facing stem from acting too quickly in the past.
As I mentioned on the English Wikipedia, the "mathematical" concept is "the intersection of a sphere's surface with the plane perpendicular to the sphere's axis of rotation and midway between the poles". I am not sure where you saw a definition related to "diameter" in my previous comments.
Here is a breakdown of the current situation:
1. The enwiki article title is confusing; we will see what they decide regarding it, but that changes nothing about what we must do here.
Currently, the English and French descriptions of equator (Q23538) (at least) refer to the "mathematical" concept. If we follow my plan, these must be updated to reflect the Earth's equator.
2. On frwiki, the article fr:équateur terrestre concerns the Earth's equator. If we follow my plan, we should revert this move by Mykhal (talk • contribs • logs). In fact, I believe we should revert all edits made by this user on both items between February 19 and 20, 2025.
3. According to my plan, the P31 values of equator (Q23538) and Earth's equator (Q112580028) must be swapped. All other properties, sitelinks and linked items for both items must then be redistributed to the correct concept.
I hope this is clear. Please let me know if you have any questions regarding this proposal. Simon Villeneuve (talk) 17:46, 1 January 2026 (UTC)

There's no subclass of (P279) for either to be an instance of, statements say both are only instances. If not suitable for Q23538 it should be a new item, instead of repurposing Q112580028. Peter James (talk) 22:05, 1 January 2026 (UTC)

Oh, I dont follow the discussion on Enwiki, I read only from the description in Wikidata item. The issue is in Wikidata so I read what on Wikidata. The rest I agree with what @Peter James said. ^{Happy New Year 2026!}Yamato Shiya^{大和 士也} (Talk • Contribs) 00:34, 2 January 2026 (UTC)

It's really disputable. I'd say from Wikipedia-centric point of view it was originally mainly a glue for pages named just equator equivalents, mentioning often both concepts. From the Wikidata-centric point of view, the earliest description was closer to the more general concept. —Mykhal (talk) 12:59, 2 January 2026 (UTC)

Problem with P4276

It seems that P4276 doesn't work anymore. I suppose there were changes on that website but I'm unable to fix the problem. Thank you in advance if you can! TwoWings (talk) 10:52, 1 January 2026 (UTC)

Sadly, it appears that the website has been completely redone in favor of fully semantic URLs (e.g. https://www.cinematheque.qc.ca/fr/oeuvres/a-tout-prendre/ ), breaking every single link generated by the property. A new property must be proposed and every item relinked. Circeus (talk) 01:56, 2 January 2026 (UTC)

Please add property numbers in parentheses after the property names

When I go to https://en.wikipedia.org/wiki/Battle_of_Fucine_Lake and look in Preview at the Wikidata entities used in the page, I see "P625" listed. I wonder what P625 is. So I click through to the corresponding Wikidata item, Q4871069, and do a Find in my browser for "P625". No results. I recommend making Wikidata more understandable to visitors from other MediaWiki sites by providing the property number, perhaps in parentheses, along with the narrative name of the property. Something like "coordinate location (P625)" would be helpful. Jonesey95 (talk) 04:46, 2 January 2026 (UTC)

A simple request

Please add vi:Auchenorrhyncha to Q202890 and vi:Tiểu vùng của Brasil to Q682944. Thank you very much.~2026-24630 (talk) 05:21, 2 January 2026 (UTC)

 Done — Huntster (t @ c) 08:24, 2 January 2026 (UTC)