Wikimore

A glitch

Looks like something went quite wrong with your recent bot edit at File:Seattle waterfront at Pier 4, ca. 1910 - DPLA - 885aa5020b31023925ce94b55e801b8d.jpg, including loss of ImageNotes. - Jmabel ! talk 04:38, 10 July 2026 (UTC)

In that file, and also in File:Tidelands SE from Occidental Hotel, ca. 1884 - DPLA - dcdd800c897fb9d1de321c352ae79db9.jpg (no ImageNotes there), my notes in the description got completely dropped. In both cases, my notes in the description are more or less incorporated by SPL's updates, so that is not disastrous, but I presume that the bot dropped the content without knowing that.

FWIW, normally when I see an edit summary like "Update description after title drift correction (DPLA ID dcdd800c897fb9d1de321c352ae79db9)" from a bot, I don't check the edit, because I assume it is just a bot doing something routine. Also, I don't necessarily watchlist every file I touch. Consequently, I might have failed to notice any number of similar errors by the bot. I'm definitely concerned that it may have killed ImageNotes on many other files, and somewhat concerned that in discarding my notes in the description for some files, significant content might have been lost. - Jmabel ! talk 05:05, 10 July 2026 (UTC)

I’ll definitely look more closely into this. I can already see the cause, since this looks like it’s after a rename. The “after title drift” is a different code path than the regular one, that is invoked when the file has to be renamed too (i.e. in the years since upload the name or ID changed). It’s different because in those situations we don’t preserve all the original data (e.g. the old DPLA ID and URL are wrong and need to be overwritten). It looks like the community metadata preservation code I built didn’t touch this flow. Luckily, everything is recoverable from the edit histories, and I’ll make sure to repair these. Dominic (talk) 11:04, 10 July 2026 (UTC)

Thanks. Looking more closely, there is info in my notes for File:Tidelands SE from Occidental Hotel, ca. 1884 - DPLA - dcdd800c897fb9d1de321c352ae79db9.jpg that did not make it into the SPL rewrite. - Jmabel ! talk 20:39, 10 July 2026 (UTC)

File:Ethel, ca. 1910 - DPLA - 4bea96f9f7d38804ad6f7038571a6169.jpg: my correction on the "Creator" info has been lost, and older content from SPL, now dropped, is misidentified as additional user-contributed metadata. - Jmabel ! talk 21:43, 10 July 2026 (UTC)

Thanks. I don't know if you're seeing my edits on the other examples, but I am testing a script that will run through all of these over again and rescue everything that was lost. I am just trying to test all possible cases still. Dominic (talk) 21:46, 10 July 2026 (UTC)

I take it that means I don't need to keep checking these one by one? That would be very welcome, because, to paraphrase Lewis Carroll, this is an awful lot of running to stay in one place. - Jmabel ! talk 21:54, 10 July 2026 (UTC)

This is one that has been rescued: File:Ethel, ca. 1910 - DPLA - 4bea96f9f7d38804ad6f7038571a6169.jpg. I will test some more cases, including everything you have given me, before running it across the whole set. Just wanted you to know I am working through it! But yes, if you can hold on for a day or two, I think I can take a pass on everything and then give you a summary of the result, so you don't need to keep checking for the time being, I don't want you to have to tak up your time with this. Dominic (talk) 21:58, 10 July 2026 (UTC)

Sorry, I meant for that link to be this one: . I'm looking at the others. Dominic (talk) 23:00, 10 July 2026 (UTC)

File:Greater White Fronted Geese in South Park pond, ca. 1890 - DPLA - ed99c4a1b626ff35d4dd9fd6e008cd8e.jpg lost an ImageNote and also lost my explicit indication of unknown photographer. - Jmabel ! talk 21:54, 10 July 2026 (UTC)

File:Helix, v.4, no.10, Oct. 10, 1968 - DPLA - c0c34376a3f9eab625c173e036b6238c (page 1).jpg lost my accurate information on who did the artwork here, inappropriately returning full "Creator" credit to the editor. Assuming that is a systematic error, that will come up heavily on Helix pages. - Jmabel ! talk 22:09, 10 July 2026 (UTC)

File:James St. and Yesler Way, 1880 - DPLA - dd06267e68254c9697fbda33fa5ca044.jpg lost all "other versions" info. I bet that is also a systematic error. - Jmabel ! talk 22:33, 10 July 2026 (UTC)

By the way: as you move away from having any of this in Wikitext, what are intended to be the correct ways, going forward, for someone to:

add to or contest the description?
refine, contest, or outright change the author info?
refine, contest, or outright change the date?

Also: I notice that for File:Tidelands SE from Occidental Hotel, ca. 1884 - DPLA - dcdd800c897fb9d1de321c352ae79db9.jpg, even your latest update fails to use {{Creator:Theodore E. Peiser}} or equivalent, it just gives his name. Jmabel ! talk 00:35, 11 July 2026 (UTC)

@Jmabel: The Tidelands photo actually looks correct for me. I think you just need to purge your browser cache. The way I have constructed {{DPLA metadata}}, all the regular wikitext parameters that have always worked in the templates we are migrating from can still be newly applied. Also, anu user-added statements in the SDC for the template parameter-based properties also render in the yellow box. Rather than make changes to the institutional metadata, the user's contributions sit alongside them now. This is the only feasible way to ensure we sync/update the instition's own metadata as it changes over time without accidentally overwriting the Wikimedia user contributions. It also is good for attribution of where the data is coming from. This means the "contest" or "outright change" parts of your question are made more difficult, admittedly. I think the the point here is that there is the wikitext parameters that afford Wikimedians the opportunity to call out corrections in free-text, so you can specifically reference the institutions metadata and state explicitly if your contribution is a correction. I tried to document all of these usage notes at Template:DPLA metadata/doc#Editing DPLA-uploaded files, but you're free to edit or provide feedback on that as well.

Aside from that, there is a real side opportunity here, which is that this allows us to surface the Commons user enhancements to the metadata. And that's a big reason I am doing this as well, because it means we can have a much easier time with data roundtripping, by actually being able to isolate and package up these changes to submit them back to the institutions for correction.

Right now I am running my first pass at a remediation script. Some of them take multiple edits because SDC and wikitext can't be edited together. There are thousands so I will check on its progress tomorrow. Thanks! Dominic (talk) 02:22, 11 July 2026 (UTC)

I haven't fully analyzed that, but two immediate questions:

In Template:DPLA metadata/doc The values appear in the yellow user-contributed box, alongside (or instead of) the DPLA-authored values: I don't follow "alongside (or instead of)". Obviously something determines which it is, "alongside" or "instead of", but the template page is unclear.
May I assume that even though it says pass one or more {{Other version}} calls, there is nothing special about {{Other version}}, and that applies just as well for {{Extracted files}}, etc.? You might want to reword to make that clearer.

Jmabel ! talk 02:34, 11 July 2026 (UTC)

That’s a good point. “Instead” is not currently accurate, though SDC does have a way to rank values, so I had been considering making this a possibility. I’ve been actively editing the template/module, so some of the documentation will need to be proofread again. And yes, theoretically you can put any templates inside the “other versions” field, I just wasn’t aware it was used for other templates like “extracted files”. I will update it! Dominic (talk) 02:43, 11 July 2026 (UTC)

Re: Creator: space, do I understand that you have no plans to integrate with that at all, and that the only way they can be added and maintained is user overrides? - Jmabel ! talk 02:45, 11 July 2026 (UTC)
Hm, it's not "no plans to integrate", per se, it's just that our source data does not already have Wikidata identifiers, or even a way to add them back in right now. It's on the road map, and maybe with some reconciliation it would be possible, but we also don't want to introduce data errors by putting a Creator pointing at the wrong Wikidata item, so that is why it's not possible right now. Dominic (talk) 20:46, 13 July 2026 (UTC)

@Jmabel: following up on the problems you flagged: I've now worked back through all the Northwest Digital Heritage records that bug affected and restored the community content it had dropped from what I can tell now (restoring ImageNote annotations, front/back {{Other version}} galleries, transcribed captions and editorial/dating notes, and community-curated categories). The process wasn't perfectly clean, it took a few tries. Feel free to spot-check a few and flag anything that still looks off or if I didn't get all the affected ones. A few examples of restored records: , , , , , . Dominic (talk) 20:46, 13 July 2026 (UTC)

All looking reasonable. I realize that we have two potentially conflicting goals to meet here (keep things sync'd with our sources, allow Commons editors to edit). At least in data terms this solves it moderately well. I'm still not sure it's an optimal solution in terms of presentation, but it's OK. - Jmabel ! talk 21:54, 13 July 2026 (UTC)

@Jmabel: Yes, it's a bit of a challenge, especially because humans act in non-standard ways, which makes it difficult to respect both goals sometimes (we need to overwrite the outdated institutional metadata each sync, without confusing the changes made by humans with the out-of-sync institutional metadata). I think there is most risk on the initial migration, but once all DPLA data is moved to the SDC, it becomes harder for a human to make changes that could be mistakenly overwritten, since our bot is only ever supposed to edit the SDC statements with DPLA references—which is part of the reason for migrating it all to SDC. In terms of the presentation, I think the data part was more the higher priority to come fist, but now we can continue to make changes to the presentation just by editing the template/module. I'm happy to iterate that over time. I appreciate your feedback! Dominic (talk) 22:05, 13 July 2026 (UTC)

bad changes

I do categorization work. This bot is making bad changes to the categorization of images--undoing my careful work. For example, look at the history of File:Heppner United Methodist Church, Heppner - DPLA - 7efbcd83689af0bd5caa71d1299bcea6 (page 1).jpg Thanks Hmains (talk) 02:27, 11 July 2026 (UTC)

convenience link: File:Heppner United Methodist Church, Heppner - DPLA - 7efbcd83689af0bd5caa71d1299bcea6 (page 1).jpg - Jmabel ! talk 02:48, 11 July 2026 (UTC)

If you look at the thread immediately above, I have been trying to gracefully fix some of the community edits that were overwritten in migrating templates previously. If you made edits in the meantime, between when the bot started to roll back its own edits to the previous state, then those new edits got accidentally rolled back too, as it was working off of a list of files. Rather than accidentally continue to revert-war, if you would be okay waiting a day, I will just run a sweep after this current batch of edits finishes to restore any Hmains edits that were overwritten. Thanks for letting me know! Dominic (talk) 02:33, 11 July 2026 (UTC)

I can't say that I understood the chain of comments you point out. I just thought I should mention what I saw. Not interested in war; not here for that. Thanks. Hmains (talk) 02:40, 11 July 2026 (UTC)

(talk page stalker) @Hmains: you sort of got caught in the cross-fire here. Dominic made some large bot edits that were basically sane but not fully thought through as to their consequences; he's now running more bot changes to fix those. I think he's probably on the right track, but he's having to have his bot recover some wikitext content it accidentally lost on that prior go-round, and it has to go back to older versions to pick up that content. When it does that, sadly, recent edits (from after that prior go-round) inevitably get lost. I'd recommend not trying to edit any of the DPLA stuff for another couple of days. After that, I think it should be OK. - Jmabel ! talk 02:55, 11 July 2026 (UTC)

Understood. Thanks Hmains (talk) 03:12, 11 July 2026 (UTC)

@Hmains: I ran a subsequent sweep to fix any edits of yours or others that got overwritten. See examples , , . Please let me know if I missed anything. Thanks! Dominic (talk) 17:11, 12 July 2026 (UTC)

Thanks, I will look around. Hmains (talk) 17:58, 12 July 2026 (UTC)

Files uploaded by Fæ

Hello @Dominic: .

Unfortunately, there is another batch of duplicate files, ones that @Fæ: uploaded to Commons years ago. We are facing this issue yet again. The DPLA needs to find a different way to handle this. I have no desire to delete user uploads from 2017 or earlier via a bot upload. Best regards, זיו「Ziv」 • For love letters and other notes 08:32, 12 July 2026 (UTC)

I forgot to mention: I won't be manually modifying the files from Fæ again, as I did with the last batch. by assigning them DPLA descriptions and moving them to the desired DPLA filenames. Instead, I simply delete the DPLA upload as the "newer" duplicate. זיו「Ziv」 • For love letters and other notes 08:42, 12 July 2026 (UTC)

Thank you. Just a reminder to anyone editing the millions of files I have worked on for many years, deleting the categories or text information from the file pages and substituting SDC fields that can break maintenance tasks is not acceptable. Adding SDC information is not controversial, and nobody has any objection.

There is no consensus to "erase, delete, blank, substitute" (by whatever pseudonym) plain text information on image file pages and the SDC is not a WMF guaranteed long term service. The last thing anyone wants is to make life more difficult for future volunteers or reusers that rely on the internal search to find content that may become effectively hidden by reliance on SDC and Lua transcoding. Fæ (talk) 09:08, 12 July 2026 (UTC)

Thank you very much for your detailed reply @Fæ.

As I (and a few others) already tried to explain in strange dupe-tagging, the DPLA upload isn't actually necessary at all.

File descriptions and reputable upload sources from other sites and institutions should be respected and do not necessarily have to be replaced by a DPLA description, because the DPLA has the same image in its collection.
File names that users assigned to their files years ago, and which were uncontroversial, should not be changed and do not require a DPLA ID number.

One solution would be as follows: as soon as the DPLA-bot detects an identical user upload for a given file, it tags the new upload as a duplicate. The file itself is placed on an "internal blacklist" from the DPLA so that the DPLA-bot does not upload it again. Consequently, neither the description nor the filename needs to be changed or adjusted. A DPLA version of the file is then not necessary. However, it would be helpful if the bot added the DPLA link under "other version" for such files, so that it is clearly evident that the file can also be found in the DPLA archive. Something like File:Angus F. Bartlett, Captain, Company H, 3rd Missouri State Militia Cavalry.jpg, or better, of course. זיו「Ziv」 • For love letters and other notes 09:39, 12 July 2026 (UTC)

That example '22412cd0994d36f03c4fcf549db2b8e5' raises additional questions. Why did the bot upload a second version of the same resolution but smaller file size 2 years later? Why did that second version match the filesize of the version I uploaded many years earlier? Not sure I want to be the one checking for root causes, however someone may wish to double check the SHA values from the API. There may or may not be 'digitally identical' duplicates as well as visual/colour/resolution duplicates. Admittedly this example appears fully identical, however if there were scans made at different times, or even different physical photographs made from the same negative, there could be reasons to keep other non-digitally-identical duplicates.

If the DPLA bot is creating duplicates with identical SHA values, that is very easy to fix and something the bot creator will no doubt retroactively fix if this has been happening for some time. I'm resisting the desire to investigate myself, there are more useful rabbit holes to spend time on.

Tip for mass uploaders - the IA has files that appear to have changed encoding over time, despite the identical file name. This means that an identical image or pdf might be a slightly different filesize and no different quality than one uploaded years ago. A simple SHA check may not be enough for the bot to act for hundreds of thousand of images at a time without more sophisticated measures. For my own code the IA ID is checked in addition to anything else, and duplicates with different file sizes and file names but using the same IA source are detected and skipped as a precaution against unnecessary duplicates. I suggest other large project maintainers take such cautious steps and test and test again before rolling out big changes. Fæ (talk) 09:52, 12 July 2026 (UTC)

@Fae: The technical answer—as to why it uploaded these files 2 years ago that are now being replaced with new, usually higher-resolution versions—is that we were uploading the files their IIIF image server gave to us at the time, and that for reasons unknown to me, those files have now changed in a way that matches these prior uploads. The prior uploads were not detected before, since they were non-identical. I don't have any direct evidence, but my guess is that they were previously had a limit imposed that was later removed. So this is not an attempt to roll out a big change, but to reduce the duplication. Dominic (talk) 16:55, 12 July 2026 (UTC)

It's not clear you have examined this example case. Neither of the 2 versions uploaded was "higher-resolution". The reasoning given here is untrue. This bot uploaded the same file twice, two years apart, on both occasions they were duplicates and this was not fixed. The bot should cease operating until this is tested and fixed correctly. Fæ (talk) 17:04, 12 July 2026 (UTC)

@Ziv: I may have misunderstood our prior conversation, but I thought we had already reached an understanding. Namely, in these situations with the more-established Fae uploads or equivalent cases, I already said I am happy for you to resolve these as you see fit, and if that means you are deciding to deleting the newer DPLA upload, that is fine. (The only thing I didn't do was change the code's logic for which file to apply the tag to, because I didn't think that you were asking for it.) I do still have an interest in cleaning up the duplication, but I don't have any problem with how you are handling it—so, just to be clear, please let me know if there is anything I should be doing differently.

I just want to clarify one thing, since you have mentioned "a DPLA version" as if one of our goals might be trying to get our own version or ID/metadata on Commons. Just to be clear, DPLA is a partnership that the Missouri Historical Society is part of, and I am doing this work together with their staff (who I also trained on editing Wikipedia to add their images). There is no such as a "DPLA version," they are providing their actual media and data directly to us, which is the whole point of this project: to add all the current media files and their data, which may have changed from other uploads that are almost 10 years old. Until we can't correct old metadata until we standardize them so we can actually detect a file reliably. None of this is motivated by trying to enforce a certain way of doing things or promote DPLA versions of images, just striving for accuracy. Dominic (talk) 16:55, 12 July 2026 (UTC)

"You saw the problem, you fix it"?

Please disable the bot until the problem it creates is fixed and has been convincingly tested as fixed. The bot is "misbehaving" and should be blocked if the operator is unwilling to handle this problem per COM:Bots. It is the bot operator's problem to fix past mistakes, nobody else should be spending their volunteer time doing this maintenance. Fæ (talk) 17:09, 12 July 2026 (UTC)

Fae, you are twisting words. I did not say that, and what I did say was in teh context of telling Ziv I am agnostic as to how the problem should be solved, just that I am happy to implement however he says so. You seem to reflexively think everything is is bad. What, specifically, are you asking for or calling misbehaving? I am trying to be responsive but instead of answering me you just keep saying it is misbehaving. The idea that no one else on Commons volunteers to help maintain bulk uploads is wrong, and you know it. The bot is emitting tags to reduce duplication ("the problem"), but you want to disable it until it? The bot cannot delete files, so that part, of course, does require assistance of Commons admins. Perhaps one could ask why your bot introduced data errors, such as mass-uploading files which say "Copyright undetermined" in their permission field—which the institution was not happy about when I met with them—and which my time is being spent trying to fix. But Commons is a collaborative project, and we recognize both your original contribution, and that no one owns files. What you are saying is self-contradictory, and I am not interested in arguing on a weekend. If you have something that needs to be fixed, please say so. Dominic (talk) 17:27, 12 July 2026 (UTC)

It is reasonable to expect the bot operator to repair mistakes and to analyse root causes, not expect other volunteers to do this for them. Here's the analysis I suggested above that I did not want to do. It demonstrates that the DPLA bot was, and still is based on the upload date of yesterday, overriding automatic duplicate warnings.

SHA1 from 2017 - 9719e05ab718aac6d400b239792ceeb45a766954 File:Angus F. Bartlett, Captain, Company H, 3rd Missouri State Militia Cavalry.jpg.

Analysis of the duplicate file history:

Timestamp | Contributing User | SHA-1 Checksum

------------------------------------------------------------------------------------------ 2026-07-11T06:00:00Z | DPLA bot | 9719e05ab718aac6d400b239792ceeb45a766954

2024-12-17T09:31:24Z | DPLA bot | 9639178e1cacf0ddddb51666dc94e0c07076e153

This demonstrates that the DPLA bot by design is ignoring API responses warning that the upload was a duplicate. Fæ (talk) 17:33, 12 July 2026 (UTC)

"If you have something that needs to be fixed, please say so."

The DPLA bot is uploading duplicates. Please fix it and disable the bot uploads until it is fixed. Fæ (talk) 17:34, 12 July 2026 (UTC)

Again, you are twisting things. These files were already duplicates in the sense that Commons cares about ("an exact duplicate or scaled-down version"). You can look at the prior version and see they are visually identical and were in that state for years. Making the upload did not change that (for the better or for the worse), it is just surfaced the existing issue and then tries to solve the issue identified by emitting a {{Duplicate}} tag. It is not ignoring the API warning, it is using it as a signal to follow a logic path to resolve the issue such that the duplicates are not left in place. Which is motivated by wanting to ensure one of the two is cleaned up—at which point it no longer matters whether two visually-identical files had a SHA1 match or not. That is what you claim to want. What is happening now is reparative. This is the fix, but you are still saying to disable it. If you have anything constructive to say about how the workflow could be improved, I am listening. Dominic (talk) 17:48, 12 July 2026 (UTC)

The "workflow" is easily improved. My uploads never ignore the API warnings of SHA1 duplicates, it is the default behavior of the system that such uploads are aborted.

Follow the standard workflow.

There is no excuse to upload SHA1 duplicates as an upload bot or manual upload needs to deliberately override the system's default behaviour. Just stop doing that rather than arguing that somehow this is desirable for Commons or our volunteer colleagues to be forced to respond to an indefinite number of duplicate uploads done by a bot that flags its own digitally duplicate uploads with a duplicate template rather than avoiding uploading the file in the first place by taking notice of the API warnings. Fæ (talk) 17:58, 12 July 2026 (UTC)

Sorry am I missing something. Is the DPLA bot not uploading duplicates since yesterday as shown in this example? My apologies if this is what "reparative" means in this case. Fæ (talk) 17:59, 12 July 2026 (UTC)

Can you not look at the prior file as I stated and see it is a pre-existing duplicate? You yourself said not all duplicates are SHA matches, which is what we are trying to fix, and now you seem confused by me agreeing this is a problem and tagging the 2-year-old duplicates. The upload yesterday is not what is creating the duplicate, as I think we all agree. It just happened to graft a SHA match onto a file that already needed to be removed as a duplicate, which is not creating any strain on volunteer resources. Dominic (talk) 18:20, 12 July 2026 (UTC)

This is incorrect. The new upload yesterday by the DPLA bot was the SHA1 duplicate (the "Analysis of the duplicate file history" could not be clearer).

The upload by the DPLA bot in 2024 was not a SHA1 duplicate and so would not have been rejected by the API. As such the 2024 upload was a "non identical" duplicate with a significant file size difference to the 2017 upload. Such non-identical duplicates are normal on Commons precisely because they are missed by the API. We have created housekeeping tasks in similar situations, such as for milhist / dvids uploads.

Regardless of other processes which might identify non-identical duplicates by checking ID numbers or similar, no automated upload process should allow files with identical SHA1 values to be uploaded. It is not just trivially easy to avoid, but it is a deliberate design decision to force an override of the API. Fæ (talk) 18:57, 12 July 2026 (UTC)

At this point, you are just upset that an upload went out changing our own file to a visually identical but slightly re-scaled version? An action that causes no actual strain additional work to volunteers (it’s getting requested for deletion either way). Just making sure I understand. Dominic (talk) 19:17, 12 July 2026 (UTC)

Could you read the facts please?

The DPLA bot uploaded a non-identical duplicate in 2024. That is a mistake but is *absolutely fine*. The correct way to find and fix those if necessary is to analyse the source references and unique IDs. In truth, you don't have to rush to fix those, they can be merged at any time and often might sit on Commons for years.

On Saturday the DPLA bot overrode the MediaWiki standard API message for SHA1 *identical* duplicates, which almost all bot uploaders would never do. This is easily avoidable, it actually takes extra work and extra design to ignore the API warnings.

The claim that this creates "no additional work" is weird when contrasted with the simple facts spelled out several times above. Fæ (talk) 04:16, 13 July 2026 (UTC)

Non-identical duplicates are undesirable, and I have heard this from most other editors besides you. That is the situation this process tries to fix. The exact same file (our own) that had an extra upload overwrite is the one we request deletion of, so it only exists in that state while sitting in the deletion queue. The bot intentionally does not have a path that would have done such an upload without a deletion request. It is, again, no more work for an admin to delete a duplicate at the same resolution as a slightly different one, so I don't understand what that specific aspect is such a concern. Most Commons editors I have spoken to do not agree with you about visually-identical duplicates being fine. Dominic (talk) 14:20, 13 July 2026 (UTC)

I no longer understand your responses. Please understand what I have written. There is a world of difference from fixing urgent things and looking to improve things which are not urgent.

No doubt you will sort all this out and stop designing bots which create identical duplicates which are trivially easy to avoid. There's no need for me to repeat the facts already laid out. Fæ (talk) 17:20, 13 July 2026 (UTC)

@@Ziv: For what it's worth, I reversed the directionality of the duplicate tags like the one you mentioned, and also in the code for the future. 02:01, 13 July 2026 (UTC)

Thank you. However, the goal should indeed be for the bot to produce fewer duplicates in the future, and not just when the old file relates to a user upload. No, files that the bot has already uploaded should also be recognized, so that these files would only need the new description and new DPLA ID. זיו「Ziv」 • For love letters and other notes 05:07, 13 July 2026 (UTC)

Before I forget, as a benchmark based on a database query, the DPLA bot created c. 9,000 digitally identical duplicates over the weekend depending on timezone. In 3 months over 120,000. The last 24 hours have seen no identical duplicates created, hopefully indicating that the standard API upload warnings are as useful as they are for other upload bots.

These numbers may be misinterpreted, for example it's easy to double count when running queries. Happy to be corrected if there are better measurements. Thanks --Fæ (talk) 18:18, 13 July 2026 (UTC)

If those numbers are accurate, that's a little worrisome. 120,000 redundant files averaging between 1MB and 10MB per file is between 120 GB and 1.2 TB of wasted storage, more if we also count the lower-res versions that were there before. I understand "storage is cheap", but even so (and especially if it is toward the higher end), that's enough to be worth some thought, especially if it is likely not to be a one-time problem. - Jmabel ! talk 22:06, 13 July 2026 (UTC)

Minor correction, though 'higher resolution' has been claimed before, the precise example above was an identical resolution and a slightly lower filesize. I am unclear why the claim was made giving an impression that the DPLA bot goal was better resolution when the case example did not support it.

BTW, counting over 90 days, this adds up to 472 GB. Fæ (talk) 05:20, 14 July 2026 (UTC)

Urgent stop request

Checking this morning, the DPLA bot has restarted mass uploading identical duplicates after a day off. Files like File:Yancey Williams, Class of 1944, Single Engine Pilots - DPLA - b70a721093cafea5c679e9db1bd8e116 (page 3).jpg are bizarrely creating multiple identical duplicates of its own prior uploads just seconds apart, overriding the standard API warnings and breaking conventions on approved bots. Avoiding these duplicates is trivially easy, the bot designer only needs to pay attention to checksum values or the rejection message on attempted uploads rather than overriding these failure messages.

In the last 24 hours the bot has uploaded 2,625 identical duplicates. The bot needs to be blocked if the operator refuses to stop these identical duplicate uploads.

@Jmabel: would you consider the evidence and advise, or does this require more eyes? Fæ (talk) 07:09, 14 July 2026 (UTC)

An interesting example. The DPLA lists the same image as "page 1," "page 2," and "page 3," even though there is no difference between them. While it is somewhat logical for the DPLA bot to upload the file three times, since there are indeed three pages. How does this happen? זיו「Ziv」 • For love letters and other notes 07:33, 14 July 2026 (UTC)

As these duplicates can be a bit hard to "see", Faebot is slowly populating Category:Digital duplicates uploaded by DPLA with duplicates uploaded in the last 24 hours but taking no other action. Thanks Fæ (talk) 08:24, 14 July 2026 (UTC)

File:James Barron's Patent Drawing for a Fan Moved by Mechanisms - DPLA - 7e865ff73427d8b3300325258d57f43e.jpg is also an interesting failure. In 2020 the file was identified as a duplicate and redirected. Less than an hour ago the redirect has been overwritten and created the same duplicate. This is undoing manual volunteer work done in 2020 assessing duplicates and removing them, by again creating the exact same duplicate that will require more volunteer effort to resolve.

Refer to the file log. Fæ (talk) 08:36, 14 July 2026 (UTC)

@Fæ: I think I should have pinged you much earlier; thanks a lot for this additional example.

The example here shows that the DPLA currently lists the same image under different IDs and with varying descriptions. James Barron's Patent Drawing for a Fan Moved by Mechanisms and Drawing of Fan Moved by Mechanism. However, the problem here lies not only with the bot itself but also with DPLA staff, who fail to notice when items exist as duplicates in the database. It is possible that this task is handled by a bot there as well. זיו「Ziv」 • For love letters and other notes 09:04, 14 July 2026 (UTC)

There seems a lack of any common sense judgement as to educational value per COM:Scope with these (identical duplicate) mass uploads. It is obvious that uploading scans of every page of documents, including blank cover sheets, is out of scope per "Files that contain nothing educational other than raw text." and have no educational value when the original pdf is linked in the records and could be uploaded instead if in total is of historic interest. It feels like the plan for how the massive collection of the DPLA archives can add value to Commons has not sufficiently been assessed, as well as the technical issue of identical duplicates being uploaded without corrective action taken. E.g. blank page, plain text page from a larger report seem both duplicates and out of scope.

It's rather depressing. Fæ (talk) 09:30, 14 July 2026 (UTC)

It is also worth considering {{DPLA duplicate}} which enables the DPLA to presume by design that Commons administrators will have indefinite time to continually delete entirely avoidable identical duplicates, rather than the bot not creating them. This is evidence of the bot misbehaving. There are 42,425 identical duplicate files that DPLA has created, waiting to keep administrators busy in Category:DPLA duplicates for deletion.

The "queue" Category:Duplicate has nothing but DPLA created identical duplicates in it, and presumably when empty will endlessly refill as there is no plan to stop the DPLA bot creating identical duplicates. This is fundamental bad design and against policy, the bot should be blocked until this is correctly redesigned. Fæ (talk) 12:40, 14 July 2026 (UTC)

The Category:DPLA duplicates for deletion was created at my request, as the bot had previously tagged several thousand items as duplicates all at once. On July 6th, there were only 3,000 files; however, if there are now over 42,000 files in there awaiting deletion, that is definitely too many. A solution definitely needs to be found as quickly as possible here so that the bot no longer generates duplicates, or generates almost none at all. זיו「Ziv」 • For love letters and other notes 12:52, 14 July 2026 (UTC)

Thanks for the context. Also raised at Commons:Village_pump#DPLA_bot pointing back here, as more eyes from affected volunteers on this mass creation of duplicates might help reach a consensus of what immediate action is needed. --Fæ (talk) 12:55, 14 July 2026 (UTC)

The bot is not currently uploading anything, and we can look more deeply. I don't understand why you think we would want duplicates. I am investigating each one, but it is not a singular There are several different things all going on:

In the past, a bug in place for a short time (maybe even a day) did create duplicates. This was fixed in the code, but left those ~40K files that I created Category:DPLA duplicates for deletion for. These are the Colorado State University images. The goal here is to fix the issue we caused, which is why I developed that system.
The bot also had some logic where it would not bother preventing the upload of a duplicate on a file it was requesting the deletion of anyway because it is already a visually identical/rescaled duplicate (this is what we were previously talking about). These were transitory duplicates, and aren't still on Commons.
Some NARA files, like this had a data issue where the same file was listed 3 times, and caused duplication by faithfully reproducing the data issue. This is the cause of the recent hundreds of duplicates a few hours ago. It is not something that has happened before, and can be prevented in the future, but I don't think it is a systemic issue that affects many items.

Let me know if there is anything else I should be looking into as well. Dominic (talk) 14:18, 14 July 2026 (UTC)

The solution has already been suggested. If the bot detects that an identical file already exists on Commons, it should abort the upload process and instead look for another solution, for example by adjusting a file description because it has changed and renaming the file, etc., or simply leave it alone and the problem will be fixed in a later update. זיו「Ziv」 • For love letters and other notes 14:27, 14 July 2026 (UTC)

@Fæ: I don't really bring anything special to this. On the whole, I think what Dominic is doing with DPLA bot is already a net plus, and the issue should be how to improve the process so the downsides are steadily reduced. I have no opinion either way on whether that should mean a pause at this time, or how long.

Question: on the files that have been identified as duplicates, do they need to become redirects, or can they just be deleted? (The latter is, of course, much simpler.) And, if the latter, are we confident that everything that has been tagged as such can be deleted without an admin needing to examine them again?

@Dominic: I realize that there is content where we really do want page-by-page files Category:Helix (newspaper) is a great example) but is there some way to identify content that would better be brought in as PDFs, and where images could be extracted on more of an as-needed basis?

(There are a lot of topics in the air at once here. If there was something else where someone wanted my thoughts/opinion, could you please single that out for me? I'm a little lost in some of this.)

Jmabel ! talk 18:42, 14 July 2026 (UTC)

Also: as I'm sure everyone active on this thread knows, there are times where a blank page that forms part of a sequence of pages is important, because if it is missing, users have no way to know why there is a missing page. - Jmabel ! talk 18:44, 14 July 2026 (UTC)

The source site I looked at had an easy export as pdf. The reports with lots of plain text and blank pages needs to be rethought out. Commons does not benefit from having every text page as a different image compared to a pdf which can even have a text layer embedded and the Commons search engine can identify matches in it. Fæ (talk) 18:51, 14 July 2026 (UTC)

File:Colorado Agricultural Experiment Station annual report 2000 - DPLA - 2b44759276f8404aa24a7d15d8032036 (page 1).jpg

File:Colorado Agricultural Experiment Station annual report 2000 - DPLA - 2b44759276f8404aa24a7d15d8032036 (page 1).jpg has been nominated for deletion at

Commons:Deletion requests/File:Colorado Agricultural Experiment Station annu…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 09:51, 14 July 2026 (UTC)

File:San Luis Valley Irrigation District bonds ($170,000) - DPLA - 2b557aeed302048b1cee8cfce8c238dd (page 41).jpg

File:San Luis Valley Irrigation District bonds ($170,000) - DPLA - 2b557aeed302048b1cee8cfce8c238dd (page 41).jpg has been nominated for deletion at

Commons:Deletion requests/File:San Luis Valley Irrigation District bonds ($1…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 09:58, 14 July 2026 (UTC)

File:Colorado Agricultural Experiment Station annual report 2000 - DPLA - de8be7623f910910cc6401fefd80a987 (page 28).jpg

File:Colorado Agricultural Experiment Station annual report 2000 - DPLA - de8be7623f910910cc6401fefd80a987 (page 28).jpg has been nominated for deletion at

Commons:Deletion requests/File:Colorado Agricultural Experiment Station annu…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 09:59, 14 July 2026 (UTC)

Usage of NoC-US template

The {{NoC-US}} template has been used as a default on an estimated hundreds of thousands of uploads like Legend 1965 - DPLA - 259d38c97f6628bbe3ce0b4e7f388289 (page 43).jpg. However the template is intended for files published before 1931. These should be corrected with an accurate copyright template, for example due to being DoD or other federal works after 1930. If you prefer we could raise a deletion request to establish a precedent. Thanks Fæ (talk) 10:18, 14 July 2026 (UTC)

That is not how copyright works. Something can be in the public domain for any number of reasons, such as ineligibility, non-renewal, no notice, etc., not simply pre-1931. The template is not being used "as a default"; it is the exact rights statement that the archivist applied to the image after doing a rights assessment. We are just copying it from the data source. Dominic (talk) 14:01, 14 July 2026 (UTC)

Then immediately STOP uploading works after 1930. Your approach is careless and no doubt has resulted in huge numbers of copyright problems downstream that unpaid volunteers are now expected to sort out for free for the DPLA. Fæ (talk) 16:35, 14 July 2026 (UTC)

No, I am saying that works from after 1930 can be in the public domain, and that's what the actual experts are there to assess. They have asserted it is in the public domain. Perhaps there was a copyright release from the donor, or it was published without notice or renewal, etc. There are a number of reasons to trust the archivist instead of trying to re-evanluate ourselves what an institution publishes about its own holdings. Dominic (talk) 16:51, 14 July 2026 (UTC)

Test that theory out by engaging with Commons:Deletion requests/Files in Category:The 1965 Lakota High School yearbook and explain exactly how this is public domain when there is no copyright release on record. Then engage with Commons:Deletion requests/File:Chefs des Nations Alliees dont le quartier general est en Grande-Bretagne (Chiefs of the Allied Nations are Headquartered in Great Britain) - DPLA - 0f2df271c8b1bfb5d9954fc11ae304f2.jpg and explain where the exact evidence is that this UK publication is public domain when there is no source information, but you can assure the Commons community that it's okay and the NoC-US license is all we need because, experts must be right. Fæ (talk) 17:02, 14 July 2026 (UTC)

You could even be right that the archivist was mistaken, and our source institutions do have a small error rate like any data source, but it would not be reasonable to stop all uploads of works after 1930—because that is not the only consideration. In the first example, it is more a question of copyright notice and renewal, or donor agreement, all things we rely on the institution for in making their determination. Dominic (talk) 17:28, 14 July 2026 (UTC)

Catalog errors happen (I encountered poor metadata when dealing with mass uploads from IA, from which a number of DR's was raised.) However, Expecting Commons volunteers to do biblographic research on items uploaded from a GLAM partner (who could be reasonably expected to have already undertaken it), is a big ask. It would of course be preferable to have accurate metadata at the source prior to upload (which is then copied into Commons.) ShakespeareFan00 (talk) 18:26, 14 July 2026 (UTC)

FWIW, I'm with Dominic and ShakespeareFan00 on this one. Unless we find over time that a GLAM has a high error rate about copyright status, we should generally assume that their diligence is as good as our own. - Jmabel ! talk 18:47, 14 July 2026 (UTC)

The case above is a UK publication. By definition the NoC-US template is inappropriate. Arguing that copyright was not renewed in the USA is nonsense.

The DPLA is flawed by assuming that everything it harvests without any review process from multiple original sources is published in the USA. If the DPLA insist on using NoC-US as a copyright statement, then it must restrict itself to US publications. Fæ (talk) 09:52, 15 July 2026 (UTC)

Notification about possible deletion

Some contents have been nominated for deletion at

Commons:Deletion requests/Files in Category:The 1965 Lakota High School year…

This is a deletion request for the community to discuss whether the nominated contents should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Affected:

File:Legend 1965 - DPLA - 259d38c97f6628bbe3ce0b4e7f388289 (page 1).jpg

And also:

Yours sincerely, Fæ (talk) 10:28, 14 July 2026 (UTC)

File:Chefs des Nations Alliees dont le quartier general est en Grande-Bretagne (Chiefs of the Allied Nations are Headquartered in Great Britain) - DPLA - 0f2df271c8b1bfb5d9954fc11ae304f2.jpg

File:Chefs des Nations Alliees dont le quartier general est en Grande-Bretagne (Chiefs of the Allied Nations are Headquartered in Great Britain) - DPLA - 0f2df271c8b1bfb5d9954fc11ae304f2.jpg has been nominated for deletion at

Commons:Deletion requests/File:Chefs des Nations Alliees dont le quartier ge…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 10:51, 14 July 2026 (UTC)

This bot removed metadata to replace it with SDC.

https://commons.wikimedia.org/w/index.php?title=File:Mr._Bryan_in_1899-%22I_Stand_Just_Where_I_Stood_Three_Years_Ago.%22_-_DPLA_-_9e31b287474bfea2ed2ca8f76a335ff7.pdf&diff=next&oldid=1229991405

If this was another less respected contributor it may have been considered "vandalism". However, I am concluding you are attempting to edit in good faith, with a degree of competence.

It would be greatly appreciated (as others have pointed out) if you temporarily suspend what you are doing, open a full discussion at the Village Pump, and gain a consensus on a co-operative way forward. I don't think migrating to SDC is a bad idea, provided it is done alongside retaining data other contributors have graciously provided.

I've also noted elsewhere: User_talk:Fæ#DPLA_bot_concerns that the SDC approach being used is more complex to query for the sadly inevitable glitches in metadata which will get copied across to Commons. Having previously had to clean up some uploads from IA (which were uploaded using a semi-automated approach), which had less than exemplary metadata (and processing), having the ability to scan wikitext for dates en-masse is incredibly useful in finding media which by dilligent consideration has been subject to the hopefully minor number of inevitable catlog gaps, omissions or erorrs. SDC is still a good idea, if it's accurate, and exists alongside conformable data in other readable forms.

Also to be noted:

I'd been previously advised that 'raster' image data, should not be uploaded as single page PDF. I am working on the assumption that it's use here was because that's what the archival source used supplied, over JPEG (which is lossy), TIFF or PNG?.

I'd also been previously "advised" (off wiki) not to remove existing wikitext data, adding any SDC (synchornised or not) alongside it.

ShakespeareFan00 (talk) 18:22, 14 July 2026 (UTC)

Yes, in this case the data in the old wikitext parameters is checked against the data in DPLA. The only data that was edited out is our own original data from the upload when it now is duplicative of the data stored in SDC. In cases where the community contributes, it is being preserved, like the categories and templates outside of the metadata template. In this case, the removal is for a purpose—we periodically update these files to sync the metadata whenever the institution updates it, which is a net value. That relies on being able to check the values of the properties in SDC, and for the template to display the SDC values directly. Looking at the original NARA catalog, it does look like they uploaded a PDF themselves. The bot code does not ever convert or modify the files themselves. Dominic (talk) 18:52, 14 July 2026 (UTC)

Do you have a process to point out catalog omissions and erors? ShakespeareFan00 (talk) 19:00, 14 July 2026 (UTC)

We know this is Public domain, by apparent date, but none of the catlog entries seen so far seem to record the original publication metadata. (It's not implausible they were not recorded for an 1896 political cartoon, but given that copyright records go back to around 1891, I would have expected the National Archives to be a bit more detailed.) ShakespeareFan00 (talk) 19:05, 14 July 2026 (UTC)

The template still takes user-added metadata. If you add anything to the template (or SDC) that is not matching the DPLA data, it will still render that in the template in a different user-added section. Let me know if you need help, but there is also documentation on the template page. Or, if you mean, to actually get it pointed out to the institution, there is a longstanding idea of using Commons edits to "roundtrip" data corrections back to the institution (and in fact, SDC makes this more feasible, since we can extract the user-added enhancements more easily!), but we're not currently doing any of that yet. Dominic (talk) 20:07, 14 July 2026 (UTC)

The SDC is not a WMF supported feature. Forcing volunteers to use it when there is no consensus for it guarantees that unpaid volunteers will not touch these files. Why should Commons regular volunteers be forced to spend hours learning how to navigate SDC field and wikidata systems just to change some dates or fix some text?

DPLA systematically deleting the file page text is actively reducing access, reuse and collaboration. Fæ (talk) 06:52, 15 July 2026 (UTC)

No one is forcing anyone to do anything, and it is not necessary to learn anything new. As I stated, the template takes parameters like other metadata templates. Dominic (talk) 13:06, 15 July 2026 (UTC)

So the standard Commons search works as before, and if I search my own upload projects for files changed by the DPLA with simple searches like "WW2 poster", they will be listed without me having to do any more work?

I have not fully tested this out, but if you can give a firm assurance that this is true, that's great. Fæ (talk) 13:18, 15 July 2026 (UTC)

Sorry, this turns out to be a mistruth, the DPLA is "forcing" users to restore the ability to search the text and restore original information on Commons files uploaded years ago. I presume because you do not know exactly what the DPLA has done? Could you please stick to facts as having repeatedly to disprove false statements wastes a lot of volunteer time.

In the case of File:A. P. Forbes (Union veteran).jpg, a file I uploaded in 2017, the DPLA has:

Put "DPLA" and "643c94ccda50aaf799940c9f84e53c5c" in the file name, despite this not being a DPLA upload.
Erased all the original useful wiki text that I original collated there for good searching. Like the subjects "A.P. Forbes, Civil War, 1861-1865, Grand Army of the Republic Ransom Post No 131, Rosch, ..."
The original archive identifier P0083-0356.
The most recent DPLA changes were on Monday 13th July 2026. As of the time of your statement above, this is the current file, with the automatic mass wiki text deletions.

As per Commons:Village_pump#Updates_on_handling_duplicates there needs to be a credible and tested plan on how to proceed, rather than continuing wrongly stating what has happened and the state of the files changed by DPLA.

Thank you for taking care to fix these mistakes. Fæ (talk) 13:56, 15 July 2026 (UTC)

The statement you are responding to, that the template takes parameters, is not a "mistruth", and I have no idea what you are talking about there. This file in question is not carrying the full DPLA bot because a sync was in progress on this exact set, which I paused. If you would like me to resume it on this file, I can. Generally speaking, this would resolve issues like the subjects not being the SDC yet. Dominic (talk) 14:13, 15 July 2026 (UTC)

The mistruth was "No one is forcing anyone to do anything, and it is not necessary to learn anything new". The example case demonstrates this is false, clearly.

The correction for the files moved and blanked by the DPLA without community consensus is to revert, rather than ploughing on. If you do nothing then the files in my upload projects will be reverted and restored to their original names. This will waste many hours of my volunteer time. It is highly noticeable that the DPLA has not made a statement about the damage that erasing the wikitext has already done for Commons searching, nor demonstrated that standard Commons searching is not damaged.

I have several times explained why blanking all the useful information and sticking information in SDC is not adequate. It would be great if this could be taken on board rather than talking around it without addressing the problem.

It would be really great if the DPLA could at least admit that it was wrong to take credit in the form of false SDC assertions that the DPLA contributed files to Commons when it was unpaid volunteers that uploaded the files several years earlier.

Thanks Fæ (talk) 14:23, 15 July 2026 (UTC)

I don't see putting data in structured form as blanking and I also don't see a libraries synchronizing their own data in a helpful way for images you uploaded from their own catalog as "taking credit". These are just things you can keep repeating, but I don't think the community is with you on that. What I do hear is that you disagree with the changes made to files you originally uploaded to look a certain way, and I am working to roll that back. They should be restored shortly. Dominic (talk) 19:08, 15 July 2026 (UTC)

How bizarre.

Above, this example was explicitly and literally blanking the original information that an unpaid volunteer added when the file was created years ago and definitely not adding the same information to SDC or anywhere else: "Erased all the original useful wiki text that I original collated there for good searching. Like the subjects "A.P. Forbes, Civil War, 1861-1865, Grand Army of the Republic Ransom Post No 131, Rosch, ..." To say this is not blanking data would be a lie.
Again literally, the DPLA project asserted that the DPLA "contributed media to Commons" when it never did, the upload was done years ago by an unpaid unaffiliated volunteer before the DPLA project had started. That statement via SDC is a lie.

It is a shame that these clearly unacceptable changes are being politically spun to try to make them appear "helpful". They are the opposite of helpful.

Thank you for working to revert errors that you created rather than expecting volunteers to do it. That's great. Fæ (talk) 22:33, 15 July 2026 (UTC)

File:Implementation of slope stability research - geologic profiles along I-70 and I-77 - DPLA - a0015c4581a9b65e9b57423776b4acbd.jpg

File:Implementation of slope stability research - geologic profiles along I-70 and I-77 - DPLA - a0015c4581a9b65e9b57423776b4acbd.jpg has been nominated for deletion at

Commons:Deletion requests/File:Implementation of slope stability research - …

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

ShakespeareFan00 (talk) 20:32, 14 July 2026 (UTC)

Courtesy notification:

In discussions elsewhere I had concerns about the DPLA bot approach, which you provided partial clarification for above:

However, another long standing contributor has identified a number of situations were the bot, performed actions on existing uploads: User_talk:Fæ#Files_moved_by_DPLA_that_are_not_DPLA_uploads, that were apparently not DPLA originated/

I appreciate that you want to synchronise data, but what was undertaken in good faith as 'synchronisation' might be seen by other contributors, as unjustified interference (at best), or depending on the contributor other less complimentary epithets (at worst).

As others have strongly suggested above, pause the bot, revert and resolve the identified conflicts, and DISCUSS before making further edits to the work of the other contributors uploads identified.

I can to some extent understand what you are trying to do, but Commons tends to work on Consensus and engagement, over 'bold' efforts by a bot, whose purpose might not be understood at first.

ShakespeareFan00 (talk) 08:36, 15 July 2026 (UTC)

When you say "not DPLA originated," I want to clarify that this type of rename only ever happened when the file was an exact SHA1 hash match (meaning exact duplicate, no user edits on the media file) to the file from the institution's catalog. In fact, the main reason I implemented this was not to touch human users' uploads at all, but because the duplicate detection frequently discovers on upload that a file is already uploaded by DPLA, but the title or ID drifted such that it is at the wrong file name. The solution there, to prevent duplication, is to rename the file rather than upload at all. Across a couple million uploads, this caught a few dozen user uploads that were also completely unchanged copies from an institution's catalog. It was not the main goal of this feature, and you can check that the main thing the bot was doing was renaming thousands and thousands of its own uploads that head dead IDs in the file name.

Having said that, when programming it, I honestly didn't anticipate anyone minding on the rare occasion a file such as that, taken directly from an institution and uploaded by a user, was encountered—we are simply offering a service by updating/correcting the metadata. Because that is the only intention here, is to facilitate institutions maintain the metadata on their own collections for the benefit of Commons, not actually trying to be "bold" or affect other users. To distinguish between bot uploads and human uploads would have been a design choice with extra logic. It certainly is possible to implement, though, and the bot is paused for a bit while I work on some other code changes. Dominic (talk) 13:03, 15 July 2026 (UTC)

Excluding US National Archives bot, 128 other uploaders were affected. It would be a nice courtesy if the DPLA retrospectively explained what happened to these volunteers, and what is being done to correct it. There are no automatic notifications. Fæ (talk) 14:12, 15 July 2026 (UTC)

Please collate 'works'

File:Four essays on the right and propriety of secession by southern states - DPLA - 1920c058e478313f8384c6d4a48e0fd1 (page 36).jpg and others.

Please collate obvious 'collections' of pages into categories, so they can be marked as {{Should be Document}} for attention by other contributors. ShakespeareFan00 (talk) 09:12, 15 July 2026 (UTC)

Having 'random' spread of pages, discourages contributors from interacting with resources you have undertaken effort in providing.

ShakespeareFan00 (talk) 09:12, 15 July 2026 (UTC)

Purge

The DPLA is not checking for zero size rendering after upload. Consequently there appear to be 23,000 files without proper thumbnails and will fail to return file info for maintenance tasks. Example File:CE 239 Copy of US Marine Corps Score Book issued to Lee Harvey Oswald - DPLA - 4a7ec8632f0d7d5b1f7cd16b570ef8c5.pdf. Fæ (talk) 09:35, 15 July 2026 (UTC)

Notification about possible deletion

Some contents have been nominated for deletion at

Commons:Deletion requests/Files in Category:DPLA uploaded pdf with one page

This is a deletion request for the community to discuss whether the nominated contents should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Affected:

File:David Addington Talks with United States Secret Service Agent at the United States Embassy Inside the Green Zone in Baghdad, Iraq - DPLA - d1083eef36bc8ffb8c672edea22c61c5.pdf

And also:

Yours sincerely, ShakespeareFan00 (talk) 10:20, 15 July 2026 (UTC)

File:CE 239 Copy of US Marine Corps Score Book issued to Lee Harvey Oswald - DPLA - 4a7ec8632f0d7d5b1f7cd16b570ef8c5.pdf

Afrikaans ∙ العربية ∙ беларуская (тарашкевіца) ∙ বাংলা ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ हिन्दी ∙ magyar ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ ქართული ∙ 한국어 ∙ македонски ∙ മലയാളം ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ српски / srpski ∙ svenska ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Hello, DPLA bot!

Thanks a lot for contributing to the Wikimedia Commons! Here's a tip to make your uploads more useful: Why not add some categories to describe them? This will help more people to find and use them.

Here's how:

1) If you're using the UploadWizard, you can add categories to each file when you describe it. Just click "more options" for the file and add the categories which make sense:

2) You can also pick the file from your list of uploads, edit the file description page, and manually add the category code at the end of the page.

[[Category:Category name]]

For example, if you are uploading a diagram showing the orbits of comets, you add the following code:

[[Category:Astronomical diagrams]]

[[Category:Comets]]

This will make the diagram show up in the categories "Astronomical diagrams" and "Comets".

When picking categories, try to choose a specific category ("Astronomical diagrams") over a generic one ("Illustrations").

Thanks again for your uploads! More information about categorization can be found in Commons:Categories, and don't hesitate to leave a note on the help desk.

ShakespeareFan00 (talk) 10:40, 15 July 2026 (UTC)

Copyright status: File:Britain Has Sent to Russia…Our Products Fight on Russian Fronts - DPLA - 66c8ac9de0e377888aea261d43095dd4.jpg

Copyright status: File:Britain Has Sent to Russia…Our Products Fight on Russian Fronts - DPLA - 66c8ac9de0e377888aea261d43095dd4.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 ∙ українська ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−

This media may be deleted.

Thanks for uploading File:Britain Has Sent to Russia…Our Products Fight on Russian Fronts - DPLA - 66c8ac9de0e377888aea261d43095dd4.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.

Fæ (talk) 12:21, 15 July 2026 (UTC)

Where NoC-US is definitely wrong, it seems easiest to use the no license template as this gives a user notice and has less impact on the volunteer community than a deletion discussion. If there is another standard process that is as easy as this one, let me know.

If the DPLA has a systematic plan to fix these copyright statements to something more credible than a USA statement for non-USA publications, let me know. Fæ (talk) 12:23, 15 July 2026 (UTC)

Requesting speedy deletion of files like this one in use on the projects, and in which the owning institution states it is in the public domain, is probably controversial, and it should be put up for debate. Dominic (talk) 13:14, 15 July 2026 (UTC)

Then by all means create the deletion requests. I shall stick to deletion requests from now on, per the DPLA preference. Fæ (talk) 13:20, 15 July 2026 (UTC)

Copyright status: File:The Voices of Freedom Live - Newspapers of the Allies Published in Britain - DPLA - cb62202118ed50f5e461cc1557d71232.jpg

Copyright status: File:The Voices of Freedom Live - Newspapers of the Allies Published in Britain - DPLA - cb62202118ed50f5e461cc1557d71232.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 ∙ українська ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−

This media may be deleted.

Thanks for uploading File:The Voices of Freedom Live - Newspapers of the Allies Published in Britain - DPLA - cb62202118ed50f5e461cc1557d71232.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.

Fæ (talk) 12:27, 15 July 2026 (UTC)

Copyright status: File:The Voices of freedom live. Newspapers of the allies published in Britain - DPLA - e0160ad69fa2bacda32652b2f4b86482.jpg

Copyright status: File:The Voices of freedom live. Newspapers of the allies published in Britain - DPLA - e0160ad69fa2bacda32652b2f4b86482.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 ∙ українська ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−

This media may be deleted.

Thanks for uploading File:The Voices of freedom live. Newspapers of the allies published in Britain - DPLA - e0160ad69fa2bacda32652b2f4b86482.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.

Fæ (talk) 12:27, 15 July 2026 (UTC)

Copyright status: File:Save the wheat and help the fleet - eat less bread. - DPLA - f0121d88ae58777980128dbe25dcd2e9.jpg

Copyright status: File:Save the wheat and help the fleet - eat less bread. - DPLA - f0121d88ae58777980128dbe25dcd2e9.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 ∙ українська ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−

This media may be deleted.

Thanks for uploading File:Save the wheat and help the fleet - eat less bread. - DPLA - f0121d88ae58777980128dbe25dcd2e9.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.

Fæ (talk) 12:29, 15 July 2026 (UTC)

Copyright status: File:British Weapons to Defeat Hitler - DPLA - 60fc07e23f31bd27efdad8872f722bc7.jpg

Copyright status: File:British Weapons to Defeat Hitler - DPLA - 60fc07e23f31bd27efdad8872f722bc7.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 ∙ українська ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−

This media may be deleted.

Thanks for uploading File:British Weapons to Defeat Hitler - DPLA - 60fc07e23f31bd27efdad8872f722bc7.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.

Fæ (talk) 12:30, 15 July 2026 (UTC)

Copyright status: File:The Downfall of the Dictators is Assured - DPLA - d39eadd84c37bedbeae0502bb7a26de6.jpg

Copyright status: File:The Downfall of the Dictators is Assured - DPLA - d39eadd84c37bedbeae0502bb7a26de6.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 ∙ українська ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−

This media may be deleted.

Thanks for uploading File:The Downfall of the Dictators is Assured - DPLA - d39eadd84c37bedbeae0502bb7a26de6.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.

Fæ (talk) 12:30, 15 July 2026 (UTC)

File:Britain Has Sent to Russia…Our Products Fight on Russian Fronts - DPLA - 66c8ac9de0e377888aea261d43095dd4.jpg

File:Britain Has Sent to Russia…Our Products Fight on Russian Fronts - DPLA - 66c8ac9de0e377888aea261d43095dd4.jpg has been nominated for deletion at

Commons:Deletion requests/File:Britain Has Sent to Russia…Our Products Fight…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 14:04, 15 July 2026 (UTC)

File:The Voices of freedom live. Newspapers of the allies published in Britain - DPLA - e0160ad69fa2bacda32652b2f4b86482.jpg

File:The Voices of freedom live. Newspapers of the allies published in Britain - DPLA - e0160ad69fa2bacda32652b2f4b86482.jpg has been nominated for deletion at

Commons:Deletion requests/File:The Voices of freedom live. Newspapers of the…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 14:05, 15 July 2026 (UTC)

File:Save the wheat and help the fleet - eat less bread. - DPLA - f0121d88ae58777980128dbe25dcd2e9.jpg

File:Save the wheat and help the fleet - eat less bread. - DPLA - f0121d88ae58777980128dbe25dcd2e9.jpg has been nominated for deletion at

Commons:Deletion requests/File:Save the wheat and help the fleet - eat less …

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 14:05, 15 July 2026 (UTC)

File:British Weapons to Defeat Hitler - DPLA - 60fc07e23f31bd27efdad8872f722bc7.jpg

File:British Weapons to Defeat Hitler - DPLA - 60fc07e23f31bd27efdad8872f722bc7.jpg has been nominated for deletion at

Commons:Deletion requests/File:British Weapons to Defeat Hitler - DPLA - 60f…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 14:05, 15 July 2026 (UTC)

File:The Downfall of the Dictators is Assured - DPLA - d39eadd84c37bedbeae0502bb7a26de6.jpg

File:The Downfall of the Dictators is Assured - DPLA - d39eadd84c37bedbeae0502bb7a26de6.jpg has been nominated for deletion at

Commons:Deletion requests/File:The Downfall of the Dictators is Assured - DP…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Fæ (talk) 14:06, 15 July 2026 (UTC)

File:Valentine from Lisa Quinn to President Dwight D. Eisenhower - DPLA - 8b65c35c99cbeb557426c19f1121e5a8.pdf

File:Valentine from Lisa Quinn to President Dwight D. Eisenhower - DPLA - 8b65c35c99cbeb557426c19f1121e5a8.pdf has been nominated for deletion at

Commons:Deletion requests/File:Valentine from Lisa Quinn to President Dwight…

This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

ShakespeareFan00 (talk) 18:39, 15 July 2026 (UTC)

Notification about possible deletion

Some contents have been nominated for deletion at

Commons:Deletion requests/Files found with intitle:dpla "ministry of war"

This is a deletion request for the community to discuss whether the nominated contents should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Affected:

File:Walk Short Distances - DPLA - a3fae6f54596a5a1459e0faccc9d9115.jpg

And also:

Yours sincerely, Fæ (talk) 11:13, 16 July 2026 (UTC)

How to add metadata?

File:Newspaper_clipping_aboutMotepublished_April_26,_1917_-_DPLA_-_19f1bcd724eff9df5c5d3f06049f9d22.pdf#{{int:filedesc}}

The template used by the DLPA bot doesn't support other_fields, meaning that, the 'simple' method for adding additional metadata was more difficult.

With {{Information}} the approach would have been simple. ShakespeareFan00 (talk) 12:09, 16 July 2026 (UTC)

You're right, that's a real oversight. I implemented the standard template fields, but let me see how other_fields works and add it to the template as well. Dominic (talk) 15:10, 16 July 2026 (UTC)

@ShakespeareFan00: Thanks for pointing this out (and transcribing the image!). It's a small change in the module and should be working now as you expected. Please feel free to test and let me know if there are any other nuances it needs tohandle. Dominic (talk) 15:41, 16 July 2026 (UTC)

The basic information could be kept in an Artwork template. As the plan, as far as I understand it, is for the DPLA to occasionally update small numbers of the files based on changes off-site, it's hardly any more work to update the Artwork template with the same data being changed as SDC fields. The key benefit would be that volunteers could still search for and edit fields in the standard and 'agnostic' Artwork template and the DPLA could have a task that judges if those volunteer changes get reflected in SDC later. Fæ (talk) 13:23, 16 July 2026 (UTC)

Collating single page uploads..

I've been trying to identify single pages of larger works:-

Category:DPLA_uploaded_pdf_with_one_page/Pages_for_collation

Any chance you could look into doing some of this automatically? @Fæ: might have some technical advice on how to do this, as they had previously attempted to match groups of images based on IA identification tags.) I sense there might be a regexp way of doing it for DPLA uploads, but.... ShakespeareFan00 (talk) 10:11, 17 July 2026 (UTC)

I understand what you are asking, but, as you have seen, every new functionality carries risk (both of not handling all edge cases, or not pleasing all editors). Detecting a single page PDF could be done on the server side prior to upload in order to use it during the upload process, though that also means it would have to be maintained continually by the sync process or else errors could be introduced. I think it is best not a bot task.

However, one thing that looks possible is that there is a file.pages attribute that could be used in the Lua module to detect the number of pages of a PDF/DJVU file, which means the template could emit a category automatically based on the value of that attribute to populate the category you made. Let me know if you want to look more into that. Dominic (talk) 15:44, 17 July 2026 (UTC)

I suggest liasing with @Fæ: as they had already previously made a harmonisation bot for IA uploads. They know more than I do on the technical side. ShakespeareFan00 (talk) 18:53, 17 July 2026 (UTC)

File:Lyman L. Hubbard, Class of 1945, Twin Engine Pilots - DPLA - dfde933db2e47e437ac96463a9fdd812 (page 2).jpg

The whole point of this redirect was because we are suppressing the duplicate files in NARA’s catalog with redirects. This logic is under some of the main reasons for redirects at Help:File redirect, “After merging two identical files (duplicates)“ and “To avoid having multiple copies of a file where we want to use different names for it in different contexts”. Since redirects are cheap, it does little harm to retain these. Dominic (talk) 14:31, 17 July 2026 (UTC)

Please check for strays..

I've attempted to collate certain files manually, but 2 or more seem to have gone missing in the process:- Category:DPLA uploaded pdf with one page/Lady Bird Johnson's Daily Diary Entry

Much apperciate if you could examine and ensure all related files are in the 'collection' category. Thanks. ShakespeareFan00 (talk) 08:56, 18 July 2026 (UTC)

Notification about possible deletion

Some contents have been nominated for deletion at

Commons:Deletion requests/Files found with intitle:/DPLA - 77a558ad91b360a4d…

This is a deletion request for the community to discuss whether the nominated contents should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Affected:

File:Report of Task Force Topsy - DPLA - 77a558ad91b360a4dea98123cc17302a (page 5).pdf

And also:

Yours sincerely, ShakespeareFan00 (talk) 10:56, 19 July 2026 (UTC)

Notification about possible deletion

Some contents have been nominated for deletion at

Commons:Deletion requests/Files in Category:DPLA - 953939a69a9d0dc41a98a7a12…

This is a deletion request for the community to discuss whether the nominated contents should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans ∙ العربية ∙ беларуская ∙ беларуская (тарашкевіца) ∙ български ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ বাংলা ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form) ∙ Zazaki ∙ ދިވެހިބަސް ∙ Ελληνικά ∙ English ∙ Esperanto ∙ español ∙ eesti ∙ فارسی ∙ suomi ∙ français ∙ galego ∙ עברית ∙ hrvatski ∙ magyar ∙ հայերեն ∙ Bahasa Indonesia ∙ íslenska ∙ italiano ∙ 日本語 ∙ 한국어 ∙ 조선말 ∙ кыргызча ∙ македонски ∙ മലയാളം ∙ Bahasa Melayu ∙ မြန်မာဘာသာ ∙ norsk bokmål ∙ Plattdüütsch ∙ Nederlands ∙ norsk nynorsk ∙ norsk ∙ occitan ∙ polski ∙ پښتو ∙ português ∙ português do Brasil ∙ română ∙ русский ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ shqip ∙ српски / srpski ∙ svenska ∙ ไทย ∙ Türkçe ∙ українська ∙ Tiếng Việt ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Affected:

File:Brazil's Roman Catholic Church - DPLA - 953939a69a9d0dc41a98a7a129da909c (page 17).pdf

And also:

Yours sincerely, ShakespeareFan00 (talk) 12:16, 19 July 2026 (UTC)

User talk:DPLA bot

A glitch

bad changes

Files uploaded by Fæ

Urgent stop request

Usage of NoC-US template

Notification about possible deletion

This bot removed metadata to replace it with SDC.

Courtesy notification:

Please collate 'works'

Purge

Notification about possible deletion

Copyright status: File:Britain Has Sent to Russia…Our Products Fight on Russian Fronts - DPLA - 66c8ac9de0e377888aea261d43095dd4.jpg

Copyright status: File:The Voices of Freedom Live - Newspapers of the Allies Published in Britain - DPLA - cb62202118ed50f5e461cc1557d71232.jpg

Copyright status: File:The Voices of freedom live. Newspapers of the allies published in Britain - DPLA - e0160ad69fa2bacda32652b2f4b86482.jpg

Copyright status: File:Save the wheat and help the fleet - eat less bread. - DPLA - f0121d88ae58777980128dbe25dcd2e9.jpg

Copyright status: File:British Weapons to Defeat Hitler - DPLA - 60fc07e23f31bd27efdad8872f722bc7.jpg

Copyright status: File:The Downfall of the Dictators is Assured - DPLA - d39eadd84c37bedbeae0502bb7a26de6.jpg

Notification about possible deletion

How to add metadata?

Collating single page uploads..

Please check for strays..

Notification about possible deletion

Notification about possible deletion