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/09.
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: 2 days ago18 comments8 people in discussion
Reviewing Wikidata:Properties for deletion over time, I have noticed a recurring pattern: deletion requests for identifier properties based on the sole premise that the underlying website behind formatter URL (P1630) is no longer available online, or the identifier scheme has been superseded.
I would like to open a discussion on whether this should remain a valid ground for property deletion. Identifiers in Wikidata are fundamentally entity keys for linked open data and authority control, not merely clickable external links.
When a website or database goes offline, deleting the corresponding Wikidata property presents several issues:
Loss of data provenance and historical mapping: The ID itself retains value. Scientific literature, legacy datasets, offline dumps, and external archives still reference these specific identifiers. Preserving them in Wikidata maintains cross-dataset traceability.
Potential resurrection or migration: Web services frequently undergo domain changes, server migrations, or rebranding. If a database comes back online under a new URL or host, having deleted the property creates unnecessary overhead to recreate and re-link the data.
Distinction between Property and Formatter URL: A property represents a unique identifier scheme from an external authority or dataset. The availability of the current website (formatter URL (P1630)) is just an access layer, not the identifier itself.
Proposed alternative approach
Instead of deleting identifier properties when a website goes down:
Mark the property as deprecated or add a dedicated property state/qualifier indicating the target database is offline or unmaintained, or if the maintainer superseded the identifier scheme (eg. MobyGames).
It would be a bad idea to delete old identifiers because "it's out of service". We don't go around deleting dead links from Wikipedia articles for that exact reason. Deprecated information still has archival value. Good point in bring this up. Aplucas0703 (talk) 01:24, 3 September 2026 (UTC)Reply
Agreed! I think the deletion policy could be updated with a property section, currently they are just handled the same as items, which seems weird to me.
At the same time I do not believe it would be possible to establish a policy that can be applied to all cases. Looking at the deletion request page, these requests are very diverse and are the majority of the requests there.
So my suggestion would be to have a different board for defunct/dead identifier properties where the community can discuss how this should be handled.
Identifiers may be migrated to a new system
Identifiers may be merged with another id
Maintainer of the identifier takes it down
And probably more, but I think in most cases it will make sense for Wikidata to preserve the id / original id, but not necessarily always the same way. Possible measures could be and sometimes multiple:
Mark as deprecated and create a specific reason for deprecation item that explains why this ID is deprecated.
Adjust the property name and description to reflect the new state
Add a qualifier that marks as defunct without deprecation
replace formatters with archive link
replace formatters with new target
replace all the ids with a new system
and probably other options
Additionally it might make sense to implement these measures in an automated way as there are often thousands if not tens of thousands of entries. Which would mean some intervention that someone would have to implement and so discussing what that should be makes sense. Kordishal (talk) 07:27, 3 September 2026 (UTC)Reply
"Add a qualifier that marks as defunct without deprecation" I thing the rank at item-level may be changed its rank to deprecated, adding the qualifier reason for deprecated rank (P2241) with the new item I suggested above as value.
"replace formatters with new target" If the organizaction just changed the target, just change formatter URL (P1630) value. If the organization does not longer exist and other organization takes the control of the website, request a new property for the new organization, even if the ID remains exactly the same, and use values formatter URL (P1630) directing to the new website.
"replace all the ids with a new system" As I understand, you want to implement a new system for implementing IDs, so I cant answer if Im unsure.
"replace all the ids with a new system" -> I meant to say that there might be situations where the new identifiers can be generated from the old ones or vice versa, then it might make sense to just keep the current property and replace existing identifiers with the new ones, since you don't actually lose anything. At the same time we do often add ISBN 10 and ISBN 13, though this case is a bit different since books older than ISBN 13 don't have one.
Generally most of my post was just hypothetical scenarios based on the properties currently being requested for deletion. The diversity of which I think is why it would make sense to have a separate board for this.
If the organization becomes defunct and other organization takes the database and the same scheme: propose the creation of a new property, keeping the older identifier, as it refers to the older database.
I believe this is for the most part current practice. Determining residual value is central to the deletion discussion. Consensus in not a simple majority. If someone argues that an ID property that no longer has a website is still useful and no one counters that argument, that suggests the property should not be deleted, but instead archived. On the other hand if we expect that the ID won't show up anywhere else, it may have lost all its application and we don't need to be shy about deleting it. Quite a few ID properties are really URL slugs and prone to changing if the website gets a redesign. If an ID has been shown to be unstable, that might be an argument for deletion. Most IDs with formatters are probably crawled by an archiver so in practice there should be fairly few properties that ought to be outright deleted. Infrastruktur (talk) 10:38, 3 September 2026 (UTC)Reply
@Amitie 10g: As I read your core argument here, I find myself shaking my head in agreement in theory. However, I think some practical considerations lead me to divergent conclusions. It's quite possible that some database might have used an identifier, and suddenly gets publicly released when its owner goes bankrupt or decides it's so antiquated as to be worthless.
And yet... I nominated Charity Navigator ID (obsolete) (P4861) at Wikidata:Properties for deletion/P4861. This value was fairly stable for an extended period of time. It's plausible that some other databases might have referenced it at one time. Why do I think we're better off deleting it? Because it's data quality was decreasing over time. Editors have routinely added incorrect values, specifically IRS Employer Identification Number (P1297) which Charity Navigator currently uses in URL slugs. Editors also routinely remove properties for deprecated properties and withdrawn identifier values. Anyone actually interested in this data is better off reading an archive of Wikidata than reading the current values. I have personally gone through and cleaned up these incorrect values repeatedly. I won't bother again.
In an ideal Wikidata, perhaps we keep these properties but have a website feature that makes editors click through a large scary warning dialog, urging them to be sure they really know what they're doing before editing a disused identifier. Frankly, I think the utility of some of these identifiers, like Charity Navigator ID (obsolete) (P4861), is small enough that it's not worth the trouble. Let's delete it and be done. Daask (talk) 01:29, 4 September 2026 (UTC)Reply
Daask, I carefuly read your comments,and I concluded you're right. Bad quality or heavily corrupted identifiers is an issue that fixing is worthless. Therefore, I reflected your concerns onto my proposal (see below section) to flexibilize it by adding "Involve heavily corrupted, mismanaged, or structurally misleading data ...", and, adding "and stable" tag on the "Belong to a valid and stable identifier" claim, and modified "Properties should not be requested for deletion nor deleted" with "Properties that deletion should be avoided". Regards
Before opening a Request for Comment, I propose changes/updates to the Deletion policy here, the Project Chat, specially because the Deletion policy lacks of a section regarding properties! What I suggest for now, is adding the following to the policy:
== Deletion of properties ==
General properties
Properties may be requested for deletion when
They involve poor data design (e.g., lack of atomicity, such as combining multiple data types in a single field).
They involve heavily corrupted, mismanaged, or structurally misleading data that leads to persistent data entry errors, widespread misuse, or an unsustainable maintenance burden for the community.
They are non-identifier properties that are no longer used in any entities and have been formally marked with their obsolete status (e.g., by adding obsolete Wikidata property (Q18644427) via instance of (P31), adding a property constraint, and/or updating the property label/description).
The property belongs to a valid and stable identifier, even if the maintainer of the external database has superseded the scheme. To adopt the new scheme, a new property proposal must be opened. Claims using the old, superseded scheme may be ranked as deprecated, where appropriate, and archive URL (P1065) may be used as a qualifier for archival links if the original URL formatter is dead.
Identifiers in Wikidata are fundamentally entity keys for linked open data and authority control, not merely clickable external links.
I don't understand using deprecated rank on a correct statement. The whole point of this discussion is that these statements are correct and the claim continues to be true even if no formatter URL (P1630) is available for the property or other registry by which to verify it. Daask (talk) 03:23, 4 September 2026 (UTC)Reply
I think this goes into the right direction. A few points:
Should there potentially be separate sections for properties in general and then one specific for external id properties? Since the third part only applies to them.
Are the speedily deleted based on examples you know off? If not I don't think this is necessary at this point.
I would avoid using the term "deprecated" in the first policy. Additionally -> The property should then be marked for their new status, for example with obsolete Wikidata property (Q18644427) or similar item via instance of (P31), a property constraint, and/or a change to the property label/description.
Remove the " from the deprecated in the last policy.
Latest comment: 3 days ago2 comments2 people in discussion
Hi! I’ve been working for quite some time on reviewing the import of biographical entries from the Czech database. There are currently around 6,000 entries about people from the USSR and Russia that don’t have a Russian label. However, roughly 15–20% of these people already have corresponding Wikidata items under other entries.
Is there any tool that could help match the Czech-labeled entries from this list that are missing a Russian label with existing Wikidata items, for example, based on similar birth and death dates?
Also, is there any way to compare Czech Latin transliterations (e.g. *Timofej Onisimovič Tverdynskij*) with Russian Cyrillic spellings (e.g. *Тимофей Онисимович Твердынский*)? In other words, something that could account for transliteration patterns such as Czech *j* = Russian *й*, etc.
In this case I would probably create table with names, dates and occupations and add one more column "transliteration", Because I know only letters from russian alphabet, I would use simple replacing f->ф, d->д etc. For this column can OpenRefine find best possibilities on Wikidata according to label. JAn Dudík (talk) 05:58, 9 September 2026 (UTC)Reply
Latest comment: 2 days ago3 comments2 people in discussion
HI,
I have imported the famous "Don't disrupt projects to illustrate a point" policy/guideline/essay (depending on the project) here, Wikidata.
For now, I have developed an essay at my sandbox, mentioning aspects relevant to Wikidata, as well as importing some aspects from the Commons' counterpart relevant to this project. The objective of this thread is to officialy import that essay onto Wikidata: namespace (including the ability to be translated), and, if the community decide, upgrade it to a guideline or a policy.
I think this is a good idea. Perhaps it needs some time for people to do copy editing or other minor improvements (although I couldn't find anything I would like to change) and then we can put the suggested upgrade from essay to guideline to the Requests for comment process. Ainali (talk) 08:03, 5 September 2026 (UTC)Reply
If I don't see substantive objections, I'll move it to the Wikidata: namespace in the next few days. Feel free to edit it once moved, but please discuss substantive changes first. The intention is to consider upgrading the essay to a guideline or policy later. Amitie 10g (talk) 21:01, 10 September 2026 (UTC)Reply
Latest comment: 2 days ago3 comments2 people in discussion
I have created a new item for Molly Miller (Q141287500), an English historian who died in 1982, and looked for identifiers. Two of them list books written (or illustrated) by the historian and about four other people called Molly Miller, who don't have Wikidata items. Do I need to create a conflation page?
Rather than creating a conflation page, I would suggest reporting the conflation to whichever source hosts the identifier so that they can correct it. Wikiproject Authority Control set up a table listing ways to contact sources on- and off-wiki. I'd recommend writing to the Library of Congress directly about their conflation since the linked books are BIBFRAME Work (Q107364994) records, which can only be edited by them, sadly. If there is an error on the author page itself other than badly-connected Bibframe work records, feel free to ping me and I'll try to sort it out.
I'm not sure it's necessarily useful for Wikidata to host items that only contain external identifiers that were deprecated by the source, which is what Molly Miller (Q141347609) will be when the data sources solve the problem. But I don't have a strongly-held opinion about that, so if others think it's useful please go ahead and make them. Mcampany (talk) 15:04, 10 September 2026 (UTC)Reply
Historical events on a 3D globe — feedback on dates and locations
Latest comment: 6 days ago3 comments3 people in discussion
I built Geotemporal Transurfing, a prototype for exploring historical events on a 3D globe. You can orbit Earth, move forward or backward in time, and see what was happening elsewhere around the same time.
The dataset is collected offline from Wikidata, Wikipedia and some manual event inclusions, with media from Wikimedia Commons. I'd appreciate feedback on the experience, event coverage, features, and accuracy of representation of the events. Are there properties, queries or existing projects I should look at?
The "Read more" button link is not obvious. I started wondering where each piece of information came from.
Additionally, often the headline is not in the "Read more" source. For transparency, it should be more clear where the headline comes from, or if it is made by you.
It does have the feel of a raft of AI generated sites appearing at the moment, all black with pastel shades, which really are not easy to read. In particular most of your fonts are far too small. On a desktop display I really struggled to follow the page. It was also a huge shock when Read More took you to to a conventional black on white display. You want a better country boundary dataset, its looks too crude. Obviously the filters need work, the 64th BAFTAs is not normally considered a conflict!. I'd want to select date ranges with dropdowns, and in most cases that would be a year, not a month. Vicarage (talk) 08:20, 6 September 2026 (UTC)Reply
can i copy entire Ps and Qs from one identical item to other multiple or single item?
just now found moveclaim in gadgets. but its also copying reference. this involves multiple times of work. perhaps i should use new and proceed from there. কল্কি (talk) 06:53, 6 September 2026 (UTC)Reply
Yes, the point of moveclaim is that it copies complete claims, including references, rank and so.
To copy lots of bare values (without copying references or anything else), specially if they are about the same property, I suggest using a query to retrieve values, an spreadsheet to edit them and QuickStatements to upload them. Pere prlpz (talk) 07:50, 6 September 2026 (UTC)Reply
Latest comment: 6 days ago6 comments3 people in discussion
I have a government agency unit that is supervised under ministry X, that is tasked to operate Y airport, then I tried to search for the appropriate item to fill the instance of (P31) value, and found three candidates:
The problem may be that, while each item has a label, a description and several "also known as" phrases in English, there is much less information in Indonesian. TSventon (talk) 11:14, 6 September 2026 (UTC)Reply
Latest comment: 5 hours ago48 comments10 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 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 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
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
Latest comment: 3 days ago6 comments5 people in discussion
There are so many uses of this value (oh, I forgot that Reasonator became useless...). I didn't remove them because I believe that the problem is more deep and should be resolved somehow. What if... we would use special value "multiple values" (in addiion to "unknown" and "novalue") instead? Infovarius (talk) 19:43, 6 September 2026 (UTC)Reply
I think they want a generic version of that when it is only known that there are multiple values, but not necessarily known what they are. I'd agree though that this does not warrant the same special treatment as no value and unknown special values.
And really there aren't that many examples of its use as far as I can tell. There are about 40 uses and the few I looked at were likely because the linked wiki article had various as the value in the info box for the property. In this case it would make a lot more sense to replace it with the actual value or no value at all. Kordishal (talk) 14:48, 7 September 2026 (UTC)Reply
Latest comment: 5 days ago3 comments2 people in discussion
I was happily coding up an application using centuries, decades and years and am baffled why we mostly, but not always don't have start and end dates. Now they do have points in time with appropriate precision, but that is of limited use when doing a SPARQL query as that throws to a particular date, the start of the period, which is of limited use if I wanted the 1960s to give me 2 date strings 10 years apart. I could hack the point in time outside WD, but it seems better to do it inside. Before I add start and end times at highest precision, is there some obvious reason I'm missing why something so fundamental is like this?
And I'm amused that the 9th century ends on 5th January 0901 according to SPARQL, while the 10th starts on the 11 th January 0901. Quite a bender that New Year! Vicarage (talk) 22:45, 6 September 2026 (UTC)Reply
Yeah because of Julian/Gregorian, stuff. Wikidata know whether it is Julian/Gregorian but not sparql. Sparlq assumes you want all in gregorian and "transform" the date into Gregorian henceforth an apparent move in the date. There are workarounds that you can ask an IA to help with.
A date in "1960s" means somewhere in the 1960s, because a better precision is not available. Same rationale with 1960 (as a year) : it may have started somewhere in 1960 and ended somewhere in 1960.
Latest comment: 6 days ago2 comments2 people in discussion
I'm not sure if I would be better to use member of (P463) or position held (P39) for members of committees of the Scottish Parliament [3]. Not sure if it makes sense to use 'member of' since this is more of a role fulfilled within the parliament than like a voluntary organisation, but from what I understand 'position held' would require creating another item for the membership of each of the 16 committees? Tigered27 (talk) 01:16, 7 September 2026 (UTC)Reply
Latest comment: 5 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-07. Missed the previous one? See issue #747.
Discussions
New requests for permissions/Bot:
HsfBot - Task/s: Mostly add missing Indonesian Wikipedia sitelinks to Wikidata items for taxonomy templates created by HsfBot on idwiki.
CrossrefIDsBot - Task/s: Adding Crossref ID, DOI, Print ISSN, and Online ISSN from Crossref dataset where they are missing in Wikidata.
CatmapperBot - Task/s: Add SocioMap ID statements for reviewed SocioMap category mappings, and provisionally add exact match URLs for reviewed ArchaMap category mappings until Wikidata approves an ArchaMap-specific identifier property.
BenchfolkBot - Task/s: Add or correct sourced statements on existing items after explicit human approval.
Pokémon Ability (Pokémon Ability assigned to this Pokémon species or form in games of the Pokémon series)
Collective bargaining coverage (Percentage of workers covered by collective agreement coverage. This is distinct from union membership rate, because non-union members can also be covered, for example France has 7% union density but 98% collective bargaining coverage.)
encompasses (specific entity this placeholder item may represent when the exact one is unknown)
marionetteist (Person who manipulates a marionette in real time to create the illusion of life.)
Schema examples: spaceport (E213): schema for spaceport (Q194188) locations, used to launch and receive spacecraft.
WikiProject Highlights: Project Medicine / Knee Arthroplasty - a comprehensive subpage to model the techniques and procedures for knee-related surgery.
Newest database reports: Same Humans/List by Occupations - this report presents possible human duplicates by comparing name and birth/death dates. They can be reviewed and flagged for merging and/or deletion.
Development
Sustainability:
We are looking into improvements to caching for Property labels (phab:T434204)
We are continuing to prepare the move of the entity_usage table to the extension database cluster. Moving the tables is tentatively scheduled to begin after 24. September. (phab:T427472)
Newcomer homepage: We are working on making the Newcomer Homepage show labels for Items instead of just the ID (phab:T429345)
Wikidata changes in Watchlist and Recent changes of Wikipedia and co: We are deciding how filtering will look for hiding language link changes on wikis where the sitelink has not changed (phab:T435904)
REST API: We are continuing to expand the support for Lexemes in the API, specifically creating a Lexeme, adding a statement to a Lexeme and adding a Form to a Lexeme
Are these "Help panel questions" templated, and if so can't they be made to show a Label in the title rather than a Q value, so the fact that this seems self-promotion is clearer?. its currently <nowowiki>Q141363686</nowiki> rather than Q141363686Vicarage (talk) 14:41, 8 September 2026 (UTC)Reply
Latest comment: 2 days ago1 comment1 person in discussion
The item for the concept of a wiki category has somehow become the same item as the project page page about categories/categorization. I had never really looked closed at the item, so I'm not sure how or why this happened. It may have been one of those unfortunate aggregations rather than a merge. Luckily it should be (in theory, anyway) fairly doable to split off the policy page as I assume very few links relate to the policy aspect instead of the category concept, but I'm very nervous about doing it myself! Any thoughts? Circeus (talk) 03:42, 11 September 2026 (UTC)Reply
Latest comment: 11 hours ago1 comment1 person in discussion
Hello I have left a request to merge two names , Onofrio in italiano and in other languages are separated. You may find the page in russian , Онуфрий, it is the same name ~2026-49241-28 (talk) 18:00, 12 September 2026 (UTC)Reply
Latest comment: 9 hours ago1 comment1 person in discussion
The other day, I noticed an inconsistency in the English labels for train stations in the San Francisco Bay Area (Q213205): many ended with "station" per the English Wikipedia, while a number of others did not (and never did). For consistency within these systems, I relegated the "station" form of each station to an alias and added the proper name as the mul label. Another editor has asked me to undo some of these changes, so I want to get a second opinion from the community. Please see my full reasoning in Wikidata talk:WikiProject Railways#Removing disambiguators from train station labels. Thank you.
Latest comment: 1 hour ago1 comment1 person in discussion
esse é um canal criado pelo criador de conteúdo Samuel Martins de Borba casado com Norberline Rodrigues Neitzke desde 2023,nascido em 29/04/2005 É cristão escrevendo livro ,e ligado com a doutrina calvinista,criador do canal Esclarecendo as Escrituras para esclarecimentos e curiosidades bíblicas Samuel Martins de Borba (talk) 03:43, 13 September 2026 (UTC)Reply
Strongly agree, a board where we don't just request the deletion but aslo other measures.
.jpg)
.jpg){kind=link}
_VI-0232.png)
Done - Fixed London Borough of Wandsworth (Q210563) as well, as that had Westminster instead of this one. The rest of the LB's look like they were added correctly, but couldn't find a Waltham Forest pronunciation audio. Kordishal (talk) 11:20, 7 September 2026 (UTC)
