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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@C.Suthorn Hi, we evaluated your ticket, and the original request you made was conflicting with Commons' guidelines on how the parameters should be compiled ("attribution" is deprecated, and should be used only if different from "author"), therefore we tried to change a bit the wording and the scope of it.
The team, in the end, decided to decline your ticket, because it isn't clear what benefit would it bring to use the "attribution" field in the template, and also because the info about who the author is is already present in {{Information}}. The ticket can be reopened, if you can make more clear your case about why this is needed, maybe presenting examples of use cases. Sorry to be the bearer of bad news. Sannita (WMF) (talk) 16:33, 20 March 2024 (UTC)[reply]
@Sannita (WMF): may I ask what Commons guideline that conflicts with? Because I think C.Suthorn is entirely correct here.
I certainly always use an explicit attribution in my uploads even of my own photos, as do at least several dozen of the more serious photographers here: there is a reason {{Self}} has an "author" argument. I've repeatedly seen that for people who do not do this, when their work is reused by third parties it is often misattributed to "Wikimedia Commons" or even "Wikipedia". Surely that is not desirable.
Also, many people often upload third-party work (as for example I did less than 20 minutes ago with File:Washington State Ferry Olympic beached on Ketron Island.jpg. For this, the attribution argument in the license is close to crucial: otherwise, it will often either be misattributed as in the first case I mentioned or misattributed to the uploader, again not at all desirable. - Jmabel ! talk20:05, 20 March 2024 (UTC)[reply]
@Jmabel Thanks for this message, evidently we interpreted in a narrower way the guidelines, and we were also lacking good examples for this. I'll try to get the ticket re-opened, even though it might take a while.
Just personally, my experience with external outlets (having worked with several) is that it's already something that they quote "Wikipedia" or "Wikimedia Commons" (or even "Wikipedia Commons"...) as source of the image. I don't think it has much to do with template attribution, but more likely with laziness and/or scarse knowledge about how to correctly quote something. But that shouldn't bring us to avoid new means to enforce that, I give you that. Hope to let you all know soon about this. Sannita (WMF) (talk) 18:38, 22 March 2024 (UTC)[reply]
Percentage next to progress bar while uploading (e.g. 14.2 %)[edit]
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)[reply]
Maybe it would be a good idea to allow people to (optionally) add license tags if they fill in this field. Currently, there is no difference between clicking on this and saying that a work is entirely your own, but why a photographed work is in the public domain varies from subject to subject. So there could be an OPTIONAL field where people can add license tags to explain why the work is (partially) free. These license tags can then appear at the bottom with a special field below the uploader's own license. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:40, 12 February 2024 (UTC)[reply]
AI-generated works are still a fairly small subset of Commons uploads, but tracking them, I'm seeing quite a few that are uploaded without making explicit the prompt that was used. That's a loss for us, as it's relevant metadata that is not possible to recover later. It should ideally be recorded using the recently introduced {{Prompt}} template; @Sannita (WMF), would it be possible to incorporate that template into the wizard when someone indicates they are uploading an AI-generated work? {{u|Sdkb}}talk04:37, 16 February 2024 (UTC)[reply]
Hey @Sdkb, thanks for the ping. I'll pass it on to the team, and we'll evaluate the request next week. I'll keep you posted on this, but feel free to ping me again if I disappear. Sannita (WMF) (talk) 09:35, 16 February 2024 (UTC)[reply]
Hey @Sdkb, I have some updates on that. For the time being this request has been put on hold, since it is not entirely within scope of this year's work. I will keep an eye on it and see if in the next months this could be fixed. Sorry for the bad news. Sannita (WMF) (talk) 09:23, 23 February 2024 (UTC)[reply]
@Sannita (WMF), I appreciate the update, but I'm not quite sure what you mean by not entirely within scope. You are in the middle of the "Upload Wizard Improvements" project currently, yes? And as part of that you introduced the "I generated this work using an AI tool" option within the wizard, yes? And this task is directly related to that option, yes? I would have hoped that, when you budgeted time for the upload wizard improvements, you anticipated that there would be community feedback like this and built in some time to address such feedback. Sdkbtalk23:53, 25 February 2024 (UTC)[reply]
@Sdkb AI tool was introduced as an option, yes, but we don't have budgeted time this year to improve on this specific item of UW, since we are working also on other aspects of it. It is though on our watchlist, so I hope in some months the decision will be reviewed. Sannita (WMF) (talk) 17:24, 26 February 2024 (UTC)[reply]
I take your word about your team's resource constraints, and acknowledge that the Prompt template was introduced only more recently. But the ask to document prompts has been stated at Commons:AI-generated_media#Description over a year now, it says (in its current wording):
Whenever you upload an AI-generated image (or other media file), you are expected to document the prompt used to generate the media in the file description, and identify the software that generated the media.
I share Sdkb's surprise that this was apparently not considered when scoping out designing the recently added current message:
Enter the name of the AI engine used, followed by the name of the person who created the prompt: Example: Author: Midjourney AI; prompted by Jane Doe
In fact, these budget constraints seem to be an argument for better, more informed planning in such matters, as it may be more costly to come back later and fix such omissions.
I assumed that I did it wrong because when you are uploading to the Commons it asks you to upload it only for educational purposes. So I guess its ok if I did it for my userpage only. My cat, that aint for educational purposes. But its alright for my userpage. Am I correct?
What do you propose? I think adding a "or for you user page" would not be a good idea and would lead people to use Commons as a social media page. GPSLeo (talk) 17:56, 22 February 2024 (UTC)[reply]
I don't see this as a problem. We cannot prevent people from making mistakes by listing every single reason their upload might (not) be allowed in the upload form. —TheDJ (talk • contribs) 13:18, 6 March 2024 (UTC)[reply]
It does seem like a problem, but a very minor one. Personally, I don't think the benefit of addressing it is worth the extra complexity cost for the interface. If the UploadWizard actually explained everything perfectly, it would look like an Apple TOS agreement. Nosferattus (talk) 16:59, 26 March 2024 (UTC)[reply]
There is still no response to my feature request for making the release rights step adaptable through upload campaigns. We really need this for the Wiki Loves Contests where most of the questions asked in this step are irrelevant but might confuse the uploader prevent them from uploading anything. GPSLeo (talk) 15:03, 6 March 2024 (UTC)[reply]
Feedback needed on proposed changes to Describe step[edit]
Hi all! We've concluded our evaluation of your previous feedback and we're ready to share with you our current mockups for a proposed change to the "Describe" step in UploadWizard.
We also have several questions for you to answer, as part of our request for feedback. I took the liberty of creating several subtopics for them, so that it will be easier for you to answer.
Now it seems everything is more compact and better organized. I think that the ideas will be more clear, and the overlap of information reduced. I would suggest to make the selection of license pre-filled with cc-by-sa-4.0, as it is the most commons one. This could be changed by default in the preferences for a user, if they prefer another one. From my experience, people don't understand the nuances of all the licenses, so giving one as default would make it easier. -Theklan (talk) 11:31, 12 March 2024 (UTC)[reply]
I think the caption should only be copied to the description (by default) if no description is provided with the default being showing the description field. The caption only allows for a short text. There's currently a big issue with images that are clicked on in the WMC search results only showing the description but not the caption where it should show both if they aren't the same (is there a phab issue for that?). As for the depicts statements – I think a large fraction of users enters at least partially problematic/inaccurate things there which are hard to find and correct while at the same time that metadata could mostly be inferred from the categories. Both the time spent on these (mostly redundant) by uploaders and the editors correcting their problematic data as well as the amount of misleading/poisonous/inaccurate data will likely increase with making these fields even more visible. Not necessarily a big problem, just not an improvement I think and something that probably will need to be dealt with at some point. Likewise, the same applies to encouraging users to enter more languages – what are people expecting them to do ideally…manually entering 300 translations? These should also be populated via modern tools that show dynamic correctable machine translations such as via the DeepL translator. --Prototyperspective (talk) 13:00, 12 March 2024 (UTC)[reply]
Regarding Most users (especially new users) may find entering captions significantly easier than providing detailed descriptions — Well, yeah, people always find it easier to do less work rather than more work. But we want people to provide as much description as possible, since the purpose of Commons as a repository of knowledge means that images with detailed associated info are significantly more valuable to us. The "100" in the bottom right seems to indicate to me that you plan to impose a character limit on the caption, and while that makes sense for the caption, I worry that it'll push users who might otherwise be inclined to provide more detailed info away from doing so. Having to actively uncheck the "same as caption" box to access the description means that few users are going to do so. An alternative approach might be to make the description the field users fill out, and then have an autochecked "same as first sentence of description" prefill the caption.
Regarding Captions offer a more structured multilingual field, can you provide some additional info on this? I wasn't aware of structural differences between the fields, and if there are deficiencies in the description field, that seems like something we'd want to upgrade as part of this work. As myself and other editors have mentioned before, we consider the description field more important than the caption, so I am concerned to see it being deemphasized in these changes.
For the "Additional information" fields, I would suggest replacing (optional) with (recommended) in all cases.
The changes to the confirmation page look good. I might suggest adding some smallish text under the green bar that helps emphasize that contributing to Commons is a public service in a way that uploading to most other sites is not. Something like Your contribution adds to the sum of freely available media providing knowledge for the world.
I notice that the "Other information" generic field has been removed. Some users or tools may use it, so I'd check to see if anything is being impeded/lost there.
@Sdkb Thanks for your opinion. Just briefly on the "100 characters limit": that limit is already in place (even though is slightly higher, it should be 250 or something around that), we're just confirming it. Sannita (WMF) (talk) 12:11, 21 March 2024 (UTC)[reply]
A few thoughts:
Having to uncheck "Same as caption" to enter a description every time will mean an extra click for me, every time. My preference should be remembered (or be a user setting). How will this work with multi-image uploads?
Users should be strongly encouraged to enter a description, if not mandatory. (Remember also that description is wiki-text; caption is plain text.)
At least one category should be mandatory. Users should be invited to enter multiple (plural) categories, not just one.
We need to tighten the wording on "depicts", to ask people to be precise as possible, and not duplicate. If the user has provided "depicts=Mississippi", we don't also need "depicts=river".
Upload date is not necessarily the date taken, even for own works.
[I'd go a step farther than that: upload date is almost never the date taken, even for own works. Some people who use camera phones upload almost immediately. Almost no one else does. - Jmabel ! talk08:14, 13 March 2024 (UTC)][reply]
@Pigsonthewing @Jmabel @C.Suthorn Thanks for this thread, I can also personally confirm this could be the case for some of my uploads with my volunteer account. This however begs the question: is date of creation/publication more important than date of upload? Should we change the name of the label accordingly? And in your experience, can dates of creation and publication differ? Sannita (WMF) (talk) 18:58, 22 March 2024 (UTC)[reply]
The indubitably can and often do differ; date of creation/ publication is the most important (although we need both) as it can effect the copyright status of the work. Date created is also relevant for a subject which has changed (Is this a picture of the building before or after restoration? A portrait of someone before or after their appointment to the position that made them famous?). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:33, 22 March 2024 (UTC)[reply]
Date of upload is always known, and is always reflected in the file history. We absolutely do not want the date of upload to Commons as the supposed date of the image unless it happens to be uploaded the day it was taken. We should never need to query the user for the date of upload. In fact, an ongoing problem is that people upload logos, old images, etc. with an inaccurate and implausible date, which turns out to be the upload date. - Jmabel ! talk21:42, 22 March 2024 (UTC)[reply]
We need "other information"; I use it often.
The current "use this image" options should be retained; but note phab:T299064 which should be resolved at the same time as this change (if not sooner)
The final screens should have a "go to image page" option.
@Pigsonthewing Thanks for your opinion. Just briefly on your first thought: we're thinking of making "same as caption" as a preference, but we still need to evaluate how much work it will be. About multi-image uploads, I can confirm it will work the same as today. Sannita (WMF) (talk) 12:15, 21 March 2024 (UTC)[reply]
On the final upload confirmation page, "xxxxx.asdgg" (the resulting text caption) could be replaced by the SDC caption entered previously. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:38, 12 March 2024 (UTC)[reply]
My main issue is that if you first (1st) type in the "File caption" field that it's much more difficult to detect any errors.
Regarding the idea that the "File description" field should be checked by default, personally I think that it would be better to have it checked by default. Also, I am not sure if we should move the focus to the "File caption" field first (1st), personally my issue with the "File caption" field vis-a-vis the "File description" field in the current iteration of the MediaWiki Upload Wizard is the fact that the "File description" field is much bigger and easier to correct, if you type a lengthy description in the "File caption" field or make a mistake earlier it's not easy to find. Let me give an example (see the attached screenshot - above on for mobile devices, to the right for desktop users).
Personally, I prefer to write the "File description" before I write the "File caption" for the very reason that it's extremely inconvenient to use the very narrow and short field. Since the MediaWiki Upload Wizard changed I also cannot stack multiple licenses for "This file is not my own work" anymore, before I could stack it like this:
PD-Vietnam
PD-US-expired
But now if I click on the "Enter" (or the "Execute") button then rather than letting me add the next license it just sends me to the next field.
Remember that public domain files are required to have both a license for why they are free in their country of origin and the United States of America (if the work is alien (from a US perspective) in origin). The current version of the MediaWiki Upload Wizard makes uploading alien works (from a US perspective) more tedious.
This same inconvenient software is used for the "File caption" field but not for the "File description" field. I don't mind the "File caption" field having this limitation, but I don't see why it should be expanded to any other field. For the aforementioned reasons I simply cannot support any changes that make it more difficult for people (especially novice contributors) to access the "File description" field, the "Same as caption" box should be unchecked by default.
Regarding the above comment "People who upload from phone will likely use the commons smartphone app, not the wizard, making it even more likely that uploads on the wizard were not created on upload day." (C.Suthorn (@Life_is@no-pony.farm - p7.ee/p), I'd go even further and state that the proposed changes solve nothing while they would create additional problems, the Wikimedia Commons already records when a file is uploaded to the Wikimedia Commons, every file has the "File history" field below, on top of that, the date of fixation for any digital photography is typically captured in a file's metadata, so any changes to the "Creation / Publication" field would inevitably create more problems than it solves as the current version can already read a file's meta-data and can be edited to be corrected. For example, a public domain document was scanned by a photocopy machine in 2006, but the original document is from 1825. With the current system the meta-data from the scanning device is captured and published, the date and time that the file was uploaded to the Wikimedia Commons is captured and published, and the uploader can correct the date by simply typing in "1825" in the "Creation / Publication" field. I genuinely don't see what's broken about the current system for recording the file's original creation and / or publication that needs to be fixed in any way.
To me, the solution for this is easy, (1) integrate the same software for redirect detection and automatic correct that HotCat utilises to the MediaWiki Upload Wizard, HotCat works amazingly well with redirects so the software has already existed for years, (2) add every Wikimedia Commons category to Wikidata and automatically import translations, redirects, and alternative names and / or spellings, obviously these would have to be at least 180 (one-hundred-and-eighty) days old or something to prevent cross-wiki vandalism, a robot 🤖 would automatically create all these redirects, and (3) create software that detects the display language of the viewer and translate category titles accordingly. This would mean someone with the default language as English would see "Category:Passports of Japan" but someone browsing this website in Japanese would see "Category:日本国旅券" (apparently the Japanese Wikimedia websites use the English word), a better example would be "Category:Moscow" Vs. "Категория:Москва".
Obviously, most of the above changes would be outside of the scope of changing the MediaWiki Upload Wizard, but implementing redirects for categories would work. I don't think that we should be making categories mandatory until we've made it convenient for speakers of every language to add them without having both an in-depth knowledge of the English language and the naming conventions of Wikimedia Commons categories, plenty of categorisers work with uncategorised media every day that have better knowledge of these subjects that might end up having to clean up heavily fragmented novice files in overpopulated main categories. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:48, 25 March 2024 (UTC)[reply]
TL;DR, I really like some of the changes but I don't think that we should disable "File descriptions" by default because of some display and typing issues with the way users can enter captions, I think that there's nothing wrong with the current way of noting years and specific dates and don't see what the proposed changes will improve in this regard, and while I think that adding categories should be strongly recommended, I don't think that they should be mandatory until we've found a way to improve category suggestions and multi-lingual category integration through software improvements. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:52, 25 March 2024 (UTC)[reply]
Do any of these proposed changes make your contribution flow more difficult? If yes, how?[edit]
...
Do any of these proposed changes help make your contributions easier?[edit]
Having caption and description together makes sense most of the time, as they are normally the same or very similar. Also, it makes way easier for new contributors to use, as the difference between both is only relevant for a small niche of files. Also, it would be really great if we could have a map with a pin to mark where the images were taken. This can be done now with external tools, but incorporating it would make way easier to find images of buildings that are uploaded but not geo-referenced. -Theklan (talk) 11:34, 12 March 2024 (UTC)[reply]
That's great! I have seen that now there's a map if we add coordinates to the file, but this is not draggable. I think that it will be a future feature, so I'm already waiting for it to happen. Theklan (talk) 19:01, 22 March 2024 (UTC)[reply]
I often upload multiple photos from one vilage/street/locality. So all these photos have almost same name and often same desription (eg. object in street XYZ). The only difference is by coordinates and later I sort most of these files to subcategories which are connected with wikidata item. But sometimes my phone GPS stucks and all files have sme cooordinates or very imprecise coordinates, so map displaying position of photo will be VERY useful, but it should be map with details (phab:T329852). JAn Dudík (talk) 10:13, 23 March 2024 (UTC)[reply]
Is there anything else you would like to see improved / added / removed in UploadWizard? If so, why?[edit]
Choosing the right category is the most difficult part of the uploading process, as it is difficult to know if a category exists. New users normally add there tags, like "building", "person", "landscape" that are not relevant for a category, but they are for the structured data. I don't have a solution for that, but using the structured data and coordinates could be a good way for suggesting categories, like in the Commons App, which suggests nearby objects and loads the category from the Wikidata item. Also, loading a small category tree (similar to cat-a-lot) could be a good way to choose the relevant category: imagine you have a photo of the interior of a church in a Smalltown. You type the name of the village, there you get "Category:Buildings in Smalltown", you click and you have: "Category:Church of the Sacred Encyclopedist in Smalltown", and there you have "Category:Interior of the Church of the Sacred Encyclopedist in Smalltown". That's the right category, but it would be hard to find if you don't know beforehand that it exists. Also, it would reduce the burden to re-categorize for experienced users that don't know if this is the Interior of the Church of the Sacred Encyclopedist in Smalltown or, instead, the Interior of the Parish of Saint John in Smalltown". -Theklan (talk) 11:41, 12 March 2024 (UTC)[reply]
@Theklan @TheDJ @Jmabel Again on categories (and the difficulty of adding them): do you think it's a good idea to limit the possibility of adding a category only to existing ones? In other words, if a user tries to add a non-existing category, it would be prevented to do so. Would it be a good idea in your opinion? Sannita (WMF) (talk) 13:08, 29 March 2024 (UTC)[reply]
Maybe. I don't use the Upload Wizard myself, and I'm not its "target market" but I'd be frustrated on upload if I couldn't add, for example [[Category:April 2024 in Seattle]] if noone had already created it and then go about creating it later. But this is part of why I avoid coming through a "Wizard". I would think that nonexistent categories more call for a warning (and a link to an information page explaining why they are a problem) than a prohibition. Plus definitely some bot-based thing that would hit up the user's talk page if they haven't created the category in an hour or so. - Jmabel ! talk16:56, 29 March 2024 (UTC)[reply]
I think that's not a good idea. From my experience, I upload bulk images of the same object (for example, interior of a church), and then I create the categories if they don't exist. Also, the problem is usually the opposite for new users: the category exists, but it is extremely broad (people, portrait, building). So I think we would have more work for the users who know how to use categories than for those who don't. Theklan (talk) 17:01, 29 March 2024 (UTC)[reply]
Same answer as Theklan. Sometimes I create new categories while filling out the description step, but caching means the UploadWizard still warns me about the category not existing. I would be fine with an ignorable warning as we have now. the wub"?!"22:42, 29 March 2024 (UTC)[reply]
Regarding location information: just a reminder that we do distinguish between camera location and subject location. These can differ significantly. Also, camera heading becomes more and more important the longer the "zoom" on the camera. Both the georeferencing templates and SDC allow for the heading to be stored, but as far as I remember Upload Wizard ignores that information if stored in EXIF and does not offer a possibility to enter it manually. --El Grafo (talk) 13:08, 12 March 2024 (UTC)[reply]
Indeed, both could be asked: subject coordinates, and camera coordinates. And if the later is available via EXIF, still it could be a good option to add the option to add the coordinates of the object, which could be infered otherwise from the Wikidata item. Anyway, having the option to add the coordinates there could be make things way easier. Theklan (talk) 13:12, 12 March 2024 (UTC)[reply]
There should be also posibility to delete coordinates (or set no coords applicable) - If I made photo of some person / movable object, coords are usually not wanted/relevant. JAn Dudík (talk) 10:16, 23 March 2024 (UTC)[reply]
And people often want to remove coordinates for reasons of confidentiality, especially when photographing in private residences. - Jmabel ! talk17:51, 23 March 2024 (UTC)[reply]
if the browser or the tab crashed during the upload process all text entered should be saved and offered to the user again. Broken running uploads should restart at the position already uploaded so far.
if the resolution of the image is smaller than 4MP or the file size is smaller than 2MB a popup should ask if the user has a higher resolution of the image available and warn, that the license is valid not only for the uploaded file but for all higher resolitions also. It should also warn that small resolutions are often stolen from the web and are likely to get deleted as COPYVIO.
if there is no EXIF or the EXIF contain Facebook or Twitter IDs the user should be warned, that the image appears to be from social media and might be deleted, if the user has no prove of own work or free license.
category selection should not be with autocomplete but as a tree browser of the commons category tree.
categories are one language only. The category selection should not be by the actual category name, but the language localized wikidata name of the category should be used for selecting categories.
When uploading, you can choose that the file includes previously free files. It could be interesting to add there which ones, so they can be automatically cited if those are in Commons. -Theklan (talk) 22:27, 12 March 2024 (UTC)[reply]
My thoughts:
I know lots of people think that adding categories should be required, but I think it's a terrible ask of users. My idea would be to make a list of 'follow-up tasks', dump them in a db table and ask (with reminders) people to complete them at a later point in time. This could be done for categories, location, depicts, adding timed text etc. Auto-delete the tasks after 2 months, and use things like {{uncat|uploadwizard}} between upload time and follow-up tasks. I think that is much more scalable and you can provide dedicated UX that will help people through the tasks and educate them at the same time.
For creation date I also like the suggestion to make it possible to grab this from EXIF. "This file might have been created at xxxx. Use this value for this field?" something like that.
Same for location
There are several things that are only possible with advanced permissions. Uploading webp and mp3 are some of these. I think this should be handled in UW and explained to the user, because right now it can be very confusing when you encounter this.
One thing that I miss in the learn and the describe step (and something that the release step DOES explain), is WHY we are asking this of people. Maybe at the top of Describe we could have something like: "In order for media files to be re-usable, next to being allowed, they have to be discoverable. Please provide accurate descriptions and additional information to facilitate discovery by other users." Maybe someone has a better text, but the main point being that we should be explaining why this form works different from other upload forms that people might be used to. —TheDJ (talk • contribs) 13:27, 13 March 2024 (UTC)[reply]
"This file might have been created at xxxx" is a bad wording. We don't care when the file was created, we care when the content was created. At least for any image format (JPG, PNG, GIF at the very least) we should say "this image [emphasis mine] might have been created at xxxx." If it is a scanned old photo, a logo, a photo of a 2-dimensional work of art, that wording is better, and in no case that I can think of is it worse. - Jmabel ! talk18:00, 13 March 2024 (UTC)[reply]
If the file includes location metadata, UploadWizard should give the user the option to strip out the location metadata before the file is published. Nosferattus (talk) 00:49, 14 March 2024 (UTC)[reply]
Multi-lingual category redirects, well, just HotLink level redirect handling in general. I also agree with the suggestions made by users "TheKlan" and "TheDJ" above regarding the suggestions for more specific category through software suggestions and not making categories mandatory. I really love categories and hope that they can be improved in the future, but unless those improvements are happening we shouldn't be shoving a broken system down the throats of confused novice users, even experienced users don't know how to navigate every niche category tree.
Also, please make it easier to add licenses in multiple lines again (like before).
I also agree with user "GPSLeo" in "we need more flexibility for adding or removing fields and more URL prefilling functionality", a more customisable MediaWiki Upload Wizard for power-users would probably preferable. Perhaps any user with an auto-patrolled user right and higher should have access to a customisable version of the Wiz, that or any user as long as they're knowledgeable enough. Perhaps a "Build your own Upload Wizard" tutorial and functionality would greatly help everyone.
New users should be encouraged to write feedback, maybe anyone doing their first (1st) upload and anyone doing their initial 10 (ten) or so uploads without having previously left any feedback should be given a message telling them to write about their experiences with the MediaWiki Upload Wizard, what they liked and what they disliked about it. The people who browse and write on this page aren't the same people as the novice users that won't make their voices heard in any community spaces. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:06, 25 March 2024 (UTC)[reply]
What are your thoughts on the information we are collecting here?[edit]
As a moderator, what are your thoughts on the information we are collecting here? Is there anything else you would like to see in the way information is collected that could improve your moderating workflows?
...
Specific question about creation/publish date[edit]
What is the current way in which you use the "date published/created" field? Is this information required for both "own work" and "not own work"? Should this remain a mandatory field?
I think this is mandatory, but it could be more flexible, for example giving the possitibility to add only Year or even Decade for old works. -Theklan (talk) 11:44, 12 March 2024 (UTC)[reply]
Agree with Theklan, it should be possible to just enter a rough date such as a year; not allowing this probably has caused a lot of faulty data and a note could be displayed if one doesn't specify the day that is asking the user to enter a more precise date if possible. --Prototyperspective (talk) 13:00, 12 March 2024 (UTC)[reply]
date needs to be mandatory. However inputs like "between 1976 and 1981" or "15th century" should be possible.
an explantion is needed that the date of creation of the work is meant is needed
date from exif can be imported, but then a popup should ask "is this the date of creation or of changes by photoshop?"
You could ask for a level of precision for the date. There is a big difference between the year 1900, the 20th century, the decade 1900-1909, and ca. 1900. I have seen sources presume that just the year means 1 January of that year; please let us not make that mistake. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:50, 12 March 2024 (UTC)[reply]
Please don't remove this pencil ✏️.
"date needs to be mandatory. However inputs like "between 1976 and 1981" or "15th century" should be possible." (C.Suthorn (@Life_is@no-pony.farm - p7.ee/p)) That is already possible with the current MediaWiki Upload Wizard, in the mock-up's I didn't see the "pen" / "pencil" found today, which is a bit worrying, but this could just be an issue of the artist that made the concept image rather than a technical change. Personally I'm not a fan of moving the date 📅 to the "Licensing" step of the upload process, but I think that adding extra pop up's is a worse idea. While people should be better instructed on how to fill in dates, I am not sure if adding a pop up to files with EXIF dates to ask if Adobe Photoshop™ made it is a good idea simply because most novice users will probably try to upload their own photography rather than altered files. In case of the dates I'd rather say "why "fix" something that isn't broken?", especially since "I think this is mandatory, but it could be more flexible, for example giving the possitibility to add only Year or even Decade for old works." (TheKlan) Is already a feature of the current "Publication date" field. In cases where works that I'm uploading contain no date but the source indicates that it's from the 19th (nineteenth) century or a specific decade like the 1840's I already just type in "1840's" and the existing MediaWiki Upload Wizard has never had an issue with it.
While I really like "File:UploadWizard improvements - Published date.png" I only like it for removing the redundant checkbox that was added a few months ago, I don't see why the date should be moved from the "Describe" step to the "Release rights" step, now that I think about it, this makes even less sense if you're uploading multiple images at the same time. Let's say you upload a batch of images from an author whose works are in the public domain but they're not all published on the same date, if you upload multiple photographs of your own then will they all have the publishing / creation date based on the EXIF data of the first (1st) image? In the middle of writing this I suddenly had the realisation why this would absolutely not work, and that's because this wouldn't work for multiple files.
The "date" field should absolutely not be moved from the "Describe" step to the "Release rights" step for the very simple reason that when uploading multiple files it is more manageable in the current iteration, especially if they all have the same license and creator, but are made on different dates (which is also true for "Own work" files which all contain separate EXIF data like literally any batch of photographs).
Let's say Sally goes to a Wikimania event, she photographs 10 (ten) pictures at a presentation, they were all made on July 4th (fourth), but at different times, the EXIF data will record these differences often to the microsecond and that shows up at the current MediaWiki Upload Wizard. She would probably be very confused if all her photographs of this 2 (two) hour long event said that they were taken exactly at 16:23. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:34, 21 March 2024 (UTC)[reply]
Do not do field tests on Wiki Loves contests[edit]
If you are planning to do some kind of field tests or A/B tests please do not do this during the period of the Wiki Loves contests with WLE from May to July and WLM in September. If you are doing field tests during this time please exempt upload campaigns from the changes. The organizers can not give support if they do not know what version the uploader sees and some tutorials might become outdated. In case of a bug there is the danger that many contest contributions get lost or at least lose some important information. GPSLeo (talk) 07:05, 15 March 2024 (UTC)[reply]
@GPSLeo Thanks for the heads up. We're not planning to do tests during this period at the moment, but it could be possible that we will do some changes to the UI depending on how the current feedback period goes. Let's keep in contact on this. Sannita (WMF) (talk) 10:42, 15 March 2024 (UTC)[reply]
If uploader think that Flickr user is the photographer it should be possible to chose {{PD-author-FlickrPDM}}. It would also be great if the uploader could chose another PD license tag. For example {{PD-old-70}} or {{PD-USGov}}.
I do not think this is a bug. While we might come up with another way to do this, the Public-Doman mark on its own does not tell us the rationale for being public-domain, which Wikimedia Commons requires. - Jmabel ! talk18:54, 25 April 2024 (UTC)[reply]
Hello @Jmabel, if a "bug" to which you referred is a software bug, then this appears to be one.
From the Wikipedia entry, "A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways."
The Upload Wizard tool is certainly producing "errors" (changing to a different Creative Commons license than the license used at the file's source webpage) and its actions "produce an incorrect or unexpected result, or to behave in unintended ways."
Better would be a choice menu to add the more specific PD-USGov tags here: Category:PD US Government with the added ability to add that same specifically chosen tag to multiple files with one click before uploading with Upload Wizard. It is a good tool that will become even better. -- Ooligan (talk) 00:36, 26 April 2024 (UTC)[reply]
@Jmabel Humans should chose the license and that is why the uploader should add it. If user on Flickr uses {{Cc-by-sa-2.0}} it does not specify why it is cc. We just assume that the Flickr user is the photographer. Its the same here. We assume that the Flickr user is the photographer and chose {{PD-author-FlickrPDM}} unless we have reason to think its not own photo. For example if it is a photo or a painting from 1905 for example the license should be PD tag to tell copyright expired. I see no reason why the uploader should not have the option to chose the correct license during upload. If needed we could have the option that if uploader does not specify a license then the Upload Wizard picks cc-zero. --MGA73 (talk) 20:08, 26 April 2024 (UTC)[reply]
If the Flickr user put a PDM mark on their own photo, that probably signals the intent to put their file in the public domain, but it also suggests someone who does not understand copyright well. That is certainly not the intent of the PDM mark on Flickr: if that is your intent, you should use CC-0.
We absolutely should not put CC-0 on a photo where the rights-holder did not specifically grant it. {{PD-user}} would be much more on the mark, except that it is only for our own users. We probably should have an analogous {{PD-Commons-user}}. The problem with CC-0 is that it has a specific waiver and public license fallback that are in no way implied by PDM. - Jmabel ! talk05:06, 27 April 2024 (UTC)[reply]
I think whoever made the upload wizard this way thought that CC-0 is a temporary template to use while someone (uploader) picks the right license. It would perhaps be better to create a "PDM-needs-check" to add on files where uploader does not pick another license (as a better temporary template than CC-0). If uploader pick a specific license I think the Flickrreview bot can pass them. If I upload a photo from the internet and claim PD-USGov for example there will in most cases be no review by someone else. So it's not a big problem if Flickrbot confirm that the file was uploaded as PDM. If anyone thinks the license is wrong they can add the correct license or nominate the file for deletion. --MGA73 (talk) 17:50, 6 May 2024 (UTC)[reply]
@Sannita (WMF) I want to raise your awareness on a bug in upload campaigns where the homeButton on the last page links to https://commons.wikimedia.org/w/ instead of https://commons.wikimedia.org/wiki/. This should be very easy to fix. GPSLeo (talk) 14:03, 29 April 2024 (UTC)[reply]
I am puzzled by the enhancements to the Upload Wizard given that uploading a new version of a file over 100Mb remains impossible. Additionally, the requirement to wait until after the upload to enter file details like title and description—potentially taking hours—feels unnecessarily cumbersome. In contrast, the Internet Archive allows for the seamless upload of large file volumes without such constraints. It's concerning that our upload wizard still does not support large files.
Here's how to replicate the issue:
Attempt to upload a new version of a file by clicking "Upload a new version of this file."
The process is blocked if the file exceeds the 100 MB limit, even though the original file may be larger.
What occurs is that the upload limit of 100 MB is inadequate for uploading a new version of a file originally larger than 100 MB. Ideally, the file should upload without such restrictions.
We are using Wikimedia Commons, and this has been an ongoing issue for years. It is frustrating. I suggest we implement a feature that allows entering all necessary details for files—such as file name, description, and category—during the upload process. This change would enable us to leave files uploading overnight without having to return to input details post-upload, streamlining the entire process. Related tickets: [2][3]Wilfredor (talk) 16:23, 2 May 2024 (UTC)[reply]
@Wilfredor: thanks for your message. As I said, I'll try to get both tickets on the devs' table as soon as possible, but I also asked you for clarifications on the second ticket. You can answer in Phabricator, so that I can update the ticket. Sannita (WMF) (talk) 16:42, 2 May 2024 (UTC)[reply]
When you upload an image to a platform, you typically follow a procedure where you first upload the image and then, only after it has been uploaded, you can add descriptions, tags, or other metadata. This can be inefficient if you have multiple images to manage, as you have to wait for each image (and all images) to upload before entering its information.
A better approach could be to allow users to input all relevant data for each image (like title, description, tags) at the same time they select the image for upload. This data would then be processed together with the image upload, streamlining the workflow and saving time, especially when handling multiple files. This method would eliminate the need to wait for each image to upload before entering information, making the entire process more efficient. Wilfredor (talk) 16:52, 2 May 2024 (UTC)[reply]
@Wilfredor @Sannita (WMF) To clear this up: revision upload is not handled by the wizard. Files larger than 100MB can only be uploaded with chunked upload. There are some tools that handle chunked upload. If you do not want to use such a tool, you will need to click on the link to the right of "upload a new version" (which is limited to 100MB, as it is not chunked), that is called "chunked upload" and starts the bigchunkeduipload tool by Rillke and mentioned by @PantheraLeo1359531. Also, if you use this tool for uploads you need to enter all the information BEFORE you select the file to upload but this does actually not matter, as for revision uploads this information is disregarded anyway and only the upload comment is actually used. On the bright side: Rillke's tool is very stable (only Offroader is more resilient). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 16:26, 15 May 2024 (UTC)[reply]
Well, we got one more extra click in the Upload wizard. Three more extra clicks in half a year. I will invest my time into writing my own wizard, I consider this development extremely user unfriendly. I do not believe anymore that the developers listen to us. Ymblanter (talk) 18:41, 15 May 2024 (UTC)[reply]
Hi @Ymblanter, I'm really sorry to hear this. I'm trying my best to obtain from the devs the possibility of reducing the extra clicks for experienced users, but there is also a discussion ongoing about preference bloating that we're considering. I'll pass on your feedback anyway, and try to make the case for reducing the burden on experienced users once again. Sannita (WMF) (talk) 08:40, 16 May 2024 (UTC)[reply]
Thank you but for the time being I am back to the old form. I will probably still use the wizard for uploading several similar times because the function of taking options from one file to the others is convenient, but for one file I think the old form is now faster. Ymblanter (talk) 09:59, 16 May 2024 (UTC)[reply]
Honestly, I don't understand why you haven't tested it well.
We have WLE in order to create new content and to get new photographers that are used to other websites and we increase the number of clicks in order to upload content and we lose good functions. In real life I have to deal with software improvement but these things wouldn't happened. I'm sorry, I'm disappointed.
Do you deploy changes to the Beta-Cluster before you deploy them on the production system? If you already do this it would be good if you would make an announcement after you deployed a change there that we can test for such bugs. GPSLeo (talk) 16:52, 16 May 2024 (UTC)[reply]
Hi @Sannita Can the community expect the problems to be resolved in the next two days? Or is the development team waiting for Pentecost to be enlightened by the Holy Spirit? Then I suggest that you please set the wizard to the status of May 13th. back and give yourself plenty of time for proper testing. Then perhaps you can present the new version as a Christmas present to the community. Good luck! --Im Fokus (talk) 17:29, 16 May 2024 (UTC)[reply]
@Sannita (WMF) Well, that's what I assumed. It's nothing but a matter of course. But how long exactly will it take? A day, two days, a week, half a month? Or even longer?
And when things are finally up and running again, you should take precautions to ensure that something like this never happens again. Because that was incredibly sloppy. After all, the errors were not in some rarely used secondary function, but in the main application of the wizard. Sorry, but that's the truth. Greetings Im Fokus (talk) 19:36, 16 May 2024 (UTC)[reply]
.png/220px-Inconvenience_of_detecting_errors_in_the_%22File_captions%22_field_compared_to_the_%22File_description%22_field_(March_2024).png)
.png/220px-Please_don%27t_remove_this_pencil_-_WMF_feedback_(March_2024).png)
Support. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:16, 17 January 2024 (UTC)
Done Task added --PantheraLeo1359531 😺 (talk) 15:43, 18 January 2024 (UTC)
.png)
.svg/15px-Pictogram_voting_comment_(orange).svg.png)
TL;DR, I really like some of the changes but I don't think that we should disable "File descriptions" by default because of some display and typing issues with the way users can enter captions, I think that there's nothing wrong with the current way of noting years and specific dates and don't see what the proposed changes will improve in this regard, and while I think that adding categories should be strongly recommended, I don't think that they should be mandatory until we've found a way to improve category suggestions and multi-lingual category integration through software improvements. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:52, 25 March 2024 (UTC)
--Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:54, 25 March 2024 (UTC).png)
