Jump to content

Commons:Bots/Work requests

Add topic
From Wikimedia Commons, the free media repository

Shortcuts: COM:BR • COM:BWR

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


# Bot request Status 💬 👥 🙋 Last editor 🕒 (UTC) 🤖 Last botop editor 🕒 (UTC)
1 Donating map images 11 4 Yann 2025-12-12 15:35 TheSandDoctor 2025-09-09 05:11
2 Tidy up Quality images of manhole covers 4 2 Schlurcher 2025-10-29 18:02 Schlurcher 2025-10-29 18:02
3 Categorize photos from Polish Wiki Loves Monuments by administrative unit 7 5 Multichill 2026-01-11 20:18
4 Files missing the infobox template 6 2 Matrix 2025-12-24 12:24 Matrix 2025-12-24 12:24
5 Populating Category:Files by language of non-English file title 2 1 Prototyperspective 2025-11-05 14:56
6 Correct colour categorisation of heraldic flags 1 1 ARK 2025-10-31 10:20
7 Merging audio files of audiobooks 1 1 Prototyperspective 2025-11-02 12:37
8 Adding the gallery page template to galleries 3 2 Matrix 2025-12-24 13:52 Matrix 2025-12-24 13:52
9 Adding noinclude to deletion request page categories 3 2 Prototyperspective 2026-01-01 21:30 Jeff G. 2025-12-24 17:31
10 Categorization of Category:Photographs by Anil Öztas/Lens focal length 1 1 OmegaFallon 2025-12-05 06:28
11 Commons:Report UncategorizedCategories with redcats needs updating 3 2 Prototyperspective 2025-12-08 23:52
12 Changing values in the date field based on categorization 5 2 Prototyperspective 2026-01-05 19:54
13 Images by HH Fred 5 4 Jeff G. 2025-12-24 16:38 Jeff G. 2025-12-24 16:38
14 Edit categorization using wikidata P31 and P13723 properties 8 2 Immanuelle 2025-12-24 11:50
15 Replace "actresses" by "female actors" in {{cl|Female actors by country}} 3 3 Auntof6 2026-01-16 21:08 DaxServer 2026-01-16 20:03
16 Syntax fixing 1 1 Stefan Kühn 2026-02-09 15:41
17 Automatically create categories for images sorted by date 5 3 Schlurcher 2026-02-14 18:33 Schlurcher 2026-02-14 18:33
18 Upload ZIP contents through OpenRefine 1 1 PantheraLeo1359531 2026-02-12 19:59
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.


Donating map images

[edit]

I wrote at the Help Desk

I have a website https://maproom.org which presents images of maps from atlases, mostly published in the 19th century. I used to sell higher-resolution versions of these images, but my sales have dropped to zero. I'm considering donating all the higher-resolution versions to Wikipedia. That's 2484 jpgs, totalling around 70 GB.
My main concern is to minimise the amount of bureaucracy for me. I would not want to have to specify a filename for each image, let alone add it to categories. I can provide access to a database with information (subject, date, source, etc.) for each image.
I anticipate that this will involve more work than any Commons volunteer would want to take on. But if there is a way of managing things, please let me know

and was encouraged to post here. The database fields include

  • the name of the uploaded file
  • the title of the plate, as in the work from which it was scanned
  • the title of the plate in English
  • a list of search terms (which might be useful in assigning categories)

Maproom (talk) 16:26, 12 May 2025 (UTC)Reply

See Commons:Batch uploading? Wikiwerner (talk) 18:50, 14 May 2025 (UTC)Reply
I have started a batch upload request: see Commons:Batch uploading/Maproom.org. Wikiwerner (talk) 11:13, 22 June 2025 (UTC)Reply
@Maproom: This definitely seems doable. How would an interested bot op get access to said database and the full resolution images? TheSandDoctor (talk) 05:11, 9 September 2025 (UTC)Reply
TheSandDoctor: thank you for your interest!
I can supply an SQL dump of the database, and change the permissions (to read-only for world) on the directory where all the high-resolution versions are. I can also give the bot read-only access to the database.
Something would have to extract the relevant details, being
  • Name of plate, in English
  • Name of plate, in own language
  • Date portrayed in map
  • Keywords, for categories
  • Bibliographical details of published source
  • Plate number as in source
I guess I could use SQL to generate the information a bot will need, in its preferred format.
Maybe it would be a good start if I emailed a database dump to the potential bot op, so they can judge how best to do this? Maproom (talk) 07:58, 9 September 2025 (UTC)Reply
I'd still like to donate these 2000+ images to Commons, but I'm not competent to do all the work myself. Is there anyone I could discuss it with? Maproom (talk) 08:36, 5 December 2025 (UTC)Reply
@Maproom: I could be interested to upload these files. Are all the maps available online? You can send me an email if you cannot provide the information online. Yann (talk) 16:14, 5 December 2025 (UTC)Reply
Thank you, Yann, for your interest. You can look at all the maps at https://maproom.org/. But you can't easily download them from there, because of the Zoomify code that presents them via the browser. (Also, the images I'm offering are mostly at twice the resolution of the on-lne images). I assume whoever uploads them will also need the database tables that specify the dates, bibliographical details, search terms etc. for each image. Maproom (talk) 20:05, 5 December 2025 (UTC)Reply
@Maproom: Hi, I haven't heard from you. Would you send me the information? Please note that there is no hurry. I won't be able to do it before January. Regards, Yann (talk) 17:54, 11 December 2025 (UTC)Reply
Yann: I've emailed the information. Maproom (talk) 13:21, 12 December 2025 (UTC)Reply
@Maproom: Thanks. I got it. I will need some time to look at it. Yann (talk) 15:35, 12 December 2025 (UTC)Reply

Tidy up Quality images of manhole covers

[edit]

For now we have 432 QI of manhole covers. After the categorisation we can met them in Architecture/Close-ups, Architecture/Other, Objects/Other and probably somewhere else. Екатерина Борисова has an idea to put all of them into Objects/Industrial, and I can with available tools remove them from everywhere and collect in one place, but not chronologically (because now all these categories are organised by time). Theoretically it's possible to see dates from linksto (like Commons:Quality images candidates/Archives July 30 2024). Can anybody help with this idea and reorganise these QI? Анастасия Львоваru/en 22:57, 6 June 2025 (UTC)Reply

Not clear how a bot would help here. --Schlurcher (talk) 08:32, 29 October 2025 (UTC)Reply
Do you really think it is a task that should be done manually? Анастасия Львоваru/en 08:39, 29 October 2025 (UTC)Reply
I'm simply saying that I do not know how to codify this. If you have an idea how this could be automated then please elaborate. --Schlurcher (talk) 18:02, 29 October 2025 (UTC)Reply

Categorize photos from Polish Wiki Loves Monuments by administrative unit

[edit]

Hello! In Polish WLM there are special prizes for photos from certain administrative units. Therefore, we categorize the photos by voivodeship (i.e. top-level administrative unit). I have prepared a list of files to be added to respective categories at User:Msz2001/WLM2025_categories.

The page has 16 sections, files in each section should be added to the category in the section header. Thanks in advance, Msz2001 (talk) 18:41, 1 October 2025 (UTC)Reply

@Msz2001: Can you give an example of exactly what category you'd want added to a specific file?
Also, that page is pretty big and is hard to load. -- Auntof6 (talk) 19:38, 1 October 2025 (UTC)Reply
@Auntof6 For example, add File:2023-05-13_090837_00535_Wrocław,_archikatedra_św._Jana_Chrzciciela_we_Wrocławiu.jpg to category Category:Images from Wiki Loves Monuments in Poland – dolnośląskie voivodeship (which is specified in the section header).
If the page takes much time to load, it might be easier to take the data from the edit view. It loads quickly, especially with syntax highlighting turned off. The structure of the source code of this page is very predictable (either file link preceded by # or category link in header). Msz2001 (talk) 19:54, 1 October 2025 (UTC)Reply
@Msz2001: Thanks, I understand better now. If I think of something that could help, I'll comment here again. -- Auntof6 (talk) 20:00, 1 October 2025 (UTC)Reply
User:Cryptic-waveform did something similar before: see Commons:Bots/Work requests/Archive 17#Mass categorization of Wiki Loves Monuments Poland photos. Wikiwerner (talk) 14:57, 25 December 2025 (UTC)Reply
I have started work on this. The first step was to expand {{Wiki Loves Monuments 2025}} to allow specifying the voivodeship (Revision #1144865823). Note that I'm using the English names of the voivodeships per COM:LANG. I have started to move images from Wiki Loves Monuments 2025 in Kraków by modifying the template. Images that don't have a voivodeship are now added to Images from Wiki Loves Monuments 2025 in Poland missing voivodeship categorization. This follows the pattern used for US images. Cryptic-waveform (talk) 15:25, 9 January 2026 (UTC)Reply
Please don't mess with 10+ year old templates like {{Wiki Loves Monuments 2012}}. These templates are per country. If you want to add more categorization, that's fine, just don't edit these templates. Multichill (talk) 20:18, 11 January 2026 (UTC)Reply

Files missing the infobox template

[edit]

Could somebody create a bot that adds the infobox template to a large fraction of files in Category:Media missing infobox template?

Those files do not have the {{Information}} set. This means for example that if they are embedded in a Wikipedia article one can't see the file description in the MediaViewer. The Commons app probably also can't read the source and description and this also goes for other and potential apps and API requests. It's important to have the file info in standardized expectable queryable format. As a note, many audio files in Category:Spoken Wikipedia use other templates and often screw the templates incl. the information template up such as having that template embedded in the info template and this may be good to fix or tag with a bot at some point too.

I'm sure there have been other threads about this, including here. It's important to only convert the loose text into the Information template if there is info on the source because otherwise a bot will tag the file for deletion if the Source or Author field are empty. This can be achieved by limiting the bot to files with Source or e.g. From: in the text (e.g. use the insource: search operator for that) and moving this part of the text into the right parameter (I suggest if a source link is given but no additional Author: text then the bot better just write See source into the author field to prevent deletion of the files just because the metadata has been moved into the proper structured template. Here's an example of how conversion looks like (and this can't and shouldn't be done by hand for 300k+ files): Special:Diff/1096226926.
Prototyperspective (talk) 12:01, 7 October 2025 (UTC)Reply

IMO this shouldn't be a pure bot task, but a semi-automated tool with human oversight. —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 12:26, 19 December 2025 (UTC)Reply
Is there a separate place to request these? If not, I think this board is also used to request such and they're difficult to distinguish. I don't really care that much about how it's implemented as long as it's implemented in an effective way i.e. something that works 1) in practice and 2) at scale. I have doubts whether a semi-automated tool with human oversight meets those two criteria, considering there's over 364,000 files in that category, and in your comment I see no reason or explanation for why it should not be a bot "but a semi-automated tool with human oversight". Prototyperspective (talk) 16:54, 19 December 2025 (UTC)Reply
@Prototyperspective: Sorry, forgot to give an explanation. If this was a pure bot task, excluding use of novel techniques like AI or NNs, it would be a nightmare to build an algorithm that could parse questions like "is it own work?", "if not where can I find the author in the source?", etc. etc. Regex along isn't going to do the trick. I think it's more important to make sure a bot would do the task well that just make sure it does it somewhat and leaves confusing messages like "see source". A semi automated tool where someone selects the description, selects the date, author, etc. would be a better use of dev time. I don't mind having a look at how to start something like this, considering it's half term, but just my thoughts. —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 21:46, 21 December 2025 (UTC)Reply
Makes sense. However, I think this only really applies if this was used for all or close to all files. probably something on the order of 90% of files missing the information template could be set well using some well-engineered conventional bot and the rest could be ignored. This would be tremendously useful and make semi-automated methods way more feasible – solve what can be solved using the bot and then have the remainder get done via the semi-automated method.
.
Secondly, if there is no info in the current file description about the author like for the example diff I linked, then there's no issue with filling that parameter with (see source). This is especially the case as this is way better than people doing this manually or even semi-automatically since a bot would have a standardized value for such cases for the parameter which means one could then search for or tag files with that specific value (like (see source)). Again, since there isn't more info about the author in the current file description (and a source was found), that's not a problem at all and it wouldn't really be a problem if the author was in the source field due to the standardized value in the author field. I haven't heard of any better alternative – e.g. semi-automatic methods won't be done for and are infeasible for over 350 k files. Prototyperspective (talk) 21:57, 21 December 2025 (UTC)Reply
Just having a look at the category, 90% seems generous, since most are only a one-line description. However, I am definitely not against it if it is possible. Any insource queries/regexes for such patterns would be helpful, since I can't seem to find any good ones though. —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 12:24, 24 December 2025 (UTC)Reply

Populating Category:Files by language of non-English file title

[edit]

Categorizing files by language of the file name if the filename is not English (English titles are the most common case) enables tracking, finding or filtering files with non-English titles by that language.

This enables users to for example create English captions for those files that are also of relevance to users not understanding the language of the title.

When I see files with say Russian, Chinese, or Japanese titles on a category page or the search results, I don't understand anything but understanding the title is often very useful or needed as things often aren't self-explanatory from the thumbnail (e.g. the case for many files here). For example, it makes these files less likely to be clicked in the results and people searching the Web in English for media (e.g. via Google Images) can't find them.

As of 2025, per COM:File naming file names with titles in languages other than English are allowed. However, assuming this stays as is, other things may change: for example a translated title of the file could be displayed in Commons to users who don't understand the title's language (and thus can't read the file title). This could readily be implemented at scale using machine translation where even if there are errors in 1% of titles would still be useful to many of those users who otherwise understand nothing of the title. It could also be implemented by showing the English caption instead for those files to those users (note that files with English captions are a small fraction).

There are of course good reasons for not using English for some files title such as when they are much more likely to be relevant to people speaking that language and searched for in that language. For example, a Russian pop-culture thing or photos of a small village in Russia are more likely to be searched in Russian than English. Another good reason would be that the uploader doesn't speak English good enough and doesn't want to rely on machine translations of the titles. These categories don't discriminate on the language, they would be useful for making files more accessible, understood and useful, not less accessible. It would make Commons overall more useful and localized better/more multilingual.

Populating these categories by hand would be a gigantic task, even when it's a small percentage of files on Commons, it would be a huge time sink, pollute Watchlists (since there is no edit-tag for this and one can't filter nonbot users) and always be very incomplete. So I think this a task best done by a bot / script.

It would probably be best to simply put all files with titles in a language in the respective category, instead of trying to distinguish files of international relevance also to people not speaking that language from files where this is arguably not the case and only putting the former kind of files into these categories.

For this, the bot would need to detect the language of the file title and then add the respective category. To detect the title language, maybe MinT could be used but if you have further ideas please do comment.
Prototyperspective (talk) 14:08, 30 October 2025 (UTC)Reply

See also Commons talk:WMF support for Commons/Upload Wizard Improvements#Detect non-English file titles and prompt user to specify language. (This would affect newly uploaded files so that this task would more or less only be needed for retrospectively adding this metadata.) Prototyperspective (talk) 14:56, 5 November 2025 (UTC)Reply

Correct colour categorisation of heraldic flags

[edit]

In accordance with Unresolved issue regarding categorisation, I would like to request that all edits by Nebula84912 with "black" or "Black" in their edit summary be reverted in a bot run.

Rationale: The user in question has incorrectly re-categorised a large number of SVG flag files as featuring the colour black. The user did so on the mistaken assumption that the mere presence of a black outline drawn around certain design elements of a heraldic flag warrants the inclusion of black as a 'colour' of that flag. Heraldry, however, has a centuries-old understanding in which black is only considered a colour of a particular design if a design element is fully tinctured black, not merely outlined, as the outlining of elements is deemed an arbitrary stylistic choice, not an integral part of the design.

Examples: a black eagle counts as an instance of the colour black. A red bear with an arbitrary black outline drawn around it does not. Thanks, ARK (talk) 10:20, 31 October 2025 (UTC)Reply

Merging audio files of audiobooks

[edit]

See Commons:Village pump/Technical#Path to merging multi-part audiobooks? Prototyperspective (talk) 12:37, 2 November 2025 (UTC)Reply

[edit]

As of now, if a gallery page on a subject exists, the Wikipedia links to that instead of the category. So people who go to Commons from the Wikipedia article, looking for more media files land on these pages which usually only contain very few files, aren't well-maintained and were last updated over a decade ago. The category has more files but users don't know of category pages or don't look any further.

The {{Gallery page}} includes a link to the associated category page but many galleries don't have that template. For example, I just added it to Dreissena bugensis which had just 3 files while the category has and explanatory video and more files. This problem is much more severe for other subjects where there are relatively many more files and subtopics and up-to-date media files in the category, such as galleries about software where the gallery has only decade-old screenshots. Gallery pages without the template I think can be identified like so.

Please add this template to all galleries that don't yet have this template at the top. Prototyperspective (talk) 16:45, 6 November 2025 (UTC)Reply

Working on this —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 22:35, 23 December 2025 (UTC)Reply
Commons:Bots/Requests/MatrixBot 6Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 13:52, 24 December 2025 (UTC)Reply

Adding noinclude to deletion request page categories

[edit]

Could some bot please wrap categories into <noinclude> and </noinclude> for deletion request categories?

If categories aren't inside noinclude tags, the page for the DRs of the respective day will be in categories like Category:Copyright deletion requests/deleted.

In this example, pages Commons:Deletion requests/Archive/2023/10/10, Commons:Deletion requests/Archive/2025/02/16, Commons:Deletion requests/Archive/2025/06/11, and Commons:Deletion requests/Archive/2025/09/10 are included there. Probably some users fix these things manually – I did it too for a few cases – but it's incomplete, slow and – maybe most importantly – costing valuable scarce volunteer time. Prototyperspective (talk) 16:48, 2 December 2025 (UTC)Reply

@Prototyperspective: ✓ Done. Krdbot already does this periodically, see Special:Diff/1135055185.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 17:31, 24 December 2025 (UTC)Reply
Thanks for the info and happy new year to you two. But it is not fully done as can be seen from the linked example(s). @Krd: So this request is changed to be about an upgrade of Krdbot so it fixes all the pages. Maybe it only checks pages once the DR is closed but not afterwards even if categories got added without noinclude afterwards.
Krd, could you change the bot so it checks deletion sorting categories for DR-day-pages in the category or does something else depending on why there are still DR pages with categories not wrapped in noinclude tags? Prototyperspective (talk) 21:30, 1 January 2026 (UTC)Reply

Categorization of Category:Photographs by Anil Öztas/Lens focal length

[edit]

For each category in Category:Photographs by Anil Öztas/Lens focal length, add appropriate lens focal length category. Example: Category:Photographs by Anil Öztas/Lens focal length 84 mm would have [[Category:Lens focal length 84 mm|Anil Öztas]] added. Thanks. OmegaFallon (talk) 06:28, 5 December 2025 (UTC)Reply

Commons:Report UncategorizedCategories with redcats needs updating

[edit]

I'm not sure if this is the right place to request this, or if I can update the page myself somehow. I just know that I did a big cleanup of things in this category last night, and several others are also visibly dated when you look. So please do a renewed run for the report. Rose Abrams (talk) 10:36, 6 December 2025 (UTC)Reply

I'm gonna humbly and carefully ping Prototyperspective who appears associated with the list. Rose Abrams (talk) 10:38, 6 December 2025 (UTC)Reply
Thank you very much for doing that cleanup, creating this category and also the ping.
I already made a request to have this report updated here at #Report update request (#2). Wikiwerner subsequently updated it manually 3 or 4 times but no bot was created. No other users replied to thread. I then contacted Mdaniels5757 whose bot updates Commons:Report UncategorizedCategories with only infobox categories which is quite similar: User talk:Mdaniels5757/Archive/2025#Request for a report to be updated by your MDanielsBot but the user said I don't think so, this query is too slow for the bot (even with my optimizations). Sorry..
I don't have experience with bots and doubt much that even if I didn't have other wikiactivities going on that I could implement this if even Mdaniels5757 couldn't.
So my next step was to create a wish in the Community Wishlist (see post about it here) and just haven't gotten to creating it yet. It would be best if somebody here knows more and could implement a bot to update the report; then I wouldn't create the wish. As for the wish, ideas for how this could be solved are making also slow queries work (see reply by Mdaniels5757) or splitting the query up into successive several parts and then putting it into either separate sections on that page or assembling it into one table there. Any further information / clues would be helpful for the wish assuming nobody implements the regular updating of the report. Prototyperspective (talk) 23:52, 8 December 2025 (UTC)Reply

Changing values in the date field based on categorization

[edit]

A bot that either puts files on a list of files to check or even directly fixes the date for files that have a false date set would be useful.

For example, this file has Category:1912 in art and Category:Science fiction in the 1910s set but had 2013 in the date field because probably that was the date uploaded at some source site the file was imported from. Corrected in Special:Diff/1127271170.

Doing this manually won't yield much, it needs an approach that works at scale. Another complementary idea would be to add a note to the UploadWizard to ask users to enter the date taken or first released in there. Prototyperspective (talk) 23:11, 8 December 2025 (UTC)Reply

This request is valid for faithful representation, but there are other types of images – e.g. photos that show statues or murals at angle, or even paintings of statues. In these cases, the date the picture was created is also relevant and shouldn’t be blindly removed. So if a bot solution is created, it should somehow differentiate between the two cases (or really just create a list, from where humans can differentiate). —Tacsipacsi (talk) 15:15, 24 December 2025 (UTC)Reply
I'm not proposing the date is removed so I don't fully understand your comment. Maybe the best solution would be to have a bot just create a list of files with the value in the date field not matching the date in the file's categories with a column(s) for the date-category and a way to fix (ie replace [not remove]) the date for selected categories complemented with a way to exclude files if they're in certain categories and to exclude categories from 'date categories'. This way one could fix the mismatches at scale if this works for category branches (ie also the selected category's subcategories) but leave out categories where the date-category is not necessarily the date of what the media shows / when the media was taken. An example for the latter would be a category about an event being in Category:1912 in politics containing a photo of a memorial taken in 2023. The maybe easiest solution there would be to simply not consider Category:Politics by year subcategories as date categories that are used by the bot.
Basically, I think this could be started by creating a bot that just lists files to check and their respective date category/ies which could then be refined over time by users checking this list to exclude certain categories (and their subcategories) from counting as 'date categories' which then could be extended with ways to fix files in batches (the list will likely contain many thousands of files with sth like 80% having wrong date). Prototyperspective (talk) 10:38, 4 January 2026 (UTC)Reply
I'm not proposing the date is removed so I don't fully understand your comment. You propose replacing the dates. A replacement is basically the removal of one value and the addition of another one. So yes, you’re proposing that one date is removed, even if you also propose that another one is added.
As I wrote, a mere listing is perfectly okay, since that implies human judgement during the actual replacement. —Tacsipacsi (talk) 23:46, 4 January 2026 (UTC)Reply
  • It's often if not usually not clear what that date is when it's not the date taken – the day the person uploaded it to Commons? The date the file was first published? The date the file was published at the source site?
  • Listing multiple dates there means it can't be parsed / read in structured ways, so one can't use it for sorting, or to display a date in some app (like the Commons app), for ranking search results, for values in API returns etc etc
  • As said, in cases like your example the date shouldn't be removed or replaced.
  • In other cases, one could move the date to a separate field if it's found to be not the date taken.
Prototyperspective (talk) 19:54, 5 January 2026 (UTC)Reply

Images by HH Fred

[edit]

We have hundreds of images by the Flickr-Photographer HH Fred (https://www.flickr.com/photos/fredhh/) on Commoms. Can a Bot add all of them to the Category:Images by HH Fred? Shark1989z (talk) 21:06, 18 December 2025 (UTC)Reply

Would it be better to request this and things like this at Commons:Batch uploading or some other place? Prototyperspective (talk) 16:55, 19 December 2025 (UTC)Reply
The files are already here on Commons. Searching for fredhh gives 693 hits. --Achim55 (talk) 19:35, 21 December 2025 (UTC)Reply
In that case, one can just use cat-a-lot from the search results to add the category. Prototyperspective (talk) 19:42, 21 December 2025 (UTC)Reply
@Shark1989z: ✓ Done. I did this for you as myself with special:search and COM:Cat-a-lot. There are now 656 files in that cat. My main search was followed by the next 500.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 16:38, 24 December 2025 (UTC)Reply

Edit categorization using wikidata P31 and P13723 properties

[edit]

I want to import data from here to subcategories of Category:Shinto shrines by ranking.

For it and its subcategories I want every category whose wikidata item has P31 for the respective category (i.e. Category:Kokushi genzaisha means all instance of (P31) kokushi genzaisha (Q118304363) items with a commons category will have the category Category:Kokushi genzaisha added to them).

For subcategories of Category:Modern system of ranked shinto shrines we will use ‎modern shrine ranking (P13723) instead.

Because of the way that categorization works and that these categories are not empty it may be better to just give these categories with the operation meant to be done on each.

P31 categories


P13723 categories

Immanuelle ❤️💚💙 (please tag me) 23:28, 22 December 2025 (UTC)Reply

Can you also do it for these ones? Using the property {{q|P149}}
Immanuelle ❤️💚💙 (please tag me) 03:45, 23 December 2025 (UTC)Reply
And for all subcategories of Category:Shikinaisha by Province please do it for shrines with the part of (P361) property Immanuelle ❤️💚💙 (please tag me) 04:30, 23 December 2025 (UTC)Reply
Immanuelle ❤️💚💙 (please tag me) 15:17, 23 December 2025 (UTC)Reply
@Auntof6 would you be up for doing this? Immanuelle ❤️💚💙 (please tag me) 22:51, 23 December 2025 (UTC)Reply
@Immanuelle: My understanding is that, for the categories listed above, their categorization should be adjusted based on values in Wikidata. I don't know how to do that, except manually, which I'm not more qualified for than anyone else. If that's not what's being asked, please explain further.
By the way, it's not necessary to pipe the entries to remove the "Category:" text. Doing that can make it look like you're listing galleries instead of categories. Not doing it would allow copy/paste of the category names directly from what shows on this page. -- Auntof6 (talk) 08:24, 24 December 2025 (UTC)Reply
@Auntof6 that’s what I was asking. It’s a simple task for me but I’m not sure about how to ask permission to do it myself. I’ll fix the piping. Immanuelle ❤️💚💙 (please tag me) 11:45, 24 December 2025 (UTC)Reply

P31 categories

P13723 categories

P149 categories

P361 categories (Shikinaisha by Province)

Here Immanuelle ❤️💚💙 (please tag me) 11:50, 24 December 2025 (UTC)Reply

Replace "actresses" by "female actors" in Category:Female actors by country

[edit]

Following the discussion at Commons:Categories for discussion/2024/12/Category:Actresses, a consensus was reached to rename categories from "actresses" to "female actors".

Most subcategories of Category:Female actors have been renamed, but the large Category:Female actors by country tree hasn't been tackled yet. I suggest using a bot to handle this massive branch, as it is too large for manual renaming. Deltaspace42 (talk) 15:45, 15 January 2026 (UTC)Reply

@Deltaspace42 Can you request it at User talk:CommonsDelinker/commands/Category moves of which the @SteinsplitterBot would take care? -- DaxServer (talk) 20:03, 16 January 2026 (UTC)Reply
@Deltaspace42: Please be careful working on these because some of the category names are assigned by templates. It might be best to break it into subsets. I can help work on it if you want. -- Auntof6 (talk) 21:08, 16 January 2026 (UTC)Reply

Syntax fixing

[edit]

I found often IMHO errors in the syntax.

  1. [{Category: (over 2400 results → Search link )
  2. [[Category:Category: (many results, but timeout → only images of the year 2026: Search link)
  3. |[[Category: (over 2900 results → Search link )
  4. [[Categori: (2 results → Search link )
  5. [[Categories: (over 300 results → Search link )
  6. [[Catagory: (1 results → I fix this.)
  7. [[Cathegory: (2 results → I fix this.)
  8. [[Categori: (2 results → I fix this.)
  9. [[Categor: (2 results, but timeout → I fix 4 errors, but maybe exits more.))
  10. [[Category : (over 70 results → should be fixed Search link )
  11. [[Category? (no ":" after → over 80 results, but timeout → Search link))

I think we need a bot, who permanently check and fix this typing errors. At number 3: often I found code like "#ifexist". I think this should not in the description page at commons. IMHO This is something that have to be inside a template. sk (talk) 15:41, 9 February 2026 (UTC)Reply

Automatically create categories for images sorted by date

[edit]

Is there a bot that can handle the task of creating categories for daily images (eg. Photographs taken on 2026-02-15). This would also apply to the various categories for images taken in a certain location (country/state/city; LOCATION photographs taken on YYYY-MM-DD).
Right now this task seems to be done by users which usually is unreliable. Is there a bot that can handle this task as well?
The specific task would be to check if there are images sorted in category X and if yes, create the category. Of course this would be limited the the given examples.
--D-Kuru (talk) 10:37, 12 February 2026 (UTC)Reply

See also Template talk:Taken on#Shouldn't a bot convert dates in the date field to add this template?. Currently these cats can't be used for filtering and are additionally misleading because they are overly incomplete. A difficulty is that not all image files are photographs. Also sometimes the set date is wrong (UploadWizard could clarify that except for film videos, this should be the date taken/shown). Prototyperspective (talk) 12:51, 12 February 2026 (UTC)Reply
As I said over on Commons_talk:Bots, the discussion about a bot adding these is different from creating them. IMO the logic behind a bot that adds categories based on the content has to be far more sophisticated than a bot who just creates categories if an image is present inside it. I don't think that it's wise to mix both requests as they have a different end goal.
However, the more I think of it, the more I do not think that adding such categories should be done by a bot as it's dealing with symptoms rather than dealing with the source. Why should there be a bot if this can be much better be done on image upload with the Upload Wizard? Upload Wizard can extract the date from the EXIF data. If the date matches a YYYY-MM-DD pattern, it could automatically use {{Taken on}} which automatically includes said categories. There would be no need for an extra bot to do the work that already could have been done on upload.
The idea behind a bot creating these categories originates from Template_talk:Taken_on#Template_behaving_incorrectly_with_videos_when_using_location_parameter and the discussion whether videos and audio files should be categorised in the same pattern as images are (so audio files would land in eg. Audio files recorded on 2026-02-15 and video files in Videos taken on 2026-02-15). IMO it's a good idea to have a comparable category name structure so I'm not against this change. I just doubt that it's a good idea to do this with a bot behind this change that would create all the new categories.
By the looks of it, there already is a bot who is doing the things I suggested: https://commons.wikimedia.org/w/index.php?title=Category:Videos_taken_on_2026-02-13&action=history
--D-Kuru (talk) 07:18, 13 February 2026 (UTC)Reply
Upload Wizard can extract the date from the EXIF data not all photos have that in the exif data. Maybe not even most of them. Additionally, some files that aren't photos also have this exif data set. Other than that, see Commons talk:WMF support for Commons/Upload Wizard Improvements.
audio files should be categorised in the same pattern as images are (so audio files would land in eg. Audio files recorded on 2026-02-13 not useful to categorize them by day I think. Instead I suggest first of all not having Category:Audio files by year 95% incomplete (making the cat near useless and misleading).
there already is a bot who is doing the things I suggested Then it may be better to ask at the talk page of User:SchlurcherBot or a related place. Prototyperspective (talk) 15:57, 13 February 2026 (UTC)Reply
My bot does creates these daily categories already, both for Photographs and Videos, however, most often someone else is faster in creating them. I'm only systematically creating them for like 2 years onwards (even if empty), as these are expected to be not empty eventually. I'm not creating any location categories and also not checking if any earlier ones are not empty. --Schlurcher (talk) 18:33, 14 February 2026 (UTC)Reply

Upload ZIP contents through OpenRefine

[edit]

From COM:VPT: I would like to upload a batch of orthophotos of Thuringia. Each tile comes as ZIP file with TIF, meta and tfw file. Is there a way to let the Wikimedia servers extract only the TIF to be uploaded? Having them down- and reuploaded on and from my PC probably takes some time. Thanks! --PantheraLeo1359531 😺 (talk) 19:59, 12 February 2026 (UTC)Reply