User talk:ArndBot

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Welcome to Wikimedia Commons, ArndBot!

-- Wikimedia Commons Welcome (talk) 15:29, 18 February 2015 (UTC)[reply]

Check edit[edit]

Hi Arndt, could you please check this edit? Looks wrong as as is not the date parameter of the information template. Thanks. Raymond 13:52, 21 November 2015 (UTC)[reply]

Raymond, thank you for being patient. You are right. It a mistake. So just revert this if you find other cases. --Arnd (talk) 14:41, 21 November 2015 (UTC)[reply]

Erroneous operation with {{cite journal}}[edit]

Hello, Arndt! Pay attention, please: the bot works on {{cite journal}} template in an erroneous way. See, please, here. Best wishes, Dmitry Ivanov (talk) 00:11, 22 November 2015 (UTC).[reply]

Adding date from EXIF when date is blank?[edit]

Arnd, your bot seems to be erroneously adding a date from EXIF when date is blank. This is outside of its approved tasks -- it is only supposed to be adding the EXIF date when it is "see metadata" and similar strings. Here is an example error. —RP88 (talk) 15:17, 24 November 2015 (UTC)[reply]

There are a lot of files having EXIF dates which is not used in date parameter. So i extended the task. I see the problem with this file. What should be done in such a case, how it can be detected? Should we use {{According to EXIF data}}? However, i am sure that such cases are very rarely. Actually, later we could check all Commons files that have dates before the upload date and mark. --Arnd (talk) 16:10, 24 November 2015 (UTC)[reply]
Well, using {{According to EXIF data}} is certainly better than what the bot has done, but even that may not be enough. It is very common for the EXIF date to be wrong in older files. I think it is fine if the bot sees text like "see metadata" and replaced it with the date, since presumably a human verified that the date in the metadata was correct before they added that string. Replacing a blank date with EXIF is very different (and more difficult) task. If I remember correctly, previous requests to do this have actually been rejected because the bot operator didn't have an adequate plan. If you think you have a plan on how to solve this, I think you should file a new bot request to add this task to your bot, rather than just "extending" the task your bot performs. —RP88 (talk) 16:22, 24 November 2015 (UTC)[reply]

Pantoja de la Cruz[edit]

No sé como arreglar esa página. ¿Habla usted español?.--Tiberioclaudio99 (talk) 18:29, 4 January 2016 (UTC)[reply]

Reading bogus compass information from exif data[edit]

Arnd, ArndBot is currently reading bogus compass information and putting it into the location template. See e.g. here: https://commons.wikimedia.org/w/index.php?title=File:GGB_Bhe_4-8_Streckenf%C3%BChrung_Rotenboden_-_Gornergrat.jpg&curid=24830269&diff=197721090&oldid=161880093

The bot should do some sanity checking. I'm not exactly sure how that would look like, but the value 65535 is certainly not valid. --Kabelleger (talk) 11:02, 31 May 2016 (UTC)[reply]

Thanks, Kabelleger. I will add a plausibilty check for the range 0<=x<360. --Arnd (talk) 11:37, 31 May 2016 (UTC)[reply]

Adding headings in location[edit]

Can you please see this and this edit. Now it has "Error: Invalid parameters!" --Smooth_O (talk) 14:51, 1 June 2016 (UTC)[reply]

Smooth_O, i am aware of this. Actually the bot is not doing wrong but several thousands of files use the {{Location}} template with three numerical parameters which is not allowed. I do not know why, but the uploaders thought the third parameter is the altitude which is not implemented. I already addressed this issue at Template talk:Location#Altitude. Depending on the result i will cleanup the effected files. --Arnd (talk) 15:55, 1 June 2016 (UTC)[reply]
OK, thanks for info. --Smooth_O (talk) 14:03, 2 June 2016 (UTC)[reply]
Smooth_O, the Bot is now cleaning up the files. --Arnd (talk) 16:22, 13 June 2016 (UTC)[reply]

Adding headings in location - 2[edit]

Hello! I uploaded several geotagged pictures with location, but without heading information (examples: File:Trem do Corcovado – “Schweizerische Centralbahn Hauptwerkstaette • System Riggenbach”.JPG / File:Rosenbauer Panther 8x8 • rechter Sitz, Flughafenfeuerwehr Bremen.JPG). As it seems, they had a heading 0° or 360° in EXIF data, something not intended by me, but apparently added by the ”Panorado Flyer“ tool. Your bot added a heading to the file. IMHO a bot should not make an automated edit adding erroneous information – although there was this data in EXIF.--Geogast (talk) 16:10, 13 June 2016 (UTC)[reply]

Hi Geogast, the UploadWizad is currently also adding the heading if it is in the valid range. And my Bot did the same for the files that have been uploaded before the change of the Wizard. Is there any easy way to find all files that are effected by the wrong heading? So we could easily repair them. --Arnd (talk) 16:29, 13 June 2016 (UTC)[reply]
Hello! Yes, but when I upload files, I have an eye on that, especially on data the UploadWizard fills in automatically. I can repair the files by myself with the help of the mails I received after these edits. The point is: is there a way to avoid this mistake? Perhaps avoiding this edit whenever the EXIF data has a 0° or 360° heading?--Geogast (talk) 18:10, 13 June 2016 (UTC)[reply]
The thing is, that valid values are 0<=x<360. If the camera or a program is adding Exif data it should never add the heading parameter if there is no value. In your case it is a bug of the ”Panorado Flyer“ and should be fixed there. --Arnd (talk) 20:03, 13 June 2016 (UTC)[reply]
Yes, it is (or at least, seems to be) a bug of the tool I use. But I take care when I upload the files. The bot doesn't. So, the bot repeatedly produces a mistake a human user wouldn't. In this case, I think a bot should skip edits in these cases in order do avoid mistakes.--Geogast (talk) 19:02, 14 June 2016 (UTC)[reply]

Stop[edit]

Please. -- Tuválkin 17:58, 12 October 2016 (UTC)[reply]

Tuválkin, thanks for be patient and sorry for this wrong edit. I will fix them. I modified the bot. --Arnd (talk) 18:06, 12 October 2016 (UTC)[reply]
Great, thanks. (I wanted to say that it should not remove line end trailing pipes after a template name if the next line doesn’t start with a pipe, but I thought speed reporting would be most important as the problem and its solution were trivial.) -- Tuválkin 18:09, 12 October 2016 (UTC)[reply]

Coordinates and Wikidata[edit]

this edit left the coordinates in situ. Did you mean to remove them? Andy Mabbett (talk) 16:14, 17 January 2017 (UTC)[reply]

Hi Andy Mabbett, it is correct the way it is. For now we leave them in place until we have a general template that displays all WD information. But you are right, maybe the summary was a little bit misleading. --Arnd (talk) 16:43, 17 January 2017 (UTC)[reply]

Gallery vs coordinates[edit]

Apparently something went wrong here. Jcb (talk) 21:22, 19 January 2017 (UTC)[reply]

Thanks for being patient, Jcb. I think it was the only edit that went wrong. --Arnd (talk) 21:34, 19 January 2017 (UTC)[reply]
No problem. Jcb (talk) 21:39, 19 January 2017 (UTC)[reply]

"Wrong date" on file talk pages[edit]

hi Arnd, could you pls check the rules of the bot? [1], [2], and [3] do not make sense for me. Raymond 20:39, 7 February 2017 (UTC)[reply]

Thanks Raymond for being patient. I removed the non-files from the list. --Arnd (talk) 20:51, 7 February 2017 (UTC)[reply]
Hi Arnd, thank you very much for fast fixing. Raymond 21:02, 7 February 2017 (UTC)[reply]

"Wrong date" is wrong[edit]

I've seen this bot tag files with "wrong date" and commentary "mentioned date is after the upload date", however, this example is incorrect. For instance, I'm in a timezone that is ahead of most of the world, and uploaded it to a server that was one day behind. Right now for me is 12:20 pm on 8 February 2017, but my signature will say otherwise. You may want to adjust the bot to tag files that are more than a day different. +mt 23:21, 7 February 2017 (UTC)[reply]

same, timezones should be considered. EoRdE6(Come Talk to Me!) 03:03, 8 February 2017 (UTC)[reply]
Thanks for the hint. I will run a cleanup task. --Arnd (talk) 07:33, 8 February 2017 (UTC)[reply]
done. If there are any other cases feel free to report it. --Arnd (talk) 10:33, 8 February 2017 (UTC)[reply]

Bot marked this as wrong date, stating that the file date was after the upload date, but it is incorrect. The image was taken on 20 July 2016 and uploaded on 6 August 2016. Beyond My Ken (talk) 17:02, 8 February 2017 (UTC)[reply]

Fix, not tag - ?[edit]

File:Bootstrapping_emitter_follower_to_increase_input_impedance.png - 18:28, 6 November 2016 in upload log, 6 November 2017 in the template - perhaps the bot could fix these simple errors? Retired electrician (talk) 09:24, 10 February 2017 (UTC)[reply]

Hi Retired electrician, you are right. But there are many different of such little mistakes. All of them need at least some human review. That is why I would like to see someone browsing Category:Incorrect date and identify groups of files with the same problem and then fix it for example with VisualFileChange.js. --Arnd (talk) 11:30, 10 February 2017 (UTC)[reply]

Bot flag[edit]

@Aschroet: Hi. I see that ArndBot has a bot flag, but it seems the edits it makes are not tagged as bot edits, for instance in my watchlist. Do you know why?   — Jeff G. ツ 14:48, 1 September 2017 (UTC)[reply]

Hi Jeff, no idea. --Arnd (talk) 14:51, 1 September 2017 (UTC)[reply]
I agree, this annoying, and when you go with minoredit!? -- User: Perhelion 19:20, 27 September 2017 (UTC)[reply]

Date changes[edit]

I see your bot did a run recently to reformat Date parameters in {{Information}}. When doing so, it for some reason left out the leading 0 when the day is less than 10, e.g. this edit. Anomie (talk) 13:39, 28 September 2017 (UTC)[reply]

Anomie, i did it for the sake of simplicity and because {{ISOdate}} can deal with this. Maybe in a later run, we could add the leading 0s. --15:05, 28 September 2017 (UTC)[reply]

In this edit, ArndBot changed the date 17/17/07 into 2007-17-17, which is obviously not a valid date in the international standard calendar of ISO 8601. Any bot should only change unambiguous cases, but it needs to be smart enough to do so. — Christoph Päper 09:56, 23 October 2017 (UTC)[reply]

Änderungen am Parameter Datum[edit]

ArndBot verändert z.T. den Eintrag unter Datum der Dateibeschreibung mMn nicht ganz korrekt. Korrekt ist die Anpassung der Formatierung, z.B. statt 7.8.2007 jetzt 2007-8-7 (besser wäre noch 2007-08-07). Nicht korrekt ist aber, dass der Bot Hochladedatum vermerkt, wenn es sich auch um das Aufnahmedatum handelt. Das Hochladedatum ist bereits an anderer Stelle (Datum der ältesten Version) vermerkt, ein zusätzlicher Eintrag ist somit redundant. Manchmal lade ich eben die Dateien bereits am Aufnahmetag hoch. Der Parameter Datum ist das Aufnahmedatum, und das trage ich eigentlich immer richtig ein. Das mit Hochladedatum zu überschreiben, verdeckt die Information zum Aufnahmedatum und unterstellt gleichzeitig einen fehlerhaften Eintrag. Bitte diese Fehlfunktion des ArndBot sofort einstellen. Gruß --Rufus46 (talk) 09:28, 11 October 2017 (UTC)[reply]

Hallo, magst du diese Fehler selbst korrigieren (siehe erg. Wartungskategorie)? --Leyo 20:46, 27 November 2017 (UTC)[reply]

Danke Leyo, hab's repariert. --Arnd (talk) 22:00, 29 November 2017 (UTC)[reply]

other date between[edit]

Hallo, Aschroet,

dein Arndbot hat bei File:Olching, Pfarrzentrum St.Elisabeth in Esting.JPG das Datum „2011-0427“ zu „2011-04-27“ ({{Other date}}) korrigiert. Der Hochlader hat aber nur einen Strich vergessen und 2011-04-27 gemeint (sieht man aus den EXIF-Daten). Vielleicht sollte dein Bot, bevor er ein between erzeugt, prüfen, ob die Zahlen dazu passen (linke Zahl kleiner als rechte). Grüße -- Renardo la vulpo (talk) 11:37, 1 February 2018 (UTC)[reply]

Danke Renardo la vulpo für den Hinweis. Ich habe schon eine Reihe von Daten identifiziert, die ich reparieren muss: [4], [5]. --Arnd (talk) 12:11, 1 February 2018 (UTC)[reply]

✓ Done

Was ist da schiefgelaufen? Die Vorlage ist laut Template:Artwork korrekt. --Leyo 13:27, 19 February 2018 (UTC)[reply]

Ich hatte ein paar Kommentare aufgeräumt, weil ich denke, dass sie nicht wirklich geraucht werden. Habe dann aber damit aufgehört. --Arnd (talk) 13:54, 19 February 2018 (UTC)[reply]
Gut, dass du damit aufgehört hast. IMHO sind auskommentierte Vorlagen in solchen Fällen durchaus sinnvoll. VFC-Änderungen sollten zudem nicht kommentarlos erfolgen. --Leyo 16:05, 19 February 2018 (UTC)[reply]

Taken on/taken in[edit]

Hello. I see your bot is adding {{Taken on}} to images where only the year is listed in the date field. That results in awkward grammar, at least in English. Instead, could you please use {{Taken in}} in these cases? Thanks! - Eureka Lott 17:40, 1 March 2018 (UTC)[reply]

Eureka Lott, thanks for your patience. Does this also hold for year and month only? --ArndBot (talk) 17:47, 1 March 2018 (UTC)[reply]
Yes, please. {{Taken in}} would work better when there's only a year and month. - Eureka Lott 17:52, 1 March 2018 (UTC)[reply]
Eureka Lott, i will clean that up soon. --ArndBot (talk) 17:53, 1 March 2018 (UTC)[reply]
Excellent. Thank you! - Eureka Lott 17:54, 1 March 2018 (UTC)[reply]

Bot edits[edit]

Please mark your edits as minor. Otherwise users got letters about every edit.--Anatoliy (talk) 11:32, 12 March 2018 (UTC)[reply]

Privit Anatoliy, VisualFileChange.js does not have such an option. I now changed my settings so that all future edits are minor ones.
User:Leyo, just as a second oppinion. Is that what we want when using VFC - bot flag and minor edits? I thought that bot is enough. I am a little nerved from repeated blockings... --Arnd (talk) 11:58, 12 March 2018 (UTC)[reply]
Bot flag or minor edit is probably sufficient in most cases.
It would be good if VFC would have the option to mark the edits as minor. --Leyo 14:11, 16 March 2018 (UTC)[reply]

Changing date formats in original upload logs[edit]

Example. I'm not seeing the purpose in changing the text used by the original uploader on the other project. These sections are no-wiki'd. Kelly (talk) 22:41, 5 April 2018 (UTC)[reply]

Thanks for the hint Kelly. I will fix my bot accordingly. --Arnd (talk) 07:24, 6 April 2018 (UTC)[reply]

Is this really an improvement?[edit]

https://commons.wikimedia.org/w/index.php?title=File:Cesar_Virata,_1983.jpg&curid=16142865&diff=310535680&oldid=273753915

Seems to me that the prior layout was easier to read when editing. Quite a few like this. - Jmabel ! talk 00:27, 11 July 2018 (UTC)[reply]

And here and again on the same file? There are many more "edits" like that. Please stop it. -- Michael Bednarek (talk) 04:37, 11 July 2018 (UTC)[reply]
Sorry guys, i made it to prepare further cleanups. It is stopped now. Hopefully, nothing is broken. --Arnd (talk) 06:41, 11 July 2018 (UTC)[reply]

really?[edit]

really? Is that the change you intended to do? erasing an empty line? ...Sicherlich talk 21:28, 6 November 2018 (UTC)[reply]

Hi Sicherlich, sorry for it. I kindly ask to ignore this since this should happen only to very very very view cases of my current bot run where i already did manual corrections beforehand. --Arnd (talk) 05:14, 7 November 2018 (UTC)[reply]
well I had several on my watchlist. ... As i saw you tried to remove the int:license-header thing right? Tell me what is the point of it. I dont get it. I asume it got to my pic via commonist. Later YaCBot added header, 2 days ago Aschroet removed it [thats the reason for you bot removing emty lines right?] and now your bot. What does that help at all. Where is the benefit having it or not having it? I have the impresssion most of my pics have more edits by bots that change actually nothing a user can see!? ...Sicherlich talk 05:32, 7 November 2018 (UTC)[reply]
Hi Sicherlich, i am cleaning up the wikitext here. The license section makes no sense at all if no license template but only the the categories follow after it. So i remove it. It seems to me that this is/was a problem of the upload tool. However, most files with this issues were uploaded till 2012. So i assume that the tools have been modified already.
The empty line removal is only a "side" edit. But as i already said this should not be the only edit.
Generally, many of these cleanups will end when Commons soon moves to Commons:Structured data where we then have the data stored in a structured way and not in ugly wiki anymore. You can see many of those bot edits as a preparation for it. --Arnd (talk) 07:56, 7 November 2018 (UTC)[reply]
hmm, so the license-header removing is more or less a cosmetic thing? The structured data is about metadata: but what data has this header? Non?! (preparation: the YaCBot was in 2004. So thats unexpected to such a long term preparation :P ) - okay I dont really get it. Some years ago it seemed important to have it, but different, now its important to remove it. Seems to me like pointless edits but I hope there is just deep sense I'm just to studpid to see ;o) ...Sicherlich talk 10:02, 7 November 2018 (UTC)[reply]

Removing data that is provided by Wikidata[edit]

Hi ArndBot!

It seems that you are deleting categories in Commons, e.g. here. Can you give me a hint, where this is discussed before? Before you deleted the Category:1980 births I could rather comfortably query it in Commons, and I got about 5000 people born in 1980. Can you tell me, how I may do this or something equivalent now, without this category?

gruß, fcm. --Frank C. Müller (talk) 08:54, 30 April 2019 (UTC)[reply]

Hi Frank C. Müller, the discussion was here. The category is still there but automatically generated by the connected Wikidata item. Since Commons is mainly a media repository and not made for storing facts like Wikidata it is better to take it from there. For your example you find him under Wadle: here. --Arnd (talk) 10:33, 30 April 2019 (UTC)[reply]
Hi Arnd! Thanks a lot! gruß, fcm. --Frank C. Müller (talk) 14:42, 30 April 2019 (UTC)[reply]

Empty categories[edit]

Hello.Please stop emptying the categories.Please delete redundant stuff only ديفيد عادل وهبة خليل 2 (talk) 10:10, 1 May 2019 (UTC)[reply]

ديفيد عادل وهبة خليل 2, example? --Arnd (talk) 13:52, 1 May 2019 (UTC)[reply]
17 times in few days ديفيد عادل وهبة خليل 2 (talk) 14:04, 1 May 2019 (UTC)[reply]
ديفيد عادل وهبة خليل 2, there were slashes in the "given name" of the WD item what broke my regexes. Fix now. Just let me know when something else happens, and feel free to just revert the edits if they are inappropriate. Anyway, thank your for being patient. --Arnd (talk) 16:13, 1 May 2019 (UTC)[reply]

Exif date[edit]

Hello, ArndBot! Are you still doing this kind of edits? I ask because it’s something I have been thinking it would be a goiod idea for a long time and only now I encountered your work for the first time. -- Tuválkin 10:11, 16 May 2019 (UTC)[reply]

Hi Tuválkin, that time i made one big bot run. I can do it again on demand. Do you think that this cases are many still now? --Arnd (talk) 11:13, 16 May 2019 (UTC)[reply]
@Aschroet: Thanks for replying! I have added manually hundreds of {{exif date| while dissiminating photos in Category:Lisbon and in several smaller ones. I suppose it is the same pretty much everywhere else with a large, constant influx of new photos. Annoyingly, most uploading services (namely Flickr2Commons) do not transcribe the value for seconds from the photo’s metadata, only hours and minutes, and adding that is an additional hassle that could be automatized. I like to do a human’s work when categorizing, but the added work used for easily automated tasks is thankless. I would say that trapping new uploads with filetype = JPEG would yield useful results. Of course, the kind of timestamp we want is the generation date, not modification. -- Tuválkin 21:50, 16 May 2019 (UTC)[reply]
Tuválkin, lets see if i can bring a bot in place. --Arnd (talk) 19:46, 19 May 2019 (UTC)[reply]

removing data that is provided by Wikidata[edit]

No, it isn't - wegen mehrerer unterschiedlicher Geburts- oder Todesdaten auf Wikidata:

--WaldiWuff (talk) 20:46, 22 May 2019 (UTC)[reply]

WaldiWuff, i fixed the Bot accordingly. --Arnd (talk) 07:09, 4 October 2019 (UTC)[reply]

defaultsort=no[edit]

Hi, see i.e. here. When you remove a DEFAULTSORT please remove also the defaultsort=no from the infobox call too because Mr. Rilley is now sorted anywhere under M and not R. Thx --JuTa 14:22, 9 October 2019 (UTC)[reply]

JuTa, i am aware of this issue and will remove this after my bot finishes. Actually, i don't know why Pi bot add this parameters. --Arnd (talk) 14:56, 9 October 2019 (UTC)[reply]
So that means another run removing that after the current run, correct? And Pi bot added that mainly when there was a mismatch between the local DEFAULTSORT and the sort based on the infobox. That was often the case if the name contained some non-startard ASCII characters. But that got fixed a while ago - see the end of this thread - opened by yourself :) regards. --JuTa 17:08, 9 October 2019 (UTC)[reply]
JuTa, correct. I will clean up after the current run which will finish soon. It is clear for me when the bot usually adds defaultsort=no but in the case that you mention above there is no such special character in the surname or given name. --Arnd (talk) 07:42, 10 October 2019 (UTC)[reply]
Maybe because there was no family name on wikidata at the time when he set it. --JuTa 08:03, 10 October 2019 (UTC)[reply]
I think the defaultsort=no was added in that case because of this vandalism. Thanks. Mike Peel (talk) 16:06, 13 October 2019 (UTC)[reply]

JuTa, Mike. Cleanup has finished. Interestingly--Arnd (talk) 20:58, 13 October 2019 (UTC)[reply]

Thx. --JuTa 06:45, 15 October 2019 (UTC)[reply]

Removing defaultsort[edit]

Hi. Perhaps you could explain why your bot is removing the DEFAULTSORT arguments in pages. Problem is, that for Nordic artists, we use the three letters "æ", "ø" and "å" to get the names sorted correctly, when those letters are part of the names. This goes against the infobox standard way, and therefore the DEFAULTSORT has to be put in place in those instances. However, when your bot removes the DEFAULTSORT, we are back with a wrong sortorder. Any solution? Cheers Rsteen (talk) 03:14, 12 July 2020 (UTC)[reply]

Rsteen, do you have an example? --Arnd (talk) 11:01, 12 July 2020 (UTC)[reply]
Sure, this one is a classic: Category:Christine Løvmand. Just look at the history. I never knew what was happening ... Cheers --Rsteen (talk) 15:19, 12 July 2020 (UTC)[reply]
Rsteen, shouldn't this be discussed on Template talk:Wikidata Infobox? Maybe it could be directly implemented in the template or they can offer a parameter for that. Btw, i discussed the bot task there as well, on Template_talk:Wikidata_Infobox#Removal_of_birth_and_death_categories. --Arnd (talk) 06:11, 13 July 2020 (UTC)[reply]
Hi again. Afraid that is too technical for me. Thing is: A Defaultsort has been placed in the category, and your bot removes it. Please stop that. Cheers Rsteen (talk) 08:55, 13 July 2020 (UTC)[reply]

Rsteen, I stopped for my bot for the moment. Mike, you adapted the {{Wikidata Infobox}} so that the DEFAULTSORTs parameter does not use special letters like "å". Is this a general rule in Commons or is it acceptable to override this conversion by reintroducing the special letters manually in DEFAULTSORT? --Arnd (talk) 10:00, 13 July 2020 (UTC)[reply]

This was at the request of @JuTa and Tacsipacsi: , if I remember correctly. Hopefully they can comment on whether it's appropriate in these cases. For your bot work, it might be best to not remove cases where the existing DEFAULTSORT includes diacritics - i.e., make sure the manually defined and the automatic ones are the same. Thanks. Mike Peel (talk) 15:55, 13 July 2020 (UTC)[reply]
Using accented letters rarely gives appropriate results: these are sorted after all non-accented ones. In the Scandinavian languages this appears to be correct, but in other (I think the most) languages like French or Hungarian it isn’t: accented letters either sort the very same as unaccented ones (e.g. in Hungarian, Ádám sorts exactly the same as Adam) or are right after the non-accented (e.g. Ottó, Ödön, Péter). So I still think removing accents is generally a better solution.
That said, the bot should not remove things that are not exactly, byte-for-byte the same; if the infobox produces the sort key Lovmand, Christine, and the category has a defsort of Løvmand, Christine, |defaultsort=no should be added and not the correct sort key should be removed. (I just noticed that Christine Løvmand’s category already had this infobox parameter. This means that the bot stated it removed things provided by the infobox, but in fact the infobox hasn’t provided any sort key, as it was explicitly disabled. That’s certainly a bug that needs to be fixed in the bot.) —Tacsipacsi (talk) 21:17, 13 July 2020 (UTC)[reply]

I fixed the bot so that names with diacritics are skipped. However, i think in an international project like Commons/Wikidata there should be a standard way to work with the sorting of such names. This should be done automatically without the possibility to override manually. --Arnd (talk) 07:22, 19 July 2020 (UTC)[reply]

Same for Dutch surnames such as Dutch director nl:Jan van Kamer should be sorted as "Kamer, Jan van", words as "van" and "van der" are ignored in Holland, however, to make things complicated, not in Belgium and the USA. Hans Erren (talk) 05:52, 26 August 2020 (UTC)[reply]

ArndBot removed "{{DEFAULTSORT:Mariette, Jean}}", but did not remove "|defaultsort=no" from "{{Wikidata Infobox|defaultsort=no}}". This causes the category to be sorted under J rather than M at, for example, Category:Printmakers from France. --Robert.Allen (talk) 08:49, 12 July 2020 (UTC)[reply]

Hi Robert.Allen, thank you for the hint. I fixed the bot [6] and try to I clean up what i missed. --Arnd (talk) 11:42, 12 July 2020 (UTC)[reply]

Good work[edit]

Helping us to prevent and eliminate overcats. A bot is an object, nobody will -normally- come and revert you thinking "Why does this jerk correct my wrong POV edits?" Thank you very much. Greetings to your operator. --E4024 (talk) 13:52, 31 January 2021 (UTC)[reply]

+1 Very good work! Just eventually i have seen this[7] and this[8]. When this can be implemented for german wikipedia for ... let's say for erasing de:Kategorie:Mann and de:Kategorie:Frau as a first beginning introduction? FYI: I am Member of the german WP:Kat-Proj. and we are just in disscussion about possibilities to switch to wikidata in de:Wikipedia_Diskussion:WikiProjekt_Kategorien#Wikidata_und_die_Zukunft_des_Kategoriesystems_von_de:Wikipedia. Best --Tom (talk) 16:44, 11 June 2022 (UTC)[reply]

Defaultsort[edit]

was deleted

https://commons.wikimedia.org/w/index.php?title=Category%3ABarthel_Beham&type=revision&diff=527839491&oldid=364866876

https://commons.wikimedia.org/w/index.php?title=Category%3AAgnolo_Gaddi&type=revision&diff=527860838&oldid=436016431

Oursana (talk) 14:15, 14 February 2021 (UTC)[reply]

Hello Oursana, what problem do you see? {{Wikidata Infobox}} automatically adds this information. --Arnd (talk) 15:51, 14 February 2021 (UTC)[reply]
Yes A.schroet, it seems to work, but in Renaissance painters from Italy the three Ghirlandaio brothers Benedetto, Davide and Domenico are not alphabetical sorted as I did considering also their first names. Where can I check or change the sorting in general?Oursana (talk) 16:11, 14 February 2021 (UTC)[reply]
Hi Oursana, i guess that the sorting is somehow influenced by the the two familiy names Ghirlandaio and Bigordi. In such a case the bot should not remove the DEFAULTSORT. I will fix that. So you should be able to add it manually without being afraid to it will be remove later. --Arnd (talk) 08:35, 15 February 2021 (UTC)[reply]
Thank you, that was a small problem, but not perfectOursana (talk) 12:40, 15 February 2021 (UTC)[reply]

Categories erased[edit]

Why this Bot erased Fernando (given name) and 1962 births categories from Fernando de Gorocica category? Sincerely yours. Fernando de Gorocica (talk) 19:11, 6 June 2021 (UTC)[reply]

Hello Fernando de Gorocica, these categories are derived from Wikidata. When you open the category you will see it. --Arnd (talk)

category deleted without it coming from wikidata[edit]

in this edit the category has been removed but it does not come from wikidata, probably because it is considered a fictitious human ZioNicco (talk) 10:10, 12 November 2023 (UTC)[reply]

Hi ZioNicco, thank you for being patient. I guess you are right that this is because of the "instance" of the connected WD item. I mentioned this issue in the WD infobox template talk. Depending on the result i will adapt my Bot to filter out such special cases. Best regards, --Arnd 🇺🇦 (talk) 08:27, 19 November 2023 (UTC)[reply]

Geolocation[edit]

Don’t do this. -- Tuválkin 07:33, 21 November 2023 (UTC)[reply]

Agree. We discussed the point on project chat a while back. Please fix any contrary bot edits. Enhancing999 (talk) 13:27, 21 November 2023 (UTC)[reply]
Next time, I’ll have to ask elsewhere. -- Tuválkin 11:35, 26 November 2023 (UTC)[reply]

Hi, thanks for caring about redundant duplicate coordinates. But as you did in [9] this will nor remove the redundant coordinates, but display them two times with same value retrieved from WD, once by {{Object location}} without args and once be {{Wikidata Infobox}}. best --Herzi Pinki (talk) 10:08, 26 November 2023 (UTC)[reply]

Please undo your edits and stop running any changes to coordinate templates. Thanks. Enhancing999 (talk) 20:00, 26 November 2023 (UTC)[reply]

Tuválkin,Herzi Pinki, Enhancing999, two basic things one should bear in mind: (1) "Wikimedia Commons is a collection of [...] files" and (2) "The category structure is the primary way to organize and find files on the Commons". So the focus of Commons are files and they are just organized in categories. To "understand" a category, before Wikidata a lot of information about it has been added to the category pages as free text and many template, which was okay that time. Now with WD, there is no reason to keep any information in the category page that is already provided by WD via {{Wikidata Infobox}}. It is personal taste when one says that an additional Coordinates template is required to describe the category since the waste amount of categories is without it. If there is a common wish to have it, then it should be added to the Wikidata Infobox. This would also solve the problem of double WD-calls. What makes no sense in my mind, is to keep local coordinates when the same are available on WD. Best regards, --Arnd 🇺🇦 (talk) 10:00, 27 November 2023 (UTC)[reply]

Oh, so it’s not a mistake of your bot’s: It’s really you going against consensus — vandalizing Commons categories by removing human generated content and replacing it with garbage data syphoned from another WMF project. Very well. That needs to be addressed in the proper venue, not in the bot’s talk page. -- Tuválkin 10:04, 27 November 2023 (UTC)[reply]

Service: The referenced discussion was here: Commons:Village_pump/Archive/2023/08#Redundancy_'Wikidata_Infobox'_and_'Object_location'_in_category_descriptions. best --Herzi Pinki (talk) 10:31, 27 November 2023 (UTC)[reply]