Lua error in Module:Tabular_data errors

I see lua errors in many category talk pages (e.g. Category_talk:Rennes/Views), related to User_talk:Dominic/2025#couple_hundred_new_lua_errors_on_view_tracking_pages. I would like to help fix these. This would help remove the pages from Category:Pages using the Chart extension with rendering errors. Do we want to convert them to historical data, like in Category_talk:Images_from_Gotlands_försvarsmuseum/Views or do we want to convert these to tabular data and have a chart for them? Aude (talk) 11:21, 25 July 2026 (UTC)

These page views were taken from the /mediarequests/ endpoint before Commons Impact Metrics, so I didn't delete them but they also can't just be added to the existing tabular data pages that are using page views, a separate metric. That's why I did the conversion at . I guess some of these were missed! I think the rendering errors category wasn't fully populated when I did this before. If you want to do this yourself, I'd be grateful. Or I can try to recreate the script myself. Thanks! Dominic (talk) 13:43, 27 July 2026 (UTC)

File:Deep Fried Oreos and Funnel Cakes stall 2 - Indiana State Fair.jpg

File:Deep Fried Oreos and Funnel Cakes stall 2 - Indiana State Fair.jpg has been nominated for deletion at Commons:Deletion requests/File:Deep Fried Oreos and Funnel Cakes stall 2 - I… 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 ∙ 中文 ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

A1Cafel (talk) 03:09, 26 July 2026 (UTC)

DPLA Bot

Hi, Dominic, Is there a reason why, for instance here, your bot reuploads unrotated photographs, that were rotated? Kind regards, --Lymantria (talk) 16:28, 27 July 2026 (UTC)

This looks to be part of a larger work in which other pages are landscape, as that is the original orientation. The bot is detecting a current upload version is out of sync with the source, and it gets replaced. Per COM:OVERWRITE, since the bot requires the unedited version to be present to detect changes, it is best to extract that file to a derivative that can be rotated and/or cropped (Commons:CropTool can also rotate and upload to a new file, I think) without changing the original archival version in context. Allowing the canonical version to be edited/rotated/cropped, etc. can cause other downstream issues, like being unable to detect a duplicate and re-uploading the original version. Dominic (talk) 17:25, 27 July 2026 (UTC)

Okay, thanks. --Lymantria (talk) 20:20, 27 July 2026 (UTC)

Shouldn't there be some way to mark particular pages to tell the bot not to do this? If you are going to download a work as a series of pages, and the pages do not all have the same orientation, surely it is still desirable that Commons be able to host each page at its appropriate orientation. - Jmabel ! talk 22:05, 27 July 2026 (UTC)

Rotating is not a violation of COM:OVERWRITE though. Maybe that needs to be tagged with {{Original}} (though the wording of even that may allow rotation). Carl Lindberg (talk) 11:34, 28 July 2026 (UTC)

@Jmabel: @Clindberg: Rotating is not, in general a violation of COM:OVERWRITE, but I was thinking about the specific instance where the orientation is actually in the archival original. There is a tension between the goal, on the one hand, of keeping media synced to the source, so we can pick up updates from the institution, and, on the other hand, allowing Commons users to alter the images in ways that cause them to fall out of sync. The bot logic only works if image edits are done under new file names. These are the kinds of edge cases that, at scale, can cause duplication issues that generate constant complaints. For example, consider the case where (1) original uploads are rotated or cropped, (2) an institution changes their identifiers so that uploads would go to a different file name, (3) now, all new duplicate uploads are generated for each altered file with the original crop/orientation, since the sha1 hash is not a match. Across millions of files, this can add up to hundreds of instances. It's a source of frustration for me as the operator because editors, reasonably, want the bot to be "smart" enough to work around situations like these, but then others want it to be "smart" enough to programmatically detect and prevent all duplication. Or, we can certainly introduce exceptions (e.g., whitelist SteinsplitterBot changes), but it is also increaseing the complexity of the bot code to maintain, and the potential edge cases that fall through. It's similar in some ways to an issue I just raised here, too. Dominic (talk) 17:12, 28 July 2026 (UTC)

One of the main reasons—some would say the main reason—Commons exists is to support the other WMF projects. No one wants (for example) a photo or map turned sideways in a Wikipedia article or such, and wherever this content is actually used in a sister project, that is the effect of the bot overwriting after a human has corrected the orientation. Presumably it is not a frequent event that a human has rotated an image that later is modified at the DPLA source and where consequently it is correct behavior to re-sync the image from the DPLA source. In other words, the vast majority of the times when your bot overwrites in this situation, it is wrong. If you are not going to either build in some sort of prevention, or take responsibility for follow-up yourself (or at least for a tool that makes follow-up easy), you are pushing the burden of checking this onto other Commons contributors.

One possible at least partial solution: whenever your bot overwrites, it adds a (new) maintenance category to that file page. That at least makes it sane to analyze how much of a problem this is, and (in particular) how often these re-uploads are corrections, rather than introducing errors. It might be useful to narrow this to when an overwrite replaces an X-by-Y pixel file with a Y-by-X pixel file, which should consistently be the case for such problematic overwrites. - Jmabel ! talk 17:43, 28 July 2026 (UTC)

Number of duplicates

Hi Dominic,

I think we agreed that DPLABot would cap the number of DPLA duplicates tagged in Category:Duplicate at 100, leaving some room for other bots (mine, for example, caps itself at 190). However, I currently count 193 DPLA files in the category.

Could you please take a look? Thanks! vip (talk) 15:57, 3 August 2026 (UTC)