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/10.
On this page all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 7 days are automatically archived.
Latest comment: 17 days ago81 comments15 people in discussion
P18 usage notes requires images to be "exemplary: representative, unambiguous, and high quality". But sometimes people add images like this to personalities' items. I removed this one, but @Jcb reverted it. I made the edit again, explaining the obvious in the summary; they reverted it again and told me that we should keep any bad quality image in P18. I explained that it's not intended use; Jcb did not respond to this.
Month later I removed the image again; Jcb's reaction this time was reverting the edit, threatening me with block, and checking my recent contributions to revert another edit (this time it was some unknown modern artist's painting of a person without any lifetime portraits). I restored the edits, pointing out that they are well founded, and urged the user to initiate blocking me if they believe I'm in the wrong here. Instead, they reverted the edits once again, discarded my explanation and accused me of vandalism.
From the user's contributions in Talk space I get the impression that they often engage in conflicts of similar sort with P18 usage being a common point of contention. I suspect the process is similar: some user sees incorrect type of image inserted into a Wikipedia infobox; they find out it comes from Wikidata and remove the image here; Jcb reverts the edits, insists on his "anything goes into P18" policy and accuses their opponents of vandalism. Someone should tell them already that:
P18 has scope
other projects expect certain type of content here
people don't like it when something unwanted gets inserted in articles via Wikidata (and it prompts the projects to disengage like English Wikipedia did)
disregarding other editors' concerns with edit wars, silence, threats and vandalism accusations is disruptive
In Wikipedia articles, we prefer having a moderate quality picture over not having a picture at all. The picture that you removed repeatedly, File:FC Internazionale Milano v US Sassuolo Calcio, 21 September 2025 - 08 (Tarik Muharemović).jpg, may not be high definition, but is definitely better than nothing. Many Wikipedia articles are loading the image from the P18 statement, so that your action removed the picture from a lot of articles. This is disruptive and, when continued after warnings, may clearly be seen as vandalism. Don't do it. Jcb (talk) 16:17, 6 September 2026 (UTC)Reply
From the P18 descriptions, constraints and discussion I think Qbli2mHd's interpretation makes sense. The only discussion on image quality I could find on the image property is here: Property_talk:P18#Image_quality
If you are going to argue something like this you should provide something backing your assertion of preferring shitty images over no image. And a single 10 year old discussion alone doesn't seem like a good enough argument to me. Kordishal (talk) 16:53, 6 September 2026 (UTC)Reply
@Kordishal you have a total of 29 edits on Wikipedia. Are you sure you have any understanding on the demands of Wikipedia and on the function of Wikidata within the Wikimedia projects? Jcb (talk) 17:07, 6 September 2026 (UTC)Reply
In 9 language versions of this article, this image was inserted manually, which clearly shows that the Wikipedia communities chose to use it. I can provide you with links to those articles, but you can check for yourself as well. Jcb (talk) 17:22, 6 September 2026 (UTC)Reply
I see, that does clear some things up. Is there a way to directly see what pages use an image directly from Wikidata?
As for the discussion itself it seems Qbli2mHd has nominated the original image for deletion, so that should settle any disputes on that end. Kordishal (talk) 17:37, 6 September 2026 (UTC)Reply
This is not how things work at Commons. First, deletion requests take forever to process (the file was nominated in June). Second, any request will be rejected per c:COM:INUSE if there is any project page using it, no matter how incorrect, out of scope, misleading the file is; if someone adds outright false content to Commons and inserts it across multiple projects, it will stay at Commons as long as there is at least a single page using it in any project. Third, the removal of the original file doesn't mean anything for derivatives, which will be kept. Qbli2mHd (talk) 17:57, 6 September 2026 (UTC)Reply
Adding images of footballers and then adding them to most of the linked projects does seem to be what they do for the most part, with many images being okay and some being really shitty. This specific image wasn't added to en.wiki, but just all the others. But mass adding poor quality images doesn't seem a positive use of time to me, but not sure how that could be addressed. Kordishal (talk) 18:17, 6 September 2026 (UTC)Reply
They added it to enwiki as well, but it was swiftly removed: [2]
The place to address this definitely lies at Commons, but it's their policy not to address this at all. Poor quality photos is just a nuisance compared to blatantly false info: unsourced graphs, incorrect maps, fantasy historical flags etc. Even renaming requests get denied there when the file name is obviously misleading. Qbli2mHd (talk) 18:40, 6 September 2026 (UTC)Reply
And it definitely changes the situation that its basically the opinion of one user to add the image vs. the opinion that it should be deleted of one other user, so threatening bans seems excessive to me.
The best course of action would of course be to replace the image with one that isn't as useless and ugly, but I imagine that wouldn't necessarily be easy. Kordishal (talk) 18:24, 6 September 2026 (UTC)Reply
The problem is with the user's overall hostile way to enforce his "anything goes into P18" approach. Either they're right, Wikidata policy supports keeping trash in P18, and we have to curb this by disengaging the projects; or they are wrong, and the editors won't need to waste time arguing next time they find some garbage in an infobox. Qbli2mHd (talk) 18:48, 6 September 2026 (UTC)Reply
Definitely agree that they should tone it down and provide policy, guidelines or discussions where this is established more firmly than one person saying that it is. Should be trivial considering how established they believe this consensus to be. Kordishal (talk) 19:33, 6 September 2026 (UTC)Reply
We have already a policy regarding media files: the Commons' Project scope: if a media file is in use in any Wikimedia page, therefore is in scope. A Wikidata policy should not supersede the local policies where the file is used nor the Commons' ones. Even, the quality of media file shouldn't even be a matter of Wikidata. Amitie 10g (talk) 11:22, 7 September 2026 (UTC)Reply
If a file is considered as "trash" this is a matter of the project where the file is used, not Commons nor Wikidata. First, you must convince the community that the file is not suitable/ugly/whathever, and, provide a better one before even removing from Wikidata and nominating for deletion at Commons. Amitie 10g (talk) 21:13, 6 September 2026 (UTC)Reply
Wikidata policies/conventions/essays/whatever related to the file-related properties should not supersede the policies of other projects where the file is used (Wikipedia, Wikiversity, etc.), nor the Commons' Project scope. Removing a file, placed directly by editing a Wikipedia article, or indirectly by establishing a property at Wikidata, will violate "Do not disrupt Wikipedia to illustrate a point" (where, at least, at the Spanish Wikipedia is a policy). Simple. Amitie 10g (talk) 21:27, 6 September 2026 (UTC)Reply
What "point" or "disruption" are you talking about? I see an unsuitable image imported into a project from Wikidata, I remove an image, someone calls me a vandal and claims that P18 must contain even bad images. Either Wikidata aims are aligned with the project's and we agree that empty P18 is better than one with a bad image, or Wikidata follows its own "anything goes" policy and the project takes measures not to import this content (like the largest wiki, where P18 is tracked, but not imported). Qbli2mHd (talk) 21:57, 6 September 2026 (UTC)Reply
What "point" or "disruption" are you talking about? I cited the exact answer to your question: Wikipedia:Do not disrupt Wikipedia to illustrate a point (Q4657775). If a file is in use on any Wikimedia project page (by directly adding it to the page, or indirectly by adding a file-related claim to an item the Wikimedia page consumes (usually image (P18)), it meets the Commons' project scope. If a file-related claim contains a value belonging to a poor-quality file, and the file is used on any Wikimedia project page by consuming the claim present in the item the Wikimedia page links, it is no longer just a Wikidata concern. By replacing the value or removing the claim without discussion at the project where the file is actually used, you are doing precisely what Wikipedia:Do not disrupt Wikipedia to illustrate a point (Q4657775) warns against—you are unilaterally removing a file used on a Wikimedia project page to prove a point about Wikidata's policies. This is functionally identical to removing the file directly from the article itself. Amitie 10g (talk) 01:47, 7 September 2026 (UTC)Reply
Ok, so me trying to remove an unwanted image from the infobox is a "disruption", explaining the edits to someone who rejects any criteria for images and only responds with threats is "no discussion", the only thing I'm missing is the "point" I'm trying to illustrate. Qbli2mHd (talk) 03:15, 7 September 2026 (UTC)Reply
Do you want this in an encyclopedia article? Do you think it's adequate to assume that someone trying to revert this insertion is acting in bad faith? What "point" can be illustrated with such a removal? Qbli2mHd (talk) 04:40, 7 September 2026 (UTC)Reply
You answered yourself, you're illustrating a point by unilatery removing claims about valid media.
What I think is irrelevant here. Nor the Wikipedia nor the Commons' policies mention "poor quality" media as a valid reason for removal/deletion. That's the point.
Two veterans (including a former Commons administrator) told you're wrong, but you insist you're righg, justifying your actions in things that aren't even policies. Amitie 10g (talk) 11:16, 7 September 2026 (UTC)Reply
My problem here is that the original warning was made without actually explaining this issue. Yes Qbli2mHd should not have re-reverted a change after, but then jcb just kept on saying what to them is obvious, but to a newer user might not. And then immediatly just threatened with bans and blocks without linking to the relevant policies. Are new users expected to first read all policies of all projects before they are allowed to make any edits?
Furthermore the Commons project page explains that images should not be removed if they are used, it does not make it clear that the same applies to Wikidata. That Wikidata images are directly used is not made clear anywhere that has been linked, its just assumed that new users know this.
So I very much understand Qbli2mHd's frustration with this issue. Situations like these are one of the reasons why new editor retention is terrible. Kordishal (talk) 07:43, 7 September 2026 (UTC)Reply
Why do you keep bringing up the Commons scope policy regarding what should be kept at Commons when the point of contention is what is appropriate for P18? I still do not understand what is this point you keep talking about. Qbli2mHd (talk) 11:26, 7 September 2026 (UTC)Reply
Because the quality of the multimedia files is not a matter of Wikidata. If you believe it is a matter of Wikidata, tell us the policy that mentions that. Amitie 10g (talk) 12:17, 7 September 2026 (UTC)Reply
Should Wikidata regulate media quality for downstream consumption?
Due to the insistence of Qbli2mHd, I think we need a policy regarding the sovereignty of Wikidata over other projects, specifically the usage of multimedia files as a value for commonsMedia properties (e.g. image (P18)). The intention of this thread is to establish clearly the scope of Wikidata as a database—a scope that regulates the quality of structured data, but not the quality of media files (this is a matter of Commons and the Wikimedia projects that use the files).
Commons has its Project scope (which is a policy), which explicitly states the educational value of multimedia files, and explicitly states that the quality doesn't matter as long as the file has educational value (e.g., the file is in use on any Wikimedia project page), and explicitly states that Commons does not overrule other projects about what is in scope.
Images should be exemplary: representative, unambiguous, and high quality. Images for a single person or object should generally include only the focal subject. If relevant, also use more specific properties (e.g. coat of arms image, locator map, flag image, signature image, logo image, collage image, calligraphy)
I can conclude two things:
It is not a policy, convention, or guideline—it is merely a description of a property.
Since it is not a policy, it merely suggests that claims related to multimedia files (e.g., image (P18)) should use high-quality media files. While "should" sounds imperative, not being a policy means it cannot be taken as mandatory. It does not mean it is legitimate to remove claims with poor-quality multimedia files as a value.
In 2016, someone asked about the quality of multimedia files we may use as a value for image (P18). 10 years later, I just answered that.
Which quality images should have to be placed at P18? What about excluding images tagged at Commons with Low quality? And what about pictures showing not an individual, but a group of people?--Kopiersperre (talk) 19:41, 9 April 2016 (UTC)
A low quality image is acceptable is there is no better picture available, I would say. For instance an item about an event that happened a century ago. Syced (talk) 08:07, 18 April 2016 (UTC)
Same from my point of view. Low quality picture is still better than no picture. Also for picture of groups, it is still better than no picture. For group situations there is a nice template on Commons - c:Template:Crop for Wikidata. --Jklamo (talk) 11:08, 19 April 2016 (UTC)
Low quality images aren't ideal, but if there is nothing else to add .. Personally I avoid group images unless it's fairly easy to determine who is the person (e.g. a female in a group of males). I'm not much into cropping .. --- Jura 11:27, 19 April 2016 (UTC)
Should the quality of multimedia files used as value for multimedia file-related claims (aka. image (P18)) be a matter of Wikidata? I don't think so. We have already the Commons' Project scope which quite clear. If Wikidata has a Project scope, it should explicitly exclude the multimedia files from the expected quality for structured data. Amitie 10g (talk) 11:50, 7 September 2026 (UTC)
Which I conclude "worse is nothing", and, quality of media files is not a matter of Wikidata.
I have added to my essay about "Do not disrupt Wikidata to illustrate a point":
* If you have found a file-related claim whose value is, in your opinion, a poor-quality media file, and any Wikimedia page linked to the item uses that claim's value...
do follow the policies of the Wikimedia project where the file is used, and discuss the matter there.
do not replace the value nor remove the claim under the sole premise the media file is low resolution. Consider replacing it with a better quality media file, if available.
This, precisely, to avoid this kind of situations.
That said, I ask
should Wikidata regulate media quality for downstream consumption?
Do we need a policy defining the relationship between Wikidata's policies and those of other Wikimedia projects when Wikidata data is consumed downstream, in light of what Commons' Project scope establishes?
I think we should adopt the image (P18) guidance as general policy Statements should be exemplary: representative, unambiguous, and high quality, and could apply to references as much as images. And for both a poor one is worse than useless, as it discourages the addition of a better one. I have the widget that shows a bar of images above an item , so I can pick one, bearing in mind that advice. I'm much more likely to add an image than replace one. Vicarage (talk) 17:44, 7 September 2026 (UTC)Reply
I agree with the usage of the description of the image (P18) property as a way to avoid using low-quality multimedia files as values for claims. What I disagree with is using the property's description to justify the removal of the value or the claim itself (unless you provide a better media file), especially if a Wikimedia page linked to the item the claim has consumes that value. . Amitie 10g (talk) 18:06, 7 September 2026 (UTC)Reply
One of my issues with this is, that it doesn't seem to me trivial to check if the Wikidata property is actually used or not. When a commons image is used by another project it is listed at the bottom of the article. The image from Wikidata on the other hand is only referenced in the templates if there are any.
Furthermore I would argue that adding a template that pulls a Wikidata image does not directly imply that the image was wanted.
Furthermore the policy to use Statements should be exemplary: representative, unambiguous, and high quality images can be applied to any items without sitelinks without a problem. So at most there is an argument to have an exception to this policy when a wikiproject depends on its presence, but generally I would prefer that Wikipedia maintains a high standard, and then individual projects can still choose to use an image directly. Kordishal (talk) 09:52, 8 September 2026 (UTC)Reply
We have no mechanism for seeing where an image is used other than presumably the Commons server logs. I use perhaps 100k P18 images over my sites https://warlike.info etc, and 300k overall in their galleries, but you wouldn't realise that. Even within the Wikipedia community is there really a way of interrogating usage across all the wikipedias? My sites are designed with clear links back to WD, and if someone sees an image on my site, and thinks its rubbish, why can't they make the decision to remove it here to improve the dataset. Vicarage (talk) 14:38, 8 September 2026 (UTC)Reply
why can't they make the decision to remove it here to improve the dataset.[?]Because Commons doesn't give itself that authority. Its Project scope explicitly says that use on another Wikimedia project makes a file in scope regardless of its quality, and that Commons does not overrule other projects about what is in scope. Why should Wikidata have greater authority over downstream projects?
More importantly, I think it is too one-sided to prioritize the "quality of the Wikidata dataset" while disregarding the fact that Wikidata is itself a data source for other projects and applications. A value in Wikidata is not merely something stored for Wikidata's own benefit: it may be consumed by Wikipedia and other Wikimedia projects, as well as by external users and tools. Commons explicitly recognizes this kind of downstream use as relevant to its scope. If Wikidata is going to act as an infrastructure layer for other projects, its data quality cannot reasonably be considered in isolation from the projects that consume it.
In other words, improving the dataset is not inherently more important than preserving valid downstream uses of the dataset. Where a value is actively being consumed, removing it unilaterally because an editor considers it low-quality can itself degrade the service Wikidata is providing to those consumers. It can also conflict with the principle of not disrupting a downstream project to illustrate a point (reflected in, e.g. Wikipedia:Do not disrupt Wikipedia to illustrate a point, which is a behavioral guideline at the English Wikipedia; or, Wikipedia:No sabotees Wikipedia para respaldar tus argumentos, which is a policy at the Spanish Wikipedia) on the project in which the media file is being used.
That doesn't mean that bad images should never be replaced or that P18 should contain anything whatsoever. It means that downstream use is part of the context that should be considered, rather than treating Wikidata's internal notion of "quality" as automatically overriding the needs of its consumers. Amitie 10g (talk) 16:26, 8 September 2026 (UTC)Reply
I can say something is bad or wrong without the obligation of providing something better. Statements can awlays be removed rather than replaced Vicarage (talk) 10:03, 8 September 2026 (UTC)Reply
I disagree. An image of a building is better than no image. We can and do improve the images used. One of my uses of Wikidata is to catalogue images on Commons. I always use the best image on Commons to add to Wikidata. It's a wiki, everything is replaceable. If a better image appears next week then we use that instead. Secretlondon (talk) 10:58, 8 September 2026 (UTC)Reply
There's enough grudge already inside the projects with the fact that edits at Wikidata add unwanted content into articles without editors' knowledge. Now you suggest to declare the removal of this content "disruptive editing".
If anything, Wikidata standards must be higher, with the assumption that whatever is introduced here will be suitable for every other project. If some project's standards are lower, it doesn't mean they have the right to use Wikidata to force the same content onto every other project. I have no problem if some project adopts "well it's better than nothing" approach, and decides, for example, to use AI slop or Paint drawings in biographies' infoboxes. But if they use Wikidata, they should consider if this addition would be welcome elsewhere. Not wanting to see a blurry upscale of someone's back or a random person's imagination of what a historical figure might have looked like is a legit concern that should be addressed at Wikidata. Either it's "the content we deliver is supposed to be good enough for everyone" attitude, or "whenever someone decided it's good for them, everyone will get it too, and you can do nothing about it". Qbli2mHd (talk) 20:22, 8 September 2026 (UTC)Reply
I see problem here other than unnecessary conflicts. If the administration of wikidata insists on keeping irrelevant, misleading or low-grade images - it's their call. Other projects will simply use something else. No big deal to me. Retired electrician (talk) 18:09, 9 September 2026 (UTC)Reply
As I already mentioned previously in this thread, I don't think this is merely a matter of "unnecessary conflicts". image (P18) has a defined scope, and its usage notes explicitly call for images that are "representative, unambiguous, and high quality", but that does not mean you can remove a claim solely on the grounds that the image is low quality, especially if the media file is in use; once a media file is in use, it is no longer solely a matter of Wikidata. If a value is irrelevant or misleading, the fact that another project happens to use it does not automatically make it an appropriate image (P18) value.
Other projects are free to use something else, of course, but that does not mean Wikidata should deliberately retain values that do not fit the property's intended use. The whole point of having property usage notes and constraints is to provide meaningful structured data for downstream use.
And finally, please be familiar with how Wikimedia projects work. Administrators cannot simply impose whatever they want; they are expected to act according to the community's decisions, as established in policies and other applicable rules. As I mentioned before, Wikidata's policies should not overrule the policies of other Wikimedia projects. In fact, Commons' own project scope explicitly states that Commons does not overrule the policies of other Wikimedia projects. Amitie 10g (talk) 18:31, 9 September 2026 (UTC)Reply
I've noticed you keep mentioning "overruling other projects" here but it's unclear to me how removing a image (P18) value is overruling anything. Wikipedias are free to use our data for images or not, and it's not as if removing an image from a Wikidata item deletes it from Commons or something. What exactly is being overruled in this situation? Kinsio(talk ★ contribs)14:20, 19 September 2026 (UTC)Reply
Right, I got that part. My question is which of Wikidata's policies ... overrule the policies of other Wikimedia projects here, since you're saying the same principle should apply to Wikidata. I'm not following the logic from "Wikidata policies should not overrule other Wikimedia project policies" to "if other Wikimedia projects consume the image (P18) value then it shouldn't be removed" (? I'm also not sure that my interpretation of that point is correct). Part of the point of Wikimedia projects querying Wikidata is that information can dynamically update if the Wikidata item is improved, and no property is guaranteed to be present on a given item so handling absence of a supported property is already part of the logic of Wikimedia templates that query Wikidata. I'm failing to see what in this situation is overruling other projects' policies. Kinsio(talk ★ contribs)21:29, 19 September 2026 (UTC)Reply
I think the key thing here is that if a client project wants to use a specific image, they can do that, but if they simply rely on P18, then they are relying on us to exercise appropriate editorial control. Using P18 is choosing our ongoing selection of the value (or no value); it is not a vote to freeze the current value. There has to be some minimum threshold (in terms of representation, ambiguity, and quality) below which it would be preferable to have no image. Bovlb (talk) 18:40, 9 September 2026 (UTC)Reply
I agree with this, Wikidata should keep editorial control of its image property and fulfill what the property promises in its description. Presumably that is how downstream services use the property. I'd be more disappointed if I got a terrible image instead of no image. Kordishal (talk) 16:15, 17 September 2026 (UTC)Reply
I work to provide images for Wikidata items. I think an image is better than nothing. It feels like many people here would wish me to stop cataloguing images on commons unless the images are exceptional. This makes Wikidata much less useful. Secretlondon (talk) 16:35, 17 September 2026 (UTC)Reply
The current word is exemplary. I think a RFC is needed if you wish to change that, not a discussion here , and its scope should be beyond images, as to whether we have standards for contribution qualityVicarage (talk) 16:43, 17 September 2026 (UTC)Reply
Exemplary doesn't mean perfect.
representative: It should be something that either depicts the item as a hole or many people agree that this represents the item. Like for example a flag of a country is something that people generally accept as a representative of a country.
unambiguous: It should be clear from looking at the image what its supposed to represent and what it depicts without much context.
high quality: The quality should be such that people would want to look at the image and not have visual artifacts or similar issues.
The image that prompted this discussion does not fulfill even one of these criteria. And I think an image can be weaker on some of it if its great in other dimensions. And don't think that is some unreachable bar. Kordishal (talk) 17:18, 17 September 2026 (UTC)Reply
Adding something to P18 is a strongly bold edit, potentially affecting dozens of articles in multiple projects. Some images are definitely worse than nothing, and if there's a reasonable doubt that it is an obvious improvement it's better left empty. Especially with alternative options like related image (P6802) in place. Qbli2mHd (talk) 18:48, 17 September 2026 (UTC)Reply
Not when you are working on the relationship between data and commons, not data and Wikipedias. The thresholds are different and I'm concerned that this discussion will shut down this work. Wikidata covers items which are not eligible for Wikipedia articles but are educational. I'm modelling church structures. Some of the churches have articles on en: Wikipedia but none of them use Wikidata automatically. Wikidata covers so many areas which are not linked to Wikipedia. I think by protecting small Wikipedias which are using Wikidata automatically we are risking neutering Wikidata. Wikidata stands on its own. A non-Wikipedia downstream provider could just use Wikidata to provide addresses and photographs of local buildings. Why remove the photographs to protect end users who are not actually using it? Secretlondon (talk) 14:44, 18 September 2026 (UTC)Reply
I remember having my own issues with the user Jcb and his understanding of what Wikidata is. This came up in the context of chemical illustrations and the established distinction whereby certain types of illustrations are stored in dedicated properties rather than in the generic P18. Unfortunately, he seems to believe that Wikidata’s role is solely to serve as a backend for Wikipedia, and that whenever a particular language version of Wikipedia has a specific need, that need should be reflected in Wikidata. He operated on the principle that “any illustration is better than none” and was unwilling to accept that the problem might actually lie with the Dutch Wikipedia’s improper use of Wikidata in its infoboxes. This sometimes led to absurd situations where he would add incorrect or duplicate illustrations that were already present in items in more specific properties. Obviously, like any other project, Wikidata also needs to care about the verifiability and quality of the data it contains. We are not a dumping ground where anyone can put anything simply because “I want to use this in my article, which imports data from Wikidata, so I’m going to add it to Wikidata.” No. We need proper data curation, including removing or deprecating data, depending on the circumstances, when they are incorrect or inappropriate. If a particular project wants to use data in a way that Wikidata does not support, it should provide the technical means on its own side to override or add information locally, rather than simply expecting Wikidata to accommodate its needs. Wikidata should contain data that are verifiable and, at the very least, reasonably suitable for reuse – not, for example, an illustration consisting of a handful of pixels that in no meaningful way illustrates the item, whose presence on Wikidata serves merely to let someone tick a box in a checklist on their language version of Wikipedia or clear a technical maintenance category. Wostr (talk) 21:10, 9 September 2026 (UTC)Reply
I can see it has use in exceptional circumstances, like asteroids or Bigfoot (Q44810), when there are good reasons why no better image exists, but it should not be an excuse for some of the laziness we've seen upthread. Vicarage (talk) 15:12, 15 September 2026 (UTC)Reply
Situations when only low-quality image is available are not exceptional, for historical people it's common. I've just recently found a case where only damaged painting is available: Pavel Petrovich Vedenetsky (Q28874426). I think guidelines that image should be exemplary and high-quality are for situations where there're enough images to choose from (high-quality is always preferred when it exists). For other cases we could just discuss and have local consensus, like for historical people or extinct animal we allow low-quality image, but for living people we prefer not to have image at all. MSDN.WhiteKnight (talk) 16:54, 18 September 2026 (UTC)Reply
Despite the damage, this portrait is almost as good as possible for a person from this time period, this is definitely exemplary in my opinion. The only problem is that it has a walled-off social media link for a source. Compare this to Max Stirner (Q76725), who notably has only two primitive pencil sketches of his appearance. But it doesn't mean we should welcome it if someone starts making similar sketches for famous contemporaries, arguing that "it's better than nothing". Making blurry photo crops is basically the same thing, and sometimes even a pencil sketch would be more representative than what we have. Qbli2mHd (talk) 17:34, 18 September 2026 (UTC)Reply
I have changed the wording (in English; others may wish to translate), to "Images should be representative, unambiguous, and the of highest quality available..."
I have reverted the change, as apart from the typo, I don't think we have agreed "and of the highest quality available", as many of us still assert that some Commons images are still unacceptably poor. WD should not be bound by Commons gate-keeping. The word "Exemplary" is still best, as it requires both quality and subject coverage. Quality is often a miss-understood term, its not high-production value, its fitness for purpose, and I think we can still challenge Commons images for not being fit for purpose here. Vicarage (talk) 20:18, 25 September 2026 (UTC)Reply
Yeah, some people here seem to think that "exemplary" is used to mean "ideal", while the following explanation specifies that it means "serving as a good example". Another reason why "the highest quality available" is problematic is that the "highest-quality" image is not always the most exemplary: a 800px image can easily be more suitable than a 5000px one. We shouldn't choose based on fidelity only, the comparison should be made from exemplarity viewpoint. Qbli2mHd (talk) 20:32, 25 September 2026 (UTC)Reply
In which case it is redundant to "representative".
Absolutely - I regularly choose lower resolution well framed images over higher resolution ones. I don't however think we should stop using low res images if it's the best we have. Secretlondon (talk) 20:18, 26 September 2026 (UTC)Reply
Do you think we have agreed with the wording to which you reverted?
The original wording has been there for a long time, so yes I think that is pretty agreed on. Your change was really not an improvement in my opinion. Kordishal (talk) 16:25, 26 September 2026 (UTC)Reply
I don't think unilateral changes to the wording of what is clearly a contentious issue are a good idea. I was happy with the existing wording, as it allowed challenge by other editors, which I don't think your version would. Vicarage (talk) 20:31, 26 September 2026 (UTC)Reply
Keep in mind that there was previous similar issue when Wikipedia was ridiculed in media for low-quality portraits of sportsmen, and some were removed from infoboxes as a result: [3]. The idea "bad image is better then no image" might not work well for living persons as the public percieves low quality portraits as sort-of offensive for some reason. MSDN.WhiteKnight (talk) 09:55, 18 September 2026 (UTC)Reply
Are full scans of books and their translations suitable for P18 for the original work?
As this discussion is going on, I am at odds over whether a full scan of the 50+ page 1881 Spanish translation El Cíclope (Q87073857) is suitable for use in image (P18) to illustrate the 5th-century BCE Greek satyr play by Euripides Cyclops (Q1206121) that the translation is based on.
The item already has File:Tragedie di Euripide (Romagnoli) VI-0232.png (shown at right) listed under related image (P6802), and so an image is already present on the data item. But is a book (full book scan, not an image of a page or part of the book) suitable for use as an illustration for the work the book is about? Could, for example, a scan of a biography of Julius Caesar (Q1048) be used as a value in image (P18) for the historical person's data item?
And what if the linked book is a translation into another language of the work to which the translation is being added as a image (P18) value? Would a Russian translation of Wuthering Heights (Q202975) be suitable as an image for the data item used for the work in general?
You can see the full discussion so far on this user talk page, with arguments that a book functions as a supporting reference. My opinion is that this conflated the function of image (P18) with the function of references. The counter-argument is that a "reference may have no veracity", and an image "here I can with my own eyes" [sic]. --EncycloPetey (talk) 21:05, 12 September 2026 (UTC)Reply
I would distinguish between an image intended to illustrate the subject itself, and an image intended to illustrate some other aspect of the subject.
If the image is intended to primarily illustrate the subject itself (as is usually the case when it is transcluded in an infobox on a Wikipedia article), image (P18) is the appropriate property. If the intention is to illustrate some other aspect of the subject, there are already a multitude of properties for multimedia files. If no suitable property exists, a new one can be proposed; a recent example is Wikidata:Property proposal/image of cosplay.
So I would not use image (P18) simply because a file is somehow related to the subject. The purpose of the property should also be taken into account.
For any file-related property, if the image is good quality (high resolution), go ahead! If the image is low resolution, and no better one is available, you may use it but with some concessions regarding its quality. Amitie 10g (talk) 21:35, 12 September 2026 (UTC)Reply
The discussion is hard to follow, but image (P18) should be an image, it should should not be a multi-page pdf. That would likely break downstream use in unexpected ways. And as we discussed here, no image is better than an inappropriate image. Vicarage (talk) 00:29, 13 September 2026 (UTC)Reply
Should image (P18) have a constraint added for file types? or is there only a problem with multi-page pdfs? How might this break usage? As many pdfs have >1 page, likely any automated pdf-related programmer/-ing would factor in the fact that there may be >1 page in a pdf, Maculosae tegmine lyncis (talk) 08:01, 13 September 2026 (UTC)Reply
It does "(?i).+\.(jpg|jpeg|jpe|png|svg|tif|tiff|gif|xcf|pdf|djvu|webp)|". The problem is that pdf is a very different format to the others. Clearly a pdf can just contain an image, but can we expect downstream users to handle that. Good practice suggests that multi-page pdfs are clearly problematic. Vicarage (talk) 08:54, 13 September 2026 (UTC)Reply
Looking at the image image (P18) and related properties, whose descriptions refer to an "image" and whose instance of (P31) value is Wikidata property for linking to a representative image (Q26940804), it is reasonable to infer that image (P18) is intended for single-page media files. That said, I see two possible approaches: either allow multi-page media files for properties such as image (P18) and provide a way to select the page to be displayed, or disallow multi-page media files by checking whether the file is multi-page and triggering a constraint violation when it is. The latter may require a feature request through Phabricator, and I would expect such a feature to be relatively low priority. It could also be computationally expensive, particularly if the file contents need to be inspected when constraints are evaluated.
Therefore, the fastest and cleanest solution is simply to extract the relevant page from the multi-page media file, either by:
Manually extracting it using your preferred tool; or
Going to the multi-page media file on Commons and downloading its thumbnail at the highest available resolution.
The extracted page can then be uploaded to Commons, indicating that it was extracted from the multi-page file, and used as the value of image (P18) or any other media file property where appropriate. Amitie 10g (talk) 01:39, 14 September 2026 (UTC)Reply
A pdf can be an image but not all pdfs are images. I'd even say most pdfs are not images. So it would probably make it easier and clearer to disallow them. Pdfs can always be rendered as images if necessary. Kordishal (talk) 17:30, 17 September 2026 (UTC)Reply
I think the preferred value for image on books is a single image of cover or title of original edition. If it's not available, we can use cover of newer edition or example page from some reasonably ancient edition. Parallel Lives (Q842337) has a page from medieval manuscript, Iliad (Q8275) has vastly damaged Roman-times papyrus, so the second approach seems more likely. Book is bibliographical item, we could live with the fact it's text-only and not looking fancy. Wikipedias are welcome to override the image locally when they don't like it. The multi-page PDF could be used temporarily if all else fails, until someone uploads the proper image. The MediaWiki engine automatically renders first page (usually a cover or title), so this seems sort of acceptable. MSDN.WhiteKnight (talk) 17:28, 18 September 2026 (UTC)Reply
Exhibition participants from museum open data: asking before I start
Latest comment: 12 days ago7 comments3 people in discussion
Wikidata knows that exhibitions happened; it rarely knows who was in them. Measured with SPARQL: 54,304 exhibition items, 40,415 of them dated, and 14,147 P710 statements across the whole project. MoMA has 2,546 exhibition items here, 4 of which name a participant. Tate Modern: 107 items, 1. Whitney: 11 items, 1.
MoMA publishes its exhibition history as open data under CC0, carrying the Wikidata identifiers the museum assigned itself. Matching on P7778 gives 1,716 matches out of 1,723 exhibitions, which yields roughly 21,000 participation statements. That single contribution would more than double P710 across Wikidata, which is exactly why I would rather hear objections before doing anything at that scale.
Why I care about this particular gap: I am building a public map of how art institutions actually work — which venues open careers, which open calls charge artists nothing — aimed at artists outside the usual centres, who have no way to read that landscape today. Exhibition participation is the backbone of such a map, and it belongs in Wikidata rather than in one private database.
Three questions:
1. Is P710 the right property for "this person took part in this exhibition"? Should the statement sit on the exhibition item, on the person, or on both?
2. What reference is expected? I plan P854 pointing at the museum's own record plus P813 with the snapshot date. Would a P248 item for the dataset be preferred instead, or in addition?
3. Preferred route for loading: QuickStatements, or a bot request first?
What I will not import: anything that is not CC0, and anything where the matching key was not assigned by the museum itself. Labels and names: nothing at all. Our own snapshot claimed 21,256 artists were missing labels; checking 300 of them live, all 300 had labels — the fault was ours, the query asked for a language list that omitted mul. Where a licence forbids reuse, the data stays out even when the matching is good.
While I learn the ground I have been adding P6379 statements for Metropolitan Museum artists from that museum's CC0 dataset, about twenty at a time, each with a link to the specific object and each re-read after the edit. My user page lists the acceptance rules, including three traps in the museum's own data that cost me the first attempt: role columns that also list sitters and printers, attribution prefixes such as After, and catalogue rows where a poet is recorded as the artist.
If this model holds up, I intend to keep going with other CC0 collections on the same rules. Suggestions for which ones are worth doing next are very welcome — particularly outside Europe and North America, where the gaps are widest.
Happy to stop, slow down or change the model on request.
Solo exhibitions are an important part of an artist's career, but I'm not sure whether participation in general exhibitions is notable enough for us, would recording the information in a separate spreadsheet linked from WD be more appropriate? Do enough institutions release the information to give us good coverage? The level of detail you want to record is laudable, but there is a danger that if you use WD for your personal research into unusual channels it becomes a lopsided dataset. Have you considered setting up your own wikibase? Hopefully there are others who want to do the same so you can establish a broad community here. Vicarage (talk) 07:15, 20 September 2026 (UTC)Reply
Good points, thank you.
The main thing: I hadn't seen your project's page on exhibition item structure when I posted. It already has both a register of sources and a section on notable exhibitions — so I'm late to this conversation, not starting a new one. I'll work through that register by licence.
It also had what I was asking for: sources outside Europe and North America. DAAO for Australia, nearly twenty thousand exhibitions, and museums.gov.il for Israel. I'll start where the licence is unambiguous.
One correction to my own figures above: the 14,147 I quoted is participation in exhibitions specifically, not P710 across the whole project — that number is around 2.6 million, mostly sporting and conference events. The exhibition gap stands: 54,304 exhibition items here, participants on 5,666 of them.
On lopsidedness — my rule is that a dataset goes in whole or not at all. All 1,716 matched MoMA exhibitions, not the ones that suit me. That can be checked against the source file in a minute.
You're right about solo versus group, and it's countable: MoMA has 571 solo exhibitions against 937 group ones, by artist count. The dump also carries the role — artist, curator, installer. Only artists would go in as participants, and I'll record the exhibition type so the two can be separated by query.
I did consider my own Wikibase, but it solves the wrong problem for me: the value here is that people who know more can correct the data. Though for anything that doesn't pass notability here, it's the right home.
I think it's fine to add information about exhibition participation for any case where both exhibition and artist is notable by our criteria. If we are already including data, it must be properly connected to be useful. Group exhibitions are less important when considering artist's notability, but they might be actually more important from larger art history view. Famous historical exhibitions, like first impressionists exhibitions, were group ones. We just need to make sure we are not mass importing non-notable items, for example, some exhibitions might be periodic rotation of drawings not permanently on display in museum collection. These should probably not be included, as this happens very often. Same for artists, if the artist is only participated in a sinlge group exhibition, probably they should not be included. Statements should be properly sourced, either via reference URL to a museum website, or via stated in for print catalogs or other publications. Looking at quality and scalability issues of existing mass imports (articles, people databases) i'd say quality is more important then including complete dataset. MSDN.WhiteKnight (talk) 07:12, 27 September 2026 (UTC)Reply
Thank you, that's a clear rule, and I'll work within it. Applied to MoMA, it looks like this:
Existing items only. Exhibitions are matched through P7778, which holds MoMA's own exhibition ID; artists through the Wikidata ID that MoMA itself publishes for each person. No new items, neither exhibitions nor people.
People only. A live check of all 3,050 artist IDs found 3,003 people and one artist group; 33 are organisations (companies, a federal agency, an observatory, credited for photographs in some shows) and stay out; 13 are redirects, which I will resolve to the current item before any edit.
Artists only. Curators, installers, judges and designers stay out, and each P710 statement is qualified with P3831 = artist.
Acquisition displays and collection rotations stay out: 178 exhibitions titled "Recent Acquisitions", "New Acquisitions", "Selections from the Collection", "Art Lending Service" and the like.
Reference: P854 to the exhibition's page on moma.org, plus P813.
That takes the roughly 21,000 statements from my first post down to about 16,000, on 1,236 exhibitions and 3,004 artists; 500 of them are solo shows. On quality over completeness, I take the point: "whole dataset" now means whole within these criteria, not everything the file contains.
Two questions before I file the bot request, which will start with a test batch of 50 edits for review:
My rotation filter goes by title, so it also drops themed shows drawn from the collection, such as "Latin-American Art, 1931-1966, from the Museum Collection". Should those come back in?
1,154 of these artists would get a single statement, from one MoMA group show, although each already has an item. In or out?
If artist already has an item, i think it's fine to add data, even if the artist is potentially non-notable. One more statement is not obstacle if we'd want to delete them in the future. For filtering rotations/themed shows, i currently have no certain opinion how it should be done. MSDN.WhiteKnight (talk) 06:10, 2 October 2026 (UTC)Reply
Does Wikidata have an AI content policy yet?
Latest comment: 17 days ago11 comments6 people in discussion
Curious from a Commons perspective whether Wikidata has taken a stance on the use of AI generated content yet. I was surprised to see an image having been removed from an item with the summary that "AI-generated images are not allowed due to copyright", when following up a Commons deletion discussion. I can't see any statements either way at Wikidata:Artificial intelligence, though.
Thanks. It'd be good to see an RfC arriving at clear sentence of guideline or policy on that, if it can be done. But I know Commons is struggling to reach consensuses on AI content itself (beyond general scope assessment we've only got as far as restricting some AI-generated portraits and unused personal AI content).
A lot of AI-generated and AI-upscaled imagery on Commons is being kept around only because we can see that it's in use on a Wikidata item (where it's often also populated across other wiki projects), even when we are agreed that it's of low quality.
I've always demurred from stepping in and removing or replacing any AI images on Wikidata, as I don't know what the consensus is here. Belbury (talk) 18:33, 23 September 2026 (UTC)Reply
If you are invested on this topic I think having a drafted policy that we could have an RfC about could make sense. Clearly there is at least some conflict potential on this topic. This would of course only indirectly affect AI images, but potentially could include something on AI slop quality as well. As far as I am aware there isn't yet a policy being written, but might want to join the discussion there and ask. Kordishal (talk) 19:24, 23 September 2026 (UTC)Reply
Oh, I'm not familiar enough with Wikidata to know what would and wouldn't be important to any such RfC, or where any such policy or guideline text would go. I'm just a puzzled Commons/enwiki user who gets very mixed signals every time I trace any AI imagery to Wikidata - I see some people removing it as being very very obviously against Wikidata norms (accuracy, copyright, "slop"), and others adding it as being very very obviously better than nothing or better than a grainy old newsprint photo. Belbury (talk) 08:28, 24 September 2026 (UTC)Reply
That is really the core of the quality discussion / conflict. That discussion I linked is considered a RfC regarding the quality. So you could start by adding your concerns there. Kordishal (talk) 08:51, 24 September 2026 (UTC)Reply
It seems like an orthogonal question from quality. Some people will consider a gleaming AI-upscaled portrait photo to be of higher quality than a faded daguerrotype, an AI-generated render of a historical site to be of better quality than a historical sketch, etc. The enwiki policy on AI images explicitly separates its stance from any measure of quality. Belbury (talk) 09:41, 24 September 2026 (UTC)Reply
ah I was only thinking of bad AI images, where quality would be a thing. An really that article shows why they are worse quality no? They aren't the same as the reality of the photo, but I guess some people consider that acceptable.
But generally I think the problem here is a bit circular. Wikidata accepts only images from Commons so, any image there is acceptable, but then Commons can't delete a file when its used on Wikidata.
And I am not sure if this problem should be solved on Commons side to make an exception for images only used on Wikidata. Or if Wikidata should be more strict than Commons what images should be used. As far as I am aware Wikidata does not have any policy regarding media files, all that we have are some discussions and descriptions / usage instructions on properties. Kordishal (talk) 10:06, 24 September 2026 (UTC)Reply
Since Wikidata is neither an encyclopedia nor an Media file hosting but a database, I don't think a policy related to media files generated with generative AI suits this project. This enters in the scope of "quality" of the media files as discussed in the section Anything goes for P18? At the Project chat. --Amitie 10g (talk) 20:28, 23 September 2026 (UTC)Reply
@Jasper Deng: I don't think you should remove images by making false claims about copyright.
I think the removal in this case of an item about an entity called Irelu/geni with an image for an entity called Carmenço is right, but the justification isn't.
As far as copyright goes, images that are AI-generated and that could be trusted to be AI-generated don't fall under copyright protection. That means that it's easier to reuse then images from WikiCommons where people frequently have uploaded copyrighted images in the past and then sued people who used them.
When it comes to image quality, it probably would make sense to have a general policy regarding it and we do have higher quality standards then WikiCommons but I don't think AI-images are automatically low quality.
Given EU-AI laws that forbid displaying AI-generated images that a normal user might think are real, we should probably not allow those images to be displayed on Wikidata and break EU law and have our data reusers break EU-law. Ideally, I would however have commons enforce rules to be compatible with EU law and not need to do that on Wikidata. ChristianKl ❪✉❫ 10:09, 26 September 2026 (UTC)Reply
WDQS is 4 hours behind!
Latest comment: 14 days ago4 comments2 people in discussion
From grafana the lag in indexing Wikidata seems to be between 13 minutes and over 4 hours right now - that's for the wdqs10* servers. The wdqs20* servers are just a few seconds behind. It looks like this has been regularly happening recently. Do we have any idea what the cause is, and is there any way to access the "20*" servers that seem to be up to date? ArthurPSmith (talk) 13:00, 24 September 2026 (UTC)Reply
Actually it looks like early yesterday (2026-09-23) the 20* servers were behind and the 10* ones were ok, then they all caught up, then it switched during the day yesterday and overnight. ArthurPSmith (talk) 13:04, 24 September 2026 (UTC)Reply
Hi @ArthurPSmith, we experienced a WDQS outage on September 21st. We were able to resolve the issue within a day by blocking the malicious traffic responsible for increasing service lag. We apologize for interruption to your work flows. BTracy-WMF (talk) 20:46, 29 September 2026 (UTC)Reply
@BTracy-WMF: - thanks for the follow-up. However the problem I was seeing was 3 days after September 21 - is there somewhere where the timing of the issue/resolution is documented that I can see?
Also - I think we've been communicating by email about the QLever replacement - did you see my email last week about getting a "Forbidden" response even with the User-Agent string you provided (I even tried the exact curl command you sent). I really was hoping to try it out last weekend, but no luck. ArthurPSmith (talk) 01:27, 30 September 2026 (UTC)Reply
How I can duplicate an item on the site?
Latest comment: 17 days ago5 comments3 people in discussion
just be careful about not creating actual duplicates that aren't distinct entities :) And include as many external IDs as you can, to make it easier to ensure there aren't dupes / make sure no one else dupes your items later. Nicereddy (talk) 14:42, 26 September 2026 (UTC)Reply
Property to indicate access to buildings
Latest comment: 16 days ago3 comments2 people in discussion
Is anyone aware of a property that records the level of public access to a building (ie none, 24 hour, working hours, exterior only, free, paid, occasional etc)? access restriction status (P7228) is a possible one, but its focus is on objects and documents, and currently is only very rarely used for buildings. I ask because in my gazetteer work its very useful to indicate whether a place can be visited, and before I propose extending access restriction status (P7228) I wonder if there are any alternatives. Vicarage (talk) 10:30, 26 September 2026 (UTC)Reply
Only 6 museums in the UK have opening time (P8626) or open days (P3025) so it has very poor coverage (I can see why, as its fiddly to model, and subject to change, I don't trust them on Wikivoyage), and they are not properties you'd apply to many public buildings, like stations or churches, or commercial ones like pubs. OSM have a property access, which while focused on rights of way also handles private, permit, customer, military, which is the kind of thing I want, as while I'd prefer to see anytime/restricted times recorded too, that is really implied by the customer flag, as customers are rarely served 24/7. It has the advantage of a clean and consistent import route too, though some of its usages have internal disputes. Vicarage (talk) 07:56, 27 September 2026 (UTC)Reply
Singh/Kaur
Latest comment: 17 days ago1 comment1 person in discussion
Announcing a new tool: Mergers & Acquisitions, a web app for finding and merging duplicate Wikidata items
Latest comment: 11 days ago12 comments3 people in discussion
Hello all! I've been a Wikidata editor for almost a decade and have always wanted a good tool for finding duplicate items. Since nothing existed and as an early birthday present for Wikidata, I've been building it for the last few weeks.
It matches based on a variety of heuristics (same external IDs, same release/creation date, same/similar name, alias matching the label of the other item, no "different from" statement, etc.) and ranks them based on those patterns. I've been tweaking it based on feedback and adding more functionality to it, and I think it's now very useful. It's not perfect (partially because our data isn't perfect!), but hopefully you'll find it useful as well.
Matches have been discovered for you, your job is to evaluate whether they should be merged or not.
Detailed display of item statements for every pair so you can quickly compare potential duplicates against one another.
Merging items.
When merging items, the app automatically handles redirecting the item and removing any already-redirected sitelinks for you.
It will force you to make manual changes if it can't handle everything automatically for you, I'll try to improve this in some cases but I want to make sure the edits are always safe!
You can "dismiss" a pair, and the app won't bring it back again in the future. This is mainly intended for items where it doesn't necessarily make sense for it to marked with P1889, but it also shouldn't be merged together.
Various filters:
by item type or WikiProject (e.g. video games, music, film/tv, anime/manga, companies, comics, etc).
by the user which created either side of the pair, if you want to look for your own dupes.
by the languages available for the item labels, so you can filter out items you can't evaluate effectively because you don't speak that other language.
Desktop and mobile support, so you can use it from your phone if you prefer.
Leaderboard, for bragging rights :P
Automatically refreshes with data from Wikidata dumps every Wednesday, and automatically finds any new dupes.
Fast load times, I've tried to optimize things whenever I've noticed any slowdown and so far it seems to be working pretty well.
Only some types of items (around 2 million items total right now) are available to match, but I intend to increase the coverage further over the next few weeks. I wanted to keep it scoped to start with so I could tweak things without needing to run hours-long imports whenever I changed the logic.
Please tell me if you have any feedback or suggestions! If you find anything where the app made an obvious mistake with a duplicate candidate, definitely send it to me!
Looks a very good tool. I suggest you display both label and description on the initial page, as often its the latter that makes the situation clear, and allow the flipping of the merge order by tapping on the arrow. Obvious areas of expansion are ships, buildings and places, and properties initial date (start, inception, publication, launch date etc) and coodinates within a mile. Vicarage (talk) 05:17, 27 September 2026 (UTC)Reply
Hmm, are you certain? I'll investigate to make sure, but the filters are stored entirely in the user's browser and never stored in any way in the database. They're persisted across reloads/page changes, which might be why you saw that behavior, but they definitely shouldn't be having any sort of session state issue. Regardless, I'll double-check. Nicereddy (talk) 13:12, 27 September 2026 (UTC)Reply
This looks like a great project.
I do agree with Vicarage, that you do want to show the property labels instead of having P-numbers on the initial page.
Currently, you label English (Q1860) and American English (Q7976) as distinct. Given that there's a subclass relationship (2-level deep) that should probably go under "similar" not "distinct".
I'll update the P-numbers to show names on the list view and I'll see about adding a picker for criterion used (P1013). I'm not sure how best to handle the sub-class relationships without needing to store the entire subclass structure of everything on Wikidata, which might slow things down considerably / require a much larger database. I could just hardcode a few common subclasses, but that feels like cheating. I'll think on it some more. Thanks for the feedback! Nicereddy (talk) 13:19, 27 September 2026 (UTC)Reply
When it comes to subclass relationships a merged item where both have unreferenced statements where one is English (Q1860) and the other is different from (P1889) also doesn't need the English (Q1860) claim, so it's not just UI.
Intuitively, maybe it can be okay to have them distinct for the initial scoring but then when the user loads the page for a given match make the queries live? ChristianKl ❪✉❫ 07:36, 28 September 2026 (UTC)Reply
I guess I could consider that, but at least right now we only have a chunk of Wikidata's database in the app. So you'd be limited in how much you can actually filter down to. Do you have anything specific you wanted to filter by? Nicereddy (talk) 22:42, 1 October 2026 (UTC)Reply
I have little desire to fix all the books in WD (for one thing, lots of the titles are in other languages, and I have no competence there), but would want to fix say the military history books, but that would require me providing a query for the subset. Other than the WD gamification people, I suspect many would want to work on an area of interest. Vicarage (talk) 12:56, 2 October 2026 (UTC)Reply
How I can edit else languages not being displayed on an item
Latest comment: 16 days ago3 comments2 people in discussion
I want edit other languages of the item name out of my babel setted on my userpage or on Meta Wikimedia (for instance, Spanish, Russian and Polish). Thanks. -- Chernobox (talk) 04:03, 27 September 2026 (UTC)Reply
The UI provides it as the the dots on the upper right/"Labels list" or "List of headers (BETA)" depending on whether you have that beta version activated or not. ChristianKl ❪✉❫ 10:34, 27 September 2026 (UTC)Reply
Latest comment: 15 days ago4 comments3 people in discussion
Sorry I have no clue how this site works but I need help finding a english translation of {Q12397781} I made a comment on the page for it in the discussion section but I don't know if that's where it's supposed to go... anyways Please be nice I have never used this Molten3 (talk) 13:55, 28 September 2026 (UTC)Reply
How should online calculation tools be represented in Wikidata?
Latest comment: 15 days ago3 comments3 people in discussion
Hi everyone,
I’m exploring how different types of online calculation tools could be represented using structured data. There are many tools that perform specific mathematical tasks, such as percentage calculations, percentage increase and decrease, unit conversions, averages, and other common calculations.
I’m particularly interested in the best way to model these resources without creating unnecessary or overly specific items. For example, should a collection of related calculation tools generally be represented by one item with appropriate properties, or can individual tools qualify for separate items when they have distinct functions and reliable references?
Another question is how Wikidata editors usually approach the distinction between a website, a web-based tool, and a specific calculator/function offered by that website.
I’d be interested in hearing how experienced editors approach this type of structured-data modeling and which properties or existing WikiProjects would be useful for this kind of case. JunaidTech12 (talk) 19:15, 28 September 2026 (UTC)Reply
The general idea is that you start by gathering the data and try to understand the domain you want to model. What Wikidata properties are there to deal with it? For what users would the data be valuable? What do they want to do with it? How does the data structure affect what they want to do with it?
Generally, if your goal is to have a lot of links to your own website, that's probably not something that's very compatible with Wikidata's ethos. ChristianKl ❪✉❫ 21:36, 28 September 2026 (UTC)Reply
Reference to the discussion on the prominent positioning of the Property P2559
Latest comment: 14 days ago9 comments5 people in discussion
Generally the UI is already fairly bad in term so of having to scroll for days to actually view and manage an item, so not sure this makes it significantly worse. The instructions were there before as well and on items they are extremely rare. Usually on items that were misunderstood / misused in the past so I think it makes sense to have these banners at the top. For example Various (Q92774440), would be somewhere it is useful to have it at the top, though also not technically necessary as the item is almost empty anyway.
I agree that a feature to collapse all but the interface language if available or at least one instruction would be very beneficial. I assume a Phabricator ticket would be necessary for that?
And I do agree that changes to the order of the Wikidata usage instruction and Classification categories of the properties should be discussed via RfC in the future. Kordishal (talk) 06:23, 29 September 2026 (UTC)Reply
The property Wikidata usage instructions is currently not yet widely used for data objects, but rather for properties. For example, the property noble title has 26 statements using this property. Among data objects, the data object name with nine statements is so far the data object with the most statements of this type, which is not – what I would call – a “Wikimedia-internal” data object. Of course, nine statements do not sound like a huge number. Nevertheless, the resulting list is not exactly short. Moreover, such prominent usage would naturally encourage further translation into additional languages, thereby making the lists even longer. --Gymnicus (talk) 11:31, 29 September 2026 (UTC)Reply
This is off-topic, admittedly: I don't really see a connection between the image and the concept described in the data object either. So, I wouldn't object to its deletion. In fact, I’d support it. --Gymnicus (talk) 12:35, 29 September 2026 (UTC)Reply
Latest comment: 14 days ago4 comments3 people in discussion
I was creating the item for Milk, a character in the Maimai series. I added a statement saying that her first appearance is in Maimai ORANGE, along with a qualifier using the field 'quotation' specifying that she first appeared in the song, "Oshama Schramble!" by t+pazolite, which is first collected in that version.
But I'm still unsure whether the field I chose is correct. Do you have a better suggestion for dealing with such running-text explanations like this? Thanks. Chernobox (talk) 06:54, 29 September 2026 (UTC)Reply
Don't add running-text explanations, Wikidata has per design no property for that. Try to understand how to express what you want to say with the existing properties. ChristianKl ❪✉❫ 14:59, 29 September 2026 (UTC)Reply
Latest comment: 14 days ago1 comment1 person in discussion
Here's your quick overview of what has been happening around Wikidata in the week leading up to 2026-09-28. Missed the previous one? See issue #750.
Discussions
New requests for permissions/Bot:
MamouriBot, Task/s: Add census demographics — population, male population, female population, and no. of households — to existing Iranian settlement items identified by Iran statistics ID (P1010), from the Statistical Center of Iran censuses of 1385 (2006) and 1395 (2016).
The program for the Wikidata Query Service Days (October 17-23) is now published, covering the migration from Blazegraph to QLever with sessions for editors, reusers, and tool builders; see the event page for details and schedule.
When the Old Constraints Disappear: Work and Creativity in the Age of AI (Wikipedia->Wikidata->Wikifunctions->Abstract Wikipedia), John Samuel, Mindstone AI Meetup, September 22, 2026, Lyon, France (Video, Slides)
HumansMap Gallery - The site offers various type of visualizations, and offers the possibility to navigate through connections between people and organizations, based on your interests, powered by Wikidata.
📚 Wikidata Book Itemizer It is a simple tool to catalog books on Wikidata! Creating work and edition items manually on Wikidata with proper metadata and multilingual labels can often be tedious and error-prone. Wikidata Book Itemizer automates this entire process with a simple form!
Other Noteworthy Stuff
Wikimedia Deutschland is researching how to improve interoperability between Wikidata, Wikibase Cloud, and Wikibase Suite. If you've worked with data imports or staging, or even if you haven't, your input would be valuable. The survey takes 5 to 10 minutes and is anonymous. More information on the background of the questions: Wikidata:Requests for comment/Mass-editing policy#Context
WikiProject Highlights: Project PCC EMCO Wikidata CoP added a subpage for listing Properties normally associated with Corporate bodies.
Development
Mobile statement editing: We are continuing with UX fixes. This is primarily visual polish and consistency as well as fixing bugs related to RTL display.
Wikibase REST API:
We are finishing the support for creating Lexemes and the statements on them.
We are continuing working on support for adding Forms to a Lexeme.
Wikidata integration in the other Wikimedia projects:
We are going to stop sending language link changes to the first few wikis. An initial deployment to group1 wikis is now planned for Monday, 05.10.2026. (Click group1 on this Toolforge page to see which Wikis are included.) This will help reduce noise in Watchlists and Recent changes and help reduce the size of the database table holding recent changes on these wikis.
Connecting a newly created Wiki to Wikidata is a manual task, we are automating that and optimising the SitesTable at the same time, making a 'single source of truth' that all wikis point to, rather than a table per Wiki that are all clones of each other.
We are experimenting with raising the entity usage limit on wikis. If this is feasible, we can reduce the amount of bundled changes. This would reduce the quantity of Wikidata-triggered Recent Changes rows being created.
Latest comment: 12 days ago6 comments2 people in discussion
Hello, I made a change to Azubu as the Korean Wiki article name has changed. So I made a merge between Q29097046 and Q12605412(Moving disambiguation page to the Corporation page), but the merge process went something wrong and the merge happened to the opppsite direction that I'd expected. I tried to fix that, but the restoration is failing. Do you mind me getting help with this problem?? Sorry for making the inconvenience. --YellowTurtle9 (talk) 19:07, 30 September 2026 (UTC)Reply
You merged two things that should not have been merged, a disambiguation page and a website. Merging doesn't move or redirect, it combines the items into one, and chooses the oldest. If you wanted to change the language link you could have done that. Now they will need un-merging. Secretlondon (talk) 10:53, 1 October 2026 (UTC)Reply
I see... Thanks for checking and fixing the problem.
I changed the Ko wiki article as the article page has been moved, so Q12605412 currently has no items inside in it. Then, if I want to remove that item, what kind of thing should I have to do? --YellowTurtle9 (talk) 15:21, 1 October 2026 (UTC)Reply
Asking why something is still happening when it happened in 2020, is a bit mistaken. Probably, someone made a change to fix some tool to not repeat the error. But that doesn't automatically mean all previous items got processed. ChristianKl ❪✉❫ 10:25, 1 October 2026 (UTC)Reply
The one from 2026 is from a QuickStatement batch by @MattArtzAnthro:. Fixing individuals tools from creating all-caps articles won't prevent someone to create a QuickStatement batch that does it. ChristianKl ❪✉❫ 18:25, 1 October 2026 (UTC)Reply
Generally if you want something done on an open knowledge platform, you do it yourself.
That being said, you can't just fix capitalization without errors, as to why people add items with all caps letters... who knows, you could ask that person, but I suspect thats just how the data came. Kordishal (talk) 18:25, 1 October 2026 (UTC)Reply
The 2026 change you listed wasn't a bot but a user who used QuickStatements. In Wikidata, actually talking to people who do things you don't like is the way to go. Calling something a disgrace is not an effective way to convince other people.
Also having clear policy written down somewhere (probably Wikidata:WikiCite), would help in cases where there are disagreement such as MattArtzAnthro thinking that just taking the data the way it can is reasonable. ChristianKl ❪✉❫ 08:23, 2 October 2026 (UTC)Reply
Its also just not that big of an issue, while libraries do remove the capitalization in their catalogs, plenty of publishers send out the data like that. So its not really about the bots, even if they were added by bots you can't just solve this automatically, since capitalization doesn't have 100% fixed rules. Alone in English you will run into issues with acronyms and proper nouns. Kordishal (talk) 18:52, 2 October 2026 (UTC)Reply
Wikidata Query Service Days: program is published
Latest comment: 12 days ago1 comment1 person in discussion
Hello everyone,
We are excited to share the program for the upcoming Wikidata Query Service Days, taking place online from October 17 to 23.
This event is part of the migration of the Wikidata Query Service from Blazegraph to QLever. It is designed to present the next steps of the migration and help you prepare for the changes. Whether you are a Wikidata editor running maintenance queries or a reuser or tool builder who will need to update your tools, this event is for you.
The full schedule is now published. You can find it on the event page here:
By becoming notable according to the relevant notability policy and then have someone write an article about you. You really can't force it. Kordishal (talk) 15:49, 1 October 2026 (UTC)Reply
please can you write About my brand because my brand is famous Alinationrecord
Latest comment: 12 days ago1 comment1 person in discussion
Sudheesh poolakkool is a malayalam poet and writer He pablished his poetry collection aham 2024.his poem are featured in compilations like Ezhuthupurayil and Thusharam --Sudheesh poolakkool (talk) 07:05, 2 October 2026 (UTC)Reply
Properties ready for creation
Latest comment: 11 days ago1 comment1 person in discussion
Latest comment: 11 days ago1 comment1 person in discussion
I found some odd behaviour in a query and posted about it in question on the talk page for bodhrán Q244976. Can anyone help? I suspect some entries for musical instruments aren't set up properly. GoPlayerJuggler (talk) 15:13, 2 October 2026 (UTC)Reply
Imprisonment
Latest comment: 11 days ago3 comments3 people in discussion
When looking at the German, English and French articles linked, and the descriptions they all refer to different concepts in both items. And I doubt its gonna get better with the other dozen or so languages linked.
If I look at the German Wikipedia pages, they seem to distinguish whether or not it's the government is responsible or not. Probably, whether or not a court decision is responsible would be an additional criteria that someone might use to distinguish it.
Cleaning it up would need thinkin about the different concepts and them probably moving a lot of Wikilinks around. This kind of cross-lingual work is probably best done by having a conversation with an LLM about it. ChristianKl ❪✉❫ 20:32, 2 October 2026 (UTC)Reply
Register of British Slave Traders & M'n'M
Latest comment: 11 days ago1 comment1 person in discussion
Latest comment: 11 days ago2 comments1 person in discussion
Is there a Wikidata property equivalent to the section or department of a newspaper, magazine or other periodical? For instance, the enwiki "Cite news" template has |department= which has values e.g. Sports, Obituaries, Lifestyle, Letters to the Editor, Classifieds, etc. When describing the same article item, Wikidata has section (P958) but this is for sections of a (legal) document. Am I missing something, or should I propose a property? — Jonathanischoice (talk) 01:01, 3 October 2026 (UTC)Reply
.jpg)
.jpg){kind=link}
_VI-0232.png)
