Wikidata:Bot requests

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 15 days.

Request to replace the superseded WorldCat Identities ID for humans with the WorldCat Entities ID, or delete the superseded WorldCat Identities ID when the WorldCat Entities ID is present (2024-01-09)

edit

Request date: 9 January 2024, by: Peaceray

Link to discussions justifying the request

This is a link to the query to find a human with WorldCat Identities ID (superseded) but no WorldCat Entities:

Task description
  1. For a human with both a WorldCat Identities ID (superseded) (P7859) & a WorldCat Entities ID (P10832), delete the superseded WorldCat Identities ID.
  2. For a human with a WorldCat Identities ID (superseded) (P7859) but no WorldCat Entities ID (P10832), query that WorldCat Identities ID. WorldCat will redirect most, but certainly not all, of the time to the new WorldCat Entities ID. If found, insert the WorldCat Entities ID & delete the superseded WorldCat Identities ID.
Licence of data to import (if relevant)
Discussion
I agree. P7859 statements should only be deleted if a P10832 is there.
There is an additional complication. I have placed multiple instances of WorldCat Identities ID (superseded) (P7859) when each applied to the same item. WorldCat has not been careful about consolidating duplicate items; this not only applies to the Identities ID but to the OCLC control number (P243) as well. However, since clicking through on WorldCat Identities ID that have no corresponding WorldCat Entities lead to a page not found message, we should consider whether we should delete all WorldCat Identities ID (superseded) (P7859) when a WorldCat Entities ID (P10832) entity is present.
Also, perhaps we should not limit this to humans. I just thought that humans were the most important to process first. Peaceray (talk) 19:34, 9 January 2024 (UTC)[reply]
@Mahir256: Have you been doing this with your bot? --Ameisenigel (talk) 21:36, 26 August 2024 (UTC)[reply]
@Ameisenigel: For those P7859 values that resolved to a page with a P10832 value, most of the replacements have been done in the manner specified by @Epìdosis: on the property deletion page. For those which led to an error page, however, I have not yet begun removing those. Mahir256 (talk) 20:22, 28 August 2024 (UTC)[reply]
Request process

Request to replace URL to idref.fr by the dedicated property P269 (2024-01-31)

edit

Request date: 31 January 2024, by: Jahl de Vautban

Link to discussions justifying the request
  • No previous discussion
Task description

The bot should replace occurrences of reference URL (P854)http://www.idref.fr/$1 or reference URL (P854)https://www.idref.fr/$1 used in references with stated in (P248)IdRef (Q47757534) and IdRef ID (P269)$1.

Licence of data to import (if relevant)
Discussion

This should ensure a more robust referencing in the (unlikely) case of IdRef changing its URL. --Jahl de Vautban (talk) 17:56, 31 January 2024 (UTC)[reply]

Request process

Accepted by (Difool (talk) 02:12, 19 July 2024 (UTC)) and under process, see: Wikidata:Requests for permissions/Bot/DifoolBot 5[reply]

Request to Google Cache URLs (2024-02-11)

edit

Request date: 11 February 2024, by: GreenC

Link to discussions justifying the request
Task description
  • See work done at Enwiki: https://en.wikipedia.org/wiki/Wikipedia:Link_rot/URL_change_requests#Google_cache
    • There is a tool for parsing GC links to find the original source URL: https://github.com/greencardamom/Googcacheparse
    • Each Google Cache link logically has 4 possible outcomes:
      1. Source URL is live: Remove the GC link and replace with the source URL
      2. Source URL is dead and archive URL is not available: Remove the GC link and replace with the source URL and a dead link template
      3. Source URL is dead and archive URL is available: Remove the GC link and replace with the archive URL of the source URL
      4. Source URL is dead and archive URL of the Google Cache URL is available: Replace with the archive of the Google Cache URL

Make any adjustments to the above for Wikidata. Experience has shown #1 is most common and #4 is least common.

Licence of data to import (if relevant)
Discussion

Since I already did this for Enwiki and have a bot programmed for it, I might be of help. I don't have time to develop a bot for Wikidata. If someone wants to send me data in a file extracted from Wikidata, which I process, then you can take the output file and feed it back into Wikidata, that would be fine also.

Request process

Request to change country of citizenship from Denmark to Kingdom of Denmark (2024-06-11)

edit

Request date: 12 June 2024, by: Colin R Robinson

Link to discussions justifying the request

https://www.wikidata.org/wiki/Property_talk:P27#Denmark_(Q35)_vs._Kingdom_of_Denmark_(Q756617)

Task description

Replace country of citizenship (P27) value Denmark (Q35) with Kingdom of Denmark (Q756617)

Discussion

While adding people with Danish citizenship to Wikidata, I saw my entries being flagged with the none-of constraint (Q52558054) and came across this discussion. I have no opinion on it, but if the consensus is that Kingdom of Denmark (Q756617) should be used instead of Denmark (Q35) then a bot should update those thousands of entries.

  Notified participants of WikiProject Danmark --Ameisenigel (talk) 15:42, 22 August 2024 (UTC)[reply]
@Pasleim, @MisterSynergy: DeltaBot does the same already for Netherlands (Q55), so this would be easy to add. I agree with the request. Samoasambia 22:09, 22 August 2024 (UTC)[reply]
The DeltaBot job for the Netherlands is defined in User:DeltaBot/fixClaims/jobs. Adding another one shouldn't be much of a problem. We currently have ~14.3k items with Q756617 as P27 value, and ~36.8k items with Q35 as P27 value. —MisterSynergy (talk) 22:27, 22 August 2024 (UTC)[reply]
@Colin R Robinson, Ameisenigel MisterSynergy: I just added {{Autofix}} templates to country of citizenship (P27) to instruct KrBot to do this task. The reasoning for it was discussed in February 2022 on Property talk:P27 before the constraint was added. Samoasambia 20:31, 21 September 2024 (UTC)[reply]
Thanks! --Ameisenigel (talk) 20:46, 21 September 2024 (UTC)[reply]
Request process

Request to change the format of DrugBank ID (P715) in references (2024-06-27)

edit

Request date: 27 June 2024, by: Wostr

Link to discussions justifying the request
Task description

Earlier this year the format of DrugBank ID (P715) has been updated from (SALT\d{1}|CAT\d{1})?\d{5} to DB(SALT\d|CAT\d)?\d{5} (i.e. including the "DB" = "DrugBank" prefix). Recently I've updated all main statements using QuickStatements, but there are many uses of DrugBank ID (P715) in the references sections.

As I can't do it easily in QS (I don't know how), I'd like to ask a bot operator to update DrugBank ID (P715) values that are present in the references sections. An example is here: all DrugBank IDs that match \d{5} should be updated to include the "DB" prefix (00898DB00898).

Licence of data to import (if relevant)
Discussion


Request process

Request to change URLs pointing to nomisweb.co.uk (2024-07-10)

edit

Request date: 10 July 2024, by: Ælfgar

Link to discussions justifying the request
Task description

Hi,

The website nomisweb.co.uk is used as a reference on many items for British places. However, they have changed their URLs and all the links are broken now. They used to look like this:

https://www.nomisweb.co.uk/reports/localarea?compare=E04009659

And now they look like this:

https://www.nomisweb.co.uk/sources/census_2011_ks/report?compare=E04009659

All URLs need to be updated by replacing the reports/localarea bit with sources/census_2011_ks/report.

Licence of data to import (if relevant)
Discussion


Request process

Request to add mul label values to names .. (2024-10-01)

edit

Request date: 2 October 2024, by: Iamcarbon

Link to discussions justifying the request

https://www.wikidata.org/wiki/Help_talk:Default_values_for_labels_and_aliases

Task description

Add mul labels to given and family names when the item has an existing native label value with a mul language. This will limit duplicate labels from being added by bots and users, while we continue to work on various issues preventing us from deleting existing duplicated labels.

Discussion


Request process

Request to adjust badge color for "recommended article" (2024-10-02)

edit

Request date: 3 October 2024, by: Jonesey95

Link to discussions justifying the request
Task description

Add a bronze-colored star badge to the mw:Extension:WikimediaBadges extension. It currently uses a gold star for featured articles (top-tier), a silver star for good articles (second-tier), and also a silver star for recommended articles (third-tier). A bronze star should be used for third-tier articles to differentiate them from second-tier articles.

The detailed technical request is at phabricator:T189374.

Previous discussions of this extension have happened at this page, so I am posting this request here. If this is the wrong venue, please provide a link to the correct discussion page. Jonesey95 (talk) 21:07, 3 October 2024 (UTC)[reply]

Licence of data to import (if relevant)
Discussion


Request process