Plánovací kalendář BOT (talk · contribs)

Operator: Plánovací kalendář (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: Three batch tasks, run from PAWS with Pywikibot, mainly on Wikimedia Czech Republic category trees (campaigns, photo contests, edit-a-thons, GLAM, programs) and related Czech topical categories such as streets in Czech municipalities:

1. Category maintenance: creating, editing, moving and merging categories; converting hard category redirects to soft {{Category redirect}}; adding {{Wikidata Infobox}}; adding by-year and maintenance categories (e.g. diffusing files into "YYYY in Orlová" by year of creation and creating the missing yearly categories via a local template). The bot only adds categories (it does not strip existing parents) and derives the year from the file name, falling back to the Information date field, skipping upload dates and ambiguous cases.
2. Linking Commons categories to Wikidata: creating Wikidata items for WMCZ campaign editions, photo-contest editions and edit-a-thons; adding the commonswiki sitelink and the relevant statements (instance of, country, organizer, point in time, follows / followed by, part of, logo, representative image P18), and correcting incorrect statements where needed.
3. Structured data on Commons (SDC): setting the creator statement (P170) on the operator's own files only, to the operator's own Wikidata item (d:Q99692082). The bot acts only on files whose Information author field matches the operator's own known signatures, so it never converts or assigns authorship of third parties. (Note: these edits are currently disallowed by Special:AbuseFilter/265 for non-autopatrolled accounts, hence the autopatrol request below.)

Automatic or manually assisted: Manually assisted, supervised. Every batch is first run as a dry run, reviewed, then run live with the output monitored. Tasks are idempotent. Edit type (e.g. Continuous, daily, one time run): Batch runs, repeated as needed (typically after WMCZ campaigns and events). Not continuous. Maximum edit rate (e.g. edits per minute): Up to about 6 per minute, usually slower, never faster than one edit per 5 seconds, and slower during peak hours.

Bot flag requested: (Y/N): Yes. Also requesting autopatrol, because some SDC edits (task 3) are disallowed by Special:AbuseFilter/265 for non-autopatrolled accounts. Programming language(s): Python (Pywikibot), run from PAWS. Test run:

• Task 1 (category maintenance):
  • By-year diffusion, creating the yearly category via the local template:
  • By-year diffusion, adding the year category to a file:
  • Sort key on a national street-name category: ,
  • Adding {{Wikidata Infobox}}
• Task 2 (Wikidata linking, edits on Wikidata)
• Task 3 (structured data): (currently blocked by Special:AbuseFilter/265 for non-autopatrolled accounts; will be added once autopatrol is granted)

Plánovací kalendář (talk) 21:04, 23 June 2026 (UTC)

Discussion

Please use edit summaries similar to Help:Gadget-HotCat when adding categories. I don't think that Wikidata item for task 3 is confirming Wikidata notability requirement. There are other ways to add attribution to Structured Data. EugeneZelenko (talk) 15:15, 24 June 2026 (UTC)

On the edit summaries: agreed, I will switch the category edits to HotCat-style summaries (e.g. "+2015 in Orlová").

On task 3: thanks, that distinction is helpful. For files where the author is a User: link, the author-name-string approach you describe (already handled by an existing bot) makes sense, and I do not intend to duplicate that. My task targets the gap: files where the author is given via the {{Creator}} template. There the Creator template is already tied to a Wikidata item, so the natural P170 value is that same linked item rather than a string. In my own case that is d:Q99692082, which meets notability criterion 1 (Commons sitelink to Category:Tadeáš Bednarz), and I would set it only on my own uploads, never for third parties.

Does using the item that the Creator template already points to, as P170, seem reasonable to you for the Creator-template case? Plánovací kalendář (talk) 17:21, 24 June 2026 (UTC)

BorkedBot (talk · contribs)

Operator: BrokenSegue (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

I'm proposing that this bot populate the structured data Wikimedia Commons content descriptor ( P14416) with the value Not Safe For Work according to Falconsai/nsfw_image_detection_26 (Q140257486) for all matching images on english wikipedia.

I'm a long time re-user of Wikipedia and Commons work and I have interacted with many other re-users. A major sticking point for them in re-using the content is reducing the risk of sharing NSFW images. Obviously nothing is going to be perfect as the very concept of NSFW (or other categories) is inherently nebulous and culturally dependent. But even a crude filtering mechanism would greatly help re-users. I often cannot even safely share a prototype without fear that I'll bomb them with something.

I recently learned of Wikimedia Commons content descriptor ( P14416) and I think humans populating that would be incredibly useful and is the best long-term solution to this problem. However, I'm working on (and aware of other projects in progress) that would benefit from results sooner. So I propose that we automatically populate content descriptors for the most re-used content (leading images on Wikipedia articles).

This process may also help human annotators as they can look for images flagged by the AI and not yet reviewed by a human. I further propose the AI annotation be removed once a human has taken a look.

I've done some sample edits on the bot already for you to examine (though those were not selected from enwiki because I wanted a sample that had a very high NSFW rate). Obviously the content is NSFW.

Bot's tasks for which permission is being sought:

Automatic or manually assisted: Automatic

Edit type: one time run

Maximum edit rate (e.g. edits per minute): 10k / day

Bot flag requested: (Y/N): Y

Programming language(s): Python. Code on github

I'm a prolific bot operator on Wikidata (where my bot has made almost 4 million edits), a former Wikidata admin and a long-time enwiki admin. I've successfully deployed ML driven workflows there.

BrokenSegue 03:36, 17 June 2026 (UTC)

Discussion

I do support the proposal in general, however, I'm not a Fan of the very granular Not Safe For Work according to Falconsai/nsfw_image_detection_26 (Q140257486). There should be very few in use, so filters to be implemented can use them adequately and easily. So, instead, I would suggest that the bot adds the same humans are expected to use like Sexualized nudity, erotica or ecchi (Q138829111) or any of the others mentioned as constraints of the property. The "Falconsai/nsfw_image_detection_26" part for me belongs into a quantifier (if at all), we usaually use determination method (Q88321276). --Schlurcher (talk) 16:46, 17 June 2026 (UTC)

so there are models that produce more fine grained classifications but they still won't perfectly align with the ontology we have created on commons. but a larger point is that I didn't want my effort to conflict with the human-driven effort. I know that work is already controversial and adding AI-powered classifications I think would make it more so. I suppose whatever extension/script they make could check the qualifier as you suggest, but that does seem like more work for them and possibly muddies the waters. would using "flagged as possibly sensitive by an AI" (or similar) work as the content descriptor (with a qualifier for the model) be acceptable to you? BrokenSegue 13:44, 18 June 2026 (UTC)

I'm not convinced that AI-powered classification need to separated, maybe other can comment on this topic here as well. If this should be done, I think the classifier should be broad (as you suggested), such that it can cover other and future models or bot requests as well. --Schlurcher (talk) 11:31, 22 June 2026 (UTC)

Could you create a gallery of around 1000 photos your bot would tag with the statement the bot would add to them? GPSLeo (talk) 15:11, 23 June 2026 (UTC)

I've produced a bunch of examples of the model output https://commons.wikimedia.org/w/index.php?title=Special:Search&fulltext=Search&search=User%3ABrokenSegue%2FNSFW&ns0=1&ns9=1&ns11=1&ns106=1

I can produce more if you want. Or more of a specific type of image. The majority of images are not NSFW and so just randomly sampling isn't interesting. BrokenSegue 15:47, 23 June 2026 (UTC)

The files you want to add a statement are all files with a score of zero or what threshold do you plan to use? In the test set at User:BrokenSegue/NSFW-Test there is not a single nude photo in the sample but many files with a score. I would like to see a set of 1000 photos where you would add the statement based on the model output to evaluate the amount of false positives. GPSLeo (talk) 17:23, 23 June 2026 (UTC)

ok. i will do that. i believe i set the threshold very high but i don't have it on me. BrokenSegue 19:31, 23 June 2026 (UTC)

ok here is a larger sample User:BrokenSegue/NSFW-Big. This took about an hour to generate. I understand you wanted 1000 positives but image downloads get throttled so I have to go quite slowly. I can do more if you want. BrokenSegue 00:25, 24 June 2026 (UTC)

Based on the false positives at User:BrokenSegue/NSFW-Test, most of the false positives seem to be text-heavy images such as newspaper scans. Adding a few hardcoded "this is not NSFW" categories to the bot's logic would likely reduce this issue. --Carnildo (talk) 21:08, 23 June 2026 (UTC)

sorry. that file is really unclear and hard to parse. I should probably stop linking to it. The only file in that set that would be classified as NSFW is File:Rachel Roxxx, James Deen on the set of eXXXtra 1.jpg. That was to demonstrate that the average image is not flagged at all. It's confusing because sorting by score doesn't properly sort it. BrokenSegue 00:06, 24 June 2026 (UTC)

ToprakBot (talk · contribs)

Operator: ToprakM (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: Cleanup: it will remove unnecessary invisible characters such as left-to-right (U+200E) or Byte order mark (U+FEFF), deciding they are not needed based on their location. In cases where these characters are needed or their necessity is uncertain, invisible characters will be made visible by replacing them with their corresponding HTML entity, such as "​" to "​". This allows editors to easily spot them in the source editor.

Automatic or manually assisted: Automatic

Edit type (e.g. Continuous, daily, one time run): probably daily

Maximum edit rate (e.g. edits per minute): something like 25

Bot flag requested: (Y/N): yes

Programming language(s): C#

This task is running on trwiki, azwiki. Source code is here. I am going to work on it to be sure it works perfectly on Commons. An example edit is here. --ToprakM ^✉ 21:20, 2 May 2026 (UTC)

Discussion

Why is this needed? --Krd 11:13, 8 May 2026 (UTC)

Hi @Krd. The majority of these characters are not added intentionally. They are usually copied from other sources and serve zero functional purpose. At least the ones I intend to remove. In severe cases, they can break templates, tables, and parser functions when accidentally pasted inside them. Since they are invisible, editors cannot figure out why a page or template does not work correctly. For example, a zero width space breaks the category link Category:​Topics. Additionally, a misplaced left-to-right or right-to-left mark can disrupt text rendering by causing unintended formatting. The bot will either remove them or make them visible in the source wikitext so editors can actually spot them. --ToprakM ^✉ 16:08, 8 May 2026 (UTC)

You provided an example where the character is in the file description. Is the removal relevant there, too? If not, I'd suggest to limit edits to files with these characters at relevant places. Krd 05:50, 9 May 2026 (UTC)

In my example, a left-to-right mark was placed between a word and a comma. While it might not visually break the page in that specific spot, such characters can confuse text rendering. Especially in mixed-direction environments, and they make source editing frustrating because the cursor behaves unexpectedly. Editors might accidentally copy and paste them into templates or categories where they will break things. I believe it is better to clean the wikitext comprehensively rather than limiting the bot only to places where the characters cause immediate, visible problems. --ToprakM ^✉ 17:13, 12 May 2026 (UTC)

I'd agree in most of other project, but how relevant is this at Commons? Krd 13:33, 16 May 2026 (UTC)

This is a task that I thought it would be helpful to run here. If you find it is unrelevant, that is fine. --ToprakM ^✉ 11:57, 18 May 2026 (UTC)

I didn't say yet how I find it, but you are requesting a bot flag for the task, so you perhaps should be able to show the relevance. Am I mistaken? Krd 13:43, 18 May 2026 (UTC)

You are right @Krd, but I don't have any points to add. To summarize, they has the potential to interfere with everything from the search function, text editing, to break templates and categories. It has no impact on the media and rarely in readability. --ToprakM ^✉ 15:26, 18 May 2026 (UTC)

I think this should not be done. Different opinions welcome. Krd 11:34, 25 May 2026 (UTC)

FlickrResourcesBot (talk · contribs)

Operator: DaxServer (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: Add {{Flickrreview}} template to files under Category:Uploads using Flickypedia so that the bot can add improve SDC (task 1) for those that pass review

Automatic or manually assisted: automatic

Edit type (e.g. Continuous, daily, one time run): Continuous

Maximum edit rate (e.g. edits per minute): 6

Bot flag requested: (Y/N): N

Programming language(s): Python, review integration at https://github.com/DaxServer/wikibots/pull/88

-- DaxServer (talk) 18:55, 16 April 2026 (UTC)

Discussion

• Here's a test run: -- DaxServer (talk) 18:55, 16 April 2026 (UTC)

they dont need review. RoyZuo (talk) 19:17, 16 April 2026 (UTC)

If they did, does it make sense to tag them for review instead of reviewing them right away? --Krd 05:54, 9 May 2026 (UTC)

@DaxServer:  ? --Krd 13:32, 16 May 2026 (UTC)

Hey @Krd Let me ask in COM:VP/C about this, I think that would be a better forum. Sorry for the delay, have too many things at my hand atm it seems. -- DaxServer (talk) 13:54, 16 May 2026 (UTC)

I've posted it on VP/C - Commons:Village pump/Copyright#Should Flickypedia uploads from Flickr be tagged for license review? -- DaxServer (talk) 13:00, 5 June 2026 (UTC)

AndrybakBot (talk · contribs)

Operator: Andrybak (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: replace {{Cc-by-3.0-us}} with {{Cc-by-2.0-fr}} in all pages of this search (15915 pages as of 20:53, 25 March 2026 (UTC)) per discussion at Commons:Village pump/Copyright/Archive/2026/03#Ukrainian pronunciation audio files. See also User:AndrybakBot/Tasks/Fixing license template for Ukrainian pronunciation audio files.

Automatic or manually assisted: semi-automatic editing using VisualFileChange (aka VFC)

Edit type (e.g. Continuous, daily, one time run): one time run

Maximum edit rate (e.g. edits per minute): whatever rate-limiting is builtin in VisualFileChange

Bot flag requested: (Y/N): Yes

Programming language(s): CirrusSearch search queries and regular expressions

Test run: 20 edits

—⁠andrybak (talk) 20:53, 25 March 2026 (UTC)

Discussion

Originally, I planned to use JWB for these edits, but turns out that JWB cannot handle pages with "Structured data"; plus, there are too many pages for JWB (at least in my experience of using it on enwiki). It is also too many edits for a regular account – using a bot account seems logical for this. Getting wider consensus wouldn't hurt too.

Per User:Jmabel, VFC is a good fit for this (Special:Diff/1175097428). I've tried VFC for the first time in these 3 edits. Its mode "Action: custom replace" seems intuitive enough. —⁠andrybak (talk) 20:53, 25 March 2026 (UTC)

VFC might be a bit slow for doing nearly 16,000 pages, though. That's about 5 or 6 times the largest thing I've done with it, and that was tedious. A true bot might be better. - Jmabel ! talk 21:32, 25 March 2026 (UTC)

I don't think that - Doing 1 replacements should be edit comments because it does not add anything to task description. EugeneZelenko (talk) 12:13, 26 March 2026 (UTC)

"Doing 1 replacements" is the part of edit summary that is automatically generated by VFC. —⁠andrybak (talk) 12:12, 28 March 2026 (UTC)

What is the status of this request? Please summarize. --Krd 07:53, 3 June 2026 (UTC)

@User:Krd: I submitted the request, User:Jmabel suggested that a different tool might be better for this bot, User:EugeneZelenko complained about the way VFC generates edit summaries.

I am waiting for an approval or a rejection of my request. —⁠andrybak (talk) 16:09, 4 June 2026 (UTC)

You can use an edit summary of your choosing when using VFC, if that is the issue. - Jmabel ! talk 17:34, 4 June 2026 (UTC)

The task appears valid to me, but I'm not sure if this should be done with a bot account when using VFC. Opinions on this? Krd 10:44, 5 June 2026 (UTC)

GinnyTheCatBot (talk · contribs)

Operator: GinnyTheCat (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: Transforming creator (P170) statements using some values to their appropriate Wikidata entry if one exists. A more detailed explanation is given on the bot's userpage.

Automatic or manually assisted: Automatic, supervised

Edit type (e.g. Continuous, daily, one time run): Currently daily, but in the future more rarely.

Maximum edit rate (e.g. edits per minute): 10

Bot flag requested: (Y/N): Y

Programming language(s): Rust

ginnyTheCat (talk) 00:50, 10 February 2026 (UTC)

Discussion

I'm currently unable to start the test run since the bots edits get blocked due to AbuseFilter 265 since the bot account is not autoconfirmed. What is the recommended solution for this case? ginnyTheCat (talk) 01:23, 10 February 2026 (UTC)

Now confirmed. Krd 07:22, 12 February 2026 (UTC)

Thanks a lot! I concluded the test run now. ginnyTheCat (talk) 14:09, 12 February 2026 (UTC)

Do such photographers meet Wikidata notability requirements? EugeneZelenko (talk) 16:25, 13 February 2026 (UTC)

That's a good question. The items already exist, the bot doesn't create them, but using them does make it more difficult to delete them in the future due to being in use, I agree. The list of photographers I currently have, I think, all meet the criteria by being people known for other things, being professional photographers, or even having newspaper articles written about them.

Also I'm not sure if It fulfils a structural need, for example: it is needed to make statements made in other items more useful. applies to SDoC as well or only statements directly on Wikidata, since otherwise it would cover this use case as well I think. ginnyTheCat (talk) 18:51, 13 February 2026 (UTC)

What about a compromise (for now)? If you have a list of photographers which already have their own Wikidata item and clearly fulfil Wikidata notability requirements (e.g. because the Wikidata entry contains several solid and reliable sitelinks as well as references to respected external sources), the bot could transform the creator (P170) statements using some values to their appropriate Wikidata entry. Presumably, hardly anyone would object to that; the P170 entries for their images would become clearer, and the work on the bot would not have been in vain. Later, in a broader discussion, possibly with Wikidata experts, it could be clarified whether the P170 statements of some lesser-known photographers should also be converted, and under what conditions. – Aristeas (talk) 10:21, 2 March 2026 (UTC)

Sounds good. ginnyTheCat (talk) 16:13, 12 March 2026 (UTC)

Please advise the exact criteria you implemented and please make another test run. Krd 06:23, 13 March 2026 (UTC)

@GinnyTheCat: : ? --Krd 16:02, 2 April 2026 (UTC)

When trying to form a set of criteria initially, I struggled with politicians or actors being creator (P170) of their own portraits. While this might be the case, I believe most of these photos are taken by a member of their team/professional photographer and the public figure just used their own Wikimedia or Flickr account to upload them, so they are only the uploader (if even).

I think this SparQL query is quite a decent set of candidates. On top of that I would exclude people with only one stub article, cases where I can't fully verify the connection to the account, public figures that are covered by the problem I described above or other cases where I'm not fully convinced that the mapping would be 1:1/lossless.

Many photographers on Commons that are in Wikidata are since they're mentioned in some authority database. I'm unsure if you would be ok with me including those in my set of criteria.

I apologize for responding so late. ginnyTheCat (talk) 16:29, 6 April 2026 (UTC)

I concluded another test run ginnyTheCat (talk) 18:29, 6 April 2026 (UTC)

I cannot follow where thhe information for Special:Diff/1192721339 comes from. Could you explain? Krd 04:00, 19 April 2026 (UTC)

Ofc, I feel like that one is one of the easier ones to verify. The Wikidata statement contains a source stating this. Other sources I used are CBS News and The Washington Post. There are probably more sources on his Wikipedia articles. ginnyTheCat (talk) 15:06, 23 April 2026 (UTC)

I have some feeling that this has implications with personality rights of the creators, perhaps not with the examples shown in the test edits, but when doing this at large scale. I'd personally need more time to think about this, additional feedback welcome. Krd 06:04, 9 May 2026 (UTC)

Yea, I appreciate your reviewing this so thoroughly. Even though the person-username link is already public on Wikidata, making this link more visible in this way does make it feel a bit odd. Especially since people often treat online accounts as different personas (like the WMF staff accounts here for example). Someone might not want their personal Flickr account to be representative of their image as a public figure, since it's just a hobby unrelated to their main job, they practise in their free time. But yea, I don't know either :/ ginnyTheCat (talk) 23:04, 9 May 2026 (UTC)

Would it make sense to obtain more feedback on this at maybe the village pump? If yes, please arrange it accordingly. Krd 11:58, 14 May 2026 (UTC)

@GinnyTheCat:  ? Krd 07:54, 3 June 2026 (UTC)