User talk:Mike Peel/Archive 3

From Wikidata
Jump to navigation Jump to search

Hi! Your bot added a sitelink connecting to the item about Maigret pointing to c:Category:Film locations of Maigret (2016). I added the P373 statement but not added a sitelink on purpose, because I think linking to the category from Wikipedia makes sense (it’s somewhat connected to the item) but adding a sitelink does not (it’s not that connected; the “Maigret” title of the infobox will be misleading once your bot adds the it). What do you think? If you agree with me, there should be a way to stop your bot—if I just revert its edit, I’m sure it will readd it. I can imagine a subpage listing blacklisted pages (easier to maintain, doesn’t mess up items) or a qualifier to P373 (more scalable, probably somewhat more efficient as the items can be excluded right in the SPARQL). —Tacsipacsi (talk) 21:56, 30 May 2020 (UTC)

@Tacsipacsi: I disagree, I don't think it makes sense to add a P373 statement in this case. Perhaps a "category for film locations" along the same lines as category for maps (P7867) would make sense. I think the best solution, though, would be to create a Commons category for the TV series, and link to that through a sitelink instead. Thanks. Mike Peel (talk) 22:02, 30 May 2020 (UTC)
@Tacsipacsi: I did some remodelling at Maigret (Q21998218), does that look OK to you now, here and on Commons? Thanks. Mike Peel (talk) 08:54, 31 May 2020 (UTC)
I also had this idea, but discarded it as it adds an extra hop for readers (Wikipedia article → c:Category:Maigret (2016 TV series)c:Category:Film locations of Maigret (2016)), which is not an ideal solution… But connecting the category page to a different concept on Wikidata is neither, so maybe yours is the least bad. —Tacsipacsi (talk) 22:09, 4 June 2020 (UTC)

San Martin, Buenos Aires

Hi Mike, think here goes something wrong: Q8702896. Rudolphous (talk) 05:56, 5 June 2020 (UTC)

@Rudolphous: Cleaned up (various bits belonged at Category:General San Martín Partido (Q30689565)), thanks for pointing it out! Thanks. Mike Peel (talk) 06:46, 5 June 2020 (UTC)
No problem - have a nice day. Rudolphous (talk) 06:56, 5 June 2020 (UTC)

Pi bot creating duplicates from dewiki and adding wrong label for French

https://www.wikidata.org/w/index.php?title=Q95951828&action=history

  • GND P227 in article, and item with that GND ID already in WD
  • Tschornaja isn't French

MrProperLawAndOrder (talk) 16:14, 31 May 2020 (UTC)

"Ljalja Tschjornaja" wasn't in Nadezhda Kiselyova (Q94741733) until it was merged, so the bot wouldn't have seen that item. Thanks. Mike Peel (talk) 17:04, 31 May 2020 (UTC)
Because you refuse to change the bot so it checks for GND ID and VIAF ID. The article contained both when created [1] MrProperLawAndOrder (talk) 13:17, 6 June 2020 (UTC)

Julie von Kästner

Hi Mike, obviously, here you were wrong: Q55090259 and Q96084425: Your Bot created a new dataset without check to the existing dataset? —Lantus 20:00, 5 June 2020 (UTC)

Q55090259 and Q96084425 - providing links. MrProperLawAndOrder (talk) 12:42, 6 June 2020 (UTC)
@Lantus: It checked, but it didn't find a match. I've merged the two items. Thanks. Mike Peel (talk) 20:03, 5 June 2020 (UTC)
Sorry, I am not happy with your answer. Same happend some days before with Q60843542 and Q95635282. You should ajust your bot! That makes no sense. —Lantus 20:05, 5 June 2020 (UTC)
"Wernhard Huber" vs. "Johann Wernhard Huber" - the bot wouldn't find the other item based on the name. Again, just merge the items. Thanks. Mike Peel (talk) 20:20, 5 June 2020 (UTC)
Yes sure, I know how to merge. But I only find them by chance and won't run behind them. How many items did your bot already create as a duplicate, i.e. without any idea behind and how many time it will cost to find and kill them? —Lantus 20:24, 5 June 2020 (UTC)
@Lantus: Either I turn off the bot, or I try to improve it. I think the latter is better. Can you help do so? The code is publicly available if you can help directly. Thanks. Mike Peel (talk) 20:31, 5 June 2020 (UTC)
No, sorry, I have no experience with programming. Propably you have to teach me. ;-)) But I know it would help if your bot would wait with his work for at least 24 hours after creating a new article. A lot of Wikipedia authors would workout a new dataset of their new lemma in Wikidata. —Lantus 20:41, 5 June 2020 (UTC)

User:Lantus, it would also help if articles about humans in dewiki get an existing GND ID faster. Maybe creators of articles about humans could be asked to add the GND ID, since they are already involved with the topic.

12 min. And of course, Pi bot should check if GND ID and VIAF ID exist in de:Template:Normdaten, cf.

Quote from Wikidata talk:WikiProject Authority control: "your Pi bot creates human items based on Wikipedia articles - if doing it from dewiki, could it also import VIAF and GND? MrProperLawAndOrder (talk) 15:28, 9 May 2020 (UTC)

Possible, but that bit of code is already quite complicated, so I'd prefer not to complicate it further. It sounds like there are other routes to import those values. Thanks. Mike Peel (talk) 15:57, 9 May 2020 (UTC)"

GND is a high value indicator to match articles about human from dewiki. Your bot not using it could be a reason for any mismatch from dewiki, since all items I create have it. If your bot could add the GND then via Property talk:P227/Duplicates users will take care of merges. MrProperLawAndOrder (talk) 01:42, 28 May 2020 (UTC)

MrProperLawAndOrder (talk) 13:11, 6 June 2020 (UTC)

Hello, please be aware, that the GND is not necessarily a reliable unique indicator in newly created german articles to identify a WD object, since authors sometimes just copy the information from other articles, which they have used as template, or they use the GNDName instead of the GND, when no GND exists. When trying to import the information with HarvestTools you get a "unique constraint violation", since the GND might already exists for another WD object and person. It has to be corrected in the german article in such cases. Sometimes also two articles with different spellings in the german WP for the same person might have been created. An addition, a lot of people, who have not published anything (for example sports people, some politicians, ...), might not have a GND (yet). --M2k~dewiki (talk) 14:29, 6 June 2020 (UTC)
In the german language Wikipedia there is a small team (about three to five people), which maintains GND and VIAF, but some time after articles have been created. A lot of authors do not know anything about this information, so it might not be included in the initial version at all, used wrong (GNDName instaead of GND), just copied from another article as template, or no GND might exist at all. In theory, it would be a unique identifier, while the actual practice is a little bit more complicated than that. --M2k~dewiki (talk) 14:51, 6 June 2020 (UTC)
In addition, there is an ongoing discussion, if the german language wikipedia should continue to maintain GND and VIAF in the wiki, or use the information from wikidata, as most of the other language versions do: de:Wikipedia:Umfragen/Normdaten aus Wikidata. --M2k~dewiki (talk) 15:02, 6 June 2020 (UTC)
@Lantus, MrProperLawAndOrder, M2k~dewiki: OK, I've changed the configuration of Pi bot so it no longer looks through dewp's recent changes to create new items for people. It does still check through duplicity - so if they remain unconnected after a few weeks then the bot will still create new items for them. Hopefully that gives you the space to sort all of this out. Thanks. Mike Peel (talk) 18:12, 8 June 2020 (UTC)
That means it will still create items from dewiki even if GND, VIAF or LCCN is present and their value is already on another item in WD, but it will not copy the value from dewiki, making it harder to find the duplication. MrProperLawAndOrder (talk) 18:34, 8 June 2020 (UTC)
@MrProperLawAndOrder: Only if you or other editors haven't already linked it with a Wikidata item. If you can create tracking categories on dewp that contain unlinked articles with identifiers, then I can write a different bot script to match those with Wikidata items. Thanks. Mike Peel (talk) 18:41, 8 June 2020 (UTC)
Then you would need to be able to read the values, e.g. GND, this is independent from a category. Could you add this reading ability to the current script? dewiki stores three values, GND, LCCN, VIAF. These are much used in WD: Wikidata:VIAF/type/human. Pi bot does great work on writing data to WD, if it could write P227 GND and maybe P214 VIAF at least on humans this would be great. This also prevents that others creating GND humans from other datasets don't create duplicates where Pi bot already created the human. MrProperLawAndOrder (talk) 19:45, 8 June 2020 (UTC)
@MrProperLawAndOrder: You're not listening. Please create tracking categories. Thanks. Mike Peel (talk) 19:57, 8 June 2020 (UTC)
"You're not listening." how do you know? Please stick to facts presented in this page. MrProperLawAndOrder (talk) 20:00, 8 June 2020 (UTC)
Sorry, it was late, I was tired. I already have scripts like [2] that can find an identifier on a page, search for it on Wikidata, and add a sitelink if it finds a match. They are separate from the one that creates new bio entries, though, and I have no plans to merge them. I can run that script either through all uses of a template (which I guess on dewp would be a long list), or through a tracking category for ones with specific issues. Hence the request for a tracking category. Thanks. Mike Peel (talk) 09:14, 9 June 2020 (UTC)

Thanks, @Mike Peel: for your adaption; it seems to work. But unfortunaly, an other bot does the same "mistake": @M2k~dewiki: please have a look here. This new item Q96200793 was created last night although the data record Q90687775 already existed. That's exactly the same problem as described above. I have no clue how to manage in general. —Lantus 04:43, 11 June 2020 (UTC)

Hello @Lantus: currently unconnected articles, categories, ... for the german language wikipedia can be found at Wikidata:Metrics. If they will be connected to existing wikidata objects, than it will be avoided that duplicates are created. --M2k~dewiki (talk) 13:00, 11 June 2020 (UTC)
@Lantus: possible duplicates might also be found a the "constraint violaton" pages of the properties for various IDs, for example:

If two objects have the same ID, then it might be a duplicate (and should be merged) or the ID might be wrong in one of the objects (and the IDs and the article they have been imported from should be corrected). Since these pages are updated by a bot from time to time (about weekly), the latest values can be found using the SPARQL-queries at the discussion pages of the properties, for example Property_talk:P345 (Strg + F -> SPARQL). --M2k~dewiki (talk) 15:45, 11 June 2020 (UTC)

Some edit you might want to take a look at

Hi,

just so you know (not sure if people already did report), it seems that PiBot did erroneously add some properties when it shouldn't, see diff. I know errors happen, I guess just checking instance of (P31) would be enough to prevent that. --Misc (talk) 20:01, 10 June 2020 (UTC)

@Misc: This is odd. Looking at the edit history, the bot made the changes at 13:53, which was before @Jesi: moved the biography to a new title on dewp at 15:19 and created the disambig entry, but somehow after marking the item here as a disambig page at 13:26? I don't understand that, so I'm not sure how the bot would - but a P31 check might make sense. Regardless, per the above discussion, the bot doesn't import items from dewp any more. Thanks. Mike Peel (talk) 20:49, 10 June 2020 (UTC)
Thanks to Misc for correcting the entries. -- Jesi (talk) 16:14, 11 June 2020 (UTC)

Hello, Mike! I have a problem related to some actions of your Pi-bot. Recently I discovered that the category at Commons for one Russian author: commons:Category:Sergey Povarnin — has not link to the Wikipedia article about this author being displayed on the left side (in the section "In Wikipedia"), though the article actually exists in the Russian Wikipedia: w:ru:Поварнин, Сергей Иннокентьевич. I decided to make the Wikipedia article to display on the commons category, and to achieve that goal, I removed link from wikidata item for category, and added it to the Wikidata item for person himself (not category about him). But now I discovered, that your Pi-bot returned all back (this and this edits). Assuming that your bot did the right thing and that it was me who was wrong, could you please explain: how I can make the Wikipedia article to be displayed in another way (since my edits are considered as wrong)? Regards, Nigmont (talk) 15:19, 18 June 2020 (UTC)

@Nigmont: The infobox code was recently rewritten, and you found a bug in the rewrite in the code that adds the extra interwiki links when the category is linked to a category item on Wikidata. I've patched it, you should now see the link in the Commons category. Thank you for letting me know about this! Thanks. Mike Peel (talk) 19:43, 18 June 2020 (UTC)

Change image

Hi! Please change Vani Bhojan Wikidata image. Vani Bhojan Zee Cine awards.jpg TO Vani Bhojan Oh My Kadavule Press Meet.jpg please change and please expand Vani Bhojan wikidata. Please I hope you change and expand Vani Bhojan wikidata. Please reply me kindly please reply me. Thanks!! Susenaes (talk) 02:27, 28 June 2020 (UTC)

Greenwich Hospital

I undid your merge, because the building and the charity are not the same thing. The Greenwich Hospital charity is still in existence but no longer housed in the old Greenwich Hospital building. Levana Taylor (talk) 19:35, 4 July 2020 (UTC)

@Levana Taylor: You mean Greenwich Hospital (Q15137935)? I'm happy for there to be separate items for the hospital and charity, but it looked like both were about the hospital. Please check the sitelinks if you unmerge it (in particular, the enwp and commons links should be on the same item, at least). Thanks. Mike Peel (talk) 19:38, 4 July 2020 (UTC)
The problem is that the Wikipedia article discusses both the charity and the building. The Commons is unproblematically pictures of the building, but it seemed to me that 4/5ths of the Wikipedia article was about the charity. Levana Taylor (talk) 19:44, 4 July 2020 (UTC)
@Levana Taylor: Perhaps split the enwp article then? There should not be a disconnect between the article and the commons category, since they link to each other via the Wikidata interwiki links. Thanks. Mike Peel (talk) 19:47, 4 July 2020 (UTC)
This is far from the only time that a single Wikipedia article covers subjects that deserve separate WD items. There was just a discussion on the Community Portal about this last month, where someone asked why some Wikipedias had only one article combining the Soemthing-Dynasty and the Something-Empire in China where other Wikipedias discussed them separately. The reply of experienced editors was that firstly, yes they should have separate items, and secondly, yes it's legitimate for some WPs to have one article for both. In this case, I think the way to resolve the problem is to create a redirect Wikipedia page for the building, link the building item to that, and leave a message on the discussion page of the existing article asking whether any editors want to turn that redirect into a real article. Levana Taylor (talk) 19:57, 4 July 2020 (UTC)
@Levana Taylor: If you think that's the best approach, go for it. Thanks. Mike Peel (talk) 19:59, 4 July 2020 (UTC)
Done. Are the interwiki links working correctly now? Levana Taylor (talk) 20:50, 4 July 2020 (UTC)

Making wikidata items for commons categories

Hi@Mike Peel: Your bot (Pibot) makes wikidata items for commons categories. This is not helpful. When I write an article for Cyathostemon, I expect to find the Category:Cyathostemon linked to the wikidata item Cyathestemon. (This maeans that a reader can find all the associated images, when they click on commons at the LHS) It would be helpul if you were to disable this aspect of your bot (or indeed your bot if this is all it does). Regards, MargaretRDonald (talk) 19:21, 6 July 2020 (UTC)

@MargaretRDonald: I think you're referring to these edits: [3] [4]. This is normal: where there is a category item available, then that's where the commons category link belongs. Then it matches categories on the Wikipedias. You may want to support phab:T232927 to sort out the sidelink issue. Thanks. Mike Peel (talk) 19:30, 6 July 2020 (UTC)
Hi @Mike Peel: Thanks Mike. It would be helpful for my understanding of what I need to do, if you were to update Cyathostemon (Q17047770) and Category:Cyathostemon (Q18282608) appropriately so I can see what I need to do in future. (And also the wikipedia article if necessary). MargaretRDonald (talk) 19:39, 6 July 2020 (UTC)
@MargaretRDonald: The same edits that Pi bot made. It will do them again soon. Thanks. Mike Peel (talk) 19:45, 6 July 2020 (UTC)
Hmmm. I remain at a loss to see just how the reader of the arricle now finds the commons category. Previously it came from the link to Cyathostemon (Q17047770) and the fact that beside the "Other wiki sites" the commons "Category:Cyathostemon" was listed. Your bot did not seem to make an appropriate link to Cyathostemon (Q17047770)??? MargaretRDonald (talk) 19:58, 6 July 2020 (UTC)
@MargaretRDonald: If you add {{Commons category}}, that will provide the link. Otherwise, it's the phab ticket I linked to above. Thanks. Mike Peel (talk) 20:01, 6 July 2020 (UTC)
Now found (P(10 Topic's main category) Thanks, MargaretRDonald (talk) 20:04, 6 July 2020 (UTC) But there does remain a problem: When I use a wikidata infobox in a commons category then the commons category:Cyathostemon NEEDS to link to Cyathostemon (Q17047770).?????? MargaretRDonald (talk) 20:09, 6 July 2020 (UTC)
Pi bot should sort it out. Mike Peel (talk) 20:23, 6 July 2020 (UTC)
Hi @Mike Peel: Perhaps you could point me to the page where this change was argued. (I now find that none of my plant articles point to their commons category unless I explicitly make them do so. And it now makes getting from commons to the articles I wish to add images to, a three step process, rather than a one step process. A total pain... and now all the thousands of plant articles which used to link to commons, all to be linked. This user is not happy). MargaretRDonald (talk) 03:48, 8 July 2020 (UTC)
@MargaretRDonald: It predated my involvement here, but see Wikidata:Requests for permissions/Bot/Pi bot 6 for the discussion with the bot task approval. You may also be interested in Wikidata:Properties_for_deletion#Property:P373, but that's a longer read. From the enwp side, you can use en:Template:Commons category, which will provide the correct link in these cases (I'm hoping that the sidebar issue can be fixed, see phab:T232927). From Commons, commons:Template:Wikidata Infobox will contain the direct link to the article, and also modifies the sidebar on Commons to link directly to the articles as well. So mostly this should be transparent, and a one-step process, not a three-step one. Thanks. Mike Peel (talk) 06:57, 8 July 2020 (UTC)
@Mike Peel: The problem is that if the infobox is linked to the category then one cannot link the category to the topic without it getting undone by your bot which then links it to the category, which does make it a three step process, and that is what I am unhappy about in the case of Cyathostemon (Q17047770) & Category:Cyathostemon (Q18282608). (I am well aware of the commonscat template - that was part of my complaint) So I do hope the sidebar issue is fixed as thousands of biota articles relied on and used it.Thanks for taking the time to reply. I hope it all gets resolved soon. From my point of view it is all currently a dog's breakfast and totally disruptive of my work on commons, wikidata and some 48 or so wikipedias.... MargaretRDonald (talk) 08:00, 8 July 2020 (UTC)

Humber

Thank you very much Mike Peel for sorting this out. I must try much harder to understand how the system works. Thank you for this and other good edits, Eddaido (talk) 08:27, 9 July 2020 (UTC)

Lady Alexandra ship

It looks like Q6469917 has elements of two ships, Commons:Category:Lady Alexandra (ship, 1924) (w:Lady Alexandra) and Commons:Category:IMO 9624835 (built 2012). It looks like you merged Q83557353 into it, which was presumably for the later ship -- any way those can be split back apart? Clindberg (talk) 20:41, 19 July 2020 (UTC)

@Clindberg: I've undone my merge, but probably there are still elements of Lady Alexandra (Q6469917) that need moving to Lady Alexandra (Q83557353), as it was mixed together before my merge. Can you check please? Thanks. Mike Peel (talk) 06:50, 20 July 2020 (UTC)
Thanks, I think I've put in correct values for each ship now. Clindberg (talk) 19:36, 20 July 2020 (UTC)

Pi bot adding self-referencing statement

Hey there! This does not look right. I’ll undo it, but you may want to look into what happened. Cheers! Edit: looks like there was an erroneous self-referencing statement that it added the reciprocal of. Belteshassar (talk) 18:50, 3 August 2020 (UTC)

@Belteshassar: It looks like garbage in, garbage out (Q1569381). Your edit has fixed it, thanks for spotting it! Thanks. Mike Peel (talk) 18:55, 3 August 2020 (UTC)
It was your helpful edit message that made me realize what was going on :) Belteshassar (talk) 20:10, 3 August 2020 (UTC)

Pi bot needs a tweak

Seems that Pi bot is not catching where someone has a category, and incorrectly used topic's main category (P910) on the item. Seems to me that we should be removing P910 rather than moving the category down the trail. [5]  — billinghurst sDrewth 11:29, 6 August 2020 (UTC)

Took me a while to work out why I had to do something that I had thought that I had corrected, as the bot repeated its move. Seen this a few times in the past few days.  — billinghurst sDrewth 11:30, 6 August 2020 (UTC)
@billinghurst: The bot doesn't check for the instance of (P31) cases, it just copies over the matching pair. I might be able to modify it to do that, but the bad cases would still need manual clean-up anyway to remove the bad topic's main category (P910)/category's main topic (P301) values, so it shouldn't be that much work - and at least the mis-edits are drawing attention to the bad data? Thanks. Mike Peel (talk) 11:34, 6 August 2020 (UTC)
P.S., if you have things you want me to change, or new things to code up, now is a good time to say as I'm on vacation from work for the next week, so will have more time to code things up here. Thanks. Mike Peel (talk) 11:45, 6 August 2020 (UTC)
Maybe we should we be looking to have a constraint violation for add P910 to a category???  — billinghurst sDrewth 11:46, 6 August 2020 (UTC)
There is Wikidata:Database_reports/Constraint_violations/P910#Conflicts_with_P31. Thanks. 11:49, 6 August 2020 (UTC)

Jackson Park

Something of a mess here. The en-wiki article is about a park; the scope of the Commons category (which doesn't look well used at the moment) is a neighborhood. - Jmabel (talk) 17:09, 14 August 2020 (UTC)

@Jmabel: Any thoughts on how to solve it? The article at en:Jackson Park (Seattle) does seem to talk about the neighbourhood a little at the bottom. Thanks. Mike Peel (talk) 17:11, 14 August 2020 (UTC)
Maybe treat the en-wiki article as a conflation. There's not a lot to say about the neighborhood: almost suburban neighborhood, handful of businesses and one big park. But they are definitely two different entities. - Jmabel (talk) 17:40, 14 August 2020 (UTC)
@Jmabel: I created Jackson Park (Q98398937) and made some changes to Jackson Park (Q6117310), does that look better now? I also removed one of the commons categories from the enwp article, just leaving the golf course one, as that seems the most applicable there. Thanks. Mike Peel (talk) 12:51, 15 August 2020 (UTC)
Looks reasonable. As far as I know, the park and the golf course are coextensive (unlike Jefferson Park on Seattle's Beacon Hill, which extends well past its golf course). - Jmabel (talk) 15:02, 15 August 2020 (UTC)

Avoiding repetitive reverse edits

I try to minimise the number of "low value"/reverse edits that I make at WD as every edit in that space is not an edit elsewhere generating the content.

So for something like creating the chapters of Studies of a Biographer (Q19069226) and linking to them to edition is fine, but then having to go to the item and adding all the chapters as the components. #ugh If there was a means to bulk add under a controlled means based on WLH or to have a bot, then THUMBSUP.  — billinghurst sDrewth 06:47, 31 August 2020 (UTC)

@billinghurst: If you're using published in (P1433), then it's not an 'inverse' property, so a bot probably wouldn't be possible. Better to just add the inverse values manually in those cases. Thanks. Mike Peel (talk) 20:16, 1 September 2020 (UTC)

PAWS/Pywikibot tutorials

Hi Mike, I'm currently working to improve documentation for PAWS. As a part of this, I'll be working on a notebook based tutorial about PAWS/Pywikibot. I was told you may be a good resource. :-) Would you be willing to discuss PAWS/Pywikibot with me (sync or async)? I'm interested in your experience with the current documentation, who you think is most likely to use PAWS/Pywikibot, common tasks folks are using PAWS/Pywikibot for, and if you have some examples you think would be good to highlight or share. Any thoughts are appreciated! Thanks! SRodlund (WMF) (talk) 17:28, 4 September 2020 (UTC)

@SRodlund (WMF): Thanks for the message! I can help on the pywikibot side (as a user of it, I don't maintain pywikibot), but I don't use PAWS, I run codes directly. Mostly on a dedicated Raspberry Pi, hence Pi bot. :-) I also make all my code open source, you can find the scripts at [6] - 'example.py' may or may not be particularly useful. Happy to chat off-wiki if you want. (P.S., the pywikibot documentation at [7] is dire and desperately needs improvements to make it more obvious how to do things with it!) Thanks. Mike Peel (talk) 17:40, 4 September 2020 (UTC)
@Mike Peel: Thank you! This tutorial will be directed at users (though initially users of PAWS), so your input is definitely appreciated. I agree the Pywikibot docs could be improved in general and would be interested in your thoughts on that. One goal for improving the PAWS docs is to make Pywikibot more accessible to newcomers-- so it goes that the Pywikibot docs should be clear and informative. I will check out these scripts, and as I get further on with the tutorial, I'll share it with you. My email address is srodlund@wikimedia.org--if you send me an email there, we can continue our discussion off-wiki. Thank you so much for your help! SRodlund (WMF) (talk) 20:48, 8 September 2020 (UTC)

Pi bot is too fast

Hi Mike, today your Pi Bot created a Wikidat item (Q99670484) just 20 minutes after the Wikipedia article (de:Boris Sergejewitsch Kolzow) was created. I think your bot should give the author and others (!) 24 hours time to look for matching articles in other Wikipedias. -- Olaf Studt (talk) 15:57, 27 September 2020 (UTC)

P.S. For subjects constricted to Germany, Austria, and eastern Switzerland, I think 3 hours are sufficient - but not for international subjects. -- Olaf Studt (talk) 16:09, 27 September 2020 (UTC)
@Olaf Studt: The bot mostly looks through recent changes to find recently created biographies, if it waits too long then they drop out of recent changes. It matches them to existing articles if it can, but the name has to be in the search results. I'm not convinced that waiting 24 hours would help. Thanks. Mike Peel (talk) 16:12, 27 September 2020 (UTC)

Merge

Hi, can you merge page of wikidata Q99943236 to Q94999718? Thank --ML8 (talk) 12:50, 8 October 2020 (UTC)

It looks like M2k~dewiki has already merged it. Thanks. Mike Peel (talk) 15:12, 8 October 2020 (UTC)

Hi. You did a few of these and there are existing category items where the Commons link may be better sited. Also, I see a problem with those as they seem a mix of template and main ns links, and at one point this one was called a list article. <shrug>  — billinghurst sDrewth 00:00, 10 October 2020 (UTC)

Thanks for finding the category item, I've linked between them now. Thanks. Mike Peel (talk) 12:12, 10 October 2020 (UTC)

Crimes or persons?

Hello Mike,

I spend lately some time to separate the item Q100256872 from Q100257355, as I feel the first is (should be) an item about a crime, the second about a person (the victim). I did state in the first item that it P31 a Q83267, whilst removing the indication that it is a person. The person is described in the second item (as I feel items should be clearly separated in Wikidata, no matter how much correlation there is between the two objects and that Wikipedia has (just) an article about the crime, as we (might) think the person itself had not sufficiently encyclopedic value before the murder on him.

Your bot did pas by and added both a P21 and a P570 to the item about the crime [8]. How can we help each other to prevent edits like that? I did make a link to the article about the person using P921, but maybe some other property would even be better.

I do see more wikidata-items where this segregation of items is not clearly made. I feel it is right to have them mixed up in Wikipedia, but that they should be separated in Wikidata.

Thanks for responding, RonnieV (talk) 17:08, 11 October 2020 (UTC)

About the same happens with Q100270220, where Pi bot did make the Wikidata item. RonnieV (talk) 17:11, 11 October 2020 (UTC)

Rudolf Christian Heinrich Kahle

Hello Mike, this seems to be a Devà-vue. Please have a look into your archive (Julie von Kästner) and have a look at my editing under Q55677918. Unfortunately you were once again too fast. I remember that we made the agreement that you should wait at least 24 hours before entering a new set of German Wikipedia articles to avoid such duplicates. Might also be interesting for User:M2k~dewiki. —Lantus 13:16, 11 October 2020 (UTC)

The code looks at recent changes, so it's not trivial to wait 24 hours. It's easy enough to merge duplicates. Thanks. Mike Peel (talk) 13:24, 11 October 2020 (UTC)
This does not seem to be a solution. So, carry on as before? —Lantus 04:50, 12 October 2020 (UTC)

Notability proposal

While last month I saw some discussion going on I didn't see any proposals around it, is the project on hold?

Also, I think that "Wikidata needs to bite the bullet" for Wikimedia Commons and just accept the structural need of Commonswiki categories for Structured Data on Wikimedia Commons (SDC), while the current proposal still requires two site links. Anyhow, there are many things we can point to, for example Wikidata includes millions of items of celestial items, so adding Commonswiki categories will be better for the SDC project, as it can be used at "its full potential" sooner. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 18:10, 13 October 2020 (UTC)

Vegan

Hi Mike! I'm not too sure regarding a recent merge of yours. Are food and cuisine the same thing? I was under the impression that food here literally referred to a concrete dish, and cuisine to a more general, over-arching category. Am I just grasping at straws here? 🤔 NMaia (talk) 23:58, 10 October 2020 (UTC)

@NMaia: Hmm, I see your point. This was vegan food (Q899696)/vegan cuisine (Q20669090) and Category:Vegan cuisine (Q8229164). However, en:Category:Vegan cuisine doesn't seem to mark any difference between the two, nor do the other wikis, and commons:Category:Vegan food matches enwp but with the different name. I wouldn't oppose splitting them again, but the sitelinks between the enwp and commons categories should be kept in the same item. Thanks. Mike Peel (talk) 09:13, 11 October 2020 (UTC)
@NMaia: I see you partially reverted the edits, it looks OK to me as it stands, let's see how it goes. Thanks. Mike Peel (talk) 19:38, 16 October 2020 (UTC)

Wikicite meeting

Hi! Asking you because you were involved in the development of en:Template:Cite Q.

Next week there is an online meeting about Wikicite. I am looking for ways to bridge the futuristic ideas of Wikicite with the actual realities and technicalities of editing the wikis. I proposed a session about this, and I'd love to hear more expert voices there. Here is the what I wrote about my presentation: meta:WikiCite/2020 Virtual conference/The frontend of WikiCite.

Would you be willing to join the panel discussion, and perhaps present some of your own ideas, or challenges of which you can think in transition to any future systems? I'd like to hear as many expert voices as possible.

Thanks! --Amir E. Aharoni {{🌎🌍🌏}} talk 12:20, 20 October 2020 (UTC)

@Amire80: In principle yes, however probably @Pigsonthewing: would be better suited (and perhaps more interested) than I. Note that five of us will be collaboratively working on Cite Q development soon via meta:Wikicite/e-scholarship/Mike Peel (Cite Q improvements). Thanks. Mike Peel (talk) 14:34, 20 October 2020 (UTC)
LOL, I've already asked him and he said yes :)
We're figuring out the final time.
If you want to join, it will be nice. --Amir E. Aharoni {{🌎🌍🌏}} talk 15:07, 20 October 2020 (UTC)
@Amire80: Sorry for the slow reply, I've been working on other things. In that case I'm happy to be involved, let me know if I should prepare anything or just participate in discussion. Thanks. Mike Peel (talk) 09:30, 22 October 2020 (UTC)

completing volume and page numbers for DNB biographies

Hi. Wondered whether you had considered the completing the published in (P1433) details of volume (P478) and page(s) (P304) numbers for the DNB articles like Bentley, Thomas (1693?-1742) (DNB00) (Q19074736). I am pretty sure that I have filled all the article gaps for volume no. in headers in DNB00, DNB01, DNB12 following the biographies move to subpages of the respective works.  — billinghurst sDrewth 14:48, 27 October 2020 (UTC)

Pi bot adding false claims of human

Special:Diff/1186983198

I understand how this mistake got made - it is because of the sloppy ways of Wikipedia categories - but it would be nice not to make it. Cheers, Bovlb (talk) 16:37, 26 October 2020 (UTC)

@Bovlb: Sorry for the slow reply. I've added an exception to skip articles where 'Disappearance' is in the article name. Thanks. Mike Peel (talk) 20:41, 30 October 2020 (UTC)
Thanks. You may want to include murder, killing, and assassination. Bovlb (talk) 18:18, 5 November 2020 (UTC)
@Bovlb: Done. Also, I had to quote you on that in 'Weird Stuff Wikidatans Say' group - I'm not sure we want a murderous bot editing. ;-) Thanks. Mike Peel (talk) 18:33, 5 November 2020 (UTC)

about a user who changes better English descriptions into over-simplified ones

Special:Contributions/118.136.0.0/16 is a user who often changes better English descriptions into over-simplified ones (almost 90%). I know his edits may not be vandalism. However it's very tiring to check his every edit and my words on User talk:118.136.4.35 seems not useful to change this situation Could you help? Thanks--迴廊彼端 (talk) 16:59, 5 November 2020 (UTC)

@迴廊彼端: It's not really the sort of thing I get involved in, perhaps ask at Wikidata:Administrators' noticeboard? Thanks. Mike Peel (talk) 18:35, 5 November 2020 (UTC)

Bot

Hello. This change and possiibly more is incorrect. [9]. Eurohunter (talk) 13:18, 9 November 2020 (UTC)

@Eurohunter: It looks fine to me. ARIA Charts (Q275029) has topic's main category (P910)=Category:Australian record charts (Q8277900), and that has the reverse category's main topic (P301) property, so the Commons category is correctly being moved to the category item. What's the problem? Thanks. Mike Peel (talk) 13:40, 9 November 2020 (UTC)
Australian record charts ≠ ARIA Charts. Eurohunter (talk) 13:45, 9 November 2020 (UTC)
@Eurohunter: Why are they linked with topic's main category (P910)/category's main topic (P301) then? Remove both of those and the bot won't try to repeat the edit. Thanks. Mike Peel (talk) 13:48, 9 November 2020 (UTC)
"main" ≠ "exact" for me so I think it is place for exact category but also related. Why it isn't it just named "Wikimedia category of subject"? Eurohunter (talk) 13:51, 9 November 2020 (UTC)
@Eurohunter: If it's not exact, then use related category (P7084) and category combines topics (P971) on the topic and category item respectively. Thanks. Mike Peel (talk) 13:55, 9 November 2020 (UTC)

Hi, Mike. I am tired restoring correct information which you are constantly destroying. Please note that not always commonscat corresponds uniquely to a Wikidata item, and use some exception list for such cases. --Infovarius (talk) 20:30, 2 November 2020 (UTC)

@Infovarius: I'm tired of you reverting them without explanation. I have a backlog of cases where I received notifications of your reverts, and I will look through them when I can (it was actually part of my plan for this evening). It would really help if you could leave me a message saying 'no, this edit was wrong because of the sitelinks in these languages', or if you could double-check the English links and split them off if they don't match other languages. Thanks. Mike Peel (talk) 20:35, 2 November 2020 (UTC)
@Infovarius: Ah, I see, there are two issues here. One is the links between topic and category items (which is what I was responding to), the other is Commons category (P373) values. I really hope we can sort out the P373 issue one way or the other soon, it's really a waste of time. Thanks. Mike Peel (talk) 21:42, 2 November 2020 (UTC)

@Infovarius: OK, let's work through the outstanding issues here.

  1. [10] - the problem is that animal (Q729) has topic's main category (P910)=Category:Animals (Q7157802) and Category:Animalia (Q6254409). From a Python and Lua perspective, this means that when you start at animal (Q729) and follow the main topic's main category (P910), you end up at Category:Animals (Q7157802), which has no Commons sitelink, and it causes an error. The ideal solution here is either to merge Category:Animals (Q7157802) and Category:Animalia (Q6254409) (and their sitelinks), or split commons/enwiki to have two separate categories here. [11] is a work-around though (re-ordering the values, and also marking one as preferred).
  2. Category:Surname (Q9740709) - the commons category clearly belongs at Category:Surnames (Q7045213) as it is for individual surnames, hence [12].
  3. Category:Stamp collecting (Q8810008) is not the same as Category:Philately (Q7215212) (you can do the former without being a philatelist)

(More soon. Thanks. Mike Peel (talk) 21:20, 4 November 2020 (UTC))

Sorry for problems but tackling your bot-like activity is time-expensive. I am trying to explain but sometimes this can be seen as not enough.
1. I don't quite understand the problem. Both commons:Category:Animals and commons:Category:Animalia works good (at least their infobox). And yes, I'd prefer to merge them everywhere, but I can't.
3. Philatelist is someone collecting (postage) stamps. I can't see the difference between stamp collecting (Q856075) and philately (Q131026). --Infovarius (talk) 16:45, 7 November 2020 (UTC)
@Infovarius: I think we're both feeling overwhelmed with each other's edits then. :-) Probably it helps to talk through at least some of them, as we both then learn from them.
1. On Commons it looks sort of OK, starting from the categories and going to the article, but from enwp it's not easy to go from the article to the relevant category. Either they are the same topic or they are different, but we should do one or the other, and not try to do both at once.
3. the difference is the same as jogging (Q816261) vs. athletics (Q542). Thanks. Mike Peel (talk) 19:17, 11 November 2020 (UTC)

Common cat edits

Hi Mike. Can you tell your bot not to do this and this? AFAIK it's standard practice that Commons category links are linked to the main articles, not to category articles. Thanks. NMaia (talk) 11:40, 14 November 2020 (UTC)

@NMaia: No, the standard is that the Commons category links go on the category item where it exists, otherwise they are on the topic item. This is Wikidata:Requests for permissions/Bot/Pi bot 6. Also see User:Mike Peel/Commons linking. Thanks. Mike Peel (talk) 11:45, 14 November 2020 (UTC)

Proper labels

Hello Mike, regarding to your created ship name labels please note, that the prefix Category should not be part of the label (see WD:L). Greetings Ein Dahmer (talk) 19:11, 17 November 2020 (UTC)

@Ein Dahmer: For the topic items (about the ship), like Wonder of the Seas (Q101936512), you're right, and the bot removes 'Category:' before creating the item. However, category items like Category:Wonder of the Seas (ship, 2022) (Q101936546) (a category related to the ship name) should have the 'Category:' prefix. Thanks. Mike Peel (talk) 19:15, 17 November 2020 (UTC)
Sorry, but I have another understanding: The topic item is the IMO number and the subsequent item is a wikimedia category related to the ship name. Therefore the label should be identical with the ship name without category prefix. Creating a new ship name label manually the prefix category is never displayed. Greeting Ein Dahmer (talk) 19:30, 17 November 2020 (UTC)
@Ein Dahmer: Ideally the topic item would have the ship names without the 'Category:' prefix too, as aliases if not the main label, but it's tricky to code up. I'm not sure we're going to make progress here, perhaps we should discuss this at Wikidata talk:WikiProject Ships or Wikidata:Project chat to get more involvement. Want to start a thread there, or move this over? Thanks. Mike Peel (talk) 19:34, 17 November 2020 (UTC)

Another false human

Re User_talk:Mike_Peel/Archive_3#Pi_bot_adding_false_claims_of_human

"deaths" - Special:Diff/1308075504 - 2020 deaths in American television (Q102047119). Bovlb (talk) 17:46, 24 November 2020 (UTC)

Hi Mike, could you please move "François Andrieu" to "F. Andrieu"? He is only known from one Medieval manuscript source, and is listed as "F. Andrieu". The assumption is that the full name is either "François" or "Franciscus" based on the norms of 14th-century France (see the English WP page for more information) but neither are confirmed. This is how Grove does it as well. Best - Aza24 (talk) 03:35, 28 November 2020 (UTC)

@Aza24: I think these were the edits you needed to do - you 'move' a Wikidata item very differently from how it works on Wikipedia etc., and anyone can make those changes. Perhaps you want to do the same for the other languages. Thanks. Mike Peel (talk) 10:33, 28 November 2020 (UTC)
Thanks, yeah sorry, I couldn't find a "move" button so I assumed that moves were admin-required here. I'll try and move the other language's pages later today. Best - Aza24 (talk) 16:23, 28 November 2020 (UTC)

Hi Mike, I'm from WMB. Just a question!

I was wondering if Citar Q (the Portuguese version of Cite Q) has archive-url as a parameter. I added a archive link in Prestes Maia Building, the greatest symbol of squatting in Latin America (Q104048129) but it doesn't show in my edit about this article. Does it support archive links automatically? Tetizeraz (talk) 06:18, 9 December 2020 (UTC)

@Tetizeraz: I think I answered you already on Slack, but just in case: full work available at URL (P953) is supported, archive URL (P1065) is not yet, but may be implemented tomorrow. It's best to ask these questions at en:Template_talk:Cite_Q so others working on the template also see them. Thanks. Mike Peel (talk) 14:20, 11 December 2020 (UTC)

Templates translation

Hi!

Thank you so much for your support at mw:Global templates/Discuss!

An essential part of that big project is now a community wish: m:Community Wishlist Survey 2021/Translation/Templates translation.

It would be very nice if you could vote for it, and invite your friends to do the same.

Thanks! :) --Amir E. Aharoni {{🌎🌍🌏}} talk 12:48, 11 December 2020 (UTC)

The bot created this, which have no content and is a duplicate with earlier created Q104413887.--GZWDer (talk) 19:15, 21 December 2020 (UTC)

Hi! I noticed your bot’s edit summaries contain the Qid’s, but without wikilinks (e.g. topic item edit, category item edit). Adding four bytes of brackets would be a pretty small change, but with a great impact: one can just click the link and check the other item, e.g. in case they want to see if the topics really match. (In this particular example, I’m not entirely sure they do match, by the way. I had to scroll down to the topic's main category (P910) statement to check this.) —Tacsipacsi (talk) 12:43, 22 December 2020 (UTC)

@Tacsipacsi: OK, changed. Thanks. Mike Peel (talk) 12:55, 22 December 2020 (UTC)

Views from

Maybe we should better discuss this here and not with many undos. I think view from a protected area does not make sense because a protected area is not a landmark. If you say this should be used much broader with also linking this to the municipality then this would be okay. But then is the question should there be a 1:1 linking or should this category-item be linked to many items? If it is only 1:1 linking Galgenberg und Fuchshöhlen (Q17123280) and Category:Views from Galgenberg (Seeburg) (Q104235842) should not be linked because the protected area has more views from the just from this mountain there. --GPSLeo (talk) 09:13, 23 December 2020 (UTC)

@GPSLeo: I think it makes sense to say 'view from this nature reserve'. However, I have no problems if you want to create an item for the mountain and move the 'view from' to that new item, I just don't have enough knowledge of this specific case to do that myself. In general, I object the removal of such statements instead of them being moved to a different item / remodeled properly. Thanks. Mike Peel (talk) 09:17, 23 December 2020 (UTC)
Of course this would be better. But as the first edit was made by a bot I just though this was accidentally. In generally we have a huge problem with people merging the items for geographic features and protected areas. --GPSLeo (talk) 09:38, 23 December 2020 (UTC)
In one of the cases the bot really had a problem. c:Category:Views from Schönberg (Ebringen) is categorized in the mountain and the protected area category but the statement was only added to the protected area and not the mountain. Schönberg (Q885298) --GPSLeo (talk) 10:08, 23 December 2020 (UTC)
@GPSLeo: Where there are multiple parent categories on Commons with Wikidata items, the bot will have problems identifying the correct one, those need manual corrections I'm afraid. Thanks. Mike Peel (talk) 11:57, 23 December 2020 (UTC)

Who is the GO TO for metadata so that enWS's header templates are best-WD

Where enWS is looking to get its headers and templates in best working order to have quality metadata that inhalable to WD and best findable, do you know who we talk to? How do we make enWS less sucky, but more suckable. Great set of passionate transcribers doing their thing, but not data visionaries. Pointers appreciated.  — billinghurst sDrewth 23:16, 24 December 2020 (UTC)

@billinghurst: Perhaps ask at Wikidata:Project chat? If you have specific tasks that I can help with via Pi bot, let me know, but I don't have the capacity to do much more than that at the moment. Thanks. Mike Peel (talk) 18:04, 30 December 2020 (UTC)

Edits on Wikimedia disambiguation page

https://www.wikidata.org/w/index.php?title=Q4167410&oldid=1331376190 seems to be wrong. ChristianKl16:06, 30 December 2020 (UTC)

@ChristianKl: Thanks! I've fixed the bug in the code, will clean up the cases in Wikimedia disambiguation page (Q4167410). Thanks. Mike Peel (talk) 17:32, 30 December 2020 (UTC)

Incorrect merge

Hi - I think you have mistakenly merged two different items. Brooke House Nature Reserve (Q42395824) is a nature reserve in Suffolk, you have merged it into a house in Devon with a similar name JerryL2017 (talk) 20:00, 9 January 2021 (UTC)

@JerryL2017: Thanks for spotting that! I've unmerged them, and I've moved the link to en:Brooke House to the correct item. Thanks. Mike Peel (talk) 20:06, 9 January 2021 (UTC)

Labels needing fixing

See e.g. Maurice Green (Q104834539).--GZWDer (talk) 19:42, 15 January 2021 (UTC)

@GZWDer: What's the problem? Thanks. Mike Peel (talk) 19:43, 15 January 2021 (UTC)
For articles, the label should not include the disambiguation bracket (e.g. use "Maurice Green" instead of "Maurice Green (cricketer)").--GZWDer (talk) 21:12, 15 January 2021 (UTC)
@GZWDer: OK, changed in the code. Thanks. Mike Peel (talk) 08:46, 16 January 2021 (UTC)

Da warst Du leider wieder zu schnell. Den Datensatz zu de:Georg Johann Detlev von Gloy gab es bereits (Q64690796). —Lantus 03:57, 21 January 2021 (UTC)

Thanks for merging them. Mike Peel (talk) 07:43, 21 January 2021 (UTC)

Hi! Thanks for explaining the removal (you could avoid one revert cycle by undoing my December revert, by the way). If you intentionally remove a sitelink, please also remove the infobox on Commons—there are already more than 60k pages in c:Category:Uses of Wikidata Infobox with no item, it should not be grown even further whenever possible. —Tacsipacsi (talk) 22:53, 23 January 2021 (UTC)

@Tacsipacsi: Sorry, I missed the December revert. commons:Category:KdF-Seebad Rügen should still have an infobox, but it needs a separate item for the building, so I've created KdF-Seebad Rügen (Q105061441) for it. Thanks. Mike Peel (talk) 10:38, 24 January 2021 (UTC)

Pi bot and aliases

Hi Mike! I was wondering whether it'd be possible to make Pi bot a little smarter when it comes to aliases. For instance, I recently saw it created Frank LoMonte (Q105091010) and George Gorse (Q104889632) for pages I wrote, but it didn't pick up the middle initials to add "Frank D. LoMonte" or "George L. Gorse" as aliases, and I don't think it picks up full middle names for pages where those are known. I'm sure there are exceptions that'd have to be handled, but given the pretty consistent formatting of bolding the name at the start of a biography, I'd think it would be possible to pick that up and add it to the "also known as" field. Would that be feasible? {{u|Sdkb}}talk 21:18, 29 January 2021 (UTC)

@Sdkb: It's possible, but tricky, since it's free prose rather than structured data. I could look for everything in bold in the first paragraph, but if there's a missing closing ' then that could easily go wrong... Thanks. Mike Peel (talk) 15:24, 2 February 2021 (UTC)

Stena Edda (ship, 2020) (Q101930547)

The IMO number refers to the hull and is invariant through its lifetime. On it is currently Stena Edda, but later in its life it may be reconstructed with a different name. Hence The Commmons category Stena Edda is currently correct- but that may change, in which case the Commons category will then be the updated name while the IMO remains the same. Not the first time this mistake has been made. Rodhullandemu (talk) 15:17, 2 February 2021 (UTC)

@Rodhullandemu: Yes, hence why Stena Edda (Q101930547) has the IMO, and Category:Stena Edda (ship, 2020) (Q101930564) has the ship name, which is linked from the first item via category for ship name (P7782). If it gets given another name, then there's another commons category that can also be linked to via category for ship name (P7782). It's set up OK at the moment, please don't mess around with it. Thanks. Mike Peel (talk) 15:22, 2 February 2021 (UTC)
An incredibly silly way of doing things, and by no means obvious, butI'm getting the hang of that here now. Rodhullandemu (talk) 15:24, 2 February 2021 (UTC)
If only Commons used a single category per ship, it would be much simpler... Thanks. Mike Peel (talk) 15:25, 2 February 2021 (UTC)
It does. They just share the same IMO. There should be a Wikidata item for each IMO, the "has part" or some analogy of that for any different uses on that hull. Rodhullandemu (talk) 15:28, 2 February 2021 (UTC)
@Rodhullandemu: Um, where the 'Wikidata item for each IMO' here is Stena Edda (Q101930547), and "the "has part" or some analogy" is category for ship name (P7782)...? Thanks. Mike Peel (talk) 15:30, 2 February 2021 (UTC)

Edition level for many reproductions of enWS works housed at Commons

Hi. Some of the reproductions that enWS produces the images at Commons are at edition level for the category, not work level, so the interwiki shouldn't be relocated. If you want to create a parent category to house editions, then please do, though please don't move them to the work item. Numbers of works have different illustrators, so we like to tie them down with a range of djvu file, and other categorisation rather than make them generic. Thanks for your understanding.  — billinghurst sDrewth 01:05, 8 February 2021 (UTC)

Addendum, if you think that the Commons categories are not suitably named, then we can look to work on that to clarify, and we have done so in later times.  — billinghurst sDrewth 01:07, 8 February 2021 (UTC)
@billinghurst: The issue with commons:Category:Diary of a Nobody is that for the enwp to commons link to work, the sitelink needs to be at The Diary of a Nobody (Q864150) and not The Diary of a Nobody (Q98785962). The simplest option is probably to have a category for the work, and then subcategories for editions, which I've demo'd in this case. Would that make sense? Also, there seems to be various bits of media about the book on Commons that might not be about the edition, I've added the ones I could find (mostly via the enwp article) to the new parent category. Finally, if you move a Commons category, please leave a redirect behind. Thanks. Mike Peel (talk) 07:48, 8 February 2021 (UTC)
I understand the consequences for the WPs, however the WSes take it in the a___ so often around links and connections, so my heart isn't exactly bleeding. Yes, I would agree that a parent category is a means to achieve a solution, as I intimated in my initial post. [Also noting that WSes can have work level pages (version pages) that link to work items and utilise those interwikis, though they are much fewer in number.] My conversation is solely about edition categories where typically the WSes have reproduced all the images from an edition of a work; and I know that it is a complex beast of a situation as nothing is ever cut and dry.

FWIW there is little value in redirects as the category is essentially complete; the category was moved and retains its history; HotCat will find that extended category name as needed; the linking at enWS is through the WD item and hard redirects can be just as problematic.  — billinghurst sDrewth 10:16, 8 February 2021 (UTC)

@billinghurst: I seem to be getting things like this from all directions as I try to sort out all the links from Wikidata to Commons. ;-) I understand your points, but it's good to try for a best practice so we're not getting in each other's way, and ideally one that doesn't require too much work. :-) Redirects are useful for at least a short time to resolve changes in Commons category (P373) values (until that property is deleted), and on enwp to update the links, otherwise Pi bot will remove the links (e.g., [13]). Thanks. Mike Peel (talk) 11:23, 8 February 2021 (UTC)

Pi bot 19 issues?

It looks like Pi bot 19's duplication checking is getting some false negatives. See (now merged—see the item you'll be redirected from) Running Against Time (Q105424715), place de l'Odéon (Q105424671), and Café Voltaire (Q105424675). CC Majavah who caught what seemed to be happening. Perryprog (talk) 14:45, 10 February 2021 (UTC)

@Perryprog: It seems to be working OK? en:Running Against Time was created on 26 January, so over 14 days ago, and hadn't been matched with the item here in that time, nor has it been edited in the last 7 days (extended from 1 day as there were presumably search results). So it meets the criteria set for creating an item, even though it may be a duplicate. Thanks. Mike Peel (talk) 14:51, 10 February 2021 (UTC)
I see—I had assumed the bot would be checking for potential duplicates to prevent it from making duplicates, as the label of Running Against Time (Q10365384) matches the title of en:Running Against Time. My apologizes then. Perryprog (talk) 15:18, 10 February 2021 (UTC)
@Perryprog: For people, the bot tries to match up items beforehand using extra info like the birth year (just the label isn't enough). For everything else it currently just waits to give time for others to match them before creating a new item for them, so they don't stay unconnected from Wikidata for too long. I can generate lists of possible matches, I can put them somewhere if there's a good place that people will look through them. Thanks. Mike Peel (talk) 19:34, 10 February 2021 (UTC)
That sounds pretty helpful. Perhaps something that's potentially a match would be listed, then after however many days, if it's still unlinked, the bot can move it to a new page/section/archive (or just delete it), and proceed as normal with creating a new item. (Or something like that—I haven't really thought this through, and I assume you already have. ;)) Perryprog (talk) 19:41, 10 February 2021 (UTC)
@Perryprog: I haven't thought it through yet either, so suggestions are welcome. I thought about setting it up as a Wikidata Game, but a game to do this already exists - I don't know where it gets suggestions from though. I could set up a wiki page (like User:Pi bot/doublecheck for imported shortdescs from enwp), but would anyone look at it? Thanks. Mike Peel (talk) 19:45, 10 February 2021 (UTC)
I mean, it depends what you mean by "would anybody look at it"—it doesn't need to be regularly viewed to be helpful (which reminds me of c:User:OgreBot/Uploads by new users, for example, but that might be just me). I personally think for this type of task, where there's a need for human review or a possibility of mistakes, some sort of log would be good (and perhaps maybe it would be frequently used, but that's hard to predict). And just because my interest in this task is now piqued, here's a rudimentary diagram of what I was thinking specifically—it's not comprehensive or anything, but hopefully you get the idea. Perryprog (talk) 21:07, 10 February 2021 (UTC)
@Perryprog: The current definition of "would anybody look at it" that I'm using is 14 days since article creation and 7 days since the last edit if there is a potential match and/or 1 day since the last edit with no potential match. The number of days can easily be tweaked if needed, but it shouldn't be too long. This approach works well for "no likely matches" at least. It is rare that there is an obvious match - for humans it's possible to identify them by cross-checking with their birth dates, but even then I've seen edits reverted because the match was wrong. "Potential match" is reasonably common, and I think this is the situation we should focus on here. We're missing the 'list it' step, the 'if unlinked' bit goes back to "would anybody look at it". Thanks. Mike Peel (talk) 21:24, 10 February 2021 (UTC)
Ah sorry—I misunderstood what you meant when you said that. I thought you were asking if a general list/log of potential duplicates would looked at. I think those are reasonable values for listing times, though. I'm wondering if tweaking the "match likelihood" could be done through some (probably tedious) examination of categories or the existence of disambiguation pages—that's almost certainly overkill and error-prone though. Regarding a "list it" step—is that covered through the step after "potential match(s)"? (I might just be misreading what you said.) Perryprog (talk) 21:43, 10 February 2021 (UTC)

Exterior of database

Hi,

I see that you bot added "exterior of Mérimée database" on many items. I'm guessing you used the Commons category but it make no sense.

I reverted it on Base Mérimée (Q809830) (it only took one click) but could you do it on the reverse item like Category:Exterior of Église Sainte-Trinité (Moussé) (Q104629437)? and/or maybe replace it with the actual building?

Cheers, VIGNERON (talk) 20:18, 11 February 2021 (UTC)

@VIGNERON: Ah, thanks for the heads-up. I'll fix them, but not tonight. Thanks. Mike Peel (talk) 20:21, 11 February 2021 (UTC)
No worries, error happens. Take your time (I prefer slow but good than fast and bad ). Cheers, VIGNERON (talk) 08:59, 12 February 2021 (UTC)

Len R. Troncale

Hi Mike, thanks for all your work here. I noticed that this edit is incorrect as my contacts in the US confirm. I hope this doesn't happen again. Best regards, -- Mdd (talk) 16:53, 15 February 2021 (UTC)

@Mdd: I'm confused, it looks like you added the date of death to the English Wikipedia article with this edit, pi bot just copied that over here. It's still live in enwp, so probably the bot will copy it over again in the future. Thanks. Mike Peel (talk) 17:13, 15 February 2021 (UTC)
Thanks Mike and my apologies. This was entirely my mistake, and this is set right now. -- Mdd (talk) 17:29, 15 February 2021 (UTC)
@Mdd: No worries, thanks for fixing it. :-) BTW, with this edit, the reason it didn't show anything is because none of the info in Len R. Troncale (Q6521924) has a reference ('imported from' doesn't count), and enwp requires references. Commons, on the other hand, doesn't - which is why it works much better in commons:Category:Len R. Troncale. Thanks. Mike Peel (talk) 17:59, 15 February 2021 (UTC)
Thanks again, I will try to keep this is mind. -- Mdd (talk) 18:16, 15 February 2021 (UTC)

Q17402020

Hi. If the page is about the Marinemuseum (Dutch Navy Museum) the (Rijks)monument part should be removed. The monument status is for the "'t Torentje" building (gebouw voor opslag voor licht ontvlambare stoffen/building for storage for highly flammable materials), not the museum itself which is composed of a site with several buildings (including another Rijksmonument "508473 Gebouw I (object D)"). It is a bit confusing however that the national monument register has named the entry "508470 Marinemuseum (object T)", but that's just because the museum used to be only that building.

So, there should be a Marinemuseum wikidata page (for the museum) and a Object T/'t Torentje wikidata page (for the monumental building). I'm not able to do this myself because I am not very familiar with wikidata. I would just make a mess. --Larshei (talk) 16:03, 21 February 2021 (UTC)

@Larshei: Ah, I see, I've created 't Torentje (Q105620609) for the building and moved the Rijksmonument statements to that, how does that look? Thanks. Mike Peel (talk) 16:07, 21 February 2021 (UTC)
Thanks. The rijksmonumentennummer should be 508470, the 21386 is an old/out of use one. --Larshei (talk) 16:38, 21 February 2021 (UTC)
@Mike Peel: Turns out there already is one: Q17459314 ! --Larshei (talk) 16:45, 21 February 2021 (UTC)
Ah! Merged. Thanks. Mike Peel (talk) 16:47, 21 February 2021 (UTC)

Q105613214

Guten Tag Mike. Hier ist Dir leider wieder ein Fehler passiert. Wir haben darüber schon einige Male gesprochen. Du bist einfach zu schnell. :-// —Lantus 07:21, 21 February 2021 (UTC)

@Lantus: Thanks for merging it, this will happen every so often, sorry. Thanks. Mike Peel (talk) 08:28, 21 February 2021 (UTC)

Hello Mike,

your bot is overall doing a great job connecting new articles to existing objects in most cases and a great help for the few users from the de-WP, who are active on Wikidata on a regular base! Thank you very much! Usually some of the duplicates created by Pi bot I can find and merge when I try to import GND, VIAF, LCCN from the de-WP (unique constraint violation).

@Lantus: Most new users from the german Wikipedia are not aware of the existance of wikidata. Some regular users, who know about wikidata, do not care about it, some even complain, when they are informed about a connection to an existing object via "ping" to the articles or categories they have created. So, in most cases (there a several hundreds of articles and categories created every day in the german language wikipedia) it would not make any difference when and how often the connection respectivley creation is done by the bot, since no user from de-WP would have done it manually. Since the bot runs every hour, on average there is half an hour time to connect to an existing object before the bot does this for articles, which are created in the article namespace (but not for articles moved from the user namespace to the article namespace or converted from a redirect to an article, in both cases this still has to be done manually, as well in cases where the bot can not decide if an object exists and for articles different from humans, like films, books, buildings, locations, organisations, categories, templates, navigation items, ...). So in most cases either an object is connected immediately after creation by the user who created to article or category or probably never, but not after a few hours.

From my point of view it would be necessary to create awareness for the existance of wikidata, the need to connect to the existing objects (or to create one if not existing), to offer help and support to the authors if necessary (a collection of frequently asked questions and answers can be found at de:Benutzer:M2k~dewiki/FAQ#Wikidata for further reference), and to explain the advantages of wikidata, like the possibility to find other external lexical entries in the wikidata object and the possibility to check the articles, sources, media, ... used in other languages (en-WP, fr-WP, it-WP, es-WP, ...) and projects (commons, wikisource, wikivoyage, ...).

Also see

Please also check

@M2k~dewiki: If it would be any use, I could set Wikidata:Requests for permissions/Bot/Pi bot 19 running on dewp (create new items for unmatched articles and categories after 14 days), although looking at the few articles on duplicity I guess you must have something similar running already? Thanks. Mike Peel (talk) 11:46, 21 February 2021 (UTC)
Hello Mike, currently articles, categories, templates, ... which are not connected by Pi bot (for some humans, not the ones moved from the user namespace for example or where the bot can not decide) or disambiguation pages (mainly handled by PLbot) are created/connected using PetScan/duplicty via the links on User:M2k~dewiki/Tools/Create_Objects for de-WP. As fas as I know there is no other bot except Pi bot and PLbot for de-WP. The articles on this list mainly should be articles which are proposed for deletion, so after the proposal has been decided and the article is keept the object will be created or no object will be created at all if the article is deleted. --M2k~dewiki (talk) 12:36, 21 February 2021 (UTC)
OK, sounds like you have it in hand then, let me know if pi bot can help further in the future. Thanks. Mike Peel (talk) 12:41, 21 February 2021 (UTC)
Hello @Mike: I would appreciate very much if you could set up your bot to create/connect articles and categories after 14 days for the german language wikipedia. --M2k~dewiki (talk)

Good day to you both, consider me pedantic or even misinformed, but for me duplicates are annoying and above all avoidable. I don't understand why the PIBot can't check for new entries with an interval of 36-48 hours. I know about the ignorance of many de-users and I would be pleased if we, M2k~dewiki, could host an event together on this topic, a Wikicon at least. Perhaps we could convince one or the other of the importance and usefulness of Wikidata. —Lantus 14:48, 21 February 2021 (UTC)

@Lantus: I agree with duplicates are annoying, but I do not agree that they are (completely) avoidable for all objects, articles, categories, ... due to

  • several hundreds of daily created articles, categories, ... (and 92 million existing objects)
  • 300 different supported languages with different alphabets, characters set (cyrillic, japanese, chinese, greek, ...)
  • the small number of active users from de-WP
  • even within one language there might be different spellings or words for the same entity
  • even if you check manually, you might overlook some variant or different spellings or wordings or you might not check every of the 300 languages or the search returns so many entries with the same name, that you overlook the right one etc.

One approach to find objects resp. duplicates is by using various IDs, like

and so on. Since these IDs should be unique, if one ID is included in two objects the objects and also the articles should be checked and corrected or merged. Every property comes with lists of "constraint violations" on the discussion page.

According to Special:Statistics we currently have 92 million objects, but current Q-numbers are higher than 105 million i.e. there are 13 million "unused" Q-IDs, Some of the never have been allocated (e.g.due to software errors), some of them have been duplicates and have been redirected and some of them have been deleted (or marked as deleted / hidden from users who are not admins). Mister Synergy once wrote in a discussion, that these three factors are about equally distributed amongst these 13 million objects, so maybe around four million objects have been duplicates and have been merged.

From my point of view, we should focus on the big mass of creations resp. connections that work really well without duplicates, and to continously improve the methods, without losing the advantage of beeing able to handle hundreds of objects every day.

For example, my suggestion/whish for Pi bot would be to check for various IDs (like IMDb, VIAF, GND, LCCN, ... - and to import them as well if available) and to also check for articles, that have been moved from the user space to the article space.

Also see:

--M2k~dewiki (talk) 16:07, 21 February 2021 (UTC)

The way the bot works is it goes through recent changes - if a delay of 36-48 hours was introduced, that method wouldn't work any more. I can read in other sources of unmatched items if they are available, though. From my point of view, some level of duplicates are unavoidable, although they can be minimised. Thanks. Mike Peel (talk) 16:09, 21 February 2021 (UTC)
Yes, certenly minimised. — No, M2k~dewiki, you are certainly right. It will not be possible to completely avoid duplicates. But I am only referring to articles, not templates etc. I just mean that duplicates could be reduced by giving a little more time to make new Wikidata records from new articles. That is my point. They do exist, the authors in deWP, who check for new articles in the Wikidata dataset to see if they might already exist, possibly with a different spelling (especially important when transcribing from other alphabets). It would simply help a lot if your bot did not become active immediately, but only one and a half to two days later. Or what is wrong with that? —Lantus 20:45, 21 February 2021 (UTC)
Hello @Lantus: since I do not operate a bot, but manually create/connect the objects, from my point of view it would not make a big difference if I would wait some time to connect resp. create the objects. If I overlook an item I probably would also overlook it at a later point in time. The main difference would be that the backlog of unconnected items gets longer and growing, so there is more work to do left.

Anyone who is willing to help in manually connecting unconnected articles resp. categories to existing objects or create new objects could do this using the following links (which I also use and also can be found at User:M2k~dewiki/Tools/Create Objects):

In order to raise the awareness for wikidata I also post the {{welcome|~~~~}} message on empty discussion pages of users who recently created articles in de-WP. --M2k~dewiki (talk) 00:03, 22 February 2021 (UTC)

Pi Bot made these edits. I have no idea where they came from (dates not in enwp at that time), but they look wrong: birth=death. There are probably others, because I found similar at Mike Opelka (Q97501525). I figured you'd want to know. --99of9 (talk) 23:16, 25 February 2021 (UTC)

Hello @99of9: the two dates are included as comments in the Infobox presenter in the parameters birth_date and death_date, see the source code of the article. --M2k~dewiki (talk) 00:22, 26 February 2021 (UTC)
@99of9: Yes, they were in the source code, I've removed them. The bot looks at the raw code, not the rendered wikitext, and it's difficult to automatically remove commented out text. Thanks. Mike Peel (talk) 08:20, 26 February 2021 (UTC)

Creation of categories and articles after 14 days

@M2k~dewiki: If it would be any use, I could set Wikidata:Requests for permissions/Bot/Pi bot 19 running on dewp (create new items for unmatched articles and categories after 14 days), although looking at the few articles on duplicity I guess you must have something similar running already? Thanks. Mike Peel (talk) 11:46, 21 February 2021 (UTC)

Hello @Mike: I would appreciate very much if you could set up your bot to create/connect articles and categories after 14 days for the german language wikipedia. --M2k~dewiki (talk) 14:55, 24 February 2021 (UTC)
For new/unconnected articles and categories different URLs are available, some are listed on Wikidata:Metrics (and User:M2k~dewiki/Tools/Create Objects). --M2k~dewiki (talk) 15:02, 24 February 2021 (UTC)
@M2k~dewiki: Sorry for the slow reply. I will implement this soon (perhaps this weekend). I've been doing a check through the backlog of articles/categories for enwp and ptwp before setting the bot running, but probably that will be quite quick for dewp. :-) Thanks. Mike Peel (talk) 19:36, 25 February 2021 (UTC)
@M2k~dewiki: I've been checking this today. For articles, I think I'm ready to go. For categories, I have a question. I see dewp has "Datei", "Vorlage" and "Wikipedia" types of categories (data, templates, and wikipedia content?), should the bot exclude or include those? I would like to set the code running when you're around, so you can help keep an eye on it, if that would be OK? Thanks. Mike Peel (talk) 18:50, 26 February 2021 (UTC)
Hello Mike, I would ignore categories beginning with "Datei:", "Vorlage:" and "Wikipedia:". There might be also other types of categories to ignore (like Benutzer:, Portal:, Hilfe:, ...), I would ignore all subcategories of de:Kategorie:!Wikipedia. Does your bot also add standard descriptions for categories? (see for example d:Q105682332) Does the bot include the part in parenthesis for categories names? (see for example d:Q105682332). How often and when does this bot run? --M2k~dewiki (talk) 19:07, 26 February 2021 (UTC)
@M2k~dewiki: OK, I can easily skip pages/categories based on text in the name, I just need a list of them. I can also skip pages/categories that use specified templates (I have a bunch of these defined already, we can add more if needed), but 'all subcategories' is very tricky so I'd prefer not to do that. For categories, they look like Category:Hospitality companies established in 2021 (Q105686964), i.e., sitelink, label, and P31 value, I think other bots add the rest anyway. It removes parentheses for articles, but not for categories. I'm currently running it manually in the mornings, but expect to schedule it to run around 5 UTC each day (the query to get the candidates currently runs on toolforge at 3:23UTC), but I'm open to running it at any other time instead. Thanks. Mike Peel (talk) 19:17, 26 February 2021 (UTC)
Subcategories of de:Kategorie:!Wikipedia / category-prefixes to ignore are:
  • Benutzer:
  • Datei:
  • Hilfe:
  • Kategorie:
  • Portal:
  • Vorlage:
  • Wikipedia:

Is the bot able to add Commonscats to categories, if they are include in the categorie, for example: d:Q105668792, d:Q105668793 ? --M2k~dewiki (talk) 19:24, 26 February 2021 (UTC)

OK, I'll configure it to avoid those. I've been doing commonscats separately, e.g. via Wikidata:Requests for permissions/Bot/Pi bot 16, but that won't work for dewiki due to the language difference. On enwp at least, editors often add commonscats that are only partly related to the category, which causes problems for their automatic import, is it the same on dewiki? Thanks. Mike Peel (talk) 19:27, 26 February 2021 (UTC)
@M2k~dewiki: BTW, a possible issue is that the bot does null edits to pages after creating the items for them, to avoid a bug in MediaWiki where it doesn't record the Wikidata link properly in the database until the page/category is edited (phab:T233520), do you know if frequent page purges are OK on dewiki or if it needs a bot flag? Thanks. Mike Peel (talk) 19:34, 26 February 2021 (UTC)
Would it be possible to add support for the german language wikipedia to Pi bot 16? As far as I have seen, if there is a commonscat in the category then it is usually related, otherwise / in a lot of cases there is no commonscat included in the category at all. "Related" commonscats are more common for articles in de-WP in my opinion, but not for categories. I do not know if a bot flag is necessary for null edits.--M2k~dewiki (talk) 20:04, 26 February 2021 (UTC)
@M2k~dewiki: I suggest we treat commonscats separately from item creation. Ideally, it would be great if dewiki could mirror the tracking categories at en:Category:Commons category Wikidata tracking categories (which are auto-added by en:Template:Commons category), then we can look through the contents of them and figure out what can be automated. Let's see with the null edits, hopefully it won't be an issue. Thanks. Mike Peel (talk) 20:11, 26 February 2021 (UTC)
OK, I've finished checking through unmatched categories now, dewp is remarkably well synced with Wikidata already, nice work. :-) If you're available sometime tomorrow, I can start the bot scripts running then. Thanks. Mike Peel (talk) 21:14, 26 February 2021 (UTC)
Are there many items, which would have to be created tommorow? I assume, that when I stop creating items today, then your bot would take over in 14 days, till then the backlog of unconnected items will grow. --M2k~dewiki (talk) 21:55, 26 February 2021 (UTC)
@M2k~dewiki: It depends on the configuration. Probably we'll find cases that you have been avoiding or have missed, which we'll then have to decide if we want to keep or not, which is a nice check that the bot works OK for dewiki's needs. But most new items would probably start at the 14 day point, as you say. I trust that you would continue matching articles/categories with existing items? Thanks. Mike Peel (talk) 22:04, 26 February 2021 (UTC)
Hello Mike Peel. Thank you for your suggestion, which I very much appreciate. I can imagine that this way of working will prove to be very beneficial. —Lantus 05:30, 27 February 2021 (UTC)
@M2k~dewiki, Lantus: OK, so I ran it through the articles, and it didn't create any items. Which is good I guess, it means that the exclusions are working OK... The null edits are also working OK. I'm now working through categories, e.g. Category:User en-GB (Q105699149), let me know if you spot any issues. Thanks. Mike Peel (talk) 12:24, 27 February 2021 (UTC)
OK, it seems that today is mostly a day of null edits to clear the backlog of database problems, with a few user language categories created. Thanks. Mike Peel (talk) 17:37, 27 February 2021 (UTC)
@M2k~dewiki: OK, first run through is done. It found de:Kategorie:Vorlage Navigationsleiste National Register of Historic Places, which I think is misnamed on dewp (should have a : after 'Vorlage'?), and Q105709722, plus some user language categories. I think this shows it won't create items that it shouldn't, so I'll set it running regularly now, let's see how it goes. Thanks. Mike Peel (talk) 10:08, 28 February 2021 (UTC)