Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Undoing a batch

[edit]

I made a mistake for the batch https://editgroups.toolforge.org/b/QSv2/238496/ and when I try to undo it, I get a "Server Error (500)". Is there a way to get the batch undoing working? Is it generally broken? ChristianKl11:22, 13 October 2024 (UTC)[reply]

Indeed, I don't get my OAUTH working for EditGroups. --Lymantria (talk) 13:19, 13 October 2024 (UTC)[reply]
@ChristianKl: It looks like your batch is only missing qualifiers. You can just run QuickStatements again and it will add the qualifiers to the values (no need to remove the values first). Dexxor (talk) 13:37, 13 October 2024 (UTC)[reply]
Unfortunately not, the problem is that some of the qualifiers were wrong. I pulled down to copy value and it counted the property numbers for the qualifiers up (some errors that result in no data but also a bunch of wrong data). ChristianKl13:45, 13 October 2024 (UTC)[reply]
Ah, I see. You could make a new batch that removes values with bad qualifiers and re-adds them with the right qualifiers (aka using QuickStatements as a poor man's undo batch button). Dexxor (talk) 13:47, 13 October 2024 (UTC)[reply]
@ChristianKl: I have recently done some maintenance work on this tool, but more work would be needed to make it work reliably. I also get a HTTP 500 error when trying to log in, so I can see it is indeed broken. I notice that my motivation to maintain this tool is dwindling. I have added a banner to the tool, pointing to a new Phabricator task to request help. As much as I see that this tool continues to fulfill an important need in the community, I continue to think that its architecture isn't fit for purpose on the long term (see this list of problems I mentioned 5 years ago). I am happy to see that with the advent of Wikibase.Cloud (where EditGroups isn't available), Wikimedia Deutschland has started to hear voices from users who struggle with undoing imports on Wikibase.Cloud, and so they are considering deploying EditGroups there. This is the paradox I am confronted with: the importance of infrastructure in this area can only be visible if EditGroups isn't available. So, in a sense, if I want something reliable to appear in this space, I shouldn't maintain EditGroups. On the other hand it really pains me to see this tool broken and people struggling to do their work because of that. It also pains me to ask for more work from others. − Pintoch (talk) 15:51, 18 October 2024 (UTC)[reply]
@Pintoch are you planning to get it sooner or later operational again, or need I go through the manual work of undoing the badge? ChristianKl22:55, 19 October 2024 (UTC)[reply]
@ChristianKl: somehow I had vague hopes that with my explanation of how uncomfortable the situation is for me, it would prompt some expression of empathy, appreciation or understanding, which would motivate me again to work on this. But I forgot that those aren't really part of the social norms here - sorry about this inappropriate outpour of emotions. I thank you for expressing your needs directly. I am impressed by your tireless work on Wikidata, so I want to help you and have spent a few hours trying to debug this. Logging in to EditGroups works again on my side - there are surely many other things still broken, but I hope you at least appreciate this small present to you. − Pintoch (talk) 22:32, 24 October 2024 (UTC)[reply]
When you explained the problem, I'm not sure whether trying to motivate you is the best. It might be better if WMDE takes over EditGroups and generally couples the function more tightly with Wikibase. I did write one message in the Telegram Wikidata saying "EditGroups seems broken right now and seems like a key tool. Pintoch seems unclear about whether he wants to continue to support it. Is this key functionality that would be better to be developed by WMDE?"
That said, thank you for fixing it. I could login and undo the batch. So do appreciate the work you put into EditGroups and feel like I understand your dilemma. ChristianKl19:25, 26 October 2024 (UTC)[reply]

Notability of items sourced purely to a Wiki Loves Monuments ID

[edit]

A couple of weeks ago I had nominated some items for gravestone for deletion that were linked nothing to else but a Wiki Loves Monuments ID. Since there's nothing in Wikidata:Notability or the original proposal for the property saying that it is an indicator of notability. Which would make sense considering Wiki Loves Monuments IDs are user generated and based purely on the existence of said monument.

@Multichill: Subsequently closed all the deletion requests as keep because Wiki Loves Monuments is supposedly a well established criterion for notability and then they threatened to block me if I renominated the items for deletion. Which, aside from just coming off like bad faithed bullying, really doesn't make much sense. So does anyone besides @Multichill: know if Wiki Loves Monuments IDs are an indicator of notability or know of any past discussions about it? Adamant1 (talk) 04:26, 15 October 2024 (UTC)[reply]

A WLM id usually means an item has been named in an official heritage register, that may not be available online. So if a WLM id exists, it's probably best to start from the assumption that the item probably is notable, unless there are any very clear reasons to think otherwise. Also, consider that removing items from the WLM list here is disruptive to a high-profile project, and may affect Wikipedia pages that automatically draw on the list here.
Looking at consequences, it would seem to me that the downside of including an item here that may not be notable is rather less that the downside of not including an item here that is notable. There is also the question of removing other people's work; and affecting images on Commons that may refer to the item here.
For all these reasons, I would suggest to be disposed to tread very softly in respect of items that have a WLM id. If there is a group of items that you think should not be included, it probably makes sense in the first place to take it up with the national group that put together the WLM list for that country. I would strongly advice that any deletion request here should not be made unless it has been cleared and approved by that group first. Best regards, Jheald (talk) 09:53, 15 October 2024 (UTC)[reply]
A WLM id usually means an item has been named in an official heritage register @Jheald: From what I understand that's not actually the case. Supposedly one of the reasons there's Wiki Loves Monuments IDs in the first place is because there's a lot of monuments that aren't in official government databases. So the IDs serve to fill in the gaps. Which makes since because there's be no point in the IDs to begin with otherwise. I know that's the case at least with monuments in Ukraine and Russia though. There's a lot of monuments in both countries that aren't in official databases that Wiki Loves Monuments has IDs for.
May affect Wikipedia pages that automatically draw on the list here. All of the items that I nominated for deletion weren't connected to other projects. Let alone where they notable enough to have Wikipedia articles or anything like that. Same goes for there being images for them on Commons. None of them did. So I don't really see how them being deleted would be disruptive or have an effect on anything. --Adamant1 (talk) 19:13, 15 October 2024 (UTC)[reply]
Afaik, the least currently of Wiki Loves Monuments ID is that it could be used in external tools. For example Wikimedia Commons app (Q12528989) and https://app.wikilovesmonuments.it uses it. More globally the Monuments database would transition to use Wikidata as backend. The reason for using single property instead of multiple ones is that in software development point of view it is overly complex to manage rules for multiple different properties. There are is also SPARQL performance reasons why one will want to keep the number of properties smaller. --Zache (talk) 13:24, 17 October 2024 (UTC)[reply]
Generally, the interpretation of what we see as falling under our notability policy gets decided over at deletion requests and some discussions about undeletion of items that happen elsewhere. Simply, renominating items after you see that a category of items get decide to be kept at Request of Deletion causes unnecessary work and is disruptive.
It's worth noting that our policies speak of "can be described using serious and publicly available references" and not "are described using serious and publicly available references", so the absence of references on an item is not in itself a reason why the item is not notable. ChristianKl10:43, 15 October 2024 (UTC)[reply]
@ChristianKl: I totally agree that something's notability should be decided over at deletion requests. The problem is that Multichill unilaterally closed the deletion requests as keep when I had just opened them and there was no discussion. Otherwise I would have been more then happy to not start this conversation and let the normal process play out. You can't have it both ways where it's disruptive to renominate an item for deletion but then it's totally fine for admins to unliterally close DRs after a couple days based on their own personal opinions and regardless if there's been any discussion about it though.
I could ultimately care less if items for monuments that are actually notable exit on here. The problem is that Multichill made a blanket pronouncement that every monument with a Wiki Loves Monuments ID is de-facto notable and then unliterally steamrolled any sort of discussion about it. At least IMO it's totally valid to renominate said items for deletion in an instance like that. Any disruption or extra work it might cause is totally on Multichill for unliterally closing the DRs out of process. --Adamant1 (talk) 19:13, 15 October 2024 (UTC)[reply]
Hey all, I'm one of the folks who create items for component parts of monuments that lack references or monuments that lack references, usually in Brazil. I believe a low percentage of listed monuments in Brazil even have a Wikidata item -- which I know from experience. And certainly not any references. I've visited the regional federal offices for listed monuments (IPHAN) to locate the monuments of a region, and there's a lack of documentation at all levels of government--federal, state, and municipal. WMB is actively collecting sources at all levels of government and academia, but it's very time consuming, or the references exist in documents that are rare or lost.
I think the context of the regions we're working with on Wiki Loves Monuments is important. Can I request that folks take a pause on deleting monuments, or components of monuments? Creating an item with no references is an interesting process, because putting the cart (the item) before the horse (references) puts you on the lookout for the references themselves! I often find highly detailed information signs, but I consider them within copyright so I don't upload them.
Most importantly, thank you all for your work on monuments in Wikidata. You're contributing to an architectural inventory that does not exist elsewhere for individual countries or even regions, and in practice does it contribute to the survival and/or preservation of these works? It sure does! Prburley (talk)
Putting the cart (the item) before the horse (references) puts you on the lookout for the references themselves! It really doesn't though. The items just stay unreferenced for years and then they can't be deleted because people like Multichill and ChristianKl complain about how doing DRs for unsourced items cause extra work or whatever. Regardless, it's ridiculous to create a bunch of unreferenced items purely because you think sources might exist for them and/or you plan on adding them later at some point in the future. Wikidata:Notability might as well not even exist at that point. But hey, screw the notability guidelines because nominating the items for deletion causes extra work though. Sounds like a great way to run a website. --Adamant1 (talk) 03:49, 17 October 2024 (UTC)[reply]
Wikidata:Notability does not say that items staying unreferenced for years is a problem. It just doesn't.
Wikidata is not run so with the intention of work of well intentioned contributors get deleted but so that a lot of different people can contribute to Wikidata.
The spirit of deletionism isn't healthy for Wikipedia either and we don't need it on Wikidata. ChristianKl10:53, 17 October 2024 (UTC)[reply]
@ChristianKl: I mean, realistically there are serious usability problems on both projects that are caused by being to inclusionist. With Wikidata specifically the main reason I got into this was because there was an item for the fictional city of New York that was being automatically added to items instead of the actual city. Otherwise I could really care less, but I don't think your handwaving about how a lot of different people can contribute to the project should necessarily come at the cost of being able to do basic things like add a location to an item. Maybe that's just me though.
I originally asked the question so I wouldn't needlessly be nominating similar items for deletion in the future if monuments with Wiki Loves Monuments IDs were in fact notable. I know admins are their own special kind of fragile, but I do find you calling me a deletionist just because I asked a question about the guidelines rather patronizing. I'm sorry if this whole thing upset you that much, but there's no reason to insult me over it. I wasn't planning on nominating any more unsourced items for deletion anyway. It was just something I thought was worth clarifying. That's all. Have fun degrading usability of the site though ;) --Adamant1 (talk) 13:18, 17 October 2024 (UTC)[reply]
My opinion is that the goal is to move national Wiki Loves Monuments databases to Wikidata. To achieve this, detailed Wikidata items are necessary, either because they are notable in their own right or because they are part of larger notable objects. For example, they could be buildings located on an island that is protected as a whole. This is why these items are needed and should not be deleted. --Zache (talk) 14:07, 17 October 2024 (UTC)[reply]
I don't have a problem with "detailed Wikidata items" for the monuments. The problem is that they inherently can't be detailed if they are unsourced. There's certainly monuments with IDs out there that are detailed though, but that's not what I'm talking about. The problem comes in where there's a years old, unsourced item for a monument that has no other information except the location, name (which is usually made up to begin with), and a Wiki Loves Monuments ID.
I've certainly added more information to a few them myself, but at the end of day the responsibility for doing that should be on the original creator of the item and it should be done when the item is created. Not 12 years later by a random passerby. Just like with any other thing on here. I highly doubt the same standard would apply for anything else. I've certainly seen unsourced items for people, movies, locations, Etc. Etc. deleted before. Monuments just seem to get special pass for some reason. I have my suspicions as to why, but their clearly treated differently. I'm sure this whole thing would have gone a lot different if this it was about something else besides monuments. --Adamant1 (talk) 14:33, 17 October 2024 (UTC)[reply]
There are a lot of things in the location data category in which validity you can confirm just by walking to it. --Zache (talk) 15:02, 17 October 2024 (UTC)[reply]
Sure, but no one does it. i didn't know personal experience was a valid source anyway though. Clearly the bar for notability and sourcing has been lowered essentially to non-existence since I signed up. That's on me thinking there were still some kind of standards on here. As long as someone had a dream about it once, whatever. As long as different people can contribute to the project right? --Adamant1 (talk) 15:08, 17 October 2024 (UTC)[reply]
Another identfier for monuments or heritage designation (P1435) should be enough in most cases; the source could be a reference URL or stated in (P248). With people there is an additional policy (Wikidata:Living people), and the deleted items often only have user-generated identifiers. People and films are also typical subjects for hoaxes. Peter James (talk) 23:19, 17 October 2024 (UTC)[reply]

@ChristianKl: In your opinion would it be OK for someone to create an item that was sourced purely to unsubstantiated information from a Wikipedia article? Also how long do you think unsourced information should stay on here or is "indefinitely" totally fine? --Adamant1 (talk) 05:52, 20 October 2024 (UTC)[reply]

Wikidata items are the best way that Wikipedia articles have sitelinks under each other and thus we allow Wikidata items without any statements provided they have links to Wikipedia articles. Generally, the more statements providing true information the better, even if that information is not referenced. That's the general Wikidata operates. There are some exceptions for property that may violate privacy (Q44601380) where I would consider it reasonable to remove unsourced information. In particular I would support removing unsourced ethnic group (P172) statements (which we currently don't and we have a lot that are a decade old).
Generally, I think the best way to have more and better data, is to make it easy for people to add more and better data. ChristianKl11:37, 20 October 2024 (UTC)[reply]
@ChristianKl: I could probably could have been clearer about it but I wasn't asking about sitelinks. What I mean is using a fact from a Wikipedia article as a reference for a statement. For instance using a Wikipedia article as a reference that a family member is related to someone or the date of an event. Not basing an item on the existence of there being a Wikipedia article having to do with the subject in the first place. Like say for John Nopel (Q130569454), assuming there was a Wikipedia article mentioning John Nopel was a historian would it be OK to use that as a reference for his occupation? --Adamant1 (talk) 04:56, 21 October 2024 (UTC)[reply]
Yes, there's no issue with that given that John Nopel is dead (and thus not subject to Wikidata:Living people). If he would be alive the matter would be more complicated. ChristianKl20:14, 21 October 2024 (UTC)[reply]
@ChristianKl: OK. Thanks for the explanation and conversation even though we clearly disagree about it. One more thing if you'll humor me, I know you say items for monuments don't need to be sourced to anything, but with an item like Q122726374 the whole justification for it seems to be that the statue is a "monument of monumental art of Ukraine of local importance." Otherwise the kind of seems pointless. Yet heritage designation (P1435) clearly requires a reference, which the statement doesn't have. That goes for most of items based on Wiki Loves Monuments IDs. Also, Wiki Loves Monuments ID (P2186) clearly requires a coordinate location. Which again, most items based on Wiki Loves Monuments IDs don't have. So do you advocate for ignoring the requirements? Or should something that explicitly requires a source probably have one? --Adamant1 (talk) 07:53, 24 October 2024 (UTC)[reply]
If the P1435 is correct, according to uk:Пам'ятка монументального мистецтва it should be in the State Register of Immovable Monuments of Ukraine. It's in Vinnytsia Oblast, so the relevant list for monuments of local importance https://mcsc.gov.ua/wp-content/uploads/2024/04/vinnyczka_obl__stanom_na15.04.2024.pdf or https://mcsc.gov.ua/files/pdf/Nacional_znachenia/%D0%92%D1%96%D0%BD%D0%BD%D0%B8%D1%86%D1%8C%D0%BA%D0%B0%20%D0%BE%D0%B1%D0%BB..pdf if it's of national importance; there is also a list of monuments removed from the register for reasons related to decommunization and derussification: https://mcsc.gov.ua/wp-content/uploads/2024/10/2024.10.22-perelik-po-dekomunizacziyi.pdf. It's in uk:Вікі любить пам'ятки/Вінницька область/Тульчинський район/Тульчинська громада but I could not find it in the references there so it could be in the register under another name, or have been removed from the register for another reason, or the P1435 could be a mistake - that Ukrainian Wikipedia list, which is only for part of the oblast, is much longer than I would expect it to be. Peter James (talk) 16:48, 24 October 2024 (UTC)[reply]
@Peter James: A lot of the names for the monuments are totally made up on our end to begin with. So I doubt you'd be able to find them in an official register even if they are there to begin with. Although several people associated with Wiki Loves Monuments have said that they include more monuments then the official registers. Which is sort of the problem here. Not every non-notable "monument" or whatever in existence should have a Wikidata item. Yet that's essentially what this whole thing sets up. Essentially every gravestone in Ukraine can have a Wikidata item simply because there's a Wiki Loves Monuments ID for it regardless of if it's included in a notional or local register, if the person is notable, or really anything else purely "because Wiki Loves Monuments ID." I guess it is what it is though since that seems to the standard people like ChristianKl want on here. --Adamant1 (talk) 15:20, 26 October 2024 (UTC)[reply]

VIAF dumps?

[edit]

Hello! Does anybody know anything about the VIAF dumps available at https://viaf.org/viaf/data/ The last one is from August. I am using those dumps since about 6 years and there was a new dump every month, but now there are two month missing? Last weekend I wrote a mail and asked, usually there is an answer on the next day, but I got no answer? --Wurgl (talk) 07:40, 18 October 2024 (UTC)[reply]

@Linda.jansova Do you happen to have any information about this, Linda? Vojtěch Dostál (talk) 10:48, 25 October 2024 (UTC)[reply]
@Wurgl, @Vojtěch Dostál Unfortunately, I do not have that kind of information but I have just send a question to OCLC myself. So perhaps we will eventually find out :-). Linda.jansova (talk) 11:08, 25 October 2024 (UTC)[reply]
Thanks! --Wurgl (talk) 11:11, 25 October 2024 (UTC)[reply]

ProVe, a new tool to help with the quality of references

[edit]

Thanks to all of you you have so far tried ProVe, the new tool for checking the quality of references in Wikidata. It's greatly appreciated :-) (link to the archived discussion here).

@samoasambia thanks for your suggestions! We are updating the script import instructions in the documentation to avoid copy-pasting code, great idea. We're also adding ProVe to the tools catalog. Thanks for your help!

@Huntster thanks for letting us know, this was a bug. It's now been fixed, if you could try again and let us know if the new version works that would be great! Thanks

Just as a reminder for everyone else, ProVe provides information about the quality of the references of Wikidata items, based on techniques like large language models, triple verbalisation, and semantic similairty. We have also developed the **ProVe Gadget**, which visually presents ProVe's results as a widget at the top of a Wikidata item page. Any Wikidata user can easily turn this gadget on, see here for install instructions. You can use it to request the processing of references, showing reference scores, navigating problematic references, and quickly fix them with better ones.

If you're curious about this we'd greatly appreciate your feedback! :-) Albert.meronyo (talk) 10:03, 18 October 2024 (UTC)[reply]

I am trying to use it, should be a useful thing, thanks. For some reason, the gadget does not analyse web.archive.org correctly and is unable to 'read' the text from the web archive. So, it says about it 'Sentence in external URL to be checked, possibly not authoritative'. --Wolverène (talk) 12:23, 18 October 2024 (UTC)[reply]
Thanks! I think we may have to do additional checks to read text from the web archive, indeed. What item are you trying to analyse? Thanks for using ProVe! Albert.meronyo (talk) 13:39, 18 October 2024 (UTC)[reply]
Well, e.g. Q23648408. (It is also listing IGN there as not authoritative although this is quite a well-known video games-related media with the serious team...) --Wolverène (talk) 19:31, 19 October 2024 (UTC)[reply]
Thanks! We're looking into this Albert.meronyo (talk) 08:49, 23 October 2024 (UTC)[reply]
Hi @Wolverène, thank you very much for your input. I've reviewed the issues you mentioned. First, accessing web.archive.org takes a considerable amount of time, roughly 1–2 minutes. The current web crawler engine on the backend is set to wait 15 seconds per URL to prevent overloading the web crawling process. Second, certain web servers, such as IGN, may deny access to their pages by the web crawler to protect their rights. Due to this access policy, the tool is unable to access IGN pages automatically. Dignityc (talk) 07:14, 29 October 2024 (UTC)[reply]
I see. Thank you. --Wolverène (talk) 04:58, 30 October 2024 (UTC)[reply]

IMDB

[edit]

Hello all,

The links for IMDb ID (P345) not working. Trivialist added this prefix to the link - https://wikidata-externalid-url.toolforge.org . I don't understand what that means and anyway the links does not working with that prefix. Geagea (talk) 06:38, 22 October 2024 (UTC)[reply]

The prefixes differ per type, so we use a volunteer tool to convert them (and have been for years). It seems like the tool is offline though, @ArthurPSmith, can you check? Sjoerd de Bruin (talk) 12:28, 22 October 2024 (UTC)[reply]
We already have the different prefixes in formatter URL (P1630) of IMDb ID (P345), can't we use those directly instead of using the tool? -- Agabi10 (talk) 13:31, 22 October 2024 (UTC)[reply]
@Geagea: Yeah, looks like it crashed yesterday - sorry to be slow noticing. It's been a year since the last restarr; it seems to be working now. Maybe I should schedule more frequent restarts... ArthurPSmith (talk) 15:20, 22 October 2024 (UTC)[reply]
@ArthurPSmith, now working thanks. Geagea (talk) 19:16, 22 October 2024 (UTC)[reply]

Is IMDb considered a reliable source for wikidata? I am pretty sure it’s not considered reliable for Wikipedia.Masai giraffe (talk) 06:33 27 October 2024 (UTC)

It is being used as an identifier rather than a source. –FlyingAce✈hello 02:59, 28 October 2024 (UTC)[reply]

Permanent records removal

[edit]

I am writing on behalf of Mr. Morgan Hermand-Waiche to formally request the permanent removal of all records associated with him from your website. Mr. Hermand-Waiche believes that the presence of this information constitutes a violation of his rights, and he does not wish for any details pertaining to him to be displayed publicly. I would like to emphasize that I am connected from the company account to validate that this information is accurate. We appreciate your attention to this matter, and please note that the reference source, Who's Who, has already deleted his records. link: https://www.wikidata.org/wiki/Q20089624 ____________________________________________________________________________________________________________________________

Je vous écris au nom de M. Morgan Hermand-Waiche pour demander formellement la suppression permanente de tous les dossiers le concernant de votre site web. M. Hermand-Waiche estime que la présence de ces informations constitue une violation de ses droits et il ne souhaite pas que des détails le concernant soient affichés publiquement. Je tiens à souligner que je suis connecté depuis le compte de l'entreprise pour valider que ces informations sont correctes. Nous vous remercions de l'attention portée à cette demande, et nous tenons à préciser que la source de référence, Who's Who, a déjà supprimé ses dossiers. Merci pour votre assistance rapide. Angeleml (talk) 12:22, 23 October 2024 (UTC)[reply]

The French Wikipedia consider him notable enough to have a page at https://fr.wikipedia.org/wiki/Morgan_Hermand-Waiche , we generally do not delete items on Wikidata if there's a Wikipedia page associated to it and even if we would delete an item with an Wikipedia page, that item would get automatically recreated.
As far as I can see the French Wikipedia does not use Who's Who has the reference for their data. If the French Wikipedia does decide to delete the article please mention it here.
Note that both Wikidata and Wikipedia are part of the Wikimedia Foundation. If you want to make a formal legal request addressed at the Wikimedia Foundation, https://meta.wikimedia.org/wiki/Wikimedia_Foundation/Legal/Legal_Affairs describes how to correspond with the legal department. ChristianKl12:40, 23 October 2024 (UTC)[reply]
Thank you! And thanks for deleting the birth date from here as it was his most important concern. Angeleml (talk) 16:56, 23 October 2024 (UTC)[reply]
@Angeleml: Unfortunately, if the information is already public elsewhere in a reliable source, it will not be removed.--Jasper Deng (talk) 06:53, 24 October 2024 (UTC)[reply]
@Jasper Deng: this information does not seem to be public, even if it were public, it's a personal data. Cheers, VIGNERON (talk) 10:39, 25 October 2024 (UTC)[reply]
Clearly it must have been gotten from somewhere unless Hermand-Waiche added the statements himself Trade (talk) 13:18, 30 October 2024 (UTC)[reply]
As the OP wrote, the statement was sourced to Who's Who which deleted their article. So while that public source existed in the past it currently doesn't exist.
Regardless, the standard our current policies suggest is "statements should generally not be supplied unless they can be considered widespread public knowledge or openly supplied by the individual themselves".
While, I personally, think that's a bit broad for date of birth (P569) that's the standard we currently have via WP:LP as date of birth (P569)living people protection class (P8274)property that may violate privacy (Q44601380). ChristianKl16:23, 31 October 2024 (UTC)[reply]

Global Ban Request

[edit]

In accordance with the global ban policy ,which requires a notification to all wikis a user has edited in, I am notifying you that I have started this global ban request. I welcome any comments. Takipoint123 (talk) 23:09, 25 October 2024 (UTC)[reply]

@Takipoint123: You forgot to post the link to the ban discussion. –FlyingAce✈hello 00:43, 26 October 2024 (UTC)[reply]
Oops! Thank you for letting me know. The discussion is at meta:Requests for comment/Global ban for Won1017 Takipoint123 (talk) 00:52, 26 October 2024 (UTC)[reply]

New property proposal: Immortal Regiment ID

[edit]

Dear Wikidata contributors,

I've proposed a new property to link Wikidata biographies with profiles on the Immortal Regiment (Бессмертный полк) website.

This will help connect valuable historical records, photos, and personal stories contributed by veterans' descendants with our biographical data. The property would be particularly valuable for preserving and discovering unique historical information about individuals from former Soviet republics.

You can review and discuss the proposal here: Property proposal/Immortal Regiment ID

Your feedback would be greatly appreciated! 🙏 David Osipov (talk) 05:19, 26 October 2024 (UTC)[reply]

Memobase ID

[edit]

Hi there,

I have an issue with the IDs of my Portal. We aggraget Swiss AV Data in https://memobase.ch. Therfore we create Institutions (https://memobase.ch/institution/xxx example https://memobase.ch/institution/bar) match them collections (https://memobase.ch/recordSet/xxx-999 example https://memobase.ch/recordSet/bar-001) and Documents (https://memobase.ch/object/xxx-999-ID example https://memobase.ch/object/bar-001-CGS_1039-1).

It seems that there are wrong properties on the Memobase ID (https://www.wikidata.org/wiki/Property:P9657).

I would like to enter the Institution and Collection ID on the wikidate (for example here: https://www.wikidata.org/wiki/Q301250)

Can anyone help me out?

Thanks Daniel (Memoriav / Memobase) Memoriav-dh (talk) 12:37, 26 October 2024 (UTC)[reply]

New property proposal: Timenote.info Person ID

[edit]

Dear Wikidata contributors,

I've proposed a new property, Wikidata:Property proposal/Timenote.info Person ID to link Wikidata items with person profiles on the international biographical encyclopedia timenote.info (Q130484179)

This property will facilitate connections between Wikidata and timenote.info (Q130484179), enabling better discoverability of biographical information and family histories. timenote.info (Q130484179) is a multilingual resource, and this property incorporates the mandatory language of work or name (P407) qualifier to specify the language version of each profile.

You can review and discuss the proposal here: Property proposal/Timenote.info Person ID

Your feedback is highly valued! Thank you. 🙏 David Osipov (talk) 14:19, 26 October 2024 (UTC)[reply]

"Given name" and "disambiguation page"

[edit]

How can Abhijeet (Q4667389) be an instance of both given name (Q202444) and Wikimedia disambiguation page (Q4167410)? I presume this should be split in two, if there is not already a second related item floating around that also needs to be fixed.

Perhaps someone should run a query for items that are in both of these categories. I doubt it is the only one.

ATTN: Inter&anthro, who appears to be the one who added given name (Q202444), making what appears to me to have been a bad merge. - Jmabel (talk) 14:59, 26 October 2024 (UTC)[reply]

The first sitelink was originally a disambiguation page but was made into a page about the name; the disambiguation page has now been split to Abhijit (Q97367012) with different spelling. I restored Q50846076 (Abhijeet) and there is also Q94700719 (Abhijit) for the given name. Q4667389 still has one sitelink (hi:अभिजीत), which is a disambiguation page. Peter James (talk) 17:13, 26 October 2024 (UTC)[reply]

Which kind of relation is best for conjugation types?

[edit]

I wanted to see how conjugation types are organized in Wikidata.

The results are:

I'm new to Wikidata ontology. What makes most sense in this situation? (Meanwhile I'll fix go Russian since that one is a clear outlier – "instance of" is used for conjugation class (P5186) in three other cases.) JWBTH (talk) 13:33, 27 October 2024 (UTC)[reply]

Neighborhood has Facebook groups

[edit]

Hello everyone,

I'm a bit confused on whether I can attach Facebook user group to the wikidata entry of my neighborhood. The thing is that a lot of districts and neighborhoods in my city have Facebook and Telegram user groups, where people post about their problems, buy and sell, opening of new shops, discounts and so on. There are not "official", of course, but number of members reaches minimum 7 000. I think they are vital to uncover to whomever moves to a new district or neighborhood, I've already added them to OSM, but it's troubling for me to correctly include them into Wikidata. At this point of time, I've created this entry of my neighborhood Orkhevi (Q130437988) and not sure whether I included Facebook groups' info correctly.

Could you pls advise on this matter? David Osipov (talk) 06:45, 28 October 2024 (UTC)[reply]

They need a qualifier object of statement has role (P3831) community group (Q106464965), but I'm not sure WD should record this given the poor mapping of our districts and a morass of Facebook groups Vicarage (talk) 08:40, 28 October 2024 (UTC)[reply]
About the mapping - we're working on it with OSM community :) There is a lot to do, yeap, but we're progressing. Thank you for the piece of advice, I'll use it right now. David Osipov (talk) 11:45, 28 October 2024 (UTC)[reply]
Unofficial groups being added to items is fraught with potential problems and it's unclear to me what the scope of "I'll use that right now" means. I think it might be worth seeking some more consensus and caution before adding or changing a significant number of statements. William Graham (talk) 14:05, 28 October 2024 (UTC)[reply]
Yeap, that's what I want to get - some consensus on it. As for now, I've 100% aware of all the unofficial groups of my own neighborhood for now, so that I've edited only it for now. But I'm also aware of unofficial user groups of other neighborhoods and districts in the city of Tbilisi, Georgia. David Osipov (talk) 14:35, 28 October 2024 (UTC)[reply]
Currently, the property is for official pages and this is not an official page. Creating a discussion on https://www.wikidata.org/wiki/Property_talk:P2013 about whether to use the property also in nonofficial instances and if so under which circumstances would be the way forward. That talk page is the proper place for a discussion as anyone who wants to understand how the property can be used can look at it, while project chat discussions are not easily findable. ChristianKl08:51, 31 October 2024 (UTC)[reply]

How to add a signature image?

[edit]

I see that many persons have their signatures (e. g. Ronald Reagan), while others do not (e. g. Sergey Aksakov). How do I add a person's signature, if there alredy exists an image at commons? — Monedula (talk) 15:26, 28 October 2024 (UTC)[reply]

use signature (P109) - Salgo60 (talk) 16:25, 28 October 2024 (UTC)[reply]
That's OK, but where is the button "Add property"? — Monedula (talk) 17:57, 28 October 2024 (UTC)[reply]
Be sure to use the desktop version of Wikidata, adding statements on mobile is sadly still not possible in 2024. Sjoerd de Bruin (talk) 08:55, 29 October 2024 (UTC)[reply]
Video how you change from the desktop version - Salgo60 (talk) 09:16, 29 October 2024 (UTC)[reply]

Now I see that is is called "add statement". But there are 2 of them on each page. Is there any difference? — Monedula (talk) 15:41, 29 October 2024 (UTC)[reply]

There is no difference, you can use any one of them and the result will be the same (after a page refresh). Samoasambia 17:05, 29 October 2024 (UTC)[reply]

withdraw a property proposal

[edit]

after some discussion it looks like the SWERIKS projects agree that they can use SWERIK ID (P12192) also for political parties in Sweden --> the Property proposal Wikidata:Property_proposal/SWERIK_Party_ID should be withdrawn.

  1. I changed the status to withdrawn
  2. what else is needed to be done ?

- Salgo60 (talk) 16:20, 28 October 2024 (UTC)[reply]

@Salgo60: 1. is all you need to do, thanks! ArthurPSmith (talk) 13:00, 29 October 2024 (UTC)[reply]

Wikidata weekly summary #551

[edit]

Automatic RFD notifications?

[edit]

Hi all, I have been watching from the sidelines for a few years now, but I'm back at it.

I have been spending quite some time on WD:RFD and wonder if it has ever been proposed that nominations to RFD should result in messages being sent to item creators? or recent editors? (probably not all, but perhaps in some cases?)

New user, no talk page, only contributor to an item that has been RFDed, send a welcome and a note about the deletion request? ·addshore· talk to me! 17:14, 28 October 2024 (UTC)[reply]

We have discussed such a bot several times, e.g. here: Wikidata:Project chat/Archive/2022/07#Deletion without discussion. There may be similar discussions from that time, but I don't fully remember where they are. —MisterSynergy (talk) 18:33, 28 October 2024 (UTC)[reply]
An interesting read, I can certainly see how 1 notification for each 1 RFD would be a bad idea.
Almost 1 notification per person maximum per day could be about right, or maybe even per week.
It would certainly make me as an admin feel better when trying to clean up WD:RFD / speed up the process as I wouldn't feel that I have to reach out to people as they will already have been informed.
Without having to rely on a bot posting messages to talk pages, we could always have the existing bot just @ mention the creator and or last editor.
Anyway, I'd love to hear some more and current thoughts! ·addshore· talk to me! 20:30, 28 October 2024 (UTC)[reply]
When using the RequestDeletion tool for creating RfD (can be activated in the settings) at least the creator gets notified (that does not work for bulk deletion requests). --Dorades (talk) 20:41, 28 October 2024 (UTC)[reply]
IMO the process should be split into nominations for deletion and requests for (speedy) deletion. Nominating would involve sending a message to the creator and letting them know what is wrong and what they should do in order to not have their item deleted (cf. User:Bovlb/How to create an item on Wikidata so that it won't get deleted). The discussion could be held on the user's talk page or the item's talk page (which can be categorized, so that there is a general overview of currently or previously nominated items). Having these discussions on WD:RfD is very unfriendly (it's a long page with many threads, it takes long to publish a comment there, it's sensitive to accidental structure changes because we have bots maintaining it, etc.). The process of nominating could also be automated which I think is desperately needed. --Matěj Suchánek (talk) 08:32, 29 October 2024 (UTC)[reply]
Sounds like a pretty nice idea! ·addshore· talk to me! 08:59, 29 October 2024 (UTC)[reply]
See User:ChristianKl/Draft:ProposeDeletion for a proposal for allowing PROD of items. GZWDer (talk) 12:04, 29 October 2024 (UTC)[reply]
That's also an interesting read, I wonder if it might be better facilitated by functionality from MediaWiki core or extensions? Delayed deletion would likely be a fairly easy one to code up. A user permission that allows you to submit a page for proposed deletion. Potentially some automatic notification to the author? A page to list what is pending? Automatic delete action if noone clicks object? Then it wouldn't have to rely on bots, more edits to Wikidata in general, and properties and statements etc? ·addshore· talk to me! 14:05, 29 October 2024 (UTC)[reply]
I think it's good if PROD uses statements. That's a feature not a bug. Adding statements means that the request for deletion shows up on watchlists. It shows up on the history of the item. It shows up on the contribution history of a user. It makes it possible to use Listeria to watch for statements in a given area of Wikidata being deleted. Each Wikiproject could have a Listeria that lists nomination for automatic deletions relevant to the Wikiproject.
Tools like QuickStatements would also make it easy to nominate a greater number of statements for deletion. Generally, it's good to reuse features within Wikidata to allow more tools to interact with it.
I would oppose a quickly-coded up way where users that are not administrators can propose to delete items without that being visible in watchlists/page history/user contributions.
The property/statement approach has the advantage that users can add new reasons for deletion and all reasons for deletion can be automatically translated (as items can have text in all languages). It makes it easier for non-English speakers to interact with the process. Wikidata is an international project and finding a good solution includes finding ways to automatically translate messages. Messages that are likely best written in item label/descriptions and templates and that can be edited by people outside of WMDE or a person who codes up an extension. ChristianKl10:11, 31 October 2024 (UTC)[reply]

We did a workaround 2021 see T291659 - Salgo60 (talk) 09:27, 29 October 2024 (UTC)[reply]

Merge Piantoni (Q63041615) with Piantoni (Q63064860)

[edit]

Gentlemen, even if I enabled the box "merge" in my gadgets, it is impossible to merge these 2 items. Any idea please ? Ricercastorica (talk) 08:42, 29 October 2024 (UTC)[reply]

Because you are not supposed to merge disambugation items with family name items. Sjoerd de Bruin (talk) 08:53, 29 October 2024 (UTC)[reply]
precisely: Piantoni refers only to a family name, thank you Ricercastorica (talk) 09:34, 29 October 2024 (UTC)[reply]
We care about what template Wikipedia pages use. If they use the Template:Disambiguation (Q6148868) we see it as a disambguation page and not as a page about family names even if all the entries on the page at a particular time are family names. If something is about a family name, Template:Human name disambiguation (Q6817136) should be used on the Wikipedia page. ChristianKl10:33, 31 October 2024 (UTC)[reply]

Duplicado

[edit]

In wikidata the people Q16190529 and Q15628981 is the same person. Is possible to merge them? Froin (talk) 18:44, 29 October 2024 (UTC)[reply]

Done. --Wolverène (talk) 04:57, 30 October 2024 (UTC)[reply]

Importing WP & WMC categories into Wikidata

[edit]

There are many categories with data that is not in the corresponding Wikidata item.

For example, list of unsolved problems in biology (Q2628887) did not have subclass of: open problem (it could also be list of: open problems) set despite that the ENWP article has the category Category:Lists of unsolved problems. Likewise, Vuze (Q3563863) does not have programmed in: Java set despite its WMC category being in c:Category:Free software programmed in Java. These are just a few examples, there are also other categories about country of origin, year of birth/death, year of film production, software license, etc etc. It would waste a lot of time to enter the data again redundantly manually and also would be very monotonous for many similar items (even just the small number of unsolved problems list items).

Is there some tool that automatically and/or semi-automatically imports data from ENWP & WMC categories? If not, such is needed and could increase the data in Wikidata a lot. It doesn't mean the categories would be redundant, they never will be – but the data already entered should I think also be in Wikidata and be reasonably in sync with it. Prototyperspective (talk) 18:19, 30 October 2024 (UTC)[reply]

A WD item corresponding to a WP list should not not be a subclass of the list element type. A query on P279 unsolved_problem should return a list of problems here, not WP pages with their own curated list. The WP list pages, and the disambiguation pages, have little purpose on WD which has its own way of recording the information, and should just be a bare bones record that a WP page exists. Vicarage (talk) 18:58, 30 October 2024 (UTC)[reply]
This is at most tangential to what this thread is about.
Nevertheless, I'm also interested in this. So what's the Wikidata list of open problems in biology? Is it nearly as complete as the Wikipedia list and what's the rationale of not making that item a subclass of open problems but just be a useless item that isn't showing up in relevant queries and just record[s] that a WP page exists? Prototyperspective (talk) 19:32, 30 October 2024 (UTC)[reply]
A list of castles is neither an instance nor a subclass of castle, its a subclass of list, but it would be pretty pointless to record it. I note that list of unsolved problems in biology (Q2628887) correctly reports a constraint violation over this. Making WD as comprehensive as the WP lists is a good idea, or ensuring the category statements become instance/subclass ones, but that would be done by annotating the list/category members, not the list/category items. Vicarage (talk) 20:37, 30 October 2024 (UTC)[reply]
So as far as I understand the correct way would be to have a new wikidata item for "unsolved problems in biology" with that subclass statement and a statement has list: Q2628887. If that's the case I think it would be better to have the item better findable and better interlinked, it's expectable that the WP list only lists a subset of these, this is already implied by it being linked as WP item so I think the way to add subclass of to List items would be better in many cases, including this one. Prototyperspective (talk) 21:37, 30 October 2024 (UTC)[reply]
If you make a proposal to automatically add information based on some Wikipedia category and the examples you bring are constraint violating, that's not tangential. Correct, ontology matters to Wikidata. is a list of (P360) works fine for stating what lists are about. There's no reason to misuse subclass of (P279) for it.
Data imports from Wikipedia should only happen if you have a way to add a lot of claims that are correct and not constraint violating.
When it comes to Vuze (Q3563863) programmed in (P277) Java (Q251) that's something someone could import from Wikipedia but it would be better to import that information from a reliable source outside of Wikimedia. Instead, of having a goal of "increasing data a lot" it's often better to have a goal like increasing quality data. ChristianKl09:33, 31 October 2024 (UTC)[reply]
  • Sorry if it was unclear – you misunderstood. Of course it's relevant but it's tangential to what the actual subject of this thread is. I may have chosen those examples not very well. One could also consider the thread to be a dual-subject thread but the thread-title and far far more important subject is the other subject so I hope that doesn't drown in the discussion about this.
  • is a list of would work fine if there was a wikidata item for unsolved problems in biology but there is none and again I think it would be preferable to set this on the Wikidata item of the Wikipedia's list item because that item is not defined by the Wikipedia list – it only has that linked in the interlanguage links. Maybe it becomes clearer that way: the item could be renamed to "unsolved problems in biology" and it's just normal for Wikipedias to describe this with an incomplete list. Why would it not be better to set these things on the item that is linked on the Wikipedia list? If you want to somehow be able to have Wikipedia lists always have a list Wikidata item is somebody creating such open problems items? I'm interested in these in particular (and think such content aggregation is of special usefulness & interesting, e.g. when it comes to modern problem-solving) so I picked that example.
  • Yes, again it's not about the particular examples. It could spark or be done after discussion of some constraint violations that maybe should not be some. One could also make it so that cat-syncs that would result in constraint violations are resolved in predefined ways such as "create a new Wikidata item for open problems in {field/subject} when importing from cat Open problems" etc. It wouldn't import anything that is constraint-violating (there may even be a list of potential catsync imports that would be constraint-violating so one can go through them starting with those that would change most items and resolve what to do about the WD constraint-WP-cat-mismatch with one option being to simply not sync that and other options including changing the constraints or writing the data differently or adding it to different items etc).
  • Yes, importing this programmed in data from GitHub is another thing I wanted to ask about at some point. The goal is not to increase data a lot, it's to at least match the data already in Wikipedia or Wikimedia Commons (and my example was WMC not WP). For items that have categories, the WD item usually does not have as much data as the categories – so what's the point of the WD item...e.g. who would use that instead of the category if the latter has more data.
Prototyperspective (talk) 13:16, 31 October 2024 (UTC)[reply]
Having Wikipedia lists (pages with templates like Template:Dynamic list (Q11164797) be linked to Wikimedia list article (Q13406463) is a general policy we use. We do that because in general sometimes a Wikipedia has both a list and another article to the same topic. The decision of what templates to use is made by Wikipedia and not one that's made by Wikidata.
If you import Vuze (Q3563863)programmed in (P277)Java from Github, you have a well-sourced statement and thus the infobox for Vuze (Q3563863) could import that statement. If you import the same statement via Wikipedia categories, you can't as easily use it in Wikipedia infoboxes because Wikipedia cares about statements being sourced.
Note that the word sync has a different meaning than the word import. To do syncing you would also need to decide with what happens when data changes. Data might change on the Wikidata side and it might change on the Wikipedia side (and each Wikipedia has their own bot policies if a bot is supposed to do changes). We do have data imports from Wikipedia from ten years ago where the data changed on the Wikipedia side but we still host the same data on Wikidata as before. ChristianKl14:35, 31 October 2024 (UTC)[reply]
Yes, I'll ask about such imports from GitHub & GitLab another time and I was surprised when I noticed this hasn't been done so far. 1. It was however only an example. 2. When it comes to these, one could still set that on the item and then only add the source whenever such a GitHub import is done and have it without source prior to that.
Yes, and that's the reason why I used the word sync – category changes should update the data on the item(s) and Wikidata items changes should e.g. suggest a category change on WMC & WP. Prototyperspective (talk) 15:28, 31 October 2024 (UTC)[reply]
Asking about GitHub imports is likely going to do very little. Bots are generally run on Wikidata because someone cares about important specific data. Wikidata is largely a place where people with different interests come together and people work on what they care about.
Speaking of Wikipedia in the singular seems a bit naive. You would need to get a bot approval in every project in which you would want to run a bot to do something. Convincing any of the major Wikipedias to allow that is not going to be easy.
If you would want to do that kind of interwiki politics you could create a bot and seek relevant approvals, but that's a complex project. There are a lot of complex projects that someone could do to help Wikidata have more and/or better data. ChristianKl16:07, 31 October 2024 (UTC)[reply]
WikiProject software seems to care about software. I don't see an explanation why it would do very little but then this thread is not about that anyway. Good point, I was speaking of ENWP (for now at least) which has the most complete cat tree. From the Wikidata side, the sync to Wikidata is what matters and that is what the thread is about. Prototyperspective (talk) 17:31, 31 October 2024 (UTC)[reply]
I think there are few people who are able to do the kind of bot work that are constraint by ideas about what to do on Wikidata. Constraints are usually either doing the work or about finding consensus.
I think that most people on EnWiki consider unsourced claims pretty unimportant and won't be helpful with the your goal of adding more unsourced claims to Wikidata based on category data.
Policy-wise that still leaves the question of how to model data syncronization so that mistakes like applying list of unsolved problems in biology (Q2628887)subclass of (P279)open problem (Q1321906) don't happen open and then the question of how data removal is managed. After that it's still up to finding someone who's interested in creating a bot for the task that will run regularly. ChristianKl18:18, 31 October 2024 (UTC)[reply]
Each category import like 'Make Category:Writers by nationality write to the country prop if none is set and list items that don't have anything that is a subclass of writer or writer set in occupation' would be configured separately in the imports system. That's better than doing it all by hand or having Wikidata be far less useful than just using the more complete WP categories. Enwiki people do not consider categories unimportant which is why they're relatively well-maintained and a huge tree. This is WD anyway so I don't know why you bring it up. After that it's still up to finding someone who's interested in creating a bot This isn't about a bot itself, it's about a tool and this thread is about that – this is the project chat isn't it; I hope interested people read the starting post. On the other hand, maybe Wikidata will always be useful only for identifiers, not for statements as Wikimedia Commons and ENWP have far more data in their categories while main statements are missing or are flawed on Wikidata even for items as fundamental/major as 'Present', 'Future', etc and also when the correct statements could already be inferred from the WP cats. Prototyperspective (talk) 19:07, 31 October 2024 (UTC)[reply]
Again, this is a proposal to add bad data. country (P17) is not supposed to be used for people and Wikidata does not have a "nationality" property (the last three proposals were rejected).
You used the word "sync" instead of the word "import". Import is a word that's about moving data in one direction while "sync" is a word to move it in two directions.
Anything, that regularly adds data is a bot.
It's worth noting that tools like PetScan exist and someone who wants can do get a list of items from a category with them and use QuickStatements to enter data. Syncronization data however is more complicated and requires you to have an ungoing process and for that you need a bot. ChristianKl19:59, 31 October 2024 (UTC)[reply]
Again you focus on the specific example. I know there's many properties for countries and I don't know which is the correct one so I just said country.
Yes, again I said sync exactly because of that and I already clarified that.
A bot only executes, a tool like mix'n'match is more comprehensive than that.
PetScan exist and someone who wants can do get a list of items from a category with them and use QuickStatements this is the first thing you wrote (and this not a thread on your talk page) that actually relates to the thread subject, thanks. Maybe the tool could be be built around PS+QS. I didn't say a bot wasn't needed, the best ways to implement this would probably involve one (existing or new). Prototyperspective (talk) 21:20, 31 October 2024 (UTC)[reply]
I asked you for how you would think about preventing bad data to be added with the tool. That's an important question. Instead of answering it, you suggest an example that adds bad data.
As I said, we don't have a property for nationality. Nationality is a social construct over which wars are fought. We don't want to fight in Wikidata about whether people in Crimea are of Russian or Ukranian nationality. It's a construct for which we in the past decided not to add properties.
A tool like Mix&Match adds data when you tell it to add data. That's the permission it has. It doesn't add data a year from now. If you actually want to keep data up to date, you would need something that can add data in the future and that's a bot. ChristianKl23:30, 31 October 2024 (UTC)[reply]

Faruqolaitan123 creations

[edit]

The user @Faruqolaitan123 seems to have spent 2022 creating a lot of hard to identify individuals, many of the items they have created seem to have only a single name and the most basic statements. What should one do when coming across cases like these? Nominate each for deletion or something else? StarTrekker (talk) 20:25, 30 October 2024 (UTC)[reply]

Accidentally created an item via typo not realizing it already existed elsewhere

[edit]

I created Cantopotamon zhuaiense (Q130745113) not realizing that Cantopotamon zhuhaiense (Q107084939) already exists. This came from an existing typo on a Commons image, and I was careless and also didn't notice the typo. Given I don't assume there are gaps in the serialized IDs, does this QID just get recycled and used for something else? Somewhat new here. TheTechnician27 (talk) 18:11, 31 October 2024 (UTC)[reply]

We don't recycle Q-IDs. Just merge the items. ChristianKl18:47, 31 October 2024 (UTC)[reply]