Bdijkstra

Pi bot reverts

In cases like [1], please read the edit summary. "Copy from P373 to commons sitelink" - remove the incorrect Commons category (P373) value from the item, and Pi bot won't copy it over to the sitelink again. Although you probably also want to remove the incorrect link to Commons from de:Holdeurner Irdenware as well, to avoid it being copied back over to Wikidata from the Wikipedia in the future. Or what you've done at Holdeurn site (Q67086666) also works, and is the best solution. :-) (although the cleanup of P373 and the incorrect commons link is still needed anyway.) Thanks. Mike Peel (talk) 19:36, 3 September 2019 (UTC)

I did read the edit summary; there was no incorrect P373, only not one eligible for copying to a sitelink. Also I wondered if Pi bot would back off for a while from an item when reverted, but alas. The problem I'm having is that Pi bot is too fast. As I understand it, if multiple items have a P373 to the same category, then Pi bot won't add a sitelink. I'm going through a few thousand pages by hand now, so I don't know yet whether items will point to the same category. For my next run I think it'll help to process the pages sorted by Commonscat. --bdijkstra (overleg) 20:02, 3 September 2019 (UTC)

@Mike Peel: now that I'm done with this run, I know how I should have done it. Does Pi bot also move Commons-category-sitelinks from "article"-items to "category"-items? --bdijkstra (overleg) 07:52, 12 September 2019 (UTC)

Yes, e.g., [2] [3]. But please don't create category items unless they're necessary (e.g., for linking multiple items to the same category, or if the sitelink is blocked by a gallery). Thanks. Mike Peel (talk) 10:00, 12 September 2019 (UTC)

No problem. So far I've merged more category items than I've created. :) --bdijkstra (overleg) 10:05, 12 September 2019 (UTC)

WTF

Gezien je aanstootgevende bewerkingscommentaren mag ik er vanuit gaan dat al die duizenden en duizenden taxa die ik de afgelopen maanden aan wikidata heb geknoopt met de halfbakken en vaak niet werkende tools, dat die vanaf nu door jou aan de nl-wiiki-artikelen gaan worden geknoopt? Edoderoo (talk) 06:23, 2 March 2020 (UTC)

Sorry dat je dat aanstoot aan nam, het was bedoeld als een uiting van onbegrip. Het is natuurlijk best wel raar om een taxon te willen koppelen aan iets heel anders, waar bovendien al een Nederlandstalig artikel over bestaat. Maar foutjes maken we allemaal, dat snap ik ook wel. Gisteren ben ik naar aanleiding van jouw melding in het Wikidata-café aan de slag gegaan met een lijstje van Duplicity en vond daar een heel aantal oude artikelen die niet gekoppeld waren. Een aantal waren door vandalisme of onkunde maanden geleden onterecht ontkoppeld, maar ook waren er een aantal recent door jou ontkoppeld. Dus je had deze fouten vrij gemakkelijk achteraf zelf kunnen corrigeren door naar die lijst te kijken of door je eigen bijdragen met "Koppeling naar [nlwiki] gewijzigd:" te controleren. Anders blijven ze misschien maanden staan. --bdijkstra (overleg) 07:24, 2 March 2020 (UTC)

Er zijn ook een paar kapotte scripts, waardoor sommige oude artikelen plots van alle talen worden losgehaald. Ik heb meermaals geprobeerd te achterhalen wat daar de oorzaak van was, maar de gebruikers die het hebben gedaan hebben niet eens door dat ze iets op Wikidata hebben uitgespookt. Soms is het ook hun enige bijdrage, via een tooltje. Het koppelen van Wikidata-items is een hels karwei, waar je per dag uren aan kunt besteden, en dan loop je nog achter de feiten aan, dat is al sinds 2016 zo. En dan is er ook nog de lijst Wikidata:Database_reports/without_claims_by_site/nlwiki voor het geval je dacht dat je klaar was ;-) Mijn eigen bijdragen nalopen op Wikidata is trouwens een leuke suggestie, maar ik ga al richting de 3 miljoen edits (en 55 miljoen van mijn bot), dat loopt je niet zomaar eventjes langs ;-) Gelukkig kunnen de meeste edits met een tool worden gedaan, anders haal je zoveel niet eens in een mensenleven. Jij zit nu op 5763 edits, zie ik hierboven staan. Edoderoo (talk) 08:08, 2 March 2020 (UTC)

Drie miljoen edits loop je inderdaad niet zomaar even langs, maar als je net een sessie van een paar duizend hebt gedaan, dan zou je dat in een paar minuten moeten kunnen nalopen (als de Wikidata-server een beetje vlot meewerkt). Aantallen edits vergelijken heeft overigens weinig zin; iedereen vervult een andere rol, verschillende rollen uiten zich in verschillende aantallen edits per uur. --bdijkstra (overleg) 09:34, 2 March 2020 (UTC)

Ik had Joopwiki er trouwens vorige week nog op gewezen, en gisteren heeft zijn batch/script ook Wikidata-items aangemaakt. Edoderoo (talk) 13:48, 2 March 2020 (UTC)

about removing the IMDb ID: [4]

Hi, I removed the IMDb ID because it links to the adapted American television series (see Storyline on IMDb: "based on the hit Dutch television series of the same name"). However, the series Utopia (Q18435255) is the original Dutch series. CENNOXX (talk) 12:33, 18 December 2021 (UTC)

Ah okay, so I didn't look closely enough, sorry. I've restored your revision. bdijkstra (overleg) 12:41, 18 December 2021 (UTC)

Thanks, no problem. CENNOXX (talk) 12:50, 18 December 2021 (UTC)

Escarbot

copied from user talk:Lymantria
Hi, I do not see the purpose to use as label the name of a category that does not exist in any Wikimedia site, like Categorie:Project:Pagina's waar de expansiediepte is overschreden My proposal is to put the Wikipedia category name as label, and the categories of other sites as aliases. Best regards, Vargenau (talk) 14:36, 15 April 2022 (UTC)
end of copy

1. I think that Escarbot shouldn't change things that aren't wrong.
2. I think that Escarbot shouldn't create a situation where an alias exists that is equal to the label. (example)
3. I think that Escarbot shouldn't editwar with a user. It's a bot, it could be wrong because it operates with simple rules, it doesn't know all the details.
4. According to Help:Label, "there is no requirement that an item's label be the same as the page name on its corresponding Wikimedia site." So it is perfectly valid for a name to be in the aliases. After all, search results include both labels and aliases.
5. Also according to Help:Label, "Category and template labels should be identical to sitelinks". For many items this is impossible because different projects use different names (in the same language). So in some cases a user might choose to use the most frequent page title as the label and set the others as aliases. Escarbot shouldn't change this, because it's a valid way to deal with this.
6. Dutch category names of maintenance categories are a little weird. In most Dutch projects there is the convention to prefix the page name with the project name. E.g. Q5321459 has 2 Dutch sitelinks:
   1. Categorie:Wikipedia:Pagina's waar de expansiediepte is overschreden
   2. Categorie:WikiWoordenboek:Pagina's waar de expansiediepte is overschreden

These names are different, but they are constructed in exactly the same way. So the convention arose to construct a neutral label by replacing the project-specific part by "Project" and add the real sitelinks to the aliases. Hence in this case the label is "Categorie:Project:Pagina's waar de expansiediepte is overschreden".

For the first 5 points above, please let me know whether you disagree and if so, please elaborate. For point 6, please let me know if you think that this convention breaks any rules or pre-existing consensus and if so, which ones.

--bdijkstra (overleg) 17:17, 20 April 2022 (UTC)

Hi,

First, I am sorry for the late answer. I was in vacation for two weeks, 21 April to 6 May, and I did not see your answer before leaving.

As a general comment, Escarbot has made thousands of edits, and if one edit out of one thousand is not optimal, I still think it is doing something very useful.

Point 1. It is OK to change something that is not wrong if it makes it better, e.g. more precise.

Point 2. Agreed. In that case the alias should be removed, but currently Escarbot is not programmed to to it.

Point 3. Agreed. But this is difficult to avoid. Sometimes the bot goes several times to the same page by a different path.

Point 4. I do not understand your point here.

Point 5. My rule here is to give priority to Wikipedia which is the major site. The other sites should be put as aliases, as well as the redirects.

Point 6. Same as point 5. I find it very strange to choose a name that does not exist in any website.

Best regards,

Vargenau (talk) 10:53, 10 May 2022 (UTC)

Indeed by far the most edits of Escarbot are useful and it is perfectly fine to make suboptimal edits every once in a while, but when it repeats the same reverted edit, then there is a problem that needs to be addressed.
Point 1. My point is that if it's not wrong, then it's better to do nothing than to make a potential mistake.
Point 2. I think in this case the easiest way to deal with this is to say that there's nothing wrong and Escarbot should do nothing.
Point 3. Difficult maybe, but I think necessary. Either you somehow avoid the edit warring, or the page will get protected or the bot will get blocked. Such is the policy.
Point 4. The point is that it's not necessarily invalid to choose a label that does not exist in any website.
Point 5. I don't think there's consensus to give priority to Wikipedia.
Point 6. It may be very strange, but it's the convention. And to my knowledge nobody tried to get consensus otherwise.
Best regards, bdijkstra (overleg) 13:11, 10 May 2022 (UTC)

@Lymantria: note that Escarbot continues to make the same objectively bad edits over and over again, like this one where a label is written that is equal to a pre-existing alias. bdijkstra (overleg) 12:59, 31 May 2022 (UTC)

@Vargenau: Your bot should be programmed in order to not make edits like this. Point 5 has been explained by Bdijkstra and a bot should never do edits that are controversial. That the cited edit is controversial, is clear from this discussion. Let this be a last warning before blocking the bot. Lymantria (talk) 13:46, 31 May 2022 (UTC)

It is clear that @bdijkstra and I disagree on what the label should be. I still claim that for a category, using a label that does not exist on any website does not make sense. So you might say that my bot edit is controversial, but I consider his revert the same. This should be discussed with the community, not just between he and me. I do not know what the best place for that would be. Perhaps Help_talk:Label. Vargenau (talk) 08:28, 1 June 2022 (UTC)

I don't really care that much what the label should be. As long as the "Category:Project:..." name remains present in either the label or the aliases, it is acceptable. But I would prefer if Escarbot would just leave the labels and aliases alone if all the sitelink page titles are already present. After all there is no consensus about the priority, so just shuffling them around would be controversial. bdijkstra (overleg) 08:49, 1 June 2022 (UTC)

Bot edits are typically hard to revert, therefore if you know there is no full consensus on an issue, you should not bot-edit that. It might be wise to broaden discussion and reach agreement, for instance in an RfC. And of course it is a task for all users to avoid reverting series. Lymantria (talk) 15:04, 2 June 2022 (UTC)

@Lymantria: would you say that this edit is controversial? It not only gave priority to Wikipedia, it also neglected to add an alias (as there are 2 valid English names). bdijkstra (overleg) 11:53, 2 June 2022 (UTC)

P.S. This is also just creating junk. bdijkstra (overleg) 11:55, 2 June 2022 (UTC)

I do see the first edit as problematic, should not have been done by bot. It is clear that the removed description was a valid one derived from the commonslink. The bot should refrain from doing so, should be programmed to check that. The P.S. edit indeed was not correct, the alias should ave been removed. But the old description IMHO did not fit, see Q105604326 which is a subcategory at enwiki. Both issues should be programmed out of the bot. I will block the bot for 1 day to achieve that. --Lymantria (talk) 15:12, 2 June 2022 (UTC)

@Vargenau, Bdijkstra: (corrected ping). --Lymantria (talk) 15:13, 2 June 2022 (UTC)