close
Jump to content

Wikidata:Project chat

Edit links
Add topic
Shortcuts: WD:PC, WD:CHAT, WD:?
From Wikidata
Latest comment: 8 hours ago by TSventon in topic Merge two Items
Edit
BERJAYA
 SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 7 days.

adding dates in different calendars

[edit]
Latest comment: 6 days ago3 comments3 people in discussion

Is there a canonical way to add a date (e.g., death date, birth date) in a calendar that is not Gregorian or Julian? If so, the https://www.wikidata.org/wiki/Help:Dates page should probably explain how to do that.

For example, hijrī (Islamic) years are lunar years, so a single hijrī year usually straddles two Gregorian/Julian years.

Scenarios:

  • how should a birth date for which the full hijrī date (year-month-day) is known be added?
  • How should a death date for which only the hijrī year is known be added? NB: every hijri year has its own wikidata item (e.g., 574 AH = https://www.wikidata.org/wiki/Q6026299), which states its start and end day in the julian/gregorian calendar.

Pverkind (talk) 09:02, 5 May 2026 (UTC)Reply

probably one should add the most specific grigorian date (e.g. decade) with qualifier refine date (P4241)="hijri date". Infovarius (talk) 16:03, 8 May 2026 (UTC)Reply
In East Asia including Japan, years with era name (Q256408) has been used. I always put Gregorian/Julian date with qualifier object named as (P1932), since refine date (P4241) wouldn't work well. For example, the date of the arrival of Christianity to Japan is 1549-08-15 in Julian and 22nd day of the 7th month in the Chinese calendar (Q839702) of Tenbun (Q1192853) 18th year in ours i.e. Kagoshima landing (Q60824598)point in time (P585)1549-08-15object named as (P1932)天文18年7月22日. I feel the use of object named as (P1932) is deviated, but it seems there are no alternatives, which actually I want. For straddling years, there are some examples of date with refine date (P4241)year-ending (Q336568). Mzaki (talk) 07:54, 12 May 2026 (UTC)Reply
[edit]
Latest comment: 6 days ago8 comments6 people in discussion

Hello everyone,

I'd like to share a tool I've been building: GapMap.wiki — a free, open-source index of knowledge gaps between Wikipedias, powered entirely by Wikidata.

What it does: You pick a source Wikipedia (e.g. English) and a target Wikipedia (e.g. Italian). GapMap shows you all the articles that exist in the source but are missing in the target, ranked by how many other Wikipedias already have them. If 50 languages have an article and yours doesn't, that's a significant gap.

How it uses Wikidata: The system periodically downloads the wb_items_per_site table from the Wikidata dumps. For each item, it counts the number of sitelinks and checks which wikis are present or absent. No SPARQL endpoint is hit at runtime — everything is pre-indexed locally. The data refreshes every ~3 days.

Example: Right now, there are over 6,000 Wikidata items with 30+ sitelinks that have an English Wikipedia article but no Italian one. Many of these are well-established topics that could benefit readers in the target language.

What I'm looking for:

  • Feedback on whether this is useful for the editing community
  • Suggestions on additional signals I could pull from Wikidata (e.g. instance-of / subclass-of for topic filtering)
  • Any concerns about how the tool uses Wikidata data

The project is open source: GitHub. The methodology is transparent — no black boxes, just cross-referencing public sitelink data.

I'm happy to answer any questions. Thanks for your time!

— ~2026-27444-29 (talk) 01:47, 6 May 2026 (UTC)Reply

Nice work! Seems like not just a good way to identify 'missing' articles, but also a way to identify missing interwiki links on Wikidata to Wikipedia articles that already exist.
That said, if I do Japanese (ja) to English (en), I see two main issues: Firstly, most of the entries are in the Module namespace. It would be good to (be able to) filter to just the main namespace. Secondly, the links to the English Wikipedia uses the Japanese name. If I'm creating an article on the English Wikipedia, it needs to have an English title. So it should probably use the English label if it exists. Yirba (talk) 16:16, 6 May 2026 (UTC)Reply
Thanks for the feedback! this is the first version ans has been online only for a few days, i was actually waiting to get some feedback from the community before making any change! can you elaborate on the japanese-english problem ? Wikigapmap (talk) 19:10, 11 May 2026 (UTC)Reply
@Yirba I understand the two issues now:
  1. Namespace filtering — You're right, Module: and other non-article namespaces shouldn't appear. I've already added an "Articles only" filter in the latest update that excludes non-mainspace entries. Could you check if the issue persists?
  2. English labels — This is a great point. Currently the tool displays the Wikidata label in the source language. I'll work on fetching the label in the target language when available, so that ja→en results show the English name. This will be in the next update.
Also, good observation about interwiki links — that's an unintended but useful side effect! Wikigapmap (talk) 22:13, 11 May 2026 (UTC)Reply
Two things: Bad contrast, grey letters on black are not comfortable combination for reading. And, please, add more languages - why is there danish with 314k articles on Wikipedia and missing czech with 590k articles? JAn Dudík (talk) 10:50, 11 May 2026 (UTC)Reply
@JAn Dudík: Thanks for the feedback!
  1. Contrast — You're right, I've already improved the color scheme in today's update. Let me know if it's better now.
  2. Czech — Good news: Czech (cs) has been added in the latest update along with other languages (now 56 total). It should be available now.
Wikigapmap (talk) 22:14, 11 May 2026 (UTC)Reply
WARNING about possible security problems with above. See: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#c-Nux-20260512133400-Wikigapmap-20260511230900 Nux (talk) 13:36, 12 May 2026 (UTC)Reply
See also mine very similar tool, written many years ago for creating needed articles lists for ruwiki: https://mbh.toolforge.org/pages-wo-iwiki . @JAn Dudík my tool could process any language. MBH 14:05, 12 May 2026 (UTC)Reply

Low-quality AI images of Basque mythological subjects

[edit]
Latest comment: 6 days ago106 comments8 people in discussion

There are a large number of very poor quality (i.e. obviously misgenerated) AI images used in items about Basque mythology, prompted and most likely added user:Theklan. When I remove them for being very low quality they are almost always reverted by Theklan and user:Iñaki LL. Examples of this situation include Q12269104 Q2894192 Q3313610 Q3148627 Q12265082 Q12254541 Q743397 Q12268145 and Q2582586. There are frequent complaints from these users about me nominating these files for deletion on Commons shortly after removing them but I think that is irrelevant to the issue at hand— that these should not be used on Wikidata. I was recommended to start a generalized thread on this issue by user:Yamato Shiya on the admin’s noticeboard. Dronebogus (talk) 02:27, 10 May 2026 (UTC)Reply

Additionally I definitely know Urtzi (Q743397) isn’t even accurate because it’s not even known for certain such a deity existed. There is no factual basis for the representation. Others could easily have similar problems. Dronebogus (talk) 02:43, 10 May 2026 (UTC)Reply
Indeed, the deities don't exist. That's why we need artistical representations of those. We could get rid of all images of Jesus or the Christian God, because those are not real images, but images generated by someone, based on their assumptions. The fact that you don't like them is not an argument for deletion. You claim those to be "obviously misgenerated", but I don't understand how you have expertise on Basque mythology to claim that the items you are trying to deface are wrongly represented. Because is not that you don't like the image of !743397, is that you are systematically deleting all the images from here so you can claim at Commons that those are not in use, which is false because they were. And I would understand that you wouldn't like me to create an image of an hindu deity and change it across all languages. Here you are acting as external judge of something that only affects a community, and thinking that you can decide over them. Theklan (talk) 06:47, 10 May 2026 (UTC)Reply
You are missing the point; I don’t mean deities literally, physically exist in the real world; I mean from a metaphysical perspective the idea of a sky god named Urtzi could just be a modern misinterpretation. The image is not based on any mythological sources because they presumably do not exist, unlike the well-developed bodies of legend and accepted visual language for, say, Vishnu or Aphrodite. Dronebogus (talk) 07:31, 10 May 2026 (UTC)Reply
You are using lots of different points, so it is easy to think that the others are not answering to your points. However, I will try to explain you why I think you are wrong here. Indeed, you point correclty that Urtzi could be a misinterpretation, but calling it modern would be complex, as nearly all of the Basque mythology and folklore is modern, and in some cases contemporary. Urtzi is different, there are no modern tales, but there are some ancient clues that can be followed:
  • First, we have that the old vasconic translation for the Dies Joves (Day of Jupiter, being Jupiter Dieus Pater, Father God) as ortzeguna, literally "day of Ortzi" (Basque Language Academy). So when the Germanic peoples translated it for Thor's Day, Basque went with Ortzi's day.
  • There are toponyms named after Ortzi, for example Ortzantzurieta, near the place where Aymeric Picaud wrote that the word for "God" waas "Ortzi".
  • Many of the things that appear in the sky are named after Ortzi. Notably, ortzadar, literally "the horn of Ortzi" which means "rainbow".
Could it be a misinterpretation of the sources, where the Basques didn't have any God named Ortzi? Indeed, it could be. It could just be that "Ortzi" means "sky", and that's it. But we can't decide if that's the case, because we have a good amount of research saying that it could be. Other intrepretations suggest that Ortzi was just the Basque name of the Christian God, and that another name was "-in", because many metereological events have double names with "ortzi" or "in". Who knows. And, as we can't decide that, what would a good representation of that God be?A good mix of Christian God (the Lord in the Heavens) and the main element associated to Ortzi, the rainbow. And that's exactly what the image is representing. Could it be another way? Sure. Indeed, it could even be a misunderstanding. But if we look to modern representations of Ortzi/Urtzi, we will find a mix of Christian like elements, Thor-like elements (more on that soon) and Heaven related elements. The image, then, is as accurate as it can be.
And Why do I mention Thor? Well, not only because Thor's Day and Ortzi's Day are the same thing, but because how to represent Thor is an interesting topic on folk reasearch. I suggest you to read "How Thor lost his thunder: The changing faces of an old Norse god", an interesting book by Declan Taggart about modern representation of old myths and cultural change associated to that. I read it when I was creating these images, because documentation matters. Theklan (talk) 12:47, 10 May 2026 (UTC)Reply
And at the end of the day, accurate or no, the image is still unacceptably poor. I assume it is supposed to be an anthropomorphic deity, but it doesn’t really look like anything recognizable. Dronebogus (talk) 00:56, 11 May 2026 (UTC)Reply
Its basically a deadlock situation, that could be solved by consensus, since poor or not is a matter of subjective interpretation on artistic license. The fact that the image is being used in Euskala Wikipedia, meant some people, the natives who have more understanding on their culture, hold their consensus that the image is notable. And to kick that images from Wikidata would meant that we deny that consensus. Which are in fact far away from the spirit of Wikidata as the repository for sum of all knowledge. Yamato~kun (Talk • Contribs) 01:12, 11 May 2026 (UTC)Reply
This is a little bit of goalposting, because the reasons for deletion are moved from: shouldn't be illustrated to the illustration is not correct to the quality is poor. You ask for the being to be anthropomorphic, what it is, but I'm sure that if it had a completely clear face, you would argue that it should be made of clouds. Your main point is that you don't want anything created with AI (you have even nominated for deletion images that were focus-enhanced using AI), so you later find arguments to defend that. And I think that's not a constructive way of having a discussion we actually must have. Theklan (talk) 05:41, 11 May 2026 (UTC)Reply
I replaced the AI image in Q3313610 with a historical sculpture. Dronebogus (talk) 06:14, 10 May 2026 (UTC)Reply
Another example: Q3403498 Dronebogus (talk) 06:17, 10 May 2026 (UTC)Reply
Q12262894 Dronebogus (talk) 06:29, 10 May 2026 (UTC)Reply
What is the problem exactly with this representation of Makilakixki? Theklan (talk) 06:47, 10 May 2026 (UTC)Reply
The donkey and boy are very poorly generated. Dronebogus (talk) 07:33, 10 May 2026 (UTC)Reply
If you see a boy, a stick and a donkey, then the image has the needed elements. Theklan (talk) 12:47, 10 May 2026 (UTC)Reply
Absolutely not. Secretlondon (talk) 16:49, 11 May 2026 (UTC)Reply
Could you explain why is it "very poor quality" moreover on "i.e. obviously misgenerated"? Does it have mischaracterization, or not faithful to the existing description on the literatures? Or its just because it was created by "AI"?
Also, I would recommend you to stop editing any image (P18) statements on any items for now to avoid more disruptions. At least until more of the community participated in this discussion. Yamato~kun (Talk • Contribs) 07:15, 10 May 2026 (UTC)Reply
Q3278064’s image is clearly just a mangled face typical of early AI images. I seriously doubt this is a deliberate attempt and rendering some canonical feature of this mythical being. File:Itsas lamina (euskal mitologia) - Midjourney AI bertsioa.png isn’t used on Wikidata (thankfully), but is supposedly a representation of Q2577796; compare the human and AI illustrations and tell me if there is even a vague resemblance between what the latter is trying to represent and what the drawings and photos depict. Q3148627 uses the worst of three visually incoherent, malformed depictions of women in Commons:Category:Ilazki by Midjourney. Bad faces and a general lack of recognizable figures and objects pervade these images. Dronebogus (talk) 07:47, 10 May 2026 (UTC)Reply
You are wrong, again. Itsas lamina is not Lamia (Q2577796), but something more similar to a mermaid. They are two different beings, and that's why the representations are different. Lamia (Q2577796) lives in the woods, near a river and a cave, has duck feet and is always combing her hair. Itsas lamina lives in the sea, is half fish half woman, and emerges from the water. Also, Ilargi (Q3148627) shouldn't have a face, is the godly representation of the Moon. Why should an easily recognized face be better than a non recognizable figure? And if so, what kind of face should she have? Theklan (talk) 12:52, 10 May 2026 (UTC)Reply
Is there actually an established image of what Ilargi looks like or are you just making up your own interpretation based on the likely scarce data available? Dronebogus (talk) 01:01, 11 May 2026 (UTC)Reply
Moon. Female. Theklan (talk) 05:42, 11 May 2026 (UTC)Reply
Is that really enough to build an illustration off of, no matter the medium? We should be wary of our original research and artistic license resulting in w:wp:citogenesis Dronebogus (talk) 06:58, 11 May 2026 (UTC)Reply
If I paint an image of a woman with moon head myself would you consider it a better replacement? Theklan (talk) 08:25, 11 May 2026 (UTC)Reply
I’d consider it a less bad replacement. Does the goddess actually have a moon for a head or are you just adding that because reasons? Dronebogus (talk) 08:34, 11 May 2026 (UTC)Reply
The goddess actually doesn't exist. Theklan (talk) 08:55, 11 May 2026 (UTC)Reply
You know I actually mean “is the goddess traditionally described or depicted with a moon for a head?” This is a “white houses don’t talk” situation— it is universally understood that if you say “the White House said this”, you mean someone in the White House staff, or the US President, said it. Similarly if I ask “does Captain America have a shield?” The correct answer would be “yes”, not “Captain America doesn’t exist”, because I’m really asking if he is usually depicted with one. Dronebogus (talk) 08:59, 11 May 2026 (UTC)Reply
You are enclosed in some depiction styles that don't fit here. What we know about Ilazki is that, according to the oral testimonies, was recorded by Barandiaran. It's very short: Ilargi o Ilazki, the Moon, it's feminine. These characters haven't been depicted until now, so asking if traditionally did have this or that thing is an absurd question here. Ilazki is the moon, the representation of the moon, and it's feminine. That's it. How has it been depicted in books by illustrators? I don't have a bunch to show to you, but you can get an idea from non AI generated images: https://euskalmitologia.com/my-product/ilargi/ or https://www.visitgorliz.eus/eguzki-ilargi-eta-ortzi/. I could search for more, but I can't upload here because of copyright issues. Theklan (talk) 13:08, 11 May 2026 (UTC)Reply
We want statues etc, not someone's interpretation. Secretlondon (talk) 12:47, 11 May 2026 (UTC)Reply
Statues, etc... are someone's interpretation. By definition. Theklan (talk) 13:09, 11 May 2026 (UTC)Reply
But someone who is not an editor. Secretlondon (talk) 16:50, 11 May 2026 (UTC)Reply
So you are saying that illustrators can't be wikimedians? That if anyone is creating something, they can't upload it to Commons? Theklan (talk) 16:53, 11 May 2026 (UTC)Reply
If you are notable, maybe. AI slop absolutely doesn't count. Secretlondon (talk) 22:15, 11 May 2026 (UTC)Reply
We have thousands of images, illustrations and simple drawings made by wikimedians. Should we delete all of those because the people doing those are wikimedians? It's a simple question. Theklan (talk) 05:42, 12 May 2026 (UTC)Reply
The crux of this dispute seems to be the fact that a bunch of wikis transclude these wikidata items in place of local infoboxes. Therefore my good-faith removal of what I perceive to be a low-quality image comes across as a mass removal of content across multiple language editions I don’t edit. Wikidata doesn’t seem to have an equivalent of commons:INUSE so you can’t really complain if a data item you use suddenly changes in a way you don’t like. I would appreciate it if user:Theklan (and anyone else upset by my removals) just inserted any AI images they want to use directly into the articles on relevant language editions and didn’t try to re-insert them into Wikidata items. Dronebogus (talk) 08:18, 10 May 2026 (UTC)Reply
Populationg infoboxes from Wikidata is not something that I invented, it's one of the core missions of Wikidata. From Wikidata:Introduction:
  • Support for Wikimedia wikis. Wikidata assists Wikipedia with more easily maintainable information boxes and links to other languages, thus reducing editing workload while improving quality. Updates in one language are made available to all other languages.
It was the core idea of Wikidata Phase II and it has been promoted many times (m:Learning_patterns/Using_Wikidata_on_Wikipedia_infoboxes as an example).
So yes, removing content from Wikidata changes the representation in some Wikipedias, because that's working as intended. Theklan (talk) 13:02, 10 May 2026 (UTC)Reply
I will try to summarize here my view on all the chat contributions above in order not to scatter too much the discussion. Some views of mine have been dealt with above by @Theklan.
My first point of concern is reporting me with little to no cause. Also the catch-all approach by Dronebogus to the AI generated pictures here discussed is conspicuous, clearly not helpful. You may pinpoint specific problems or contradictory formal aspects in a given picture, that is positive action. Generic dismissive approaches come across as noise and sweeping statements based on perception.
I am no expert on religion or mythology, but I would say that depictions of deities in other religions or mythologies are the product of a historic build-up, i.e. later depictions refer to earlier depictions, but earliest descriptions of them are vague, they tend to represent a story and/or a concept.
Along these lines, I found illustrative and enlightening the images generated by AI that I checked out, they are both functional and operative for the readers to grasp the conceptual and formal aspects of the characters depicted. It does not make any sense discussing regular physical details if they are not overtly contradictory or out of place.
I am no expert on Basque mythology, but have published something on history, and have read quite a lot on the subject in question. I support the views on ortzi noted by Theklan above. Besides other points explained, it is generally accepted that ost/ortz means sky or heaven and that Ostegun equals English language Thursday.
Technology does not always deliver optimal results, since it is always improving, but that is inherent to the whole Wikipedia/Wikimedia concept. Iñaki LL (talk) 21:41, 10 May 2026 (UTC)Reply
I reported you using the vandalism template because there isn’t really a general board for user conduct. That was a mistake born of inexperience with Wikidata’s internal processes and I apologize. Dronebogus (talk) 01:03, 11 May 2026 (UTC)Reply
At this point it’s pretty clear that the differences of opinion here are intractable. My advice is that Theklan and any other interested parties find, request or commission superior works from actual human artists to replace the AI images. At the absolute minimum they should at least replace them with improved AI images. Dronebogus (talk) 01:08, 11 May 2026 (UTC)Reply
If you argued it so, then until such images are available, we use the currently available ones, however ugly other assessed it, or until the community hold consensus that such image is not notable or not appropriate and remove them, from both Wikimedia Commons and Wikipedia and Wikidata. And since you mention your inexperience in Wikidata, might I suggest to read Wikidata Notability Criteria, it could be derived into understanding such nature of the notability of items linked to Wikidata.
Until then, I would suggest also you to let it slide for a moment, and contribute to other sides of Wikidata. I receive some advice that my writing has condescending tone to it and I retracted them. I apologize for this mistake. Yamato~kun (Talk • Contribs) 01:19, 11 May 2026 (UTC)Reply
AI images are worse than no image. We should not be using them at all because they pose copyright issues–our content is freely licensed but more often than not, the models are trained with non-free images. Also, they are theft from real artists. Jasper Deng (talk) 07:00, 11 May 2026 (UTC)Reply
My thoughts exactly, especially when the subject is some mythological entity we barely know anything about such that we can barely come of with a reliable description of it. Double especially when the image is exceptionally poor even by AI standards due to being about four years old, when the medium was just starting to produce semi-passable results. Dronebogus (talk) 07:04, 11 May 2026 (UTC)Reply
I'd like to also add that AI-generated images are a gross misinformation liability, and are a direct vector for enshittification, especially as Google often pulls from our database for images of subjects. They should be outright banned except when they are the official logo of an organization, and even then should be limited to the most authoritative cases. Jasper Deng (talk) 07:09, 11 May 2026 (UTC)Reply
Yes - if we do not have an historical image, a statue or an image from an old book then we should have no image rather than someone's invention. Secretlondon (talk) 12:49, 11 May 2026 (UTC)Reply
An statue or an image from an old book is someone's invention. Any artistic representation of any non-existing object is someone's invention. Theklan (talk) 13:10, 11 May 2026 (UTC)Reply
Your invention has no worth, unlike one from a book, where we can say it is the interpretation of author X, or from the Blah museum, or similar. Secretlondon (talk) 16:52, 11 May 2026 (UTC)Reply
The worth is given by the Wikipedia community which used those. Theklan (talk) 16:53, 11 May 2026 (UTC)Reply
The copyright issue should be discussed in Commons, not on Wikidata. At the same time, it can't be argued that the imames should be better and that they shouldn't train on copyrighted art. Both arguments can't coexist at the same time. Theklan (talk) 07:45, 11 May 2026 (UTC)Reply
No. We are responsible for our content's compliance with copyright laws, not Commons, so that very much is an issue to discuss here. Because they are inherently copyright violations, unless the model is entirely trained on free images (which all current models are not), AI-generated images are inherently incompatible with the license under which we release our content. That's non-negotiable and not open to challenging. We could and should codify this better, but whether this is true or not is not up for debate. Also, At the same time, it can't be argued that the imames should be better and that they shouldn't train on copyrighted art. is a patently false statement. When an actual, informed, human artist draws something better, both issues are avoided. Jasper Deng (talk) 07:51, 11 May 2026 (UTC)Reply
Can you point me to where we claim that we have to check the images from Commons and their license again in Wikidata? I honestly can't find that. Theklan (talk) 08:07, 11 May 2026 (UTC)Reply
That's an implicit requirement of our license. We cannot release into the public domain anything we do not have clear permission to do so with. Jasper Deng (talk) 08:08, 11 May 2026 (UTC)Reply
Sorry, but not everything linked from Wikidata is in the public domain. Theklan (talk) 08:26, 11 May 2026 (UTC)Reply
Yes it is, per CC0, aside from trademarks like the Wikidata logo itself. Even this discussion is released under CC-BY-SA 4.0–not something we can release non-free images under either. Jasper Deng (talk) 08:28, 11 May 2026 (UTC)Reply
CC =/= public domain; arguing about licensing is a distraction from the issue at hand anyway. Dronebogus (talk) 08:32, 11 May 2026 (UTC)Reply
CC0 basically is. Read [1]. All items and properties are licensed under it. Jasper Deng (talk) 08:34, 11 May 2026 (UTC)Reply
I know what CC0 is. But images are not all CC0. This is once again a strange tangent that isn’t particularly relevant to AI images. Dronebogus (talk) 08:35, 11 May 2026 (UTC)Reply
You can't include them in documents like items that are CC0. Also, this is the only binding policy reason to remove the images without enacting a new policy, as much as I hate them. Jasper Deng (talk) 08:37, 11 May 2026 (UTC)Reply
But aren’t many images used on Wikidata under licenses that aren’t CC0, PD, or PD-equivalent? I’m confused. Dronebogus (talk) 08:39, 11 May 2026 (UTC)Reply
It's a gray area when it comes to CC-BY-SA, in which case it is argued that the link to Commons is the attribution needed. But it's a bright line violation to have non-free images at all on Wikidata or Commons. Jasper Deng (talk) 08:42, 11 May 2026 (UTC)Reply
There are no unfree images on Wikidata if they are hosted on Commons with valid, acceptable, accurate licenses. AI images are allowed on Commons because they are currently accepted as being PD everywhere except Hong Kong and the UK. It is a valid concern that they may eventually be declared copyright violations in other jurisdictions; but it is not a valid concern that they are currently unfree, because they aren’t. Dronebogus (talk) 08:45, 11 May 2026 (UTC)Reply
That would be the case if the models were not trained on non-free images. What you refer to pertains to whether the images themselves are subject to copyright as independent works; however, please read the section on copyrights of the authors of the works used for training. Right now, it does say they're possibly copyright violations and there is active litigation in United States courts over this matter, so it's far from a settled issue. Unless WMF legal counsel advises otherwise, we have to take the cautious route. Jasper Deng (talk) 08:49, 11 May 2026 (UTC)Reply
I agree that we should not tolerate AI images for this exact reason, but neither Commons nor Wikidata (nor even English Wikipedia, which otherwise has one of the strictest policies against AI generated content) has any policy that AI images should automatically be considered copyright violations. I see nothing wrong with such a policy, besides losing a few hundred files in legitimate use, but you would have to propose it before suggesting we apply it here. Dronebogus (talk) 08:55, 11 May 2026 (UTC)Reply
Just because they are too permissive doesn't mean we can be. Unless and until WMF legal counsel advises otherwise we cannot assume the legal risk of this copyright problem. Jasper Deng (talk) 09:01, 11 May 2026 (UTC)Reply
Again, that's an issue to discuss in Commons, not in Wikidata. Theklan (talk) 09:04, 11 May 2026 (UTC)Reply
Nope. Wikidata is its own project, with its own licensing requirement that we are responsible for complying with, not Commons. Even if it is under discussion on Commons, the right course of action is always to err on the side of caution on copyright issues so you are not winning this argument. Jasper Deng (talk) 09:06, 11 May 2026 (UTC)Reply
Again, the images linked here are not CC0. The link to that data is what is CC0, not the object itself. Theklan (talk) 09:07, 11 May 2026 (UTC)Reply
@Jasper Deng: this is not a discussion about copyright. You really need to drop this angle because it’s not working and doesn’t make any sense. I’m saying this as someone who otherwise agrees with you here. Dronebogus (talk) 09:08, 11 May 2026 (UTC)Reply
You don't get to pick that, sorry. Everything I've said has no legal wiggle room. I do welcome another RfC to ban AI slop on Wikidata, but in the meantime the stricter interpretation of copyright always prevails in the absence of more specific legal guidance (which none of us are qualified to provide). Jasper Deng (talk) 09:13, 11 May 2026 (UTC)Reply
Again, Wikidata can host links to copyrighted materials. We do host it. What is CC0 is the database itself, the data, not the final object represented in that data. If you don't think so, you can open an RfC to forbid all images not under CC0 or PD license in every item, and see the result. Theklan (talk) 09:14, 11 May 2026 (UTC)Reply
Are you a lawyer? A legal scholar? Because you are speaking with a degree of confidence on this I’m not sure even Wikimedia Legal has. Dronebogus (talk) 09:15, 11 May 2026 (UTC)Reply
Once again, this needs to be a policy before you can treat it as such. Right now you are simply derailing this discussion with a personal interpretation that doesn’t reflect the actual status quo Dronebogus (talk) 09:04, 11 May 2026 (UTC)Reply
This is a simple matter of copyright law. Unless and until WMF legal counsel advises otherwise, we cannot put any possible copyright liability on their shoulders. Jasper Deng (talk) 09:07, 11 May 2026 (UTC)Reply
WMF legal is not going to advise you on something that it's in the footer of every Wikidata page. Theklan (talk) 13:10, 11 May 2026 (UTC)Reply
CC0 is public domain. Wikipedia is not CC0, nor the content from Commons. Sorry, but the licenses of images are not in public domain, are under their respective licenses and discussed in Commons, not here. Theklan (talk) 08:56, 11 May 2026 (UTC)Reply
Wrong. Wikidata specifically uses CC0. Please see the notice under Special:CreateItem. Content included in an item is not above this release requirement. Jasper Deng (talk) 09:00, 11 May 2026 (UTC)Reply
If it uses CC0 for all content then that policy simply is not enforced, because a plurality if not majority of data items with images use non-CC0/PD/equivalent free licenses. Wikimedia almost universally uses just about any free license that isn’t non-commercial or no-derivative-works; Wikidata bucking this expected trend is news to me. Dronebogus (talk) 09:03, 11 May 2026 (UTC)Reply
There's simply no legal wiggle room around dubious-freeness content like the images in question here. Free images are another matter. Jasper Deng (talk) 09:04, 11 May 2026 (UTC)Reply
Do files used on Wikidata need to be CC0 or PD? Because if so that policy needs to be explicitly stated and enforced. Dronebogus (talk) 09:06, 11 May 2026 (UTC)Reply
This is a corollary of the license, as I have stated repeatedly. Don't make me repeat myself more than needed. Jasper Deng (talk) 09:07, 11 May 2026 (UTC)Reply
No, it's not. Theklan (talk) 09:08, 11 May 2026 (UTC)Reply
Yes it is. Your only option is a broader RfC on this matter, but you will need to craft it in a strictly nonpartisan fashion; in the meantime, the stricter interpretation prevails. Jasper Deng (talk) 09:09, 11 May 2026 (UTC)Reply
Except it doesn’t. You just seem to think it does. Practice says otherwise. Dronebogus (talk) 09:10, 11 May 2026 (UTC)Reply
Point to where practice overrides any copyright law in the United States, whose laws the WMF servers are bound by. Jasper Deng (talk) 09:14, 11 May 2026 (UTC)Reply
So you are claiming the answer is yes? Dronebogus (talk) 09:09, 11 May 2026 (UTC)Reply
To your statement, no. There's no wiggle room around releasing any non-free content under CC0. Free content is another thing. Jasper Deng (talk) 09:10, 11 May 2026 (UTC)Reply
So, under your interpretation, Wikidata can't have an image in Douglas Adams (Q42) because that image is not CC0? Because that's what you are arguing here. Theklan (talk) 09:20, 11 May 2026 (UTC)Reply
That's a freely licensed image that technically does not belong there, yes. But non-free images are an absolute no; free images are a red herring. Jasper Deng (talk) 09:21, 11 May 2026 (UTC)Reply
Wikidata uses CC0 for data, not for the wikiprojects linked. Commons is not CC0, and nearly all the images we are adding here are not PD nor CC0. Theklan (talk) 09:05, 11 May 2026 (UTC)Reply
Images count as data and get displayed on our website, and are thus subject to the same licensing requirement. Even if it were CC-BY-SA like other projects, non-free AI-generated images are an unambiguous no-no. Jasper Deng (talk) 09:08, 11 May 2026 (UTC)Reply
No. Images don't count as data. Links count as data. Theklan (talk) 09:15, 11 May 2026 (UTC)Reply
You would have a point if we did not display the images on the item pages themselves. But because we do, you don't. Jasper Deng (talk) 09:17, 11 May 2026 (UTC)Reply
So we can't show any image that is not under CC0 or PD? Is that what you are claiming? Theklan (talk) 09:21, 11 May 2026 (UTC)Reply
Technically, no. But the issue is much more pressing with anything non-free. Jasper Deng (talk) 09:22, 11 May 2026 (UTC)Reply
Please, open an RfC on that, because I think you are completely wrong. But don't take my point on that as given. Theklan (talk) 09:29, 11 May 2026 (UTC)Reply
These should not be used here and should be deleted at Commons. The only AI media we should be using are media about AI itself or that are historically notable (like when the president of the United States is a Facebook troll who posts racist garbage online, thereby making it historically significant). ―Justin (koavf)❤T☮C☺M☯ 07:09, 11 May 2026 (UTC)Reply
This whole discussion is vey long and weird. I don't really like AI but if there is no alternative and if Commons has no problem hosting it (which is aminly a Commons problem), then I don't see any problem having a link to these images on Wikidata. Also, if one want to hunt AI, it should be done generally, not just on a few random items and a RFC is probably needed. @Jasper Deng: your whole copyright understanding is unusual and very concerning ; at the bottom of every Wikidata pages, there is a clear indication starting with "All structured data from the main, Property, Lexeme, and EntitySchema namespaces is available under the Creative Commons CC0 License" (emphasis on : "All structured data"). Cheers, VIGNERON (talk) 09:32, 11 May 2026 (UTC)Reply
Other content still has to be licensed freely so non-free content is a clear absolute no. I don't get why anyone thinks that is controversial. We also do not in any way need to inherit any potential copyright violations on Commons itself. Jasper Deng (talk) 09:34, 11 May 2026 (UTC)Reply
If you want, I can explain you why this is controversial:
  1. Because the CC0 license is only about data, not about the items linked. For example, we add OpenStreetMap based tiles, which are not PD or CC0. Or we add links to propietary databases. Or to Wikipedia items, which are not CC0, but normally cc-by-sa-4.0. The data itself and the content of that data point are onthologically different.
  2. Because following that discussion, AI images are not currently defined as copyrightable (currently, because that might change in the future), and are by definition PD in most of the jurisdictions, so under that logic AI images should be accepted while CC-BY-SA-4.0 or equivalent images shouldn't, which is contradictory.
The discussion here is about using those images in Wikidata items, not about the copyright. Is something that Dronebogus is trying to correctly frame. We disagree on the objects representation themselves, but the copyright status of those images, in any case, should be discussed in Commons. And there, maybe, there should be other points where we even agree. Theklan (talk) 09:41, 11 May 2026 (UTC)Reply
I just emailed the legal team for advice on this matter, but you are still incorrect that this is only a matter of links. I even agree that links are fine. But the Wikidata website uses images and so this is not a matter of links. I will not comment until legal has a chance to opine. Jasper Deng (talk) 09:49, 11 May 2026 (UTC)Reply
Keep in mind too that we do more than just link to the images. Honestly, a link would be perfectly fine. But our website displays the images and that's clear and unambiguous usage of the images, so is subject to licensing. We can move this conversation to an RfC on condition that the images in question remain out of the items pending its resolution, but really, what we should be doing is contacting the WMF legal team and asking for their guidance. Anything they say supersedes what I say. Jasper Deng (talk) 09:38, 11 May 2026 (UTC)Reply
An image of a mythological creature is understood in context. It is X deity as portrayed by the creators of a statue in the 13th century, or in a painting by Y from 1392. It is not as described by a random user and made by an AI prompt. Even a painting or drawing made by a random user isn't okay. It's not your truth. This is original research. Secretlondon (talk) 12:53, 11 May 2026 (UTC)Reply
Commons is not against original research. And every author who paints something is doing own interpretations. Yes, even your prefered deity. Theklan (talk) 13:11, 11 May 2026 (UTC)Reply
Just because original research is tolerated on Commons (and I guess Wikidata, for that matter) doesn’t mean it should be encouraged. At the very least you should use and cite sources for files, instead of relying on “just trust me” or “my source is I made it up!” Dronebogus (talk) 14:52, 11 May 2026 (UTC)Reply
I don't want this to be ad-Hominem, but I can see some artworks uploaded by yourself at your user page that don't have any source. Creative works don't need references, in any case it should be the article at Wikipedia which can dismiss those for not being reliable. Theklan (talk) 14:56, 11 May 2026 (UTC)Reply
Most of those are really the sort of things that need sources. However infographics like File:Linguistic makeup of the Petit Prince Collection.png are sourced, as was File:Bupuro-chan.png Dronebogus (talk) 15:12, 11 May 2026 (UTC)Reply
Oh, the irony: en:Talk:Menhera#image. Theklan (talk) 15:27, 11 May 2026 (UTC)Reply
That’s why I added the sourcing. There is no irony here. Dronebogus (talk) 15:35, 11 May 2026 (UTC)Reply
Yes, the irony is that the same arguments you are making for deleting this items were used to delete your artwork. But you defended those, and you were right to do that. Theklan (talk) 15:39, 11 May 2026 (UTC)Reply

“Sexualized nudity, erotica or ecchi“ (Q138829111) in the Wikimedia Commons content descriptor system (Q138829103)

[edit]
Latest comment: 5 days ago7 comments4 people in discussion

Compared to the other categories (which are basically just “sex” and “gore”) this seems like a problematic outlier. Most of the examples on Commons so far do not seem to actually be cases of individually assessing the files but rather tagging everything in a broad category with the property, resulting in bizarre outliers on both ends of the spectrum (this obviously isn’t NSFW, whereas this is very NSFW and should clearly be in the “sex” category). Even if you removed the obvious false positives, what is the definition of “sexualized nudity, erotica, or ecchi”. Is this, which I wouldn’t describe as “NSFW”, sufficiently risqué to qualify for the content descriptor? What about women in bikinis? Or two scantily clad male strippers? What about this “sexy” pony? These are all currently tagged with this content description, and could all be argued to fall under it. But if the purpose of the content descriptors is basically to filter out content that is “NSFW” by the standards of your average westernized society these images would only be unsafe for work if you were in a convent or an elementary school. I think this item should basically be redefined to only cover nudity in general (“sexualized” or not) and some extreme outliers of near-nudity (like thongs that reveal essentially all of the buttocks and pasties on female nipples). Even though it’s probably undesirable to have your boss catch you looking at anime girls in itty bitty swimwear, it’s unlikely to get you fired in the average western workplace like a 4K image of a penis on your screen; the content descriptor system should be amended to reflect that while it’s still new and not clogged with files to re-sort. Dronebogus (talk) 10:01, 12 May 2026 (UTC)Reply

Isn't this one for commons? We don't apply the filter here. Secretlondon (talk) 11:10, 12 May 2026 (UTC)Reply
Yes, but the filter is defined by a data item here on Wikidata Dronebogus (talk) 11:19, 12 May 2026 (UTC)Reply
@Secretlondon unfortunately, the categorization was created here.
Wikidata:Property proposal/Wikimedia Commons content descriptor was a successful property proposal.
This seems one of the cases, where people think "this sounds" great on a property proposal instead of really thinking through the implications. This is why it makes sense to read through property proposal and voice issues.
At this state it would probably be best to have a discussion over at WikiCommons about what they think about it, whether it should be changed to serve their needs or whether it just created added complexity and would be better of with the property deleted.
As far as Sexualized nudity, erotica or ecchi (Q138829111) goes, it does not seem to me like an 18+ label based on the image example of the property example but what might be PG-13 in CividAI. The images you linked to also seem to me like they would be PG-13 or make even R-rated in a scheme like the one CividAI has. Ideally, properties like that would not be created without there being a policy about what should get what categorization. ChristianKl ❪✉❫ 21:07, 12 May 2026 (UTC)Reply
I did not added those property examples and I have zero clue why the ones from the proposal was completely changed Trade (talk) 21:16, 12 May 2026 (UTC)Reply
@Trade I see File:Dakimakura, 2view s-2424069217.webp as the one chosen proposal. To me that does not look like 18+ image but something PG-13 or R rated.
In any case, there's a complete lack of any policy about what those terms are supposed to include, which is bad for a system where different people need to agree on how to classify images. ChristianKl ❪✉❫ 21:39, 12 May 2026 (UTC)Reply
I like the idea of the classification system and support the other categories as reasonable (I haven’t looked at the “gore” ones but I am willing to assume they’re good enough; the “sex” one has a huge amount of false positives in searches but subtracting those the correct examples are all accurate and sensible). I just don’t get what the point of a vague “racy” category is; it should just be a “nudity” category since that is objective and makes sense. Dronebogus (talk) 04:51, 13 May 2026 (UTC)Reply

Better detecting bots and replacing our CAPTCHA

[edit]
Latest comment: 5 days ago5 comments3 people in discussion

Hello from the Product Safety and Integrity team! After a successful trial of hCaptcha for bot detection on English, French, Japanese, and four other Wikipedias, we will be rolling out hCaptcha to all projects over the course of the next few weeks.

Specifically, this will include using hCaptcha for account creation, and for edits by newer users. This replaces the use of the traditional "type in the word" CAPTCHA that is currently required of many users for these flows. hCaptcha is set up to only challenge likely-suspicious activity, so very few humans will be interrupted at all. In our trial, we estimate that only about ~2% of human users were actually challenged.

For background - as part of our focus on securing the wikis and detecting bad-faith activity, we are building stronger protections against bots carrying out activities that are generally intended for humans, such as creating accounts and editing. As the web has evolved and computers have gotten smarter, our old CAPTCHA has become both challenging for humans and easy for computers.

We recognized this and began with a trial of hCaptcha, third-party bot detection service, to replace our old CAPTCHA. Since then, eight Wikipedias, including English, French, and Japanese, have been using hCaptcha to protect account creation and certain kinds of edits. hCaptcha is a company that specializes in bot detection, with experience protecting very large online websites while prioritizing user privacy in its design. We have implemented technical safeguards to reduce the sensitivity of the information we send to hCaptcha.

It also gives us "likely bot" signals for account creation and covered edits, regardless of whether the session was challenged. Those signals inform what we show CheckUsers and stewards, who use them to find and remove bad-faith activity that was likely done by bots and which may not have been found any other way.

You can read more about this project at our recently updated project page. We welcome comments here or at that project's talk page. Subscribe to the Wikimedia Foundation Bulletin to follow the most important news from the Foundation. Thanks! SGrabarczuk (WMF) (talk) 13:22, 12 May 2026 (UTC)Reply

@SGrabarczuk (WMF) how does this interact with edits that are not about the standard web interface? ChristianKl ❪✉❫ 14:46, 12 May 2026 (UTC)Reply
@ChristianKl that is a work in progress that we are tracking in T426089: hCaptcha: Enable usage on wikidata.org. KHarlan (WMF) (talk) 15:45, 12 May 2026 (UTC)Reply
That ticket says something about a skipcaptcha right. If you want add new rights like that, being explicit about that in your communication would be good. It's also not clear to me from the ticket what the intended result would be for the various services that currently do Wikidata edits that aren't the webUI. ChristianKl ❪✉❫ 21:11, 12 May 2026 (UTC)Reply
skipcaptcha isn't a new right, it's part of the autoconfirmed user group definition per Special:ListGroupRights.
> It's also not clear to me from the ticket what the intended result would be for the various services that currently do Wikidata edits that aren't the webUI
Eventually, we would want clients that make edits for users who don't have skipcapcha to obtain an hCaptcha token as part of the submission. We have some prior art for this (for gadgets) here T422878: hCaptcha: Add support to mw.libs.confirmEdit.CaptchaWidget KHarlan (WMF) (talk) 14:19, 13 May 2026 (UTC)Reply

It's just the same thing: Q235356 and Q14565995

[edit]
Latest comment: 6 days ago5 comments4 people in discussion

What's going on? IgnacyPL (talk) 14:56, 12 May 2026 (UTC)Reply

Both items have fr and es link, co cannot be merged JAn Dudík (talk) 15:16, 12 May 2026 (UTC)Reply
So what should I do? IgnacyPL (talk) 16:50, 12 May 2026 (UTC)Reply
One is a subtype of the other. Secretlondon (talk) 16:54, 12 May 2026 (UTC)Reply
You COULD have replaced the English name, since that was obviously the source of your confusion. Circeus (talk) 02:43, 13 May 2026 (UTC)Reply

Need help in creating an entry

[edit]
Latest comment: 5 days ago3 comments3 people in discussion

I'm a software engineer with an established Google Knowledge Graph footprint (Score: 453) and an ORCiD profile, and I need assistance creating a clean semantic item. SafiullahKorai (talk) 23:07, 12 May 2026 (UTC)Reply

These are probably not enough to create an item that meets WD:N. It's also not recommended to create items about yourself. Ternera (talk) 13:39, 13 May 2026 (UTC)Reply
See also WD:SELF. Bovlb (talk) 17:10, 13 May 2026 (UTC)Reply

Difference between Q39297 and Q12488383?

[edit]
Latest comment: 5 days ago3 comments2 people in discussion

What is the difference between volume (Q39297) and content (Q12488383)? - Erik Baas (talk) 07:50, 13 May 2026 (UTC)Reply

One is the uncountable contents of something like a box eg the box contains a hat, one is the countable measurable 3d item the volume of the box is 45 cm3. Secretlondon (talk) 16:42, 13 May 2026 (UTC)Reply
I see, thank you. - Erik Baas (talk) 17:35, 13 May 2026 (UTC)Reply

What to do?

[edit]
Latest comment: 15 hours ago5 comments4 people in discussion

When an external source has misread the name of an 18th century painting? Purre or Stint (Q110028942) is so titled according to the museum that holds the artwork; this source is referenced for the name at the item here. However, the painting itself is clearly captioned "Purre or Stint." and not "A Pair of Stints" as captioned by the museum. Purre and Stint are two old (17th-18th century) names for the Dunlin (Q26650) (ref. W. B. Lockwood, The Oxford Book of British Bird Names, 1984; pp. 122, 147); names quite possibly unfamiliar to the museum and hence misread. My preference would be to rename the item to 'Purre or Stint.', but what should I do for a reference for this? Can the painting itself be cited as the source reference for its name? Thanks! - MPF (talk) 15:30, 14 May 2026 (UTC)Reply

I would start by adding all documented titles with their respective sources.
Then, determine whether there's a case (based on the sources) to mark one title with preferred rank (see ranking).
Then select the best supported title as the label, and add alternatives as aliases.
Be careful to rely on sources, not on your own synthesis or speculation. Bovlb (talk) 16:26, 14 May 2026 (UTC)Reply
According to the museum website, the inscription is "Pierre or Stint". You could contact them to suggest it should be "Purre or Stint". The page says "If you have information about this object that may be of assistance please contact us", with an email link at the end. TSventon (talk) 18:01, 14 May 2026 (UTC)Reply
@TSventon thanks! I'll try that - MPF (talk) 20:45, 14 May 2026 (UTC)Reply
I have retitled the item, with the correct name moved to an alias, and deprecated that name in title (P1476).
Contacting the museum will also help. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:14, 18 May 2026 (UTC)Reply

Possible duplicates: Q752297 and Q849697

[edit]
Latest comment: 2 days ago7 comments4 people in discussion

Can someone explain what is the difference between Doctor of Philosophy (Q752297) and doctorate (Q849697)?

Both seem to represent the academic degree following master's degree (in the latter, the English description says "academic or professional degree", which sounds more general, and Doctor of Philosophy (Q752297) is a subclass of (P279) doctorate (Q849697); but, doctorate (Q849697) is both an instance of (P31) and a subclass of (P279) academic title (Q3529618).

So, I'm a bit confused. Which one should I select as the value for the property academic degree (P512) of someone who holds a PhD?

Thanks a lot in advance! E L Yekutiel (talk) 21:25, 14 May 2026 (UTC)Reply

Doctor of Philosophy (Q752297) is indeed a subclass of (P279) doctorate (Q849697). Thera are other doctoral degrees as well, for example, Doctor of Education (Q837184), Doctor of Laws (Q959320) and Doctor of Music (Q5287516), which are also subclasses of doctorate (Q849697).
If someone has a PhD (and not for example Doctor of Theology (Q1233889)), you should use Doctor of Philosophy (Q752297) as the value for academic degree (P512). Valtaisa varpunen (talk) 07:37, 15 May 2026 (UTC)Reply
Amazing, thanks a lot for the very helpful clarification!
I think that it would be useful to have this Q&A archived to the talk page of one of these items, in case others might have a similar question (I came here after not finding anything there). Does that make sense? (Or, alternatively, to link from there to this answer, once it's permanently in the project chat's archive. Any of these options would ve great).
Thanks again! E L Yekutiel (talk) 08:58, 15 May 2026 (UTC)Reply
To be honest Wikipedia will cover the differences between these. en:Doctor_of_Philosophy and en:Doctorate Secretlondon (talk) 09:39, 15 May 2026 (UTC)Reply
True... I should have looked there as well.
Still, I think that it wouldn't hurt to have a local clarification about the difference between the scopes of two items, instead of relying on a sister project; for one thing, not all items have sitelinks. The talk page sounds to me like a natural place for such clarifications. But, of course, if the community (or even one or two editors with more Wikidata experience than myself) thinks otherwise, I'll gladly align.
Thanks again! E L Yekutiel (talk) 13:11, 15 May 2026 (UTC)Reply
I have removed "Ph.D. degree" as an "Also known as" value for doctorate (Q849697) as that could contribute to confusion. TSventon (talk) 14:30, 15 May 2026 (UTC)Reply
There are quite a few confusing "also known as" entries. Secretlondon (talk) 06:50, 16 May 2026 (UTC)Reply

Mix'n'match problems?

[edit]
Latest comment: 15 hours ago2 comments2 people in discussion

Is anyone else having issues with the Mix'n'match tool? For the last few days this tool has been non-functional. A query brings up potential matches, but it is impossible for me to confirm matches, create new items, or remove preliminarily-matched items. Every attempted action results in error messages such as Cannot read properties of null (reading 'getUserName') or Something went wrong: Cannot read properties of null (reading 'is_logged_in'). I've tried clearing caches, and logging off and back in. Running on Google Chrome. No luck. -Animalparty (talk) 04:40, 15 May 2026 (UTC)Reply

I saw some intermittent issues a couple of days ago; but it was fine yesterday. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 18 May 2026 (UTC)Reply

Possible self-promotion

[edit]
Latest comment: 3 days ago2 comments2 people in discussion

I noticed that the item Q139801430 was created by Hiperchef (talk • contribs • logs) without any references backing their claim. Virinas-code (talk) 08:09, 15 May 2026 (UTC)Reply

reported to admins Vicarage (talk) 08:29, 15 May 2026 (UTC)Reply

access restriction status (P7228) and online access status (P6954)

[edit]
Latest comment: 3 days ago1 comment1 person in discussion

Can someone explain to me how these are supposed to be different at all. Several of the allowed values of P7228 are explicitly linked to the internet yet somehow they are not considered online Trade (talk) 13:18, 15 May 2026 (UTC)Reply

Autocomplete incorrectly redirects X‑WIX (Q139470659) to QWIBY (Q139551861)

[edit]
Latest comment: 3 days ago2 comments1 person in discussion

Hello, could you please check the following issue: The item X‑WIX (Q139470659) is being incorrectly replaced by QWIBY (Q139551861) in the Wikidata autocomplete. Both items are completely different entities, and they do not share any aliases. Despite this, typing “X‑WIX” in the search field automatically redirects to QWIBY. This behavior is incorrect, because two different Q‑items must always be treated as separate entities, regardless of activity, popularity, or external identifiers. I kindly ask for: • a review of the autocomplete ranking, • removal of any unintended redirect behavior, • ensuring that X‑WIX appears correctly when its name is entered. Thank you very much for your help and your time. Wishing you a great weekend and all the best! Recordarchiv (talk) 13:27, 15 May 2026 (UTC)Reply

Thank you very much, the issue seems to be fixed now. Have a great weekend! Recordarchiv (talk) 14:52, 15 May 2026 (UTC)Reply

LumiMemoX item deletion - items Q139801923 and Q139806511

[edit]
Latest comment: 2 days ago2 comments2 people in discussion

I have already tried twice to create an item for LumiMemoX, a premium photo restoration service with its own website and social profiles. The items Q139801923 and Q139806511 were deleted immediately for “does not meet the notability policy”.

My goal is just to have a normal organization item with instance of = online service / business, official website, country, etc.

Is this type of small business considered out of scope for Wikidata, or is there a recommended way to model it?

I want to follow the rules and avoid creating problematic items. Please help . Thank you . Lumimemox (talk) 14:19, 15 May 2026 (UTC)Reply

Wikidata:Notability is a good place to start. Also Wikidata:What Wikidata is not a collection of yellow or white pages. Secretlondon (talk) 06:48, 16 May 2026 (UTC)Reply

Recording inverse properties on pairs of items

[edit]
Latest comment: 1 day ago6 comments5 people in discussion

@Bouzinac is not convinced that they should not record pairs of inverse properties for items (in this case a country participating in a battle), and I've failed to persuade them with my argument. I'm struggling to find a wikidata policy document to convince them. We have plenty of tutorials for WD, but do seem lacking in a style guide for things like this. Vicarage (talk) 15:32, 15 May 2026 (UTC)Reply

We often do have two way properties, some properties require it. Secretlondon (talk) 06:40, 16 May 2026 (UTC)Reply
Should be common sense in this case. Countries are participants in thousands of things as you said; the country items would be unmanageable if you were to take that to its logical conclusion. —Xezbeth (talk) 09:40, 16 May 2026 (UTC)Reply
The argument was that the consistency check tool was flagging it. Perhaps the tool's authors @Magnus Manske and @JonnyJD might like to weigh in? Yirba (talk) 13:56, 16 May 2026 (UTC)Reply
Isn't the tool User:Frettie/consistency check add.js? I've left a comment on its talk page. Difool (talk) 10:12, 17 May 2026 (UTC)Reply
Ah yes, there was a mix-up between the "consistency check" tool and the "consistency check add" tool. Apologies to the authors of "consistency check". Yirba (talk) 10:27, 17 May 2026 (UTC)Reply

Ireland's Memorial Records, 1914–1918

[edit]
Latest comment: 17 hours ago3 comments2 people in discussion

I believe en:Ireland's Memorial Records, 1914–1918 and Ireland, Memorial Record: World War I, 1914-1918 - FamilySearch Historical Records (Q94424021) describe the same book series, but I am not quite certain if an article about books should be directly linked to FamilySearch historical record. Can the article be linked to the existing item or should there be a new item? MKFI (talk) 08:03, 17 May 2026 (UTC)Reply

I'm not sure why we have an entry just for part of FamilySearch. Secretlondon (talk) 10:47, 18 May 2026 (UTC)Reply
In fact a lot of User:GZWDer (flood)'s imports don't seem to be notable? Secretlondon (talk) 10:58, 18 May 2026 (UTC)Reply

Wikimedia human name disambiguation vs. regular disambiguation

[edit]
Latest comment: 1 day ago1 comment1 person in discussion

Hello! I am unsure how to combine disambiguation items where one has instance of (P31)Wikimedia disambiguation page (Q4167410) and the other instance of (P31)Wikimedia human name disambiguation page (Q22808320), such as Julie Ryan (Q117303594) and Julie Ryan (Q135457796).

Human name disambiguation pages is only a concept in some Wikipedias, but the two items clearly have the same scope and should be merged.

Please add to the discussion at Talk:Wikimedia human name disambiguation page. Thank you, your opinions are much appreciated! Fallen Sheep (talk) 16:57, 17 May 2026 (UTC)Reply

What to do when correct info is blocked by the spam filter?

[edit]
Latest comment: 1 day ago1 comment1 person in discussion

I tried to put the older amzn.to short url over at Amazon.com (Q124609769) under shortened URL formatter (P11136), but it's blocked by the spam filter... Even though it is, in this instance, indubitably valid information. What to do in such a case? Circeus (talk) 18:57, 17 May 2026 (UTC)Reply

Reminder: Propose a session for WikiProject Days 2026 (deadline Sunday May 24)

[edit]
Latest comment: 19 hours ago1 comment1 person in discussion

Hello everyone,

A quick reminder: WikiProject Days 2026 is coming up (online, June 19 to 21), and the Call for Proposals closes on Sunday May 24.

Do you have a talk, workshop, or discussion about WikiProjects in mind? Your proposal can be just one or two sentences. Here are some suggestions, other topics welcome:

  • How to use WikiProjects to connect with others and improve data modelling
  • How to revive a neglected WikiProject
  • What makes a good WikiProject

If you have an idea, add it here: Event talk:WikiProjects Days 2026

You can also register to attend at this link.

Let me know if you have any questions.

Looking forward to your ideas. - Mohammed Abdulai (WMDE) (talk) 08:49, 18 May 2026 (UTC)Reply

User:Molarus/globe.js

[edit]
Latest comment: 15 hours ago1 comment1 person in discussion

Is anyone familiar with the above? I raised an issue at User talk:Molarus/globe.js#Qualifier, about coordinates' globe attributes, but the script's author hasn't posted in years and the talk page appears to be little-used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 18 May 2026 (UTC)Reply

Wikidata weekly summary #732

[edit]
Latest comment: 12 hours ago1 comment1 person in discussion
BERJAYA
Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2026-05-18. Missed the previous one? See issue #731.

Discussions

  • New requests for permissions/Bot:
    • PatsaBot 1 - Task/s: Add sitelink from Template:Taxonomy/* on thwiki to same entry from enwiki and update Thai description from generic template format to "แม่แบบอนุกรมวิธาน" (taxonomy template).
    • MarisDreshmanisBot 2 - Task/s: Create occupation Q-items and add native-language labels on existing occupation Q-items from 33 state-issued national occupation classifiers (165 national registries, 154 countries, ~30,000 new Q-items, ~120,000 native labels across 53 languages).
    • ias-kbase - Task/s: Read-only bulk entity lookups for an internal knowledge graph project. Fetches labels, claims, and sitelinks from Wikidata and intro-paragraph extracts from English Wikipedia. No writes.

Events

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • Tighter connection of the Wikibase Ecosystem: We've been working on making it possible to use Wikidata Items (and later from other Wikibase instances) as values in statements on other Wikibase instances. You can now try it out on a demo system or set up your own test instance to give it a try. More details in the announcement.
  • Wikidata integration in the Wikimedia projects: We are continuing the work on showing less irrelevant changes on recent changes and watchlist on Wikipedia and co by trying to determine if an edit from Wikidata actually changed the rendered article or not
  • Mobile statement editing:
    • We worked on reducing the load for users with limited data
    • We are continuing to fix issues uncovered in testing
  • Making Wikiprojects more visible: We are getting ready for testing of the prototype. We'll be adding links to the respective Wikirojects on Item pages in the tools menu to make it easier for people to find the corresponding Wikiprojects. This is based on statements already on the Item such as specific external IDs.

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

Merge two Items

[edit]
Latest comment: 8 hours ago2 comments2 people in discussion

Can someone merge Q105791797 to Q17783234. It's a duplicated category from Portuguese Wikipedia and I can't merge them because of "conflicting descriptions for language". Thank you, heylenny (talk/edits) 19:17, 18 May 2026 (UTC)Reply

I did the merge and didn't get an error message. TSventon (talk) 19:56, 18 May 2026 (UTC)Reply
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2494078859"