Jump to content

Wikidata:Project chat

Edit links
Add topic
Shortcuts: WD:PC, WD:CHAT, WD:?
From Wikidata
Edit

Free access parameters

[edit]
Latest comment: 20 hours ago10 comments4 people in discussion

[moved from Wikidata talk:Property proposal#free access parameters ]

CS1 templates have indicate whether certain identifiers are freely accessible or not. See en:Help:Citation_Style_1#Access_indicator_for_named_identifiers

In practice, this is how it's used in citation templates

({{doi|10.1038/495426a|doi-access=free}})/ ({{doi-inline|10.1038/495426a|doi-access=free}}) and others en:Template:Bibcode, en:Template:Hdl, en:Template:JSTOR, en:Template:OL, en:Template:OSTI, en:Template:SSRN, en:Template:S2CID

Currently, while Wikidata (I think) supports bibcode, doi, hdl, jstor, ol, osti, ssrn, s2cid, their access parameter are not supported. They should be supported.

I tried making a request for these parameters via the forms, but they are completely unintelligible to me, and half an hour later I'm not even halfway through the fields without any clue about what I'm even answering.

So here's my request for that. A list of free DOI registrants can be found in en:Module:Citation/CS1/Configuration (more in en:Module:Citation/CS1/Configuration/sandbox) as well as specific strings for specific registrants. For the rest, you can probably import access parameters directly, as well as those of cs1 templates + Headbomb (talk) 15:46, 23 August 2026 (UTC)Reply

At User:Headbomb's request, I drafted Wikidata:Property proposal/Bibcode access status, which awaits his example values.
I have also questioned, in the "Motivation" there, whether we need multiple properties, or whether a single generic property to hold multiple values will suffice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 23 August 2026 (UTC)Reply
This could also be a qualifier, for the individual identifier values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:03, 23 August 2026 (UTC)Reply
While Wikipedia only supports |identifer-access=free, there could be other levels supported like |identifer-access=subscription for things like |mr=, |zlb=, or |identifer-access=embargo (for something like a PMC with and embargo date, like |pmc=12824308 + |pmc-embargo-date=February 1, 2027 as in en:25CN-NBOH. Headbomb (talk) 16:43, 23 August 2026 (UTC)Reply
Likewise if Wikidata wants to specifically flag arxiv links as free, it could have |arxiv-access=free. Wikipedia doesn't need it because it automatically flags all arxiv links as free. Headbomb (talk) 17:18, 24 August 2026 (UTC)Reply
@Jonathanischoice: points out that online access status (P6954) might be used for this. Used in No detectable supernova remnant near the pulsar PSR 1930 + 22 (Q68550452) for the bibcode, for example. Headbomb (talk) 12:18, 27 August 2026 (UTC)Reply
See [1], which maybe takes care of this? Headbomb (talk) 12:24, 27 August 2026 (UTC)Reply
I updated it to use qualifiers rather than references, but yes - that's the gist of it I was thinking of. Jonathanischoice (talk) 13:34, 27 August 2026 (UTC)Reply
I strongly support using online access status (P6954) as a qualifier for all identifiers and oppose creating separate property-specific qualifiers like Bibcode access status. Daask (talk) 03:49, 4 September 2026 (UTC)Reply
Hi @Pigsonthewing - I had the same thought at about the same time, and I'd like to add that to Cite Q which should be straightforward, but I'd like to get the Thesis and retracted indicator changes in first before the sandbox gets too cluttered. — Jonathanischoice (talk) 14:36, 29 August 2026 (UTC)Reply

Linking items

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

Q108830078: no description is a son of the fourth generational owner of Joy Hing's Roasted Meat (Q10894923): Restaurant in Hong Kong (a family business).

how to record this relation in wd? RoyZuo (talk) 08:25, 26 August 2026 (UTC)Reply

@RoyZuo add child (P40) property Shushugah (talk) 08:49, 26 August 2026 (UTC)Reply
how? child of what item? RoyZuo (talk) 15:42, 1 September 2026 (UTC)Reply

Search by ISBN

[edit]
Latest comment: 4 days ago10 comments6 people in discussion

Almost every book in wikidata contains the ISBN attribute. I wasn't able to use the search function of Wikidata to identify any book by its ISBN number. I tried e.g. 9780140449136, 978-0-140-44913-6, or these numbers accompanied by "ISBN". What can be reason for this ? ~2026-46878-68 (talk) 11:28, 27 August 2026 (UTC)Reply

It's possible but it's a bit weird and definitely not something you would ever guess on your own. You need to use the haswbstatement: search operator. You want to reference one of two properties, ISBN-13 (P212) or ISBN-10 (P957). The properties use the values with dashes, so following the example you gave, you'd want to search for haswbstatement:P212=978-0-140-44913-6. (It looks like we don't have that one, by the way. Or at least if we do, it needs to have a ISBN-13 (P212) statement added.) You may want to try Special:BookSources, which will give you a list of links to various sources of information about a book using its ISBN. Kinsio (talk ★ contribs) 12:07, 27 August 2026 (UTC)Reply
Thank you.
As far as I can see an ISBN number should be written as follows:
978-0-140-44913-6 (xxx-x-xxx-xxxxx-x)
It appears the book with that ISBN number has been registered in Wikidata as
978-0-14-044913-6 (xxx-x-xx-xxxxx-x)
Now I was able to find it, using this (syntactically) invalid ISBN number.
Your suggestion to use haswbstatement:P212=978-0-140-44913-6, appears to be not necessary to find Crime & Punishment.
Maybe someone could correct the invalid ISBN number for Pjotr.
But: since ISBN numbers have a strict format, I think the search algorithm should be able to convert a 13 character long 'number' into a valid ISBN-number. ~2026-46878-68 (talk) 14:38, 27 August 2026 (UTC)Reply
I believe that 978-0-14-044913-6 is the correct hyphenation, at least according to the list on English Wikipedia en:List_of_group-0_ISBN_publisher_codes, where it is stated that 978-0-14 is the prefix assigned to the Penguin Books publisher and the prefixes with 140, 141 etc are nonstandard. Why do you think that 978-0-14-044913-6 is synactically invalid and 978-0-140-44913-6 is correct? VLysikov (talk) 18:49, 27 August 2026 (UTC)Reply
It's possible that the ISBN on the book has incorrect hyphenation. The ranges and prefix lengths are available from https://www.isbn-international.org/range_file_generation. Would it be useful to have two P212 statements, with the rank of one set to deprecated or preferred? Peter James (talk) 19:50, 27 August 2026 (UTC)Reply
ISBN codes validate only the numbers. The hyphenation exists for the benefit of human eyes, but they are not part of the actual ISBN. For automatic search I would generally recommend to remove the hyphens. Libraries will usually remove them as well (at least the library I work for and other libraries in my country). Kordishal (talk) 06:49, 28 August 2026 (UTC)Reply
Yeah, I was honestly surprised that Wikidata includes the hyphens. Maybe we shouldn't. Kinsio (talk ★ contribs) 00:09, 29 August 2026 (UTC)Reply
There are many discussions on the property discussion page about that and currently more people seem to think that the hyphens are helpful. See Property_talk:P212. There also appears to be someone who has a maintenance script that adds in hyphens based on the table provided, so I think it would unfortunately be difficult to change this. The main argument is that adding hyphens is more difficult than removing them, but to me that seems unnecessary as I don't see any common use cases where you actually want the hyphens. Usually all you want to do with the ISBN is to search for the book, and that is almost always more successful if the hyphens aren't there. Kordishal (talk) 08:01, 29 August 2026 (UTC)Reply
You give the "search algorithm" far too much credit. For one thing, Wikidata is really mainly meant to be accessed with APIs like SPARQL query (which can do things like use regular expressions to match the value both with and without the hyphens, or with varying hyphen placement). haswbstatement: really just covers the case where you know exactly what the value should be – and in this case that includes hyphen placement, because as a property with the "external identifier" data type, the value of ISBN-13 (P212) is stored as a string of characters. Kinsio (talk ★ contribs) 23:24, 27 August 2026 (UTC)Reply
Maybe we should have a bot that fixes incorrectly-hyphenated (or -spaced) ISBNs? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:44, 31 August 2026 (UTC)Reply

Storing academic lab information?

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

For Manolis Kellis's Lab, I was tempted to add this link as an official website (P856). However, there are also academics with personal websites and lab websites: take the XLab, which is run by Juliana Schroeder. What would be a good way to store lab information? (Some labs can also be run by several co-PIs: would it make more sense to treat labs as actual objects themselves? I can't find any examples of this happening for academic labs, but national labs such as LANL are treated this way.) LeoDog896 (talk) 22:00, 27 August 2026 (UTC)Reply

perhaps object of statement has role (P3831) --> lab website (Q6466676) on the PI's item. Other URLs could be qualified as personal web page (Q2737701) or faculty web page (Q109647055). -Animalparty (talk) 15:55, 31 August 2026 (UTC)Reply

People with different names in different contexts

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

i just found that Diane Yap (Q102435716): American mathematician, Ph.D. University of Hawaii 2012, founding member of the Friends of Lowell Foundation's surname is yap (葉) after her father, but in chinese she takes the surname 張 after her mother, according to a news report.

i guess for all "official id" her surname is yap and only yap since usa doesnt have chinese as a language on its documents, but referring to her in chinese is 張 and only 張.

how to record this nuance? set surname = those two items, but how to note down the nuance that she doesnt use two surnames simultaneously, but one for each writing system?

and how to handle people's different names in different languages in general? i've asked a similar question before: Property_talk:P1559#c-RoyZuo-20260409154400-Property_for_formal_names_in_non-native_and_non-fluent_languages. RoyZuo (talk) 12:12, 28 August 2026 (UTC)Reply

I would add both family names and then use one of these three qualifiers to differentiate them:
language of work or name (P407)
writing system (P282)
applies to jurisdiction (P1001)
I am not sure from your description which one would actually apply. Kordishal (talk) 14:43, 28 August 2026 (UTC)Reply
@RoyZuo If you can find a good reference to attach, it may also clarify which qualifier applies as well. Kinsio (talk ★ contribs) 15:49, 28 August 2026 (UTC)Reply

Huge change

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

Would it be possible to standardize the Bulgarian descriptions of items that have Wikimedia category (Q4167836) as their instance of (P31) to "Уикимедия категория", rather than "категория на Уикимедия", "категория в уикимедиен проект", etc.?

The same could be done for templates: preferably "Уикимедия шаблон". --Like the windows (talk) 21:49, 28 August 2026 (UTC)Reply

A lot of the translations are added by bots. Eg [2] which had категория на Уикимедия added by User:Mr.Ibrahembot. That bot does many languages at once and I do not know where the translations come from. Secretlondon (talk) 12:14, 30 August 2026 (UTC)Reply
User:Mr.Ibrahembot adds descriptions according to User:Mr. Ibrahem/descraptions.json and it replaces descriptions – which would be needed in this case – according to User:Mr. Ibrahem/replace descraptions.json, if I understood correctly. You may want to contact Mr. Ibrahem to have him change the descriptions. --Volvox (talk) 12:43, 3 September 2026 (UTC)Reply
I think that's probably the best I can do for now. --Like the windows (talk) 13:10, 3 September 2026 (UTC)Reply
The Bulgarian label of Wikimedia category (Q4167836) may be disputed
Like the windows changed it to "Уикимедия категория" at 12:23, 7 August 2025 diff
Vargenau changed it to "категория на Уикимедия" at 11:55, 19 May 2026 diff
TSventon (talk) 14:09, 30 August 2026 (UTC)Reply
Vargenau is French, while I am Bulgarian. I think I know what I am doing. --Like the windows (talk) 14:42, 30 August 2026 (UTC)Reply
Hello,
My bot is precisely standardizing the descriptions for categories.
It is standardizing to "категория на Уикимедия" as it is currently more common that "Уикимедия категория".
"категория на Уикимедия": 3 462 277
"Уикимедия категория": 2 166 005
Best regards, Vargenau (talk) 18:51, 30 August 2026 (UTC)Reply
Which is the better translation? It doesn't matter as much which is the most common. Secretlondon (talk) 10:20, 31 August 2026 (UTC)Reply
Exactly. And in my opinion, the latter of the two sounds better, even though it's not the most common. --Like the windows (talk) 13:10, 3 September 2026 (UTC)Reply

Named after and languages

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

Anindilyakwa (Q30663861) has an English name of 'Anindilyakwa'. The source says it's named after Anindilyakwa Land Council (Q130287034). The word 'Anindilyakwa' is derived from the Anindilyakwa (Q2714654) language, spoken by the Anindilyakwa (Q2714654) people. How do I say the place is named after the Land Council and the placename is derived from the language? Stuartyeates (talk) 03:47, 29 August 2026 (UTC)Reply

Maybe named after (P138) pointing to Anindilyakwa Land Council (Q130287034) and with the qualifier language of work or name (P407) to Anindilyakwa (Q2714654)? Then reference the source that explains it in more details. Potentially use applies to part (P518), but I am not sure how you would use that to specify the first word of the name, but at the same time it should be fairly clear how that is meant. Kordishal (talk) 06:14, 29 August 2026 (UTC)Reply

Special:BookSources page has quite a few broken links

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

The page Special:BookSources has quite a few broken links when trying to use it. In some cases the DNS is even redirected to unrelated websites. I can't edit special pages and not sure who can. I'd be happy to lend some support to whoever can actually edit the page.

Example: https://www.wikidata.org/wiki/Special:BookSources/3-598-11666-7 Kordishal (talk) 08:37, 29 August 2026 (UTC)Reply

I've update some parts of it, but there is still definitely some work to be done. Tried to update it from en.wiki, since that is much more up to date, but some of the work there requires changes since the CSS applied isnt the same. Kordishal (talk) 05:47, 30 August 2026 (UTC)Reply

Incorrect English label on Q7387349

[edit]
Latest comment: 4 days ago9 comments3 people in discussion

The English label on S. Abdul Khaliq Sweets (Q7387349) is "S. Abdul Wahid Sweets", but the item's sitelinks are the English and Bengali Wikipedia articles on "S. Abdul Khaliq Sweets". These are two different Pakistani companies. Could an uninvolved editor correct the label to match the sitelinks? Disclosing that I run S. Abdul Wahid and have a separate item at S. Abdul Wahid (Q141234721), so I'd rather not edit Q7387349 myself. Firewire787 (talk) 07:16, 31 August 2026 (UTC)Reply

This seem to be the result of promotional editing/ vandalism (the English article was hijacked several times in now-reverted page moves). I have fixed it and added some detail. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 31 August 2026 (UTC)Reply
Thanks Andy. Firewire787 (talk) 13:32, 31 August 2026 (UTC)Reply
Are you the person who previously edited from the account User:Firewire78? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:13, 31 August 2026 (UTC)Reply
yes ~2026-47427-59 (talk) 14:40, 31 August 2026 (UTC)Reply
Please do not use multiple accounts. If you have lost or forgotten the password to the earlier account, please use your new account to mark it as dead and replaced.
And please remember to sign in before commenting. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:44, 31 August 2026 (UTC)Reply
Sorry, b=my bad. Did not realize I am logged out. For transparency: that account was blocked on the English Wikipedia following a content dispute involving my own business. I am not editing Wikipedia. I am here on Wikidata only, and I disclose my conflict of interest on anything connected to it. Firewire787 (talk) 14:55, 31 August 2026 (UTC)Reply
If your account is blocked on the English Wikipedia, that does not mean it is blocked here.
If it is blocked on that Wikipedia, you may not edit there using any account. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:01, 31 August 2026 (UTC)Reply
I think I've done what you asked me to. Firewire787 (talk) 15:23, 31 August 2026 (UTC)Reply

Wikidata weekly summary #747

[edit]
Latest comment: 4 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-08-31. Missed the previous one? See issue #746.

Discussions

Events

  • Upcoming events:
    • WikidataCon 2027 will be hosted in Istanbul, Türkiye from 29 to 31 October 2027, in partnership with the Wikimedians of Turkic Languages User Group. The dates mark Wikidata's 15th birthday. More details to follow.
    • Wikidata Query Service Days, October 17-23: The next online event by Wikimedia Deutschland will be about the migration from Blazegraph to QLever. Learn what's changing, try the new system, and get help rewriting your queries. Register now!
    • Next LD4 Wikidata Affinity Group session – 1 September 2026: Adélie Ranville will present how Wikidata can support literature reviews. Event page — 16:00 UTC / 6pm CEST.
    • OpenStreetMap X Wikidata Meetup #92 Sep. 7 Time: 19:30-21:00 UTC+8 at Mozilla Community Space Taipei (Q61752245).
  • Looking ahead: Wikidata Day in New York City 2026 - hosted by the Pratt Institute School of Information on October 30, 19:00 - 23:00 CEST.

Press, articles, blog posts, videos

Tool of the week

  • Timetrail is a tool by Nahom Araya it visualizes the movement of Wikidata items over time by mapping their associated events and locations. Enter an Item ID/Name and select a supported property from the dropdown list to fetch a timetrail.

Other Noteworthy Stuff

  • The Wikimedia Deutschland software development plan has been updated to include activity estimates for the third quarter (Q3).
  • The Wikidata development team is proposing a redesign of Special:NewItem with a warning banner and conflict-of-interest checkbox to reduce the increase in promotional editing. We need your feedback on the wording and designs. Head over to Wikidata:Reducing promotional editing and share your thoughts on the talk page by 15 September.
  • Due to an increase of non-notable item creation, and their subsequent request for deletion (and undeletion), a new page has been created. Requests for new items exists for those who are unsure if their item idea is notable enough, or have a conflict of interest. The Wikidata Community can help by reviewing requests and offering advice.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • Query Service: We have continued adapting the Constraints system for the migration from Blazegraph to QLever.
  • Wikidata integration in the Wikimedia projects:
    • We are investigating how to treat watchlist and recent changes entries from Wikidata that are about adding, changing or removing a sitelink. These seem to be category of Wikidata changes not everyone is interested in and a candidate for filtering.
    • We looked into how to make the process of adding Wikidata support for a newly created Wikimedia projects less manual for the team and did a proof of concept for automating some of the database operations.

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

Weekly Tasks

Connect disambiguation pages

[edit]
Latest comment: 1 day ago7 comments4 people in discussion

Hi, these two disambiguation pages for Jorge Rodríguez ; Caracciolo and Phillip Island were recently created on the it.Wiki; is it possible to link them to Wikidata? I don't know the procedure could someone with more experience do it? Thanks in advance for the help. ~2026-47511-02 (talk) 09:50, 1 September 2026 (UTC)Reply

Jorge Rodríguez (Q14497342) already exists. Secretlondon (talk) 15:43, 1 September 2026 (UTC)Reply
Also Caracciolo (Q378251) and Phillip Island (Q846680). Peter James (talk) 18:36, 1 September 2026 (UTC)Reply
@Peter James @Secretlondon But it:Caracciolo is not listed as a disambiguation page on the it.wiki. The same applies to it:Fessura. I don't know what the problem is or how to solve it. ~2026-47756-03 (talk) 15:18, 3 September 2026 (UTC)Reply
The link was made to the Italian page on Caracciolo, but it was removed as the Italian page was deleted. Secretlondon (talk) 15:22, 3 September 2026 (UTC)Reply
@Secretlondon The page has not been deleted, but is present at it:Caracciolo. ~2026-47756-03 (talk) 16:20, 3 September 2026 (UTC)Reply
There was a temporary deletion to merge the history of it:Caracciolo (disambigua) and it:Caracciolo; I have restored the link. Peter James (talk) 16:54, 3 September 2026 (UTC)Reply

Chinese railway station codes

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

Railway stations in mainland China have both a non-unique pinyin code (Chinese: 拼音码) and a unique telegraph code (电报码), both of which can contain 3 latin letters. Most stations on Wikidata (e.g. Beijing North railway station (Q3267033)) put both of them under station code (P296) and it is therefore impossible to distinguish them.

Is this something that would merit two new properties? It would be possible to import some of the data from Wikipedia, Chinese Wikipedia uses "commercial_code" and "pinyin_code" properties in infoboxes while English Wikipedia tends to put items in bullet points in the "code" property. Artemisty (talk) 19:31, 1 September 2026 (UTC)Reply

I would agree that two properties would make our life easier. Ymblanter (talk) 18:16, 2 September 2026 (UTC)Reply

Updating P6010 to new schema?

[edit]
Latest comment: 1 day ago3 comments2 people in discussion

After looking at Encyclopedia of Alabama ID (P6010), it looks like the schema has changed since the property was first created. The encyclopedia no longer uses numerical codes for articles, but just a plain name (so John Abercrombie (Q1702161) is no longer "h-3659" but "john-william-abercrombie").

I can probably go through and update these fairly easily - since the old URLs redirect to the new ones, the process seems simple:

  • Grab all the old IDs from the property's Mix'n'match catalog
  • Follow the URLs to see where they redirect to (the new ID is in the redirected URL)
  • Replace the value of P6010 with the new ID (through QuickStatements)
  • Update P6010's statements as necessary to reflect the new schema

but this is my first time doing such a large change, so I want to make sure I do it right. Is there anything I have to do before doing this, like notifying a Wikiproject or discussing the change beforehand?

Thanks in advance. Tymewalk (talk) 22:40, 1 September 2026 (UTC)Reply

@Tymewalk: Before doing this you should create a new discussion on Property talk:P6010 and ping the people involved in the property proposal discussion (linked from the property), and perhaps anybody else who you see in the history of changes to the property. The question is whether the new ID should be a new property (this is often the best option here) rather than changing the old one. ArthurPSmith (talk) 20:39, 2 September 2026 (UTC)Reply
Thanks for the advice, I'll go open a discussion there. Tymewalk (talk) 17:33, 3 September 2026 (UTC)Reply

Save the date: Wikidata Query Service Days, October 17-23

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

Hello everyone,

We are excited to announce the upcoming Wikidata Query Service Days (October 17-23, 2026), an online event focused on the migration of the Wikidata Query Service from Blazegraph to QLever.

The event is organized by Wikimedia Deutschland in collaboration with the Wikimedia Foundation's Wikidata Platform team. It will be a space for the community to come together around this major transition.

📅 Register here to get the access link to the event: Event:Query Service Days 2026

What is this event about?

The Wikidata Query Service is moving from Blazegraph to QLever. This is a significant change that will affect everyone who uses WDQS. For example, editors running maintenance queries or developers maintaining tools and services. This event is designed to:

  • Update the community on the current state of the migration
  • Help people get familiar with the new system and try it out
  • Explain what is changing and what you need to adapt to
  • Provide hands-on support for rewriting queries
  • Give the development teams deeper insight into community use cases and concerns

Format and participation

The event will be fully online, with live sessions spread over one week (October 17-23). Sessions will be recorded and made available afterwards. We will try to cover different time zones by repeating key sessions at multiple times.

The Program

A detailed schedule will be published in the coming weeks. Sessions will include:

  • Overview of the migration and timeline
  • Demo of the query rewriting tool
  • Hands-on workshops for rewriting queries
  • Sessions for tool maintainers and data reusers
  • Bug triage and Q&A sessions

For any questions, feel free to write on the event talk page or reach out to Sannita (WMF), Danny Benjafield (WMDE), or myself directly.

We look forward to seeing you at the Query Service Days.

Cheers, Mohammed Abdulai (WMDE) (talk) 11:03, 2 September 2026 (UTC)Reply

We need your feedback on reducing promotional editing

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

Hi everyone. Over the past months there's been plenty of discussion around promotional editing on Wikidata. We're looking at ways to emphasise the importance of notability when creating new Items, and we're exploring a few options for Special:NewItem:

  • A clear warning banner explaining what Wikidata is and isn't for
  • A checkbox asking editors to confirm they are not creating promotional content
  • Clearer guidance on notability requirements upfront

We'd love your feedback on the mockups we've prepared at Wikidata:Reducing promotional editing.

Please share your thoughts by 15 September.

-- Mohammed Abdulai (WMDE) (talk) 11:08, 2 September 2026 (UTC)Reply

Luis Machado

[edit]
Latest comment: 1 day ago3 comments3 people in discussion

Hi, on the Italian Wikipedia, the page it:Luís Machado was moved to it:Luis Machado (without the accent), but it is not listed as a Wikimedia disambiguation page. Is it possible to fix this on Wikidata? I don't know what to do. Thanks. ~2026-47755-49 (talk) 12:17, 2 September 2026 (UTC)Reply

Fixed Added the article you mentioned as a sitelink on Luis Machado (Q140277725) (weirdly enough, it doesn't seem like it was there even before the move?) and added descriptions in both English and Italian, which I believe should fix the issue you're referring to. Checked the page on itwiki and it does now display "pagina di disambiguazione di un progetto Wikimedia" as the short description, as expected. Kinsio (talk ★ contribs) 13:05, 2 September 2026 (UTC)Reply
@Kinsio Thanks. The same problem would apply to it:Caracciolo and it:Fessura. ~2026-47756-03 (talk) 15:16, 3 September 2026 (UTC)Reply

Property P625 showing as 'State of Palestine'

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

The property P625, which should be 'coordinate location' is being rendered as 'State of Palestine'. I'm guessing some sort of vandalism, but I cannot see where. -- Chris j wood (talk) 12:18, 2 September 2026 (UTC)Reply

Looks like it was indeed vandalism that has since been fixed. You may need to purge the cache for the change to be reflected. Kinsio (talk ★ contribs) 12:41, 2 September 2026 (UTC)Reply

Mobile editing help

[edit]
Latest comment: 2 days ago4 comments3 people in discussion

I'm trying to update the URL for Crida LGBTI (Q104986237) as it is dead, and seems to replaced by this one. However, I cannot find the edit button for the URL, at least on mobile. ABx11 (talk) 15:10, 2 September 2026 (UTC)Reply

✓ Done Kordishal (talk) 15:32, 2 September 2026 (UTC)Reply
Improvements to mobile editing are in-hand. Meanwhile, I find it better to use "desktop site", or whatever your browser calls it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:10, 2 September 2026 (UTC)Reply
Makes sense, thanks! ABx11 (talk) 16:32, 2 September 2026 (UTC)Reply

Amazon Standard Identification Number (P5749) and albums

[edit]
Latest comment: 1 day ago4 comments2 people in discussion

This property is incompatible with albums. This is a bit of a problem since this would be a useful statement on an album. Take https://www.wikidata.org/wiki/Q138858381. Try to add the ASIN to it, and it will tell you that it is incompatible because it is an "album". This is despite the fact that it matches perfectly with the Amazon Music album ID (ASIN and AMAID are the same), and that every other streaming service has their ID on the item. This has a practical problem, which is that the Amazon Music release ID cannot be queried on an item like this.

Should we consider lifting that constraint or just add the Amazon Music album/release ID as its own separate property? Aplucas0703 (talk) 21:20, 2 September 2026 (UTC)Reply

The constraint for album says: Use the ASIN on the item for the relevant release instead. So its supposed to be on a specific release of the album and not on the album itself. And there is also Amazon Music track ID (P13398), which would be what the id is that you use no? At least they match what other IDs tell me. Kordishal (talk) 05:58, 3 September 2026 (UTC)Reply
@Kordishal The Amazon Music track ID is constrained to only be allowed on audio tracks and does not allow albums. Aplucas0703 (talk) 14:15, 3 September 2026 (UTC)Reply
Ah I got confused, because the track page has links to all the songs of the album. And looks like there are 13 859 albums with an ASIN, so adding it there seems already at least a bit of a practice and I can't find the original documentation why that is, but I assume the idea is to have an album as the work itself, and then separate items for each specific release. However, I don't know what these would be called and couldn't find the relevant documentation. Maybe you could ask on the wikiprojekt music page? Or otherwise start the discussion on the property page to potentially change the constraint and ping whoever added it originally Kordishal (talk) 16:43, 3 September 2026 (UTC)Reply

Should identifier properties be deleted when the external website goes offline?

[edit]
Latest comment: 20 minutes ago16 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.
  • Archivability: Many "dead" databases remain accessible via the Wayback Machine (Q648266), archive.today (Q13515725) (use it under your own risk), or institutional data repositories. The formatter URL (P1630) can often be updated to point to archived snapshots.
  • 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).
  • Use the archive URL (P1065) qualifier as we use it at Wikipedia for references (even, there is a bot that update dead links to Wayback Machine (Q648266)).
  • Reserve property deletion strictly for cases involving bad data design, copyright/privacy violations, or widespread invalid/spam identifiers.

I would welcome the community's thoughts on establishing a clearer consensus or guideline regarding offline identifier properties. --Amitie 10g (talk) 21:42, 2 September 2026 (UTC)Reply

I agree that deleting the identifier is too final, for all the reasons you give. Using an instance of (P31) offline marker seems preferable to deprecation. Vicarage (talk) 21:52, 2 September 2026 (UTC)Reply
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
Wikidata:Requests for comment/Handling of stored IDs after they've been deleted or redirected in the external database had a similar outcome (keep outdated properties and property values) but was inconclusive about how to apply it. Epìdosis 07:12, 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
Kordishal, regarding your comment:
  • "So my suggestion would be to have a different board for defunct/dead identifier properties"
 Strongly agree, a board where we don't just request the deletion but aslo other measures.
  • "Identifiers may be migrated to a new system"
I'm unsure what you're refering exactly. Explain more.
  • "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"
This was made for MobyGames-related properties using the older scheme.
  • "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.
Regards. --Amitie 10g (talk) 12:15, 3 September 2026 (UTC)Reply
Regarding "Identifiers may be migrated to a new system" -> For example with Hungarian National Namespace organisation ID (old) (P6989) that has now a new variant. The origin database created new ids for all their entries.
"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.
Kordishal (talk) 13:26, 3 September 2026 (UTC)Reply
Regards. --Amitie 10g (talk) 23:43, 3 September 2026 (UTC)Reply
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
Yes I can think of a few that were just ways of accessing a website, were barely used (and never by anybody else) and then the website changed. Secretlondon (talk) 15:18, 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

Changes to the Deletion policy

[edit]

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).

Properties may be speedily deleted when:

External identifier properties

External identifier properties may be requested for deletion when
  • The external database uses unstable identifiers (e.g., the identifier format changes frequently or is dynamically generated without persistence).

External identifier properties may be speedily deleted when:

  • They consist of widespread invalid or spam identifiers.
  • The identifiers are sourced from stolen or illegal datasets.
A deletion process for properties must be avoided when
  • The property belongs to a valid and stable identifier, even if the underlying target behind formatter URL (P1630) is no longer available online. Instead of deletion, the property should be set as obsolete by adding obsolete Wikidata property (Q18644427) to instance of (P31). Additionally, archive URL (P1065) may be used at the item level as a qualifier to provide an alternative link to archival services like the Wayback Machine (Q648266).
  • 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.

Regards. --Amitie 10g (talk) 23:54, 3 September 2026 (UTC)Reply

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
You're right. Deprecated_rank may be more suitable for superseded schemes. Amitie 10g (talk) 04:10, 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.
And overall not so sure about the formulations, but someone else will have to have a look at that. Kordishal (talk) 21:25, 4 September 2026 (UTC)Reply
  • "Should there potentially be separate sections for properties" I requrded the proposal and separated the non-identifier with identifier properties.
  • "Are the speedily deleted based on examples you know off?" Them are examples I guessed, but examples may be found.
  • "I would avoid using the term "deprecated" in the first policy" As I mentioned above, I reworded the proposal.
  • "Remove the " from the deprecated in the last policy" As I mentioned above, I reworded the proposal.
Regards. --Amitie 10g (talk) 23:46, 4 September 2026 (UTC)Reply

Russian-Czech matching problem

[edit]
Latest comment: 1 day ago1 comment1 person 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.

Maybe there are some additional tools, approaches, or tips that could help with this task? Mitte27 (talk) 05:30, 3 September 2026 (UTC)Reply

Bot (or bots) for importing European Legislation Identifier published articles?

[edit]
Latest comment: 1 day ago2 comments2 people in discussion

The ELI protocol provides both identifiers, and api-based publishing, meaning that legislations could be imported into Wikidata programmatically. (Although note that different countries have different URLs for their end-points). Should one or more bots be created that could do this? Or would automatic import of legislation be considered excessive in some way?

While the proposal for an ELI property was withdrawn (Wikidata:Property proposal/European Legislation Identifier), an alternative was mentioned in the form of using P973. Perhaps that would be enough?

Curiously, for Irish law we have the Irish Statute Book ID as its own property, with ELI as a characteristic. Would copying this for other countries make sense, or would it be excessive? Ferret-like Gal (talk) 15:48, 3 September 2026 (UTC)Reply

It might be worth making an estimate to see how many items we are talking about, but my gut feeling is that EU legislation would be valuable. Some already have Wikipedia articles which speaks to the notability level. Ainali (talk) 22:11, 3 September 2026 (UTC)Reply

Duplication of page?

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

Committees of the Scottish Parliament (Q5153129) already exists because it was created by a bot linking to the existing article en:Committees of the Scottish Parliament. I'm not sure if I should use that item to link individual committees to or if there should be 2 separate pages: one for the Wikipedia article and one for "committee of the Scottish Parliament" as a singular?

Because the current page is instance of (P31) a Wikimedia list article (Q13406463), it conflicts if I add it as a subclass of (P279) a committee (Q865588) as well. Should I remove the "instance of list article", or add "subclass of committee" to a new item with different definition.

If you look at history revisions of page you can see what I've tried with it. Tigered27 (talk) 00:27, 4 September 2026 (UTC)Reply

I think I've answered my own question with Presiding Officer of the Scottish Parliament (Q3567536) as an example of two separate items for one Wiki page, so going to do that. Tigered27 (talk) 00:45, 4 September 2026 (UTC)Reply
Yep and then just link the two with the is a list of (P360) and has list (P2354) props. Kordishal (talk) 05:18, 4 September 2026 (UTC)Reply

Merge duplicate items into Q122495361

[edit]
Latest comment: 4 hours ago6 comments4 people in discussion

I have checked Q32730157, Q32730160 and Q122495361 and confirmed that all three items represent the same river in Rajasthan, India, known as Dheel River / Dhil Nadi (ढील). Q122495361 should be retained as the main item. I propose merging Q32730157 and Q32730160 into Q122495361, while preserving all valid labels, aliases, statements, identifiers and references. Q29091643 is a Wikipedia disambiguation page, not a separate river item. ~2026-47728-81 (talk) 03:56, 4 September 2026 (UTC)Reply

You are right that this is all the same river. Unfortunately merging them is not trivial.
Dheel (Q32730157) and Dheel (Q32730160) are bot pages on ceb.wiki, meaning that they can't be merged unless cebuano wiki does first. The reason why they are separate pages is that GeoNames has assigned the two parts of the river two different ids. The parts are before the dam and after the dam, which maybe forms a lake, though the lake doesn't seem to be permanent.
Dheel (Q122495361) is the article on en.wiki and it could be merged with either of the two ceb.wiki entities, but the question is then which.
We could also see if the ceb.wiki editor who created these bot stubs could merge them there User:Lsj. Kordishal (talk) 06:02, 4 September 2026 (UTC)Reply
For now merged Dheel (Q32730157) into Dheel (Q122495361) and marked Dheel (Q32730160) as permanent duplicate. Kordishal (talk) 06:18, 4 September 2026 (UTC)Reply
Merged on cebwiki now. ~2026-48088-62 (talk) 13:10, 4 September 2026 (UTC)Reply
...and apparently I wasn't logged in here. Lsj (talk) 13:11, 4 September 2026 (UTC)Reply
Thanks! Finished merging. Kordishal (talk) 20:02, 4 September 2026 (UTC)Reply

Validating lack of P17 in items

[edit]
Latest comment: 8 hours ago3 comments3 people in discussion

Hi, I was working this query to find lack of country (P17) but they are so numerous false positives so I would like to get a review and refining of this query. Any advices? 

SELECT DISTINCT ?item ?country WHERE {
  ?item p:P276 ?statement .
  ?statement ps:P276 ?loc .

  VALUES ?exclus {
    wd:Q3305213
    wd:Q12043905
    wd:Q7725634
    wd:Q8092
    wd:Q93184
    wd:Q21745157
  }  # Exclude items having one of these P31 who do not need P17
  MINUS {
    ?item wdt:P31 ?exclus .
  }

  # Exclude items already having a country-related property
  MINUS {
    ?item wdt:P17|wdt:P495|wdt:P27|wdt:P1532|wdt:P8047 ?existingCountry .
  }

  # Country of the P276 location
  ?loc wdt:P17 ?country .

  FILTER (?loc != ?country)
}
LIMIT 5000
Try it!

Bouzinac 💬●✒️●💛 06:38, 4 September 2026 (UTC)Reply

A good approach, I think you will be very busy fixing them all! I suggest you restrict the query to particular subdomains and lead with a MINUS {?item wdt:P17 ?country} to get the query faster. Pick domains where modern country is clearly required, events for example are often best with current and contemporary countries indicated with qualifiers, so best avoided on a first pass. You might want to avoid border disputes countries too. Be wary of locations in multiple countries.
Why did you choose location (P276) rather than located in the administrative territorial entity (P131). I suspect the latter gives a better single-value country set. Vicarage (talk) 08:05, 4 September 2026 (UTC)Reply
Be careful about disputed territory. I tried a sweep like this a few years ago and ran into some issues with that. Bovlb (talk) 15:26, 4 September 2026 (UTC)Reply
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2540301491"