Commons:Village pump/Proposals

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2022/06.

Please note

One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
Have you read the FAQ?

Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

Adding alt texts through structured data[edit]

The alt texts are a feature for accessibility, they are a text for people who can not see the photo itself. In the Wikipedias it is possible to add the alt text when adding a file to the article. On Commons we do not have a standardized way to add an alt text to a file. This proposal proposes to add an additional field similar to the captions field where alt texts in multiple languages can be added. How this is used in the Wikis has to be decided by the Wikis.

In short: "The Commons community asks the SDC development team to add a structured data text field (like the caption field) for multilingual alt texts."

Discussion (alt texts)[edit]

Prior discussion

Resources on alt text

The following remark is, perhaps, redundant to prior discussion, but is repeated here because I think it addresses (at least in part) the objection by User:Glrx below: Alt texts are language-specific, so each property-value should always have a language as a qualifier, using language of work or name (P407). This is already how Wikidata property used as "depicts" (P180) qualifier on Commons (Q70564278) works. - Jmabel ! talk 22:57, 26 May 2022 (UTC)[reply]

I think it would make sense clarify a bit that:

This would be a general-purpose default/fallback alt text. Obviously, we cannot store alt text hand-tailored for use in specific contexts.
This proposal is only about making it possible to enter and store this on Commons (that involves developers working on StructuredData)
Making the stored alt texts usable at the local projects is another matter (that would probably involve developers working on other parts of Mediawiki). But it seems obvious that established alt text syntax should override the default/fallback stored at Commons: [[File:foo.jpg|thumb|description|alt=specific alt text]]

--El Grafo (talk) 08:34, 2 June 2022 (UTC)[reply]

@Jmabel: I would have thought that a language-tagged text datatype (like MonolingualTextValue used by title (P1476)) would be more appropriate than a mandatory qualifier. Is there a good reason not to use one? bjh21 (talk) 21:09, 11 June 2022 (UTC)[reply]

@Bjh21: Just trying to parallel how we use Wikidata property used as "depicts" (P180) qualifier on Commons (Q70564278), which seems to me to be the most similar existing property. - Jmabel ! talk 23:12, 11 June 2022 (UTC)[reply]

Also: the idea with title (P1476) is that you may want to use (for example) the title in its original language even in the context when you are otherwise working in a different language. That consideration doesn't apply to alt text. - Jmabel ! talk 23:16, 11 June 2022 (UTC)[reply]

Previous proposals on Wikidata for a monolingual text property: Feburary 2017 (not done), November 2017 (not done), February 2021 (still unresolved). There is also a ticket in Phabricator. - Nikki (talk) 15:15, 30 June 2022 (UTC)[reply]

Votes (alt texts)[edit]

Support --GPSLeo (talk) 18:36, 26 May 2022 (UTC)[reply]
Oppose For the reasons given multiple times when a property for this purpose has been discussed on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 26 May 2022 (UTC)[reply]
Would you please link to some of these discussions on Wikidata? Peaceray (talk) 23:38, 26 May 2022 (UTC)[reply]
Discussions (from 2017) are here and here. Karl Oblique (talk) 10:40, 27 May 2022 (UTC)[reply]
There is also d:Wikidata:Property proposal/alt text from last year and still unresolved. - Nikki (talk) 15:02, 30 June 2022 (UTC)[reply]
Oppose. The proposal is compound and confused. I support accessibility and the addition of alt text. I oppose locking in a specific approach such as Wikidata or structured data. Wikidata labels and descriptions have translations, but Wikidata does not translate the property data. The properties should be language-independent. The properties should also be structured; alt text would be both opaque and atomic rather than structured. Glrx (talk) 19:14, 26 May 2022 (UTC)[reply]
The alternative for using the tools Wikibase provides would be to create a total new feature in MediaWiki or a new extension. I do not see why the needs for alt texts should be different to them for the captions. --GPSLeo (talk) 06:37, 27 May 2022 (UTC)[reply]

Support. — Jeff G. ツ_{please ping or talk to me} 22:20, 26 May 2022 (UTC)[reply]

Support - Jmabel ! talk 22:45, 26 May 2022 (UTC)[reply]

Support I am slightly confused by the relationship between Commons and Wikidata. As far as I can tell, Commons runs a separate instance of wikibase, the software? In that case, the decision is somewhat easier because the alt text is a core attribute for image files. On Wikidata itself, I can sort-of see how it deviates from orthodoxy. It would be most similar to the descriptions, in that it is multi-lingual free-form text entered by users (as opposed to copied from a reference). There are properties that are free text and multi-lingual ("first sentence" for books etc) and many involve some subjective reasoning by users, but rarely both. Still, I would support it even on Wikidata and believe if it is required to make it work for commons it would be looked at somewhat more favorable than before. Karl Oblique (talk) 10:53, 27 May 2022 (UTC)[reply]

I think you got it right: the alt text would of course not be stored at wikidata, but here on Commons in the StructuredData that is attached to every file. El Grafo (talk) 07:51, 2 June 2022 (UTC)[reply]

Oppose - Alt text is language dependent, so to hold alt texts here on commons (or on wikidata) would require alt texts for all languages. In addition, if done propoprly, alt texts should be context specific, depending on how the image is used. Alt texts should be produced locally, not imposed.Nigel Ish (talk) 14:19, 28 May 2022 (UTC)[reply]

That you think we should not have generalized alt texts for cases where no individual alt text was set is okay, but that the feature should allow alt texts in all languages (like at the captions) in clearly written in the proposal. --GPSLeo (talk) 16:31, 28 May 2022 (UTC)[reply]

So how is this different that the thirteen different language captions I currently see available for a media file? Peaceray (talk) 04:35, 2 June 2022 (UTC)[reply]

It would be similar, but content-wise alt texts need to be written in a different way - especially when it comes to things like graphs and diagrams. A caption would normally just give you the general subject and context of an image, the rest you can see for yourself. But since an alt text is for people whom for one reason or another, cannot see the image, it needs to describe the content in much more detail - to the point that it would be considered ridiculously redundant to someone who can see it. El Grafo (talk) 08:14, 2 June 2022 (UTC)[reply]

My understanding is that that like many infoboxes derived from Wikidata, the alt text parameter would be override-able. In practice, we already do this today with the default caption currently generated by the "Use this file on a wiki" function. Peaceray (talk) 04:43, 2 June 2022 (UTC)[reply]

Yes, the proposal is really not very clear about this, even though we discussed that at the Village Pump recently. It would need to be treated as a general default/fallback alt text that is only shown if no more specific alt text is specified when a file is being used. So when using [[File:foo.jpg|thumb|description]] the default alt text stored at commons would be shown in the user's language, but when using [[File:foo.jpg|thumb|description|alt=specific alt text]], the specific alt text hand tailored for the specific context would override that. El Grafo (talk) 08:03, 2 June 2022 (UTC)[reply]

Support As the 2017 discussion on Wikidata was summed up, It might be relevant to propose it again once structured data is available on Commons. Stuctured data is here, let's put it to good use with this. Peaceray (talk) 04:47, 2 June 2022 (UTC)[reply]
Support offering(!) general alt texts on Commons as a default/fallback. Using StructuredData for this would make a lot of sense. If and how that would be deployed to the local projects is another matter that probably should be discussed elsewhere. --El Grafo (talk) 08:44, 2 June 2022 (UTC)[reply]
- In this edit the above vote was removed without explanation, I restored it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:05, 30 June 2022 (UTC)[reply]
Support excellent! -KH32 14:44, 30 June 2022 (UTC)[reply]
Strong support Using structured data on Commons is a good way to edit, optimize and watch growing alt-texts directly at the media. API gives new possibilities of providing alt-texts also for small Wikipedias. Content specific alt-texts and usage in all Wikimedia-Projects like written above are the next steps. Conny (talk) 14:43, 30 June 2022 (UTC).[reply]
Support, per El Grafo's reasoning above. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:07, 30 June 2022 (UTC)[reply]

File usage on openstreetmap.org, The following page uses this file[edit]

In addition to the listing "File usage on Commons" a listing "File usage on openstreetmap.org" would be very useful from my point of view. Especially to be able to take this into account for deletions.

Example: https://commons.wikimedia.org/wiki/File%3ABeobachtungsturm_Strengsee%2C_Seitensicht.jpg Use not recognizable: https://www.openstreetmap.org/node/3094456337#map=18/52.35720/12.69014 — Preceding unsigned comment added by Molgreen (talk • contribs) 05:07, 11 June 2022‎ (UTC)[reply]

Support to enable listing of all InstantCommons uses. — Jeff G. ツ_{please ping or talk to me} 05:59, 11 June 2022 (UTC)[reply]

I do not think that this is technically possible. The only way to do something like this would be a bot going through the OSM database and adding a template to the file page. --GPSLeo (talk) 06:43, 11 June 2022 (UTC)[reply]
Thanks for your feedbacks. Yes, I had already thought of a bot that searches for "wikimedia_commons" in the OSM database. Then perhaps the link of the parent note (example here: https://www.openstreetmap.org/node/3094456337#map=18/52.35720/12.69014) could be determined and the necessary link to the file (here: File:Beobachtungsturm Strengsee, Seitensicht.jpg) is also available. It would only be necessary to find someone who would have time to implement this . . . — Preceding unsigned comment added by Molgreen (talk • contribs) 09:00, 11 June 2022‎ (UTC)[reply]
I think having such a bot edit the file page would be disruptive: people get annoyed enough at watchlist notifications for changes to structured data; notifications for changes to the usage of a file would be even worse. But a bot could maintain a user gallery or several that contained files used in OSM, and those would appear in the list of local uses.

However, I would then wonder why this should be limited to OSM. Other sites can use Commons images, either through InstantCommons as Jeff mentions, or by just recording URLs in a database (e.g. MusicBrainz). Do we in principle want to know about all external uses? Or maybe just ones in free-content projects? --bjh21 (talk) 10:16, 11 June 2022 (UTC)[reply]
I agree a bot scanning file links to deleted or rename files would be useful but this is nothing to discuss here this is a topic for the OSM forums. It is also a question if direct linking of the files is needed. Most objects in OSM where a photo makes sense do have a Wikidata item where the photo is linked. --GPSLeo (talk) 10:49, 11 June 2022 (UTC)[reply]
From my point of view, it would be interesting to record all uses. But that should be very controversial (I suspect)? OSM is a special project for me. I would even call it a partner project. I am meanwhile in both worlds (Wikiversum and OSM) on the way and think that with OSM similarly high quality standards apply as in the Wikiversum. --Molgreen (talk) 10:58, 11 June 2022 (UTC)[reply]

@GPSLeo: To be clear, I did not suggest a bot scanning file links to deleted or rename files. As you say, such a bot and the question of whether the wikimedia_commons key should exist at all, are both matters for the OSM community. My suggestion was of a way to implement what Molgreen proposed without spamming people's watchlist. --bjh21 (talk) 11:02, 11 June 2022 (UTC)[reply]

Comment To give an idea of scale, OSM taginfo says there are 67,390 distinct values of the wikimedia_commons key on OSM at present. --bjh21 (talk) 10:22, 11 June 2022 (UTC)[reply]

Hello bjh21, this is very interesting. Thank you for the link! (There is still much possible . . .) --Molgreen (talk) 11:02, 11 June 2022 (UTC)[reply]

(I mean the use "wikimedia_commmons" is apparently only at the beginning. Hopefully still very much develops). --Molgreen (talk) 11:24, 11 June 2022 (UTC)[reply]

Further comment I've written a trivial script to convert data from Overpass into a gallery and created User:Bjh21/files used on OSM containing files referenced by OSM in and around London. This means that if you visit File:Halfway II Heaven, Trafalgar Square, WC2 (3614629275).jpg, for instance, that gallery appears in the list of uses of the file. I think I could fairly easily run a bot to maintain a collection of such galleries for the whole world if there were a consensus in favour of that. --bjh21 (talk) 11:37, 11 June 2022 (UTC)[reply]

@Bjh21: That is a very elegant solution and I can see it being very useful, both for us and for our OSM colleagues. Woudd there be some way to display the results on a map, also? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:45, 11 June 2022 (UTC)[reply]

@Pigsonthewing: I could probably arrange to add maps, but that's a lot more complicated and not really within scope. If you want you can get the same set of objects on an interactive map by typing wikimedia_commons~"^File:" into the overpass turbo Query Wizard. --bjh21 (talk) 20:01, 11 June 2022 (UTC)[reply]

@Bjh21: Thank you very much! A great solution from my point of view as well. The key thing here is that the usage is automatically displayed on the file page. This works great. One question: what are the chances that the solution will be implemented permanently and for all these files? --Molgreen (talk) 17:45, 11 June 2022 (UTC)[reply]

@Molgreen: From a technical point of view I don't think there's anything stopping me implementing this. I've tested it without the geographical restriction and the Overpass query runs in a couple of minutes, generating a 4 MB wiki page with 42,000 pictures on it. I'd probably want to carve it up into smaller subpages, but doing that and wrapping it up into a bot that runs daily or weekly would be easy. The only likely obstacles are organisational. I'd like to allow for some more opinions here so I can be confident we've got some kind of consensus. Then I'll go through the procedure for getting permission to run a bot. --bjh21 (talk) 20:55, 11 June 2022 (UTC)[reply]

@Bjh21: It would be very nice if that would work. Either way, thanks again for your effort up to here. --Molgreen (talk) 15:45, 12 June 2022 (UTC)[reply]

I have requested permission to run a bot to do this: Commons:Bots/Requests/Usage Bot. --bjh21 (talk) 15:31, 19 June 2022 (UTC)[reply]

Support in principe, if it's technically possible. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:08, 30 June 2022 (UTC)[reply]

New Wiki Product[edit]

Hello,

I write today as I have an idea for a new Wiki service. Called "Wiki Archives" its main purpose would be preserving artifacts like Documents and Photos that others might not seen in saving. Wikimedia Commons is a great service, but I believe that some of what's in it should be split into this new product. When you search for something, you can find pictures in like old building plans and old photos which should be in an archive where they could be appreciated more. It would work like commons as people could upload things, but it would be stricter in what it lets in (e.g. New phots taken by users and other things). If you have any questions, feel free to contact me. Thanks! DiscoA340 (talk) 16:50, 21 June 2022 (UTC)[reply]

@DiscoA340: When would be the cutoff? Which would rule in cases of filename conflicts? Is it really a good idea to split Admin attention at this time? — Jeff G. ツ_{please ping or talk to me} 21:19, 21 June 2022 (UTC)[reply]

For the cutoff, I would say 20 years is a good rule of thumb, but as long as it's what you expect in an archive, then it should be good. I don't think there will be an issue with filename conflicts as most documents should be different from each other. For multi-page docs, I would think people would name each "Document X (P1)" and maybe for bigger docs, they could be combined into a single filename but with multiple pages (Sorry for being vague, I don't know how to explain it other than making bigger docs into a slideshow type file." The issue about Admins is a bigger issue I don't think I could answer and be 100% accurate, though I would say that making an archive could attract more future admins who like the idea and want to help. DiscoA340 (talk) 22:31, 21 June 2022 (UTC)[reply]

Commons is already our document and image repository and archive, full stop. There's no benefit to splitting the collection. In fact, there are very real downsides.

Take Jeff's question about file name conflicts that you didn't answer. If Commons has a document called File:Example.pdf, and someone uploads a different document called File:Example.pdf to this archive, which document gets served to Wikisource for transcription? If Commons has a photo called File:Example.jpg and this archive gets a different photo uploaded as File:Example.jpg, which photo appears in a Wikipedia article? If this new archive restricts uploads so that file names don't conflict with Commons, then what is the point in separating it out? Essentially that would just be a subsidiary of the larger repository split under a different domain name.

That then bridges into Jeff's second unanswered question. With a limited corps of trusted volunteers, is it a good idea to create another project that needs admin supervision? Instead of admins monitoring one domain name looking for files tagged as copyright violations, they'd need to monitor two domains. Or you'd have to recruit a second set of admins for the new site. You'd have to duplicate the various core policies to another domain. You could get weird inconsistencies where a file that doesn't technically conform to one site's policies technically conforms to the other.

So that brings me back to my first statement here: Commons already is the archive. Imzadi 1979 → 18:54, 26 June 2022 (UTC)[reply]

Global coordinates; latitude, longitude.[edit]

Hi,
I contributed this picture which is used in the Oberon book. The global coordinates are obviously wrong, as easily seen in Open Street Maps. Also the page for the picture has the message "There is a discrepancy of X meters between the above coordinates and the ones stored at SDC (Y). Please reconcile them." There are two problems with the location template.
(1) I haven't found documentation specifying the order of latitude and longitude in the template. Does documentation exist? If not, it should be created. In any case, a search of Help should find it.
(2) Apparently the location template accepts decimal degrees. Nevertheless coordinates are displayed as dms (degrees minutes seconds). What is achieved other than confusion? Our world is digital. Conversion is a nuisance. Display decimal degrees! In brief, my proposal is "Make location work".
Thanks for your attention, ... PeterEasthope (talk) 22:39, 26 June 2022 (UTC)[reply]

@PeterEasthope: That file description page is using {{Location}}. The documentation is at {{Location/doc}}. Parameter 1 is Latitude, degrees North of the Equator. Parameter 2 is Longitude, degrees East of the Prime Meridian (Greenwich Observatory). Where I live, Latitude is positive and Longitude is negative, putting me in the Northern and Western Hemispheres, and I'm fine with that. The numbers in that photo's file description page when I first got to it ("49.2637|123.2461") indicate a location in Hulunbuir, Inner Mongolia, China. I have a feeling "49.2637|-123.2461" in University of British Columbia Hospital, Greater Vancouver, British Columbia, Canada is more appropriate given where you live in British Columbia. — Jeff G. ツ_{please ping or talk to me} 23:25, 26 June 2022 (UTC)[reply]

Fixed the sign of longitude in the location template, thanks. The SDC reconciliation page suggests fixing the structured data. OK but I don't know where it is and the page doesn't give a clue. =8~/ The map shows the correct location for the coordinates. If SDC doesn't agree, sorry, I'm baffled. Regards, ... PeterEasthope (talk) 00:29, 27 June 2022 (UTC)[reply]

@PeterEasthope: On the "Structured data" tab, did you try to tap the "Edit" link next to "coordinates of the point of view" and save your changes? — Jeff G. ツ_{please ping or talk to me} 00:43, 27 June 2022 (UTC)[reply]

Found the structured data and fixed the longitude. There the location now appears correct. The file information tab still has the complaint "There is a discrepancy of 7356007 meters ...". =8~/ What?

The entire problem can be eliminated by taking the numbers in Structured Data as authoritative and propagating automatically to File Information if necessary. Correct? Thanks, ... PeterEasthope (talk) 01:40, 28 June 2022 (UTC)[reply]

Policy status for Commons:Harassment[edit]

The page has stated that it is proposed for three years, with no complaints. Let's make it official, like en:WP:Harassment. — Jeff G. ツ_{please ping or talk to me} 10:54, 6 July 2022 (UTC)[reply]

What are examples of harassment on the Commons that have not been addressed, or not adequately addressed, by existing policy? In the absence thereof, how is this not w:WP:CREEP? Why is a policy that was copy and pasted from en.wiki being presented here for approval with only superficial localisation? "WP" shortcut prefixes, for example, were simply swapped to "COM" resulting in redlinks like "COM:HUSH"--or missed altogether, like the still-remaining "WP:HNE". The page is replete with links, see alsos, and references to en.wiki. This is the Commons. Эlcobbola _talk 14:19, 6 July 2022 (UTC)[reply]

Duplikat-Erkennung: Commons Hochlade-Assistent und Commons-App[edit]

Seit ein paar Wochen habe ich Gefallen an der Commons:Mobile app gefunden. Ich habe vor, später (in ein paar Jahren) Teile meines Medienarchives mit dem Commons Hochlade-Assistent zu veröffentlichen und fürchte dann, versehentlich Bilder mehrfach zu veröffentlichen. Der Commons Hochlade-Assistent erkennt zuverlässig seine „eigenen“ Duplikate. Er kann aber nicht erkennen, wenn dasselbe Bild bereits mit der Commons Mobile App hochgeladen wurde. (Möglicherweise liegt das an unterschiedlichen Metadaten?) Ich habe hier auch schon darauf hingewiesen. Molgreen (talk) 15:24, 17 July 2022 (UTC)[reply]

Ja die Fotos unterscheiden sich um wenige Bytes und können daher nicht als Duplikate erkannt werden. Das Problem, dass Uploads von der App beim nochmaligen Hochladen im Wizard nicht erkannt werden lässt sich also leider nicht so einfach lösen. Das ein Foto aus der App zweimal hochgeladen werden kann, obwohl es die bitgleiche Datei ist, ist wohl tatsächlich ein Bug. --GPSLeo (talk) 15:46, 17 July 2022 (UTC)[reply]

Kann mir jemand sagen, ob ich das umgehen kann, wenn ich in der Commons:Mobile app alle EXIF-Tags in den Einstellungen auswähle? --Molgreen (talk) 16:14, 17 July 2022 (UTC)[reply]

Ich habe es mal versucht, wenn alle EXIF Tags in den Einstellungen der „Commons App" ausgewählt sind: auch dann erkennt der „Commons Hochlade-Assistent" nicht, dass es ein Duplikat ist:

Bild mit allen EXIF Tags per „Commons App" hochgeladen

Duplikat mit allen EXIF Tags per „Commons Hochlade-Assistent" hochgeladen (Hochlade-Assistent erkennt „Commons App" Duplikat nicht)

Why not just use the mobile version of the MediaWiki Upload Wizard? The mobile app is notoriously bad at the basic functions it provides and is inferior to any browser-based web interface, just use the mobile upload wizard and the issues unique to the mobile app would disappear (for you, not for those unfortunate to use the mobile app). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:18, 17 July 2022 (UTC)[reply]

thanks for the hint. I will try it soon --Molgreen (talk) 16:49, 17 July 2022 (UTC)[reply]

The "Nearby" feature mentioned here

Hello Donald Trung 『徵國單』, thank you very much for the tip about UploadWizard the mobile version of the MediaWiki Upload Wizard. I have tried it. The upload works very well as expected. At the same time, the Commons app also has good features such as "Nearby" / "Photos needed".— Preceding unsigned comment added by Molgreen (talk • contribs)

Comment, wouldn't it be wise to propose for the mobile app to become a web-wrapper until they can make their version of the Upload Wizard equal or better to the one we have for us web-users (saying this as a user who currently only uses his mobile telephone 📞 to edit). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:20, 17 July 2022 (UTC)[reply]
- Why not use both? The feature sets overlap but some features work better or are only available in one of the two. One user can choose to use one method to contribute to Commons in one situation, and another in another situation. whym (talk) 12:41, 21 July 2022 (UTC)[reply]

Thank you, yes, that's exactly what I'm practicing successfully by now.

It remains very unfortunate for me that the two upload wizards do not recognize each other's duplicates. --Molgreen (talk) 15:14, 21 July 2022 (UTC)[reply]

@Molgreen Do you mean UploadWizard (the web version) successfully detected those duplicates with different metadata? If so, I wonder why. As far as I know, both of UploadWizard and the mobile app rely on hash values to detect duplicates. The two Schwanenteich images have different hash values, so both should fail to detect them as duplicates. (It's "sha1" in the result.) whym (talk) 22:28, 21 July 2022 (UTC)[reply]

@whym thank you for your feedback. In my experience:

Does the UploadWizard reliably recognize its own duplicates
Does the Commons:Mobile app not recognize any duplicates (see Commons:Mobile_app/Feedback#Feedback_from_Molgreen_for_version_4.0.1~66f8f97d0_3 here
Commons:Mobile app and UploadWizard do not recognize duplicates of each other. This may be technically difficult. But I would really like it, because unfortunately I've accidentally uploaded the same file twice via Commons:Mobile app and UploadWizard. --Molgreen (talk) 05:51, 22 July 2022 (UTC)[reply]
There seems to be two issues. 1) I wonder if something other than the two upload tools might have changed the file (or the metadata of the file). For example, you might have used Google Photo to transfer the file, and Google Photo might have modified/normalized something in EXIF. If so, another duplication detection method (that ignores EXIF) might be the solution. That would be a feature request to the MediaWiki developers. 2) File:Schwanenteich_im_Annatal.jpg and File:Schwanenteich_im_Annatal_4.jpg are completely identical, so if the mobile app showed no warning about duplicates, that is a software bug. I think this needs to be fixed by the mobile app developers. whym (talk) 03:28, 23 July 2022 (UTC)[reply]

Support --Molgreen (talk) 09:52, 23 July 2022 (UTC)[reply]

Another test[edit]

to be on the safe side, I did another test. It seems to be very complicated:

in the following order:

- I download Schwanenteich im Annatal.jpg to the download area of my smartphones

- now something is different: duplicate is detected, but I can still upload

Mass move of files containing space before the file extension[edit]

I came across File:The Heart of a Hero (1916) .webm this morning, and I do remember seeing other webm files in the past that also had spaces before ".webm". I was wondering if it might be a good idea to use a bot to do a mass move of files with this specific issue, since it is an obvious, straightforward, and unambiguous error IMO. PseudoSkull (talk) 12:50, 21 July 2022 (UTC)[reply]

Support with redirects. — Jeff G. ツ_{please ping or talk to me} 23:18, 21 July 2022 (UTC)[reply]

Commons:Village pump/Proposals

Contents