Commons talk:WMF support for Commons/Upload Wizard Improvements

Archives Archive (Oct 23-Jan 24)

The 50 files limitation

Tracked in Phabricator
Task T349368

New users have a 50 files limitation. When they try to upload more than 50 files the upload wizzard simply crashes and no files get uploaded. It is convenient that this happens after the user has completed all the work in naming the file, giving the description and searched for categories and put in a lot of work and effort, which is then gone in a second without a warning or explanation. The program should either block the upload of more than 50 files or inform the user about this limitations. This bug has created a lot of frustrations to new user and they have no clue what went wrong. This is an effective procedure to keep new users frustrated and deter them forever from contributing to Commons ever again. Giftzwerg 88 (talk) 14:25, 10 October 2023 (UTC)

Hey @Giftzwerg 88: , thanks for raising this issue. I’ve opened a Phab ticket about it, and the team will take a look at it in one of the next meetings. I’ll keep you posted on this, but you can subscribe to the ticket and be aware of what’s going on there. Also, feel free to edit the ticket if I made some mistakes. Thanks! --Sannita (WMF) (talk) 10:48, 20 October 2023 (UTC)

The wrong orientation bug

Tracked in Phabricator
Task T349369

The preview shows uploaded pictures without regards of the orientation. This affects pictures in portrait mode. The preview shows them tilted sideways in 90° angle. New Users that do not know about this bug often delete it and try it a second time or even multiple times before they give up. But they simply keep showing up in the wrong direction each time. They think they have done something wrong, or something is wrong with the camera or the picture. Others report on the user forum and ask about pictures that got uploaded in the wrong orientation. We even had cases where the picture was rotated by another user and then were upside down, all the while the uploaded picture does not even need rotation, it is just that the user got tricked into believing that the picture was uploaded in the wrong orientation. This annoying bug is a good way to introduce new users into a world with half-baked software designed to make beginners life harder and create confusion and make them doubt their choices in life. To contribute to commons for example. Soooo, please admit to the bug and tell the user ahead that in preview some pictures might appear in wrong orientation, ooooor fix it, that the user can see the true orientation of the picture. But long time users are no longer in panic, but annoyed by this bug too. Imagine you made a series of portraits and want to choose the best of the files. It is very hard to determine that you have picked the perfect file when you see it in the wrong orientation in preview. Our brains are not used to see and process portraits rotated at a 90° angle, and you no longer can see if the face shows the desired expression or emotion or the small differences between different versions. So please FIX it. Giftzwerg 88 (talk) 14:48, 10 October 2023 (UTC)

I agree, I fall into this trap myself. Ziko van Dijk (talk) 20:22, 13 October 2023 (UTC)

Hey @Giftzwerg 88: , thanks for raising this issue too. I’ve opened another Phab ticket about it, and the team will take a look at it in one of the next meetings. I’ll keep you posted on this, but also in this case you can subscribe to the ticket and be aware of what’s going on there. Also, feel free to edit the ticket if I made some mistakes. Thanks again! --Sannita (WMF) (talk) 10:49, 20 October 2023 (UTC)

Allow multi-line in the source and author fields

Tracked in Phabricator
Task T352988

Currently, the source and author fields only allow single line and we can only put one source and author in the fields. However, there are some files that have multiple authors and sources, for example File:1937 Events Collage V 1.0.jpg this collage.

Therefore, it is suggested that the source and author fields allow multi-line, or there will be an option that can switch to single line / multi-line. Thanks. SCP-2000 11:39, 29 November 2023 (UTC)

cc @Nagae Iku: SCP-2000 11:41, 29 November 2023 (UTC)

@SCP-2000 thanks for your feedback, I'll report it to the team, and let you know about it, hopefully soon. -- Sannita (WMF) (talk) 15:40, 30 November 2023 (UTC)

@SCP-2000 We've opened a ticket for your request, the team will work on it. I expect this change to be ready for January (since we have to account also for the end-of-the-year block in new deployments). --Sannita (WMF) (talk) 15:05, 7 December 2023 (UTC)

Line breaks in the textfields for author and file source

Tracked in Phabricator
Task T352988

I would like a reimplementation of line breaks in the textfields for author and file source as before. I think it would be easier, especially if you habe a free file with several authors or you want to provide more links as source.

Thanks! --PantheraLeo1359531 😺 (talk) 18:47, 14 December 2023 (UTC)

• Just saw that this issue was already mentioned --PantheraLeo1359531 😺 (talk) 18:49, 14 December 2023 (UTC)

  @PantheraLeo1359531 Yes, we're aware of this and we're working on it. The change will probably be shipped in January, since deployments are halted due to Christmas/New Year's holidays. I'll keep you posted. Sannita (WMF) (talk) 10:08, 18 December 2023 (UTC)

Thanks! --PantheraLeo1359531 😺 (talk) 15:59, 18 December 2023 (UTC)

Two extra clicks again

Tracked in Phabricator
Task T353654

I use predefined answers to the Upload Wizard questions (choice of license and whether I upload my own work); however, with the two new questions it is not possible to predefine the answers. This gives two extra clicks per upload, THIS IS A LOT. I mentioned this issue last time, nobody (including the WMF team) seemed to care. May be now people would care. Ymblanter (talk) 20:20, 14 December 2023 (UTC)

It might be wise for them to create something like "Special:UploadWizard (Beta)" separate from "Special:UploadWizard", so they could actually get community feedback before implementing these "improvements" (as is how it was reported on in Tech News 🙄). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:29, 14 December 2023 (UTC)

It is discussed in detail above on this page, and my comments are also there. Ymblanter (talk) 20:38, 14 December 2023 (UTC)

@Ymblanter Do you mind helping me translating your request into a Phabricator ticket? I guess we can work at making the two extra clicks pre-defined in the users' preferences, or at least I can ask the team if this would be feasible. Sannita (WMF) (talk) 14:54, 18 December 2023 (UTC)

Yes, sure. User preferences would indeed solve the problem. Ymblanter (talk) 14:59, 18 December 2023 (UTC)

For experienced users who happen to know how to tweak user preferences. There are some people who have edited here for years and don't know things that seem "basic" to others, like a WikiGraphist that has been here 17 (seventeen) years, but didn't know how they could change their signature in user preferences. While many "power users" could circumvent the 2 (two) extra clicks, this would still be a hassle for the vast majority of users who don't know about this. It might be best to link to user preferences somewhere directly inside of the MediaWiki Upload Wizard then. Especially since the vast majority of people who would become regular volunteer uploaders here might not like to constantly confirm that the image of an archeological museum exhibition isn't a selfie 🤳🏻. Ease of use should be accessible to everyone, not just the more experienced users who happen to know where and how to tweak things. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:06, 18 December 2023 (UTC)

@Ymblanter: I created a Phabricator ticket for your request, and (I hope) I tagged you as a subscriber. Please, feel free to edit, add context, or correct it. As I already said in other threads, now there is the end-of-the-year freeze on new deployments, so this ticket will likely be analysed in January. I'll keep you posted about it, but feel free to ping me personally if you don't receive news from me. Sannita (WMF) (talk) 15:31, 18 December 2023 (UTC)

Great, thanks a lot. Ymblanter (talk) 17:13, 18 December 2023 (UTC)

Another similar issue for which I don't think creating a new section would be due:

• Copy information… default selection: Would it be possible to somehow store the recently used checked boxes under Copy information to all uploads following … or to specify a default?
  • I sometimes upload images from multiple CCBY scientific studies in a row and then always need to change the default selection to Copy caption, date, categories and nothing else. Until there is some kind of Study2Commons tool where you just enter a URL to e.g. a paper on nature.com and it prefills all the title and description etc fields that you then only edit as needed.

Also I'd like to briefly express support for Ease of use should be accessible to everyone, not just the more experienced users who happen to know where and how to tweak things – this often gets overlooked where things are considered 'solved' if somewhere there is an unknown barely used external script/nondefault gadget for it. Prototyperspective (talk) 15:39, 28 December 2023 (UTC)

V2C should integrated into MW

Hi, FYI, I created a feature request: phab:T353659. Yann (talk) 16:27, 18 December 2023 (UTC)

attribution parameter in license template

Tracked in Phabricator
Task T354181

UW should use the attribution paramter in the license template. Re-users are told by the license template what license applys. In most cases the author has to be attributed. In most cases a re-user has to search for the author in the information template. but the license template has an mostly unused attribution parameter that can and should be automagically filled in by the UW for the benefit of re-users. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 17:56, 25 December 2023 (UTC)

@C.Suthorn Thanks for your comment (and sorry for taking a week to answer, but I was out of office for the holidays). Would you please file a Phabricator ticket for your request, so that I can forward it to the team for evaluation? If you don't know how to do it or can't do it, I can do it for you, but then I'll ask you to double check it, just to be sure that everything is in place. Let me know! Sannita (WMF) (talk) 11:35, 2 January 2024 (UTC)

@Sannita (WMF) Phab:T354181 C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 11:56, 2 January 2024 (UTC)

@C.Suthorn Thanks a lot! I hope I'll let you know asap, but in case feel free to ping me about it. Sannita (WMF) (talk) 20:20, 2 January 2024 (UTC)

Unknown author added in wrong place

Tracked in Phabricator
Task T354182

It looks like the {{Author|Unknown}} template is being added just above the categories, rather than in the Information template's |author= field. For example, see this file, but I've noticed this on a few files lately when using the new unknown-author checkbox in UploadWizard. Sam Wilson 23:51, 30 December 2023 (UTC)

@Samwilson Thanks for noticing. Would you mind creating a Phabricator ticket for this, so that I can send it to the team for evaluation? If you don't know how to do it or can't do it, I can do it for you, but then I'll ask you to double check it, just to be sure that everything is in place. Let me know! Sannita (WMF) (talk) 11:30, 2 January 2024 (UTC)

@Sannita (WMF): Sure! Done: phab:T354182. Sam Wilson 12:09, 2 January 2024 (UTC)

@Samwilson Thanks a lot! I hope I'll let you know asap, but in case feel free to ping me about it. Sannita (WMF) (talk) 20:21, 2 January 2024 (UTC)

@Samwilson A patch has been submitted to fix this problem, and it's currently in review. If it's not shipped this week, it will probably go next week. I'll keep you posted about it. Sannita (WMF) (talk) 15:43, 15 January 2024 (UTC)

@Sannita (WMF): Thanks! I've tested the patch, and left a comment there. (I do sort of think that it should keep using {{Unknown}}.) Sam Wilson 23:40, 15 January 2024 (UTC)

Uploader not linked

Tracked in Phabricator
Task T354529

In my latest uploads, the author name in the information template is not linked to the account on Commons (see e.g. my upload from yesterday, File:Prague Public Transport Museum Tram 88.jpg). I checked my uploads and I see that it stopped being linked on 12 or 13 December. I have heard the same from @Екатерина Борисова: who also mentioned that in case of a reupload the author is still linked, and apparently it is still linked if one uses a mobile app (I did not check this). Since there is no reason it should not be linked I assume this is a bug and needs to be fixed? Ymblanter (talk) 18:57, 7 January 2024 (UTC)

@Ymblanter Yes, this definitely looks like a bug. I created phab:T354529 and took the liberty of putting you as a subscriber to it directly. Please, can you review the ticket to be sure I understood correctly the problem? Thanks! Sannita (WMF) (talk) 13:50, 8 January 2024 (UTC)

Great, this is perfect. Ymblanter (talk) 15:01, 8 January 2024 (UTC)

@Ymblanter FYI, the patch has been added short of an hour ago, and should be shipped during the week. Thanks again for noticing us the bug, and we apologise for the disruption. Sannita (WMF) (talk) 12:10, 15 January 2024 (UTC)

Great, thanks a lot. It might be a good idea to run a bot restoring the link to the username; may be someone reading this knows how to request such a bot (obviously it only makes sense after the patch has been implemented). Ymblanter (talk) 15:38, 15 January 2024 (UTC)

@Ymblanter I'd raise the suggestion at the Village Pump, since there's another discussion going on about it. Sannita (WMF) (talk) 15:41, 15 January 2024 (UTC)

Tnx. Ymblanter (talk) 16:08, 15 January 2024 (UTC)

Another confusing message

Now, I understand why the Wikimedia Foundation (WMF) tries to add these additional clicks to the MediaWiki Upload Wizard, but as I demonstrated before, many of these just contain either factually incorrect or just confusing information, here is another one:

• Please confirm the following statement before proceeding.
  • I confirm that this work does not include material restricted by copyright, such as logos, posters, album covers, etc.

Well, if you came this far in the upload process you 1. (One) already included a free license, and 2. (Two) already provided a source and authorship. But now imagine you're a new user to the Wikimedia Commons and you see logos on Wikipedia, you see that one has a free license and emulate it. Then suddenly you see this box that explicitly tells you not to upload any logos, images like this are not out of scope, but the current wording makes it sound like these images should not be uploaded here.

Again, I'm getting the impression here that these changes were made to lessen the "burden" of admins and patrollers and not to actually make it easier or better for the uploaders themselves. Especially since the wording doesn't seem to be based on any existing policy or guideline and is completely redundant to the rest of the fields in the decision tree.

But still, the wording is "I confirm that this work does not include material restricted by copyright"... Isn't this redundant? The process literally starts with "You can upload someone else's work as long as it is published under a free license or its copyright has expired." and then immediately asks for a license, so what use does this extra box have other than to irritate uploaders? A free logo is a free logo, a copyrighted logo is a copyrighted logo, the status of the word is already established in the very first (1st) step of the process. So what use does this extra click have?

Note: I wanted to post this earlier, but a software issue is making this website very mobile-unfriendly for me so I refrained from engaging in many discussions for some time. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:47, 7 January 2024 (UTC)

I would suggest that this particular question makes sense (at least as a reminder) when people claim to be licensing their "own work" with a CC license, but it's probably not useful when someone has asserted that they are uploading something under a particular PD rationale. I'm guessing that we get far fewre bogus claims of PD than of "own work" for non-trivial logos, posters, album covers, etc. (though I don't have statistics to back that). - Jmabel ! talk 00:28, 8 January 2024 (UTC)

Improvements to the "Describe" step in UploadWizard

Hello everyone! As a next step in improving UploadWizard, we want to focus on the "Describe" part, where our usability findings have identified several criticalities:

• users involved in the tests had difficulties in understanding the difference between title, caption and description;
• adding categories to the media was described as challenging;
• other fields may result confusing and therefore left unused by the users.

We want to try to simplify the page, so that users (especially newcomers whose media is often flagged for deletion) would find it easier to provide the key information moderators need to evaluate the media.

Our questions are the following:

1. How is the "caption" field being used right now?
2. Would it be better to move the "caption" field outside of the "core information" part of the form?
3. How frequently are "location" and "other information" fields used? What "other information" is used for usually?
4. Is the "date of creation" field used also to evaluate potential problems with Freedom of Panorama and/or copyright of the image?
5. How correct and useful are the categories added by users while uploading the media? How much work has the community to do to eventually fix them usually?

Thanks in advance for your help! Sannita (WMF) (talk) 14:23, 16 January 2024 (UTC)

Use of captions

How is the "caption" field being used right now?

Good questions! I'll add some quick responses to start us off.

I use it as basically a shorter form of the description field. Basically, the description field should answer any information that anyone might want to know about the photo, whereas the caption field should be what we'd expect the caption to be in a normal use of the photo (meaning no more than a line or two). The caption field becomes the default caption when an image is used on Wikipedia.{{u|Sdkb}} ^talk 17:32, 16 January 2024 (UTC)

When I explain to students what each field is for, normally I have a problem to explain the difference between title, caption and description. Title and caption many times end being exactly the same text, and sometimes the three are the same. I think that with structured data and the description it should be enough, given that the title of the image is normally very similar to the title... or it should. We may encourage uploaders to be descriptive (caption-like) in the image title, so it can be easily found. Theklan (talk) 18:53, 16 January 2024 (UTC)

I see a lot of new users using the caption field as the only description - which is not really what we want. Kritzolina (talk) 18:57, 16 January 2024 (UTC)

I'm guilty of using the caption as the only description sometimes, when there's not much that I want to say about a file. The thing about UploadWizard however is that it mandates a description and not a caption, so I sometimes just put the same text as both and then go back and remove |description= (letting it be filled by {{Information}} with the caption; since that functionality came along I must admit I thought it was an indication that the caption should be done first, and the description only added if there was more info needed). Sam Wilson 08:58, 17 January 2024 (UTC)

I personally also use it as a short form of the description. I see that sometimes, especially with GLAM uploads, the description is quite extensive, often it contains templates, then a short caption is needed. Ymblanter (talk) 08:23, 17 January 2024 (UTC)

May I remind you all that Commons is a multilingual project?

• "Title" (the file name) is a field that contains the caption and description in ONE language only (and in most cases it is a dialect of Tibetan language that was mostly spoken between 1446 and 1476 in a small village in the Himalaya).
• "Caption" is a collection of translations of that "title" into only that languages that got a language code assigned by the MediaWiki software, but you will only see the one language selected by your web browser preference.
• "Descripton" is a collection of translations in languages that come with a template:de, template:de-at, template:de-li, template:de-lu, template:de-formal or template:de-li-formal template and you will see all translations unless you activate a dropdown box that selects only one language, but of your own choice.

However mostly title, caption and description are all in Tibetan or sometimes in a language named english (who understands that anyway?) but never both. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:20, 17 January 2024 (UTC)

@C.Suthorn: Which file has caption and description in "a dialect of Tibetan language that was mostly spoken between 1446 and 1476 in a small village in the Himalaya"?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 14:04, 17 January 2024 (UTC)

@Jeff G.: which contributor has a sense of humor? - Jmabel ! talk 19:19, 17 January 2024 (UTC)

@Jmabel: I was humoring {{u|C.Suthorn)).   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 10:01, 18 January 2024 (UTC)

I use the caption field to describe the file as succicently as possible, the title usually for the title of the work or to incorporate the important info in the caption of the work, and I use description to transcribe the captions that originally accompanied published photos, maps or drawings in newspapers or to copy the caption field if that's what's best. Abzeronow (talk) 19:40, 17 January 2024 (UTC)

Move the "caption" field?

Would it be better to move the "caption" field outside of the "core information" part of the form?

If I had to choose, I'd say that having a comprehensive description is more important than a caption, since a short caption can always be derived from a good long description, but not the other way around. But both are important. {{u|Sdkb}} ^talk 17:32, 16 January 2024 (UTC)

I think that "caption" is repetitive, and information should be encouraged more, with a clear focus on what information means there. Lot of people also add the original files if the image is derivative in the information, but this could be another field if you choose to inform that the file is derivative. Theklan (talk) 18:54, 16 January 2024 (UTC)

Here and on the prior question: the description is essential. A caption is nice to have, but not nearly as important. - Jmabel ! talk 22:39, 16 January 2024 (UTC)

I would say some explanation what is a description and what is a caption (like popups) would likely help (not to me, but to new-ish users).--Ymblanter (talk) 11:32, 17 January 2024 (UTC)

No. Since when did SDC become unimportant? For the purposes of ease of understanding, it might be better to label the wizard's caption field something like "Short description (one sentence)"; and the current description field as "Long description". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 18 January 2024 (UTC)

Location and other information

How frequently are "location" and "other information" fields used? What "other information" is used for usually?

• Quite frequently. Often, the description/caption don't include proper location information, so that is then derived from the location field. It's also potentially useful for categorization (e.g. there's this landmark at these coordinates, so let's see if we have any photos from those coordinates). And all metadata is very useful for identifying copyright violations, since it tends to be scrubbed from images just downloaded from the web. {{u|Sdkb}} ^talk 17:32, 16 January 2024 (UTC)

  Oh, I thought we were talking about location information in the file metadata. The location field in the description is generally derived from that. It's still often useful, though. {{u|Sdkb}} ^talk 19:02, 16 January 2024 (UTC)

• Other information is also often used by experienced users to put templates like the personality rights warning there. --Kritzolina (talk) 18:54, 16 January 2024 (UTC)
• I barely use them when uploading. The coordinates can be filled automatically from the image, or suggest a procedure where you pin the image in a map when uploading. I normally add the "other information" suggested here in the description itself. -Theklan (talk) 18:59, 16 January 2024 (UTC)
• Location, however it is derived, is very useful when other info is short-changed. It gives someone else a fighting chance of working out what is going on. - Jmabel ! talk 22:39, 16 January 2024 (UTC)
• I often use "other information" when I'm uploading a scan of a photograph and I've got files for the front, back, and some cropped/tweaked versions as well. These aren't quite "other versions" but it's still useful to have them all listed on each file (although come to think of it, if "other versions" was editable in UploadWizard it could probably be used instead). Sam Wilson 23:44, 16 January 2024 (UTC)
• I always use location if it make sense (obviously not when uploading artwork etc), it can not be derived from the metadata of my files. However I am not sure everybody knows that location is the camera location, not the object location (and the object location would be problematic if there are many objects on the picture). I do not think I ever in my life used "other information", and I have several dozen thousands of uploads.--Ymblanter (talk) 20:14, 17 January 2024 (UTC)

Date of creation

Is the "date of creation" field used also to evaluate potential problems with Freedom of Panorama and/or copyright of the image?

Yes. {{u|Sdkb}} ^talk 17:32, 16 January 2024 (UTC)

There is an enormous problem that people often give the date of the upload, or the date they scanned or photographed a much older 2-dimensional work, where their derivative work would have no copyright of its own. If we are in a scenario where we know already that we are dealing with a scan (or equivalent) of someone else's 2-dimensional work, it would be very useful to underscore that the date we care about is the date of that 2-dimensional work. - Jmabel ! talk 22:39, 16 January 2024 (UTC)

Categories

How correct and useful are the categories added by users while uploading the media? How much work has the community to do to eventually fix them usually?

Often quite bad. The core problem, in my view, is that we have a very complex system of diffusion, where you're (generally) supposed to place an image only in the most specific categories it belongs to (so e.g. don't add an image to Category:Men when it's already in Category:Fred Rogers, which is a subcategory — several layers down — of the men category). This system is often difficult even for experienced editors to work in, let alone newcomers, for whom it is completely non-intuitive. Often they will place images in overly broad categories that then need to be diffused. This isn't the worst problem in the world, as there are lots of wikignomes who do category diffusion, but if your goal is to help newcomers categorize well enough that others aren't needed to clean up after them, this is your main problem.

The way out of this mess, in my view is to focus on structured data, which doesn't have the mess of diffused categories combining topics, and from which categories can theoretically be derived. So, for instance, rather than knowing that, say, Category:Fred Rogers in swimming pools is a diffused subcategory of Fred Rogers, users would just enter Depicts: Fred Rogers and Depicts: swimming pool, and if we really wanted a Fred Rogers in swimming pools category the software could derive it automatically from the structured data. Doing this would solve the awful redundancy of asking users to first add categories and then add structured data, which is what we currently have. The rub is that the process of deriving categories from structured data is currently just theoretical, so additional technical work is needed there, and that categories have been deeply entrenched in Commons for many years, so shifting from them to structured data will require a shifting the community to orient around them. I expect those blockers to be dealbreakers for you, but still want to raise them, as I think it's important to look forward to the vision of where we ultimately want to end up. Hope all that's helpful! Cheers, {{u|Sdkb}} ^talk 17:32, 16 January 2024 (UTC)

I agree that we probably won't get most beginners to do a great job of categorization. If they add more-or-less reasonable categories, the wikignomes can take it from there. It is very important that we get at least one somewhat appropriate category; anything beyond that is gravy. Also, in my experience, beginners don't do any better with "depicts" than with categories. I believe I've seem more really bad "depicts" than really bad categories. Both are folksonomies that take some time to learn. But in my opinion categories are much more important than "depicts". - Jmabel ! talk 22:39, 16 January 2024 (UTC)

I think the problems beginners have with "depicts" currently are rooted largely in the fact that the structured data interface hasn't been optimized for newcomers at all yet. And I'd say that categories are certainly more important in the current Commons environment, but that they're a legacy system that's going to become less important over time as we transition toward using structured data given its inherent advantages. That transition could be several years away, but for purposes of improvements to the Upload Wizard, I think the forward-looking/future-facing approach would be to not neglect structured data. {{u|Sdkb}} ^talk 18:44, 16 January 2024 (UTC)

I support what it has been said there. Most of the newbies add very generic categories, normally in their own language, so they upload photos to categories like: "People" or "House". The idea we should push is the depiction itself, and try to suggest categories based on that. Theklan (talk) 19:01, 16 January 2024 (UTC)

Many categories don't belong as "depicts", and I'm constantly seeing people put content in as "depicts" that doesn't belong there. Examples:

• a country should never be "depicts" except something like a map of the country
• a city similarly, or maybe OK in a distant skyline (but most skylines show a downtown district that has its own distinct Wikidata item)
• similarly when a photo of one item in a museum's collection is said to "depict" the museum.
• (etc.)
• person who the image is somehow related to but is not shown (a picture of someone's house or signature does not depict that person)
• a medal does not depict a regiment, etc.
• dates
• information about the medium ("depicts black-and-white photograph")
• information that is really about provenance
• and really things like "depicts cultural heritage" or "depicts [some branch of] physics" are not quite right, either.

All of these things can, at least potentially, be covered by categories (and by other SDC properties that aren't, and probably don't need to be, in the UploadWizard). - Jmabel ! talk 22:55, 16 January 2024 (UTC)

The commonest error I see from new users is adding multiple levels of a category hierarchy ("Shops in London", "Shops in England", and "Shops in the United Kingdom"). Software could detect this.

Other issues could be reduced by using a HotCat-like display where child categories of the current selection are shown. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 18 January 2024 (UTC)

Ok. I personally find the Upload Wizard very convenient for adding categories, basically because of the dropdown menu, though in many cases I have to look up the main category, to put it on a hotkey and then upload it from the hotkey to the category field, otherwise I will not be able to find it - for example how could I know that the correct category is Category:St Magnus Cathedral, Kirkwall and not Category:Saint Magnus Cathedral (Kirkwall) or Category:Kirkwall Cathedral? But this is not the point. The point is that I am not even close to an average Commons uploader. Unless I am mistaken, we are pretty much the only file depository in the world which still uses categories, everybody else uses tags. One possible conclusion is that we should be moving closed to tags and away from the categories, which is conveniently done with Structural Commons, but for many reasons this is probably not going to happen. Another possible conclusion would be to use categories as tags - to ask uploaders to add as many they want (most of which naturally are going to be redundant) and then find some automatic or semi-automatic way to bring them to align them with our category system. For example, no uploader would ever have an idea to add a category Category:Women photographed from the back against the light in Ontario (and it is unfortunate that we have such categories at all), however, if categories (tags) "woman" and "Toronto" are added everything else should be somehow possible to move down the category tree using fully automatic means, certainly after the AI has become available.--Ymblanter (talk) 19:36, 18 January 2024 (UTC)

May be useful to add my own practice. I upload mostly my own photographs which are landscapes and cityscapes. The categories which I add are: (i) what is on the picture (down the category tree), sometimes one, sometimes two, sometimes five categories, as precise as I can; (ii) category of the type "August 2025 in Beijing", sometimes down to a year, sometimes down to a month, whatever is available/reasonable; (iii) "Taken with <camera model>" (iv) "<Country> photographs taken on <date>" - these categories some categorizers diffuse to the administrative divisions, but I believe there is community consensus against such diffusion; (v) my personal categories, "Photographs of <Country> by Ymblanter", so that I can find the upload later. All my rant above is about (i), bots should be able to add (ii), (iii), and (iv) fully automatically. Ymblanter (talk) 19:43, 18 January 2024 (UTC)

It would be very helpful, if uploader can choose between possible categories based on EXIF coordinates like in commons mobile app. Many people uploads mainly photos of places and object. JAn Dudík (talk) 21:45, 18 January 2024 (UTC)

Percentage next to progress bar while uploading (e.g. 14.2 %)

Tracked in Phabricator
Task T355340

Hi!

I thought about this longer, but I think it is useful to have a number in percent to see how far the upload progress is, similar to the percentage display when uploading a video on YouTube.

In addition, it would be nice to see how much megabytes were uploaded already and how large the total amount of size is that will be uploaded (e.g. 142 MB of 240 MB uploaded). This is particularly useful for estimating whether an upload will be fast enough for large amounts of data (fluctuations in the upload speed can make it difficult to predict the remaining upload time). Greetings --PantheraLeo1359531 😺 (talk) 16:56, 17 January 2024 (UTC)

•  Support.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 17:16, 17 January 2024 (UTC)

I would support assuming it does not take much resources. Ymblanter (talk) 20:11, 17 January 2024 (UTC)

Hey @PantheraLeo1359531, thanks for the idea. Would you be so kind to open a Phabricator ticket for this? I don't think we can work on it in the next future, but at least it would get on our dev's radar. Sannita (WMF) (talk) 13:24, 18 January 2024 (UTC)

Thank you, I will add it :) --PantheraLeo1359531 😺 (talk) 15:35, 18 January 2024 (UTC)

 Done Task added --PantheraLeo1359531 😺 (talk) 15:43, 18 January 2024 (UTC)

Fantastic, thanks! Sannita (WMF) (talk) 20:09, 18 January 2024 (UTC)