Jump to content

User talk:DPLA bot

Add topic
From Wikimedia Commons, the free media repository
Latest comment: 1 day ago by Ziv in topic strange dupe-tagging

strange dupe-tagging

[edit]
Latest comment: 1 day ago42 comments7 people in discussion

Hi DPLA_bot, today you (resp. your bot) has speedy-tagged a number of files as duplicates, which - wrt their content - are not duplicates at all.

and many more. Is this really intentional? --Túrelio (talk) 07:59, 20 May 2026 (UTC)Reply

@Túrelio: That bot only do shit at the moment, moving files like File:Ronald Reagan and Douglas Ginsburg.jpg, uploaded by User, Change the file description and deleted all categories. Adding or updating the file description might be acceptable, but renaming the file is rather questionable, as is deleting categories – totally unnecessary, yes, even vandalism. זיו「Ziv」 • For love letters and other notes 17:11, 20 May 2026 (UTC)Reply
Addendum: The license is now also incorrect. זיו「Ziv」 • For love letters and other notes 17:43, 20 May 2026 (UTC)Reply
Yes, I’ve been working on cleaning this up as soon as I realized. I appreciate your patience in allowing me resolve it. I undid all the duplicate tags that shouldn’t have gone out, and will sort out the rest, too. I understand this is frustrating, but it’s certainly not ill-intentioned. The bot runs at high volume. Dominic (talk) 17:49, 20 May 2026 (UTC)Reply
Thank you very much for your answer @Dominic. I don't know if there are any other files like the one I mentioned above; I just noticed just this one. If so, please correct them, thank you. Best regards, זיו「Ziv」 • For love letters and other notes 18:04, 20 May 2026 (UTC)Reply
Also, I didn't mean to be short above, just trying to work quickly. I want to give a fuller explanation later, but I can tell already that what happened was I had some test code I was working on that then ran overnight before I realized it was not the regular code. My first priority is just rolling back any unintended edits. Dominic (talk) 18:09, 20 May 2026 (UTC)Reply
same thing happened to File:Nancy Reagan waves while visiting the Statue of Liberty in New York City.jpg Surajr7 (talk) 18:21, 20 May 2026 (UTC)Reply
I agree about the renaming, why does the file name need to have the DPLA id in it? It just clutters the file name and makes it extra lengthy for no benefit. Traumnovelle (talk) 01:15, 27 May 2026 (UTC)Reply
@Traumnovelle: Thanks for asking! There are a few different benefits. One is that the institutions who provide these files are maintaining their metadata over time, and some times corrections or changes are made. The goal of our project is synchonize that dataset with the uploads on Commons so that they are also maintained here. Standardizing the image titles and metadata allows them to be maintained by bot. The only images the bot will touch are ones that are exact hash matches for the file from the institution's own catalog, meaning someone uploaded the file to Commons from the institution exactly as is. Sometimes they are uploaded here either with a title copied from Flickr, which wasn't really selected by the user anyway, and comes from the institution ultimately, or it might be a user-generated title which is sometimes not descriptive, and not trackable. I know what you mean about adding length to some file names, but it's not useless or for vanity, it's for a real purpose! Dominic (talk) 04:46, 27 May 2026 (UTC)Reply
@Traumnovelle: FWIW, working in categories with a lot of archival materials, I find it useful to know at a glance which ones came into Commons via DPLA bot. Sets my expectations very clearly for what will be the strengths and weaknesses of the metadata (in the broad sense of the latter). - Jmabel ! talk 14:31, 27 May 2026 (UTC)Reply
File names such as 'Woldruck - DPLA' would convey the same information in that regard. Traumnovelle (talk) 20:14, 27 May 2026 (UTC)Reply
There is more to it than that, though. There are over 10 million files from DPLA, so unique names are essential, and also the IDs are the only way would could associate them with the source metadata and maintain them. Dominic (talk) 03:53, 28 May 2026 (UTC)Reply
@Dominic i think you should make use of com:sdc instead of using the filename which is pretty damn useless and unimportant.
if necessary, make a new property like d:Wikidata:Property proposal/Flickr Photo ID did.
take a look at how flickr backfilled their metadata User:FlickypediaBackfillrBot.
https://commons.wikimedia.org/w/index.php?diff=1222566342 you removed some commons users' work, which is not from the institutions you are working for. that should be avoided. RoyZuo (talk) 09:08, 30 May 2026 (UTC)Reply
there's actually already DPLA ID (P760). you should write that to sdc instead of doing anything with filename which is a maintenance burden and not stable. RoyZuo (talk) 09:13, 30 May 2026 (UTC)Reply
@RoyZuo: Please add back any descriptions that the bot mistakenly deleted, like this was once the media of the day etc.. זיו「Ziv」 • For love letters and other notes 06:41, 7 June 2026 (UTC)Reply
Hey @RoyZuo and @Ziv, thanks for flagging this and for the fix on that one. You're right, it was a real regression: our new title-drift metadata-rescue code is preserving other user-added content like licenses, "image extracted" templates, categories, etc., but assessment-class templates like MOTD weren't accounted for and got dropped. I scanned all 11,588 of the bot's rescue edits since that code shipped on May 18, and this Chiang file was the only one that lost such a template — and Ziv had already restored it manually before I got there. The fix is now live (dpla/ingest-wikimedia#277) and covers Media of the day, Picture of the day, Featured/Quality/Valued picture, and the {{Assessments}} bundle going forward. Dominic (talk) 21:29, 7 June 2026 (UTC)Reply
a user contributed description in ukrainian. RoyZuo (talk) 22:17, 7 June 2026 (UTC)Reply
This is more complicated to parse out, but I am looking into it. Dominic (talk) 22:52, 7 June 2026 (UTC)Reply
@Ziv and RoyZuo: , just to follow up, I did a full sweep and found about 30 files that were affected. I have added them back in, with a series of edits like this one. Let me know if you see any other issues. Dominic (talk) 05:02, 12 June 2026 (UTC)Reply
@Dominic, looks good for me. Thank you. זיו「Ziv」 • For love letters and other notes 06:05, 12 June 2026 (UTC)Reply
@Dominic thx a lot for the recent update using sdc. it looks very neat.
one potential problem from your file moves. if a file is audio or video, it may have com:timedtext, which i think are not automatically moved. i'm not sure if your bot has accounted for this situation. if not, you might wanna check these files and move the timedtext accordingly. RoyZuo (talk) 16:57, 14 June 2026 (UTC)Reply

There are a couple of things going on here to explain:

  1. The {{Duplicate}} tagging wasn't working as intended, and is, of course, only intended for non-controversial exact duplicate cleanup. I reverted them all, but sometimes images do get uploaded twice when a title or ID changes, so I will go back and make sure no actual duplicates are left in place.
  2. Sometimes we try to upload from a partner and find out that a Wikimedian already uploaded it. Or that we uploaded it before under a different name. In these cases, we want to maintain the metadata and title, so there is proper information and attribution, It might have been uploaded 10 years ago with minimal description. What I was testing was how we could do that cleanly. Overwriting valuable info like categories and copyright templates was not intentional, and is a new insight when we do implement anything like this.
  3. This was all test code not intended to be run without monitoring. Some of it was even unfinished. I wouldn't normally test like that, and never have. Please let me know if you catch anything I didn't mention above. Dominic (talk) 18:31, 20 May 2026 (UTC)Reply
Sorry, but this is still inaceptable. Like File:David Addington, Lucy Tutwiler, and Katie Wilson Wearing Body Armor at Hakim Compound in Red Zone, Baghdad - DPLA - e259228a1ef65e5fe7223a6f841c2e39.jpg. Old file name was good enough. The DPLA number can be included in the file description, but it doesn't have to be in the filename. Please stop moving correctly named files. זיו「Ziv」 • For love letters and other notes 20:21, 22 May 2026 (UTC)Reply
Addendum: Overwriting valid licenses is also a problem here. Originally, this was a Flickr upload with the license {{Flickr-no known copyright restrictions}}, now we have {{PD-US}}, which states that the image is not in the public domain in some countries, which was previously the case. The correct license should be {{PD-USGov}}. The bot should check which files it has inserted an incorrect license into and adjust them accordingly. זיו「Ziv」 • For love letters and other notes 21:54, 22 May 2026 (UTC)Reply
I hear why you’re frustrated, so I just want to clarify a few things. The bot is operating under the direction of the National Archives itself. Whatever they previously uploaded to Flickr is not as authoritative as the current metadata and identifier. We are only touching files that are exact hash matches for the file in the current NARA catalog. When one is detected, I am renaming it to provide the accurate current title, metadata, and identifier, and link to the new catalog. Most of these are many years old. I am doing our best to do it the right way, such as leaving redirects in place and using the User:CommonsDelinker process so no links are broken. If there is a PD-USGov template, it is retained. The Flickr tag is not necessary or helpful for a file which is directly copied from the official catalog, and the Flickr-no known copyright restrictions doesn’t really add anything, certainly not somehow worth retaining over the exact copyright statement from the institution does. Dominic (talk) 22:22, 22 May 2026 (UTC)Reply
Okay thank you. זיו「Ziv」 • For love letters and other notes 05:39, 23 May 2026 (UTC)Reply
Hello @Dominic:
For your information: I added the Category:Files exempt from duplicate tagging to both files File:(Sherman case docket) - DPLA - 2e9d3ca5d4c772d9e3da903fe4812265 (page 1).jpg and File:(Sherman case docket) - DPLA - 2e9d3ca5d4c772d9e3da903fe4812265 (page 12).jpg. Otherwise, OptimusPrimeBot would recognize them as duplicates again and tag them accordingly. This prevents them from being deleted again. Best regards, זיו「Ziv」 • For love letters and other notes 16:04, 24 May 2026 (UTC)Reply
Same also for File:(Sherman case docket) - DPLA - 2e9d3ca5d4c772d9e3da903fe4812265 (page 2).jpg & File:(Sherman case docket) - DPLA - 2e9d3ca5d4c772d9e3da903fe4812265 (page 13).jpg זיו「Ziv」 • For love letters and other notes 16:22, 24 May 2026 (UTC)Reply
Unfortunately, it's happening again that the bot is now marking older user uploads as duplicates. Example: File:Advertisment for the St. Louis and St. Clair Ferry, July 4, 1842.jpg. That shouldn't happen. זיו「Ziv」 • For love letters and other notes 17:24, 21 June 2026 (UTC)Reply
Plus also a batch that tagged duplicates like this File:Distribution Department, Low Service Spot Pond Reservoir, verso, "height of camera objective - 6.5 feet; note that a rise of water level will expose a new but excellent front", Ston - DPLA - 01e81012a2a12fa66704075773b08b0c.jpg. זיו「Ziv」 • For love letters and other notes 17:41, 21 June 2026 (UTC)Reply
@Ziv: There's a lot of edge cases that keep cropping up because I am trying to manage a backlog of maintenance on files, some of which are many years old. Thanks for bringing File:Advertisment for the St. Louis and St. Clair Ferry, July 4, 1842.jpg to my attention. Here's the complicated path: (1) In 2017 Fae uploads this file, (2) Back in 2024, DPLA_bot uploads this exact same item, but for whatever reason (they are visually identical, so it wasn't a bug per se), the MHS image server at the time was serving the same image at a different resolution, so there was no duplicate collision, (3) today, the bot is re-running this collection and MHS's image server is back to giving the file it gave Fae in 2017, (4) since we can't move the old file to the new correct name, where a file already exists, the bot overwrites the version at the desired title and tags the old one as duplicate. The part of this that went wrong is there is supposed to be a path that rescues categories and other user contributions, but it didn't trigger here. This already works in other situations, such as when a hash duplicate already exists on Commons without the presence of a file at the desired title (like this). What I am going to do is kill the ongoing process, fix the bug to ensure the categories and templates are copied over before duplicate tagging in this type of situation too, and then apply that to the ones that were already tagged, so they can still be safely deleted. Dominic (talk) 19:10, 21 June 2026 (UTC)Reply
Also, the second issue with the template breaking is a situation where the file name has the = character, breaking template syntax. A simple escaping bug that can be fixed like this. I will apply the fix in the code as well. Dominic (talk) 19:24, 21 June 2026 (UTC)Reply
All of the bad = templates were fixed, like so. Dominic (talk) 20:37, 21 June 2026 (UTC)Reply
@Ziv: There were about 40 files, I think all from Fae, where the older contributions, such as categories, have been rescued. But ultimately, in these cases, tagging the older file was correct, since the corrected title with the DPLA ID already has a file at it; where two files exist, meaning the situation can't be resolved with a file move, one needs to be deleted be and should be the one at the wrong name (as long as user contributions are being preserved, as it all has been now). Dominic (talk) 20:37, 21 June 2026 (UTC)Reply
@Dominic: Thank you very much for the quick solution. However, I am not entirely satisfied for files uploaded by Fae or other users years before the DPLA bot uploaded a identical file. I liked the way you handled, for example with File:Nancy Reagan Waves While Visiting The Statue of Liberty in New York City - DPLA - 27f33ae983dc977c6096f75934bd706d.jpg. Renaming the files may be controversial, but user uploads should definitely be retained. Best regards, זיו「Ziv」 • For love letters and other notes 08:40, 22 June 2026 (UTC)Reply
@Ziv: Right, that would be my goal as well. The issue here is that there is both a file previously uploaded at another name and a file already at the new file name. Let me know if you have a better idea I can implement, because I am happy to work on it. The most straightforward way I think we could handle this that deletes the newer file over the older file but still achieves the desired file rename would be to upload the duplicate file to the desired file name for the purpose of then immediately tagging it as as a duplicate—which I think would cause some confusion as well. And then I'd still have to come back later and re-run them all to actually do the renames once the existing file was deleted. Or, and this also seemed a little controversial to do on my own initiative, I could move the existing file to a temporary name, which would allow me to move the old file over the new redirect, and then tag the file at the temp name as a duplicate (so I don't have to do a second run). That would be the optimal, in a way, though it would look messy to anyone who didn't understand what we're doing. Dominic (talk) 14:17, 22 June 2026 (UTC)Reply
Lemme show you something on File:Advertisment for the St. Louis and St. Clair Ferry, July 4, 1842.jpg. The bot now only needs to rename the file. זיו「Ziv」 • For love letters and other notes 20:20, 22 June 2026 (UTC)Reply
If that's a good idea, then I can handle Fae's other uploads the same way. זיו「Ziv」 • For love letters and other notes 20:22, 22 June 2026 (UTC)Reply
Or i can move the files to the DPLA name myself. Then you have absolutely nothing left to do. זיו「Ziv」 • For love letters and other notes 20:26, 22 June 2026 (UTC)Reply
Dang! Sorry for the copy paste error... But you see what I'm getting at. Because there aren't that many. זיו「Ziv」 • For love letters and other notes 20:31, 22 June 2026 (UTC)Reply
Did now the same with File:A.F. Bullard, Captain, 38th Massachusetts Infantry (Union). - DPLA - 249b96450fce5f80ca03d997111fd6ea.jpg, without producing a double extension. זיו「Ziv」 • For love letters and other notes 20:48, 22 June 2026 (UTC)Reply
Hello @Dominic.
Even without waiting for your reply, I continued working on this today. I really don't see why user uploads and version histories are being destroyed here just because DPLA thinks "only we have the right file and the right filename." In that sense, I will continue to add the DPLA description to the uploads and adjust the filename accordingly, but that doesn't mean that just because there's an exact duplicate in your database, other databases are useless. Regards, זיו「Ziv」 • For love letters and other notes 23:24, 23 June 2026 (UTC)Reply

Rename speed

[edit]
Latest comment: 8 days ago4 comments2 people in discussion

Can you limit the speed of the bot moves? It is filling the User:CommonsDelinker/commands/filemovers at impossibly fast speed and I worry that it would be hitting maximum page size limit if not enough attention is guaranteed in a short period… (which often doesn't get one for hours) — regards, Revi 10:40, 16 June 2026 (UTC)Reply

Also, it somehow seems to me that the bot is posting to /filemovers even if the file being moved has 0 Special:GlobalUsage (i.e. Special:GlobalUsage/Remarks by President Ronald Reagan during reception for the Trilateral commission. East Room. - DPLA - c2a827167d0de5d8ee3363f8d5705d7a.mp3). If this is true, please stop the bot immediately and ensure it only posts for COM:CDC/filemovers when there is actually any usage. — regards, Revi 10:52, 16 June 2026 (UTC)Reply
I am killing the upload batch that was triggering these. I hadn’t really considered checking for usage before posting there. Let me think though how to do that. Dominic (talk) 12:34, 16 June 2026 (UTC)Reply
@Revi C.: Previously, I designed this with the thinking that CommonsDelinker would handle the task of finding any actual file usage and de-linking only those. I wasn't thinking about any other costs you have raised. I worked on some code to verify against GlobalUsage before actually posting a request to CommonsDelinker, as you suggested. I will let the current requests drain before re-testing it live on a batch that has a lot of page moves to do, like that Benjamin Harrison Presidential Site collection. Sometimes this happens where every file has changed due to something structural, so it's a lot all at once. In this case, I think that institution entirely changed their web site and all their identifiers, and also hadn't been synced en years, so that is why suddenly every file encountered was a rename. But most files are not actually used, as you correctly note, so when it is re-run, I expect only a small percentage would actually need CommonsDelinker. Thanks! Dominic (talk) 16:12, 16 June 2026 (UTC)Reply

New Duplicate batch

[edit]
Latest comment: 8 days ago3 comments2 people in discussion

Hello @Dominic.

I noticed that the bot tagged a lot of duplicates. I've already deleted a few of them and created the redirect. However, I noticed that the wrong file was probably tagged, for example: File:Emily Jane Staley Baumeister, Pullman, Washington, circa 1900 - DPLA - f019f6ed3ae830df1c3342b19d4e915c.jpg, link works to https://dp.la/item/f019f6ed3ae830df1c3342b19d4e915c. Bot tagged to File:Emily Jane Staley Baumeister, Pullman, Washington, circa 1900 - DPLA - 4424b724c4725421a083db8f7dd81378.jpg (older upload) link: https://dp.la/item/4424b724c4725421a083db8f7dd81378 (Page not found). Please correct this. I have now stopped deleting duplicates; for files that I have now deleted, the bot should simply change the file description and name. Best regards, זיו「Ziv」 • For love letters and other notes 13:34, 16 June 2026 (UTC)Reply

@Ziv: Yes, thanks for that. This is intended, but let me explain. I need to resolve an error where—in the past—the bot was not correctly renaming files where the title changed, and uploaded a duplicate version instead. Some of the older versions are may years old, and their IDs or title has been changed by the institution, breaking links. Even though the new version has the correct metadata, my preference is to delete the newer version so I can re-run the corrected code on the old files and they will get their file names renamed and all their links and metadata corrected, while preserving the original edit history and any contributions made to them by the community over those years. Hope that makes sense! Dominic (talk) 13:54, 16 June 2026 (UTC)Reply
@Dominic:
Thank you for your detailed explanation. I'll go ahead and delete duplicates now. זיו「Ziv」 • For love letters and other notes 13:57, 16 June 2026 (UTC)Reply

Copyright status: File:Bat, Baseball, Sally Ride - DPLA - 4d22ddc2bb67b8dbace85b06b49649ee (page 3).jpg

[edit]
Latest comment: 6 days ago1 comment1 person in discussion

Copyright status: File:Bat, Baseball, Sally Ride - DPLA - 4d22ddc2bb67b8dbace85b06b49649ee (page 3).jpg

العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ English ∙ español ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ हिन्दी ∙ hrvatski ∙ magyar ∙ italiano ∙ Indonesia ∙ 日本語 ∙ ಕನ್ನಡ ∙ 한국어 ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ norsk bokmål ∙ norsk nynorsk ∙ norsk ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ svenska ∙ ತುಳು ∙ Türkçe ∙ українська ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−
Warning sign
This media may be deleted.
Thanks for uploading File:Bat, Baseball, Sally Ride - DPLA - 4d22ddc2bb67b8dbace85b06b49649ee (page 3).jpg. I notice that the file page either doesn't contain enough information about the license or it contains contradictory information about the license, so the copyright status is unclear.

If you created this file yourself, then you must provide a valid copyright tag. For example, you can tag it with {{self|GFDL|cc-by-sa-all}} to release it under the multi-license GFDL plus Creative Commons Attribution-ShareAlike All-version license or you can tag it with {{self|cc-zero}} to release it into the public domain. (See Commons:Copyright tags for the full list of license tags that you can use.)

If you did not create the file yourself or if it is a derivative of another work that is possibly subject to copyright protection, then you must specify where you found it (e.g. usually a link to the web page where you got it), you must provide proof that it has a license that is acceptable for Commons (e.g. usually a link to the terms of use for content from that page), and you must add an appropriate license tag. If you did not create the file yourself and the specific source and license information is not available on the web, you must obtain permission through the VRT system and follow the procedure described there.

Note that any unsourced or improperly licensed files will be deleted one week after they have been marked as lacking proper information, as described in criteria for deletion. If you have uploaded other files, please confirm that you have provided the proper information for those files, too. If you have any questions about licenses please ask at Commons:Village pump/Copyright or see our help pages. Thank you.

This action was performed automatically by AntiCompositeBot (talk) (FAQ) 19:08, 18 June 2026 (UTC)Reply

Files that now use the {{DPLA metadata}} template.

[edit]
Latest comment: 2 days ago9 comments4 people in discussion

Good morning @Dominic: .

While deleting duplicates, I noticed that some files now have the template {{DPLA metadata}} instead of a complete file description. This made me wonder what happens if a user decides to crop the image and upload it as a new version, perhaps to remove a distracting frame or to crop a single person. And that's exactly what I did with File:St. John high school class, St. John, Washington, 1952 - DPLA - ed7c1321cfcf84324824e25c7a66c17c.jpg and reduced the image to three students. File:St. John high school class, St. John, Washington, 1952 - DPLA - ed7c1321cfcf84324824e25c7a66c17c (cropped).jpg. As I correctly suspected, the file description and license were not transferred to the cropped version; this is completely empty. This is not intended and can lead to problems. Best regards, זיו「Ziv」 • For love letters and other notes 06:50, 21 June 2026 (UTC)Reply

I forgot to mention that I had already cropped images from the DPLA bot before. Example File:Steinitz, William-4 - DPLA - 9eeab9ac335135c24b69ab7e36fc5354 (cropped).jpg, everything worked perfectly here, as the original file uses the {{Artwork}} template. זיו「Ziv」 • For love letters and other notes 07:29, 21 June 2026 (UTC)Reply
Further update: As expected, the file has now been tagged by @AntiCompositeBot: because a license is missing. I understand the idea behind {{DPLA metadata}}, it makes your files less maintenance-intensive, but if the template for derived works doesn't work properly, then it's completely unsuitable. I'd rather have more edits from DPLAbot, but users still have the option to create derived works without having to search high and low, possibly having to manually add their own templates and licenses. זיו「Ziv」 • For love letters and other notes 08:13, 21 June 2026 (UTC)Reply
Awesome! Thank you so much.
Understood. This is definitely an unintended situation. It's not an error by the bot, but certainly an undesireable interaction with the CropTool. We didn't invent the idea of template metadata pulled from SDC. For example, User:GeographBot has already been doing it for far longer. I tested how those are handled here, and it also loses most of its SDC when run through CropBot, the main difference being that its copyright license seems to be hardcoded so it doesn't get flagged by AntiCompositeBot. I think there is a solution here, but I need to work through the Lua. For example, if File:A is extracted from File:B, is it possible for Module:DPLA to fallback on File:A to File:B's SDC on any fields where they are blank? That would be the solution that works for both the bot workflow and the users using CropTool. Dominic (talk) 20:49, 21 June 2026 (UTC)Reply
@Ziv: I was able to get it to work as I was hoping, via Lua. You can see on your test file. No further edits were made to that file's SDC, but it is emitting the SDC from the {{Extracted from}} file as a fallback (until any metadata is added directly on the file, which would take precedence). This means all CropTool files that copy the template will work natively, as long as the linkage through {{Extracted from}} is kept in place. Dominic (talk) 01:11, 22 June 2026 (UTC)Reply
Dominic! You did it exactly the way I imagined and was hoping for. Yes, I'm familiar with GeographBot. I also once cropped a file uploaded by that bot. I had the same result as you. However, I then went and added the missing information myself. Perhaps your solution would also be something for @Multichill: , who runs the GeographBot? Anyway. Thank you so much for fixing this. Great job! Best regards, זיו「Ziv」 • For love letters and other notes 08:05, 22 June 2026 (UTC)Reply
Maybe on the extracted file consider a "subst" so that the wikitext gets populated, instead of relying on a different file's SDC? - Jmabel ! talk
@Jmabel: The Lua module can only affect the template display, but not make an actual edit. The issue here is that these are uploads being made by CropTool (via user accounts), not DPLA bot. DPLA bot has no knowledge of these files and isn’t maintaining them, since it also doesn’t really k ow what the user has cropped the images to and if it would be accurate to continue syncing the original metadata to it. The template is designed so that using wiki text parameters will override the SDC fallback. But actually hardcoding it by bot would need to be done on the CropTool side. Or we could run a periodic scan for these, but that is a lot of architecture and still leaves them in the state they are in now in the interim anyway. Dominic (talk) 19:48, 22 June 2026 (UTC)Reply
CropTool has been under continuous active development lately, so it's plausible that side could be addressed. Doc James, any thoughts? - Jmabel ! talk 23:37, 22 June 2026 (UTC)Reply
Sure will ask User:Bawolff to add support for this work flow if possible. Doc James (talk · contribs · email) 00:57, 23 June 2026 (UTC)Reply
Retrieved from "https://commons.wikimedia.org/w/index.php?title=User_talk:DPLA_bot&oldid=1237216608"