Commons talk:WMF support for Commons/Upload Wizard Improvements

Your Feedback Needed

Hello everyone! We are delighted to share with you our current designs for improving UploadWizard. Current designs for the “release rights” part include:

• Choosing the “own work” vs “not own work” step
• Specifying release right information for both “own work” and “not own work”

You can see the screenshots and the working prototype in the main project page.

These changes will try to make the upload process more intentional, so that it could prevent upload of content not intended for Commons and could decrease future burdens for administrators.

Our designs are based on the feedback we received from uploaders and moderators on Commons that we interviewed from July to September 2023. You can learn more about this by reading our initial report on uploader research and the summary of the administrator interviews (a full report on our investigations will be shared at a later time).

We are looking for your feedback about these designs for the “release rights” step improvement, that we have validated with several user tests.

In addition to the general question about what do you think about our proposal, we have some more specific questions to ask you:

Questions about “Own work” flow

1. Do you think that re-ordering licenses from most free to least free (i.e. CC0, CC-BY, CC-BY-SA) would improve understanding of the licenses from users? What are your thoughts on the order of licenses?
2. Is there a recommended license uploaders should select for their own work?
3. In these designs there is no default select option, in order to encourage more intentionality in choosing the license from uploaders. What do you think about it?
4. We added an option for those who realized a media with the help of an AI tool. Do you think it’s necessary or helpful to add this information or not? How should this info be made clear (template, tag, …)?

Questions about “Not own work” flow

1. Are there any situations where the uploader doesn’t need to enter “author” information other than the ones captured in the designs?

Thanks in advance! - Udehb-WMF (talk) 10:12, 10 October 2023 (UTC)

Hi, File:Upload Wizard improvements - Own work.png and File:Upload Wizard improvements - Not own work.png are quite an improvement, but be aware "works in public place" is not sufficient in many countries, where there is no freedom of panorama. What is bulletproof copyright-wise are pictures of people, nature, plants, events, vehicles, etc. Yann (talk) 10:17, 10 October 2023 (UTC)

Hello @Yann: , thanks for your feedback. Regarding your comment about FoP, we are not planning to address it at this point, since the solution is likely to require some more input from experienced users like you.

One potential idea, that came up while discussing your feedback with the team, is that we can add an additional (optional?) step to ask the uploader if the picture is about a monument, public building, public art, etc. and if they are knowledgeable about FoP or not. Do you think this would help detecting in time images that violate FoP or do you think it’s just an additional burden? What would work in your opinion? - Udehb-WMF (talk) 11:07, 20 October 2023 (UTC)

@Udehb-WMF: The ideal would be a system which asked where is the monument, and then says if it is OK or not. But it will get very complex. We need at least a warning (may be with a list of countries) that the picture is a derivative work. Yann (talk) 12:29, 20 October 2023 (UTC)

@Yann Thank you for this insightful suggestion! Your idea of asking for the location of the monument and giving feedback based on that is interesting, but just like you outlined, is technically complex and is currently not within the scope of the current phase of the project. We will certainly think about this and the idea of providing a warning regarding derivative works when we start our work on FOP-related issues. Take care. -- Sannita (WMF) (talk) 09:24, 26 October 2023 (UTC)

First, it is an improvement, but it adds quite a number of extra clicks for own work - four or five. This is quite a lot. We can consider giving some trusted users a right to skip this part (either by assigning a new user right, or in some other way), or pre-filling the defaults. In any case, CC-BY-SA 4.0 is the default version and should be the first in the list. We should also realize that many users do not understand the difference between these licenses very well, and should either add some text, or remove the box anyway (e.g. by pre-filling cc-by-sa 4.0 and leaving and option open for changing the license).--Ymblanter (talk) 10:25, 10 October 2023 (UTC)

Hi @Ymblanter: , thanks for your feedback. We are not keen on adding right now a way for experienced users to skip this part, because we wouldn’t know who can be considered “experienced enough” or a “trusted” user at this point. We can think of adding a particular user right, though I don’t know how much time it would take to do it, but first of all I think the community should decide first who should be entrusted with such user right.

About licensing, we did some user tests with the proposed order of licenses, and from our data the order was not that relevant in choosing the license. But if there is consensus on reordering the licenses again, we’re ready to change that.- Udehb-WMF (talk) 11:09, 20 October 2023 (UTC)

This is ok, but I am not willing to use the wizard if it gives me five extra clicks. I will either manage to write my own wizard for personal use, or will go back to the old form. Ymblanter (talk) 12:52, 20 October 2023 (UTC)

• There is disparity between the wording "anyone is free to use it" and "is free to share". The two should be made consistent.
• The wording "Do you know what Creative Commons licence this was published under" is inappropriate; there are many acceptable licences that are not by CC.
• The wording "the author is now unknown" is problematic, as it does not differentiate between "not known [to the uploader]" and "cannot be determined"
• The wording "Please confirm... does not include any copyright material" excludes de minimis cases
• The wording "photos of myself, my family..." is problematic because we often ask article subjects or their relatives to donate photos; and allow Wikimedians to upload a selfie for their user page

Has any A-B testing of the above, and other new wording, vs. alternatives, been done? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:46, 10 October 2023 (UTC)

Thank you for your detailed feedback, Andy Mabbett (Pigsonthewing). We appreciate your insights on the wording and its implications.To address your question about A-B testing, we've conducted user tests and iterations for these specific improvements. These changes are thought-through from both a design and legal perspective. That said, community feedback like yours is crucial to us. We're actively collecting responses to understand how we can further improve the workflow. Your points will be considered as we continue to refine the current improvements to Upload Wizard. Udehb-WMF (talk) 17:08, 10 October 2023 (UTC)

Hello Andy, we have analyzed your feedback and we have some more answers to give.

1. regarding the disparity in wording: we would argue that the minor difference in semantics is important. One issue that is usually overlooked by uploaders is that people do not realize that anyone can use it for any reason within the scope of the license. Hopefully, this will call attention to it because this issue has been evident in testing, as well as the VRT tickets where people don't realize what uploading to Commons means and try to remove their media later on. From a UX perspective, making a difference between the phrasing of the two makes it slightly more clear that they're different choices. None of the problems this phrasing is trying to solve is going to be a magic bullet to solve problems raised, but the two are intentionally different and, over the course of thousands of uploads, a minor change like this could move the needle slightly.
2. regarding all other non-CC but acceptable licenses: yes, what you say it’s true, but the most common licenses that are used are CC, and currently UploadWizard only mentions CC as well. However, entering a different license in wikitext is still available for an advanced user. But for the normal user, who knows little about open licenses or Creative Commons, answering this question alone might be already a big leap to take, so we want to make sure that this step is as simple as possible for them to take, without either having them to lie about the license, or quitting the process because it’s too complex.
3. about author unknown/not known to the uploader/cannot be determined: good point, we will try to find a way to split the two cases and reword the phrase. We’ll get back to you.
4. about de minimis cases: de minimis is an advanced concept. If you know what that is, then you already would know that it's fine to click on it worded as is. If you don't, you'll be confused. It's reasonable to assume that an average user also can’t be properly educated on de minimis within the context of the UploadWizard educational dialogue box to make a reasonable guess. We can add an info pop up, with an educational dialogue box that explains all, but even that might be confusing to people not acquainted with the concept, and a simple repetition for those who are. Does this resonate with you? -Udehb-WMF (talk) 11:50, 20 October 2023 (UTC)

• Looks and it's great that you added a field for AI-generated media which is something I intended to propose otherwise. It would be good if selecting that added a prominent template above the description that makes it clear the image is AI-made. However, there I see a very large problem at the bottom of the "Own work" page: Yes, this media has encyclopedic value, and provides knowledge, instruction, or information to others. is not a fitting description for COM:SCOPE (and additionally discourages people too much from uploading useful media as this is easily misinterpreted when they can't readily easily see how exactly the file could be useful in a Wikipedia article). The scope is described as "realistically useful for an educational purpose", and even when not considering Wikimedia-external use of media, there also multiple other Wikimedia projects next to Wikipedia where they could be useful and of course the free media can be useful when only on WMC as well. So this sentence really does need some improvement.

If goal is to discourage uploads & 3 tool proposals

If you did this because you intend to discourage upload further than the Upload Wizard guide already does: that way many constructive uploads would get discouraged as well and if time to manage the influx of media is an issue: needed is more work on scripts and tools that a) automatically detect copyright violations etc b) automatically subcategorize and categorize (cat-proposals at least) media c) and better ways to see most relevant or best images of a category and it subcategories with a button like "show all images of this cat and its subcats on one page" (images get hidden deep down in arbitrary subcats with no way for scroll-to-explore/find with all on one page).

1. That's more intelligible and a more reasonable order. 2. It would be nice if CCBY was the default, not the SA one – it always confounded me why SA would be the default 3. I don't think that's a good idea since uploading should be as easy and accessible as possible 4. It is helpful and (sooner or later) probably necessary. I think a template well-visible right underneath the image would be best (another thing to consider is adding something to the file titles).

Prototyperspective (talk) 21:22, 14 October 2023 (UTC)

Hi @Prototyperspective: , thanks for your feedback! As we already noted elsewhere on the page, we already are working on a different wording for the "encyclopedic" part. We are thinking of rewording it linking directly to Commons' guidelines, but we are still defining the new message. We'll get back to you when we're ready.

About AI-generated media: we can work on such a feature, but we would first wait on the community making the template in the first place.

About the order of the licenses: we are not defining any of the licenses as default, merely rearranging their order – and asking feedback about it. - Udehb-WMF (talk) 12:29, 20 October 2023 (UTC)

@Prototyperspective Also about AI-generated media, you might want to take a look at phab:T347750 and phab:T347755 to get to know how we have for now defined the tracking for AI generated medias. Sannita (WMF) (talk) 19:01, 20 October 2023 (UTC)

The explanations for the CC licenses are helpful, but I would support the suggestion below for including a way to display/choose a wider range of licenses. I'd also note that these tweaks don't seem to handle well the common issue I see where someone takes a photo or scans something then applies the license and attribution based upon the derivative image they created, instead of for the work they photographed. Perhaps this can be addressed in the "Is this entirely your own work?" question by adding something like the green text to "Examples: If someone else's work is visible in the work you are submitting, your work is a reproduction or capture of someone else's work, or if you've mixed someone's work with your own." —Tcr25 (talk) 20:33, 16 October 2023 (UTC)

@Tcr25, thanks for this additional feedback. About the wider range of licenses, as I already told you, we're evaluating how to include that in the form, and we'll get back at you as soon as possible. About the suggestion you make about "not entirely my own work", we're evaluating your proposal for next iterations, but be aware that this is technically complex to solve, as there could be cases in which capturing someone else's work could be perfectly in line with Commons guidelines, and we want to avoid tagging the correct image for the wrong reason. We'll keep you posted about it. Sannita (WMF) (talk) 13:46, 26 October 2023 (UTC)

Thanks, I understand, but this doesn't seem to be a technical issue, so more user experience/interface and how you explain the workflow. As Kritzolina notes below, the word "work" is a big ambiguous and too heavy reliance on it (without broader examples) may add to confusion and inappropriate licenses. Take for example File:Robert Hooper Portrait PAFA.jpg, since I took the photo of that portrait, uploading it as my own work with a CC by SA license would seem logical and I often see at DR files like that labeled as "own work" and dated to when the photo was taken, instead of properly crediting the artist and work of art. Maybe the simplest solution would be a third workflow built around {{PD-Art}} and {{PD-Scan}} for contributions like these. —Tcr25 (talk) 14:41, 26 October 2023 (UTC)

@Udehb-WMF: The "own work" vs. "not own work" distinction is nice, clean, and simple, but not quite comprehensive if we're trying to cut down on the number of images tagged with {{No permission since}}. Generally, we require COM:VRT if 1) the uploader claims that someone else is the author of the work; or 2) the work has been previously published (or both). The purpose of VRT in the first case is to get a legally binding document from the purported author (assuming good faith that the authorship is correctly identified), since they did not go through the UploadWizard clickwrap. The purpose of VRT in the second case is to get some piece of evidence that cannot easily be replicated by someone stealing the image from an external website and pretending to be the author. (That piece of evidence could consist of: being sent from an email address associated with the original location of publication, a higher-resolution version of the image which has not been previously published, etc.)

So to address the second case, we need UploadWizard to let people know that they need to go through VRT for images which have been previously published on an external website without a free license, even if it is their own work, unless they have already established their identity via {{Verified account}}. -- King of ♥ ♦ ♣ ♠ 23:18, 16 October 2023 (UTC)

@King of Hearts, thanks for your feedback. We will think about how we can include your considerations in the next iterations of our work, but please keep in mind that this can be technically complex to solve. Our main worry is to avoid as much as possible to move the burden of checking images from Commons users to VRT agents, who are a smaller subset of people. Anyway, we’ll keep you posted about it. Sannita (WMF) (talk) 14:09, 26 October 2023 (UTC)

--- " Is there a recommended license uploaders should select for their own work?"

I think CC-BY.

--- "In these designs there is no default select option, in order to encourage more intentionality in choosing the license from uploaders. What do you think about it?"

Good. No need to worry about inadvertently selecting a different license and uploading it.

[Other]

I was uploading as a name with a little appended to the username, so I want a name input field. RuinDig (talk) 23:51, 7 December 2023 (UTC)

I was uploading as a name with a little appended to the username as "RuinDig/Yuki Uchida". RuinDig (talk) 00:05, 8 December 2023 (UTC)

Strongly disagree with recommending CC-BY. I doubt you could find 5% of admins here who would recommend that over CC-BY-SA (currently CC-BY-SA 4.0), probably far less than 5%. - Jmabel ! talk 03:00, 8 December 2023 (UTC)

Additional question

• Should we disable the "Next" button when users encounter a warning about not being able to upload, effectively blocking them from proceeding without the correct information? Or should we rely on the warning alone, trusting users to make the right decision on whether to proceed or not? - Udehb-WMF (talk) 09:38, 12 October 2023 (UTC)

cc: Yann, Andy Mabbett , Ymblanter, Giftzwerg_88, PantheraLeo1359531, Ricardalovesmonuments, Kritzolina, El_Grafo

I'm tending towards no on that. Based on past experience, users will tend to just put anything that will make the system let them proceed (just my personal impression though, I have no actual data to prove that). Missing information is much easier to detect than technically fitting but factually wrong information. --El Grafo (talk) 10:05, 12 October 2023 (UTC)

I agree with that. Yann (talk) 10:14, 12 October 2023 (UTC)

I agree as well. Ymblanter (talk) 10:30, 12 October 2023 (UTC)

+1, there could be also a chance that actual correct information are entered, but the system recognizes them as incorrect --PantheraLeo1359531 😺 (talk) 13:36, 12 October 2023 (UTC)

I'm tending towards agreeing also, but I think it depends on the context. We might allow uploads with no category, for instance, but insist on a date. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:49, 13 October 2023 (UTC)

@El Grafo, Yann, Ymblanter, PantheraLeo1359531, and Pigsonthewing: Thanks for weighing in! I guess consensus is about not blocking people in upload, we already included this in our current patch. Thanks again! Sannita (WMF) (talk) 09:25, 26 October 2023 (UTC)

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)

Dropdown list for less common licenses and "license builder" for beginners

I think it would be nice to have a drop down menu for licenses like "PD-scan", "PD-EU-anon", GNU GPL, Apache etc, maybe also grouped by Copyleft licenses, by Public Domain licenses, Software licenses etc.

Also it would be good if there is a guide that provides the best license. Questions could be: What kind of file is this? (Photo, Screenshot, Video), Is it your own work?, Is it a derivative work and by whom? Do you want to assure that your work must be always under the same license, when edited? ...

Greetings --PantheraLeo1359531 😺 (talk) 15:09, 10 October 2023 (UTC)

Yes it is distracting that the mock-up offers only certain Creative Commons licenses, when there are some common situations like public domain status which ought to be just as prominent. It may not be tidy but if you know there are other options, put a catch all field for "other" in the options to demonstrate awareness that messy design may be a requirement. Bluerasberry (talk) 15:49, 12 October 2023 (UTC)

They should not be visible to new users as we want to decrease the mistakes made by them. Therefore this should be part of some kind of advanced mode that can be turned on in the settings. GPSLeo (talk) 06:16, 14 October 2023 (UTC)

I'd disagree with that because having just a few Creative Commons licenses there will likely picking whichever one sounds best without much consideration. Having more options is likely to make a careful uploader think more closely about the appropriate license. —Tcr25 (talk) 20:23, 16 October 2023 (UTC)

Hello @PantheraLeo1359531, Bluerasberry, GPSLeo, and Tcr25: , thanks a lot for your feedback. As we noted above with Andy, what you say it’s true, but the most common licenses that are used are CC, and currently UploadWizard only mentions CC as well. However, entering a different license in wikitext is still available for an advanced user. But for the normal user, who knows little about open licenses or Creative Commons, answering this question alone might be already a big leap to take, so we want to make sure that this step is as simple as possible for them to take, without either having them to lie about the license, or quitting the process because it’s too complex. - Udehb-WMF (talk) 11:54, 20 October 2023 (UTC)

@Udehb-WMF, there are two aspects I'm seeing.

1. On the not my own work option, what's the next step in the workflow if someone clicks "Yes, I have this information"? Will lead to a more helpful dialogue with a range of possible license options? Will it step through a few other screens to narrow down the choices?
2. On the my own workflow, I'm not sure there are many other options beyond CC0, CC4 and CC4 by SA that might be desired, but if there are the "Enter a different license in wikitext" option should be available.

—Tcr25 (talk) 14:00, 20 October 2023 (UTC)

@Tcr25: Regarding your first question, you can test what happens next with the prototype on Figma that we prepared for this (be aware that some links or functions may not work as expected due to prototyping limitation).

Regarding your second comment, we're thinking of integrating an option for users to provide a different license. We'll get back at you when it will be ready. Sannita (WMF) (talk) 09:33, 26 October 2023 (UTC)

I can understand the aspect that it might become too complicated for new users. But I think that it could be useful to have an option at the end, if someone is looking for a not-CC license in particular. Let's assume that a user finds a screenshot online that is licensed under the Apache license. For this case, it would be good to either have some sort of searching function, or a list that offers some options to further license (maybe grouped after Copyleft licenses, etc.) :) Just some thoughts I would like to share --PantheraLeo1359531 😺 (talk) 12:48, 21 October 2023 (UTC)

In such a case they should go to their user preferences and activate the advanced mode. Having this rare cases in the standard mode is not useful. GPSLeo (talk) 16:16, 21 October 2023 (UTC)

Create new commonscats when uploading

I am one of the busiest Wikipedia photographers in Germany and use the Upload Wizard all the time because it's quick and easy. I would like to create new commonscats in one go when uploading, but if you want to specify a commonscat that does not yet exist in the upload form, the technology of the upload form is inconvenient. Can you do something about that? Greatings Ricardalovesmonuments (talk) 15:37, 10 October 2023 (UTC)

I am also thinking about creating a customized commonscat for myself with predefined categories (I am uploading about 10 images per day on average), but it would take more than 10 minutes, and I just can not find time to write it. Ymblanter (talk) 16:25, 10 October 2023 (UTC)

When I go on vacation or long weekends in places and/or areas with a rich collection of art and architectural historical buildings, I often take 100 to 175 pictures per day. Since I always start the next tour right after breakfast, it is necessary to have the photos uploaded before I go to sleep. greetings Ricardalovesmonuments (talk) 16:33, 10 October 2023 (UTC)

Well, I still post-process all the photos, I typically upload them many months after they were taken. Anyway, interests of mass-uploaders (minimizing the number of actions) should be taken into account. Ymblanter (talk) 17:03, 10 October 2023 (UTC)

+1, sometimes, the upload limit of 500 uploads is not enough :D --PantheraLeo1359531 😺 (talk) 17:10, 10 October 2023 (UTC)

@PantheraLeo1359531 The upload restrictions can be overcome when you run several instances of the Upload Wizard. Just a suggestion. But it will consume your bandwith as well and will not save you time. I use that to upload pictures of different scope in order to be able to use the copy function. I use the time as one windows loads up to fill in the descriptions of the other windows. Giftzwerg 88 (talk) 22:45, 10 October 2023 (UTC)

Thank your for the suggestion, I sometimes try a similar strategy, but it depends on the browser stability and sometimes some processes are lagging temporarily, like publishing :) --PantheraLeo1359531 😺 (talk) 15:04, 11 October 2023 (UTC)

If creation of categories is added, it should also create the wikidata item for the new category (and insert the "wikidata infobox" template into the category description). This way the depict statement of the upload image can be made the new wikidata item. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 16:36, 10 October 2023 (UTC)

I am a bit confused by this request. The main work of creating new categories is not in technically creating it, but in choosing under which categories it should be sitting and in possibly moving existing images from those top categories there. I usually do this before I start my uploads. Others do this before they even start their photowalks, while choosing the route.

Upload wizard of course could create pages that look like categories, perhaps it could suggest top categories for certain kinds of categories, but only for very limited cases like putting a new "Interior of xyz building" under "xyz building". But I see no way the work of friendly users like Luftschiffhafen, who is doing a lot of this work for you, could be done by a tool like the upload wizard. How do you imagine this to work? What kind of input would you think the upload wizard would need and how would giving this input easier then creating the Categories before uploading? Kritzolina (talk) 15:47, 11 October 2023 (UTC)

@Kritzolina the point is precisely that if I want to upload pictures of Chapel YXZ (of which there is no Commonscat yet) and want to enter the exact category name of the chapel in the category field of the Upload Wizard and the upload technique does not want an existing cat instead, and accepted my input. As a result of uploading and sending images, the new category is displayed as if you were moving images into a new category, which you then created by adding main categories. This is exactly how it should work. It's a mystery to me why you didn't understand that for God's sake, you actually seem obtuse to me. Greetings Ricardalovesmonuments (talk) 18:29, 11 October 2023 (UTC)

Well, always happy to have my intelligence judged by people who don't know me. Perhaps try to explain what you want again in German in very simple words even an obtuse person can understand? Your English seems a bit confusing to me, sorry. Kritzolina (talk) 18:52, 11 October 2023 (UTC)

Ich bin einer der meistbeschäftigten Wikipedia-Fotografen in Deutschland und nutze den Upload-Assistenten ständig, weil er schnell und einfach ist. Ich würde beim Hochladen gerne auf einmal neue Commonscats erstellen, aber wenn man im Upload-Formular einen Commonscat angeben möchte, der noch nicht existiert, ist die Technologie des Upload-Formulars unpraktisch. Können Sie etwas dagegen tun? Der Punkt ist genau der, wenn ich Bilder von Chapel YXZ hochladen möchte (von denen es noch keinen Commonscat gibt) und den genauen Kategorienamen der Kapelle in das Kategoriefeld des Upload-Assistenten eingeben möchte und die Upload-Technik dies nicht möchte stattdessen die vorhandene Katze und akzeptierte meine Eingabe. Durch das Hochladen und Senden von Bildern wird die neue Kategorie so angezeigt, als würden Sie Bilder in eine neue Kategorie verschieben, die Sie dann durch Hinzufügen von Hauptkategorien erstellt haben. Genau so sollte es funktionieren. Ich benutze den Google Übersetzer, mein eigenes Englisch reicht für sowas nicht aus. --Ricardalovesmonuments (talk) 19:10, 11 October 2023 (UTC)

Also das klingt jetzt so, als wolltest du etwas, was schon exisitiert. Der Uploadwizard akzeptiert durchaus Kategoriennamen, die noch nicht existieren. Er schlägt zwar andere vor, aber wenn man auf der neuen Kategorie besteht, ordnet er die neuen Bilder dort auch ein. Diese wird dann allerdings rot und nicht blau angezigt. Wenn man anschließend auf die dann immer noch rot angezeigte Kategorie geht, findet man dort die Bilder und kann Top-Kategorien hinzufügen. Und andere Bilder aus den Top-Kategorien hinzufügen.

Ohne das Selbstlob am Anfang, geht das alles übrigens auch ... ^^ Kritzolina (talk) 19:18, 11 October 2023 (UTC)

Examples given in the mock-ups

First of all, thanks for working on this. These will be important improvements, once they really work. Still I have some critical points about the examples given in the mock-ups. My first impression - the examples given are way to vague to be useful. The list given further up by Yann is already more useful than the list on the mock-up, even though it still has issues. Please try and put time into choosing really good examples. The only place where the mock-ups give examples, they are not on point. When you list picutres of oneself, family and friends it misses the points, that these people a) might be notable for Wikipedia, or b) might be photographed in a way to illustrate something educational, like doing a ritual or tradition that is immaterial UNESCO-heritage, or to show symptoms of a disease, or taking part in a notable event. Please also remove the word "encyclopedic" from the scope explanation, Commons is not only useful for illustrating Wikipedias, but used as an educational resource with a much wider scope. Kritzolina (talk) 08:13, 11 October 2023 (UTC)

Agreed, please replace "encyclopedic" by "educational" and make sure to link COM:SCOPE. El Grafo (talk) 09:29, 11 October 2023 (UTC)

@Kritzolina @El Grafo Thanks for your feedback! Also, we already are working on a different wording for the "encyclopedic" part, since this piece of feedback was already shared by another user yesterday on Telegram. We are thinking of rewording it linking directly to Commons' guidelines, but we are still defining the new message. We'll get back at you when we're ready. Sannita (WMF) (talk) 11:53, 11 October 2023 (UTC)

Would it be possible to store the texts on Commons in the MediaWiki namespace that wording changes do not need developer involvement? GPSLeo (talk) 06:11, 14 October 2023 (UTC)

@GPSLeo I don't think it's possible. Sannita (WMF) (talk) 09:49, 15 October 2023 (UTC)

Is this not what the mw:Extension:JsonConfig is made for? GPSLeo (talk) 10:06, 15 October 2023 (UTC)

@GPSLeo I'll ask to the team and let you know. AFAIK, it's not possible, but I may be wrong. Sannita (WMF) (talk) 10:17, 15 October 2023 (UTC)

Hi @Kritzolina: , we took some more time to analyze your feedback and we agree with the idea that examples should be as refined as they can be. It’s worth remembering though that any example we make needs to have a very large set of different, and sometimes competing, characteristics based on testing and general UX best practices: they need to be representative, i.e. talk about the most likely things that one would consider uploading to Commons; they need to avoid contradiction or nuanced exceptions, because more specific definitions might be more accurate, but can also generate confusion as they might seem to negate the straightforwardness of the more general example; they need not to suggest that Commons’ scope is too limited, i.e. making the user think that the examples given are the only allowed kind of media we accept. Then there are other limits, such as too many examples or too much text that actually discourages readers from reading the text at all, and so on.

In short, we agree that examples are key to comprehension, so we encourage anyone who has suggestions to give them here, so that we can incorporate the ones that best fit the (narrow) space allocated and meet the criteria we explained. - Udehb-WMF (talk) 12:19, 20 October 2023 (UTC)

Hi Udehb, for the first example, I think "photos of nature, public events or anything you designed yourself" would meet your requirements and be more specific.

For the second example, I would alter the second part of the sentence to "artwork or other things designed by someone else."

On the second page, under 1. I would prefer "someone elses art or design" instead of work.

Work was used in all examples, but work could also be repairwork or a craft like someone thatching a roof - both things are absolutely fine to go on commons. I think we need to make it clearer that we mean the copyrighted work, which is art or design. What do you think? Kritzolina (talk) 16:24, 20 October 2023 (UTC)

@Kritzolina Thank you for your suggestions, we passed them on to the dev team and we're evaluating with the legal team about their inclusion. Sannita (WMF) (talk) 09:34, 26 October 2023 (UTC)

Adaptability in campaigns

It would be good if the release rights section can be adapted in upload campaigns. For photo competitions it would be useful to hide the not own work part as this part is not needed there. And the possibility to add campaign specific questions. GPSLeo (talk) 06:08, 14 October 2023 (UTC)

Two suggestions

The "Does this media provide value to others?" question is a waste of time and space. No one is ever going to choose "No" to that question, even if it's a blurry image of a rock (or more likely a penis). Nor will it discourage anyone from uploading such images. Also, change the wording of the confirmation question from "copyrighted material" to "material restricted by copyright". The difference is important. Nosferattus (talk) 04:32, 15 October 2023 (UTC)

Hey @Nosferattus: , thank you for your feedback! We think the question has a reason to be, since it’s an opportunity for us to link to COM:SCOPE for new or inexperienced users. We changed the wording on what you suggested though.- Udehb-WMF (talk) 12:33, 20 October 2023 (UTC)

@Udehb-WMF: The problem is that the users you're trying to target with that question are exactly the users that don't care that Commons has a scope policy. It's like asking people at the self-checkout if they neglected to scan anything in order to deter theft. It sounds good on paper, but it will have minimal effect, and will just inconvenience everyone else. Nosferattus (talk) 15:05, 20 October 2023 (UTC)

Thank you for your feedback! The first batch of changes to UW will go live soon

Hi everyone, we would like to thank all of you for your participation. We greatly appreciate your suggestions and insights on your work, and we are already evaluating ways of integrating that in our next iterations of our work.

I also wanted to tell you that the first batch of changes to the UploadWizard interface have been introduced and will be live by early November. We will watch closely their effect on new uploads, and we will communicate further big changes in time.

Thanks again for your collaboration and support! -- Sannita (WMF) (talk) 15:41, 30 October 2023 (UTC)

Hi Sannita, thanks for the update! Any ideas what changes we suggested made it into the version that is going to go live? Or do we need to wait, see and compare ourselves? Kritzolina (talk) 09:25, 2 November 2023 (UTC)

@Kritzolina For now, very few changes have been made, some of your suggestions are still being investigated with legal and design, in order to find the best way to integrate them. I'll keep you posted on this. Sannita (WMF) (talk) 12:37, 2 November 2023 (UTC)

Utilise redirects

An example of how the HotCat tool utilises category redirects to immediately place a file in the correct category, even when the "incorrect" name is used.

Not sure if this page is still open for more suggestions, but one thing I've been saying for years is that the Wikimedia Commons needs to integrate redirects better (like what Wikipedia does), in one way this could be seen as SEO (search engine optimisation) as not everyone searches in English using extremely specific and often idiosyncratic terms, but it would also make the project both more multilingual and easier to navigate. This starts at the MediaWiki Upload Wizard, imagine someone typing in "Deutschland" and then automatically getting "Germany" if their default language is English, or Wikidata utilising alternative titles to translate category names (and then automatically create redirects based on those alternative titles, obviously after a few days to prevent vandalism). This all starts by actually making redirects useful for uploading.

Currently, if a user uploads a file into a country like "of Sweden" and the correct country is "in Sweden" the file gets stuck in the redirect. Because of this many users prefer to always delete old names whenever they move a category (even if the policies clearly state that such names should be kept) because people commonly mistaking the other name creates more workload for categorisers. But if you use the HotCat tool you can type in the name of the redirect and it immediately adds the file to the correct category, the MediaWiki Upload Wizard does not do that. Please update the MediaWiki Upload Wizard to utilise redirects in the same way as HotCat currently does, this would single-handedly make redirects more useful.

Despite knowing about this page I completely forgot to write this suggestion down and I hope that I'm not too late to make it (even though I've been saying this for over half a decade at this point). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:58, 2 November 2023 (UTC)

Just to clarify; you are suggesting to let people enter a redirect of a category, and then return the associated destination category in the result list and have that be picked by the user ? You are not suggesting to have the autocomplete list redirected titles of categories ? —TheDJ (talk • contribs) 15:58, 15 November 2023 (UTC)

Ah wait, it already works like this. The problem you are describing is that Commons doesn't use redirects in many cases. They use the redirect template, which is... NOT a redirect. As far as I can see, this template hasn't been needed for over 10 years. Why is it still in use ? —TheDJ (talk • contribs) 16:05, 15 November 2023 (UTC)

The main issue isn't the template, HotCat can work with the "{{Category redirect}}" template without it interfering with its functioning. I just wonder why HotCat can work with it but the MediaWiki Upload Wizard can't. Having intelligent redirects (for example different categories in different languages) can aid the multilingualism of the Wikimedia Commons, but to avoid populating redirects many people have been against preserving redirects. Most of this cultural attitude seems to be technical in origin. Of course, depreciating the template could also work, whatever improves the usability of the MediaWiki Upload Wizard. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:40, 19 November 2023 (UTC)

The template is still in use because "move page" automatically inserts it into the redirected page. Furius (talk) 23:58, 5 December 2023 (UTC)

Concerns about changes

 You are invited to join the discussion at Commons:Village_pump/Technical#Bad changes to the upload wizard. CC Udehb-WMF and Sannita (WMF). {{u|Sdkb}} ^talk 04:35, 7 November 2023 (UTC)

Experience uploading videos

The error message for attempting to upload an MP4 file

Hi @Udehb-WMF and @Sannita (WMF)! As you go about improving the upload wizard, one area I hope you can work on is the experience users have uploading videos (something I've expressed exasperation about previously). Currently, anyone who uploads a MP4 file, the most common type of video file, is met with a "this wiki does not accept" error message that doesn't even point to Help:Converting video, let alone guide users to a conversion tool or (better) offer to do the conversion on the spot. {{u|Sdkb}} ^talk 16:05, 7 November 2023 (UTC)

@Sdkb Thanks, I'll raise this point at the next meeting, and I hope to let you know about it soon. Sannita (WMF) (talk) 16:49, 7 November 2023 (UTC)

Appreciated! {{u|Sdkb}} ^talk 17:16, 7 November 2023 (UTC)

@Udehb-WMF and @Sannita (WMF): And video2commons (V2C) is seriously broken. Please see the list of issues here: Commons talk:Video2commons. I reported 2 of the most serious problems: [1] and [2]. Fixing V2C should be one of priority of WMF. Thanks, Yann (talk) 22:08, 29 November 2023 (UTC)

I'd say simply integrating "Upload from URL" and having a built-in video conversion system (and also for other files) would basically solve all the issues video2commons (V2C) has, in fact, we'd probably lose the need for a lot of alternative tools if these simple features were implemented. Fixing this tool is simply fighting the symptoms of having a largely lackluster MediaWiki Upload Wizard (MWUW) tool. If the MWUW had better import and upload features more than half of the Commonswiki-based tools in the Toolforge would become obsolete overnight. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:20, 29 November 2023 (UTC)

Uploading vidoes is purposfully complicated, as checking videos for COPYVIO is complicated. More users who check videos for COPYVIO would be needed... (same with mp3: new users are not allowed to upload mp3 because of the number of COPYVIO) --C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 07:34, 30 November 2023 (UTC)

We could simply have a system where if a new user tries to upload an ".MP3", ".MP4", or ".webm" file that a message would greet them "The ability to upload sound and video recordings is restricted to users with special rights, if you wish to upload these files please request these rights and explain what kind of content you wish to upload" and have a dedicated "Commons:Audiovisual uploaders/Requests" page where people can request such a thing after articulating what and why they want to upload something, this would keep away both those that deliberately wish to upload copyright ©️ violations (like the Wikipedia Zero (0) film pirates) and those who may or may not know what is and isn't a copyright ©️ violation. Uploads by these users wouldn't be auto-reviewed but require additional verification by a special patroller (not necessarily an admin, to spread out the workload).

The main issue with preventing content creation is that you simply get less content, why did Nupedia fail and Wikipedia succeed? Because Nupedia had a lot of checks and balances and Wikipedia had none, literally anyone could do anything and they didn't an account to do it. We should prevent copyright ©️ violations to a reasonable extend, we shouldn't make it difficult for people who do know what educational content is and isn't copyrighted to be prevented from uploading free educational content because they're technically unable, because with this mentality you punish those who want to upload free educational content but are technically less versed while you don't necessarily prevent those who know how to circumvent these.

I've noticed an odd trend that any policy that tries to make it easier for users to upload files when approved gets stuck in limbo for years (for example people voted to allow ".MP4" files a couple of years ago, I'll dig up the suggestion later), yet suggestions to add more filters to block most users from uploading certain files get implemented immediately (like the ".MP3" ban, the overwriting for non-patrolled users, and now one for ".webm" files). The Wikimedia Commons will never become a place for sounds and videos if it's deliberately difficult to upload them.

We should also remember that there are users with thousands of edits to a Wiktionary that want to add sounds but can't because they need to have the special rights here, they would simply need to be informed about the rules here and then given "a badge" so they coule start uploading, having a dedicated group for that would solve this issue. We shouldn't sabotage the MediaWiki Upload Wizard for everyone to keep a few novices unfamiliar with this project out. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:53, 30 November 2023 (UTC)

+1 to everything Donald said. Very well-put. {{u|Sdkb}} ^talk 15:15, 30 November 2023 (UTC)

Thanks to all the people who intervened in this discussion. Next week we'll have a meeting regarding the video problems that you raised, and I will be probably able to answer to your questions. I'm sorry it's taking this long, but key people are out of office as of now, and we need to wait on them to reach a decision. I'll keep you posted. Sannita (WMF) (talk) 15:28, 30 November 2023 (UTC)

As I already said below, I made the case for focusing on some improvements on audio/video files, and unfortunately they are outside the scope of the current fiscal year's plans. I'll try to make the case for next year's plans, but I cannot promise you anything on the issue. I am truly sorry. Sannita (WMF) (talk) 16:45, 7 December 2023 (UTC)

Thanks for letting us know and for your advocacy on this; hopefully it makes the cut next year. {{u|Sdkb}} ^talk 05:51, 8 December 2023 (UTC)

The ability to convert file types during (or after) the upload process

Perhaps it would be useful if the MediaWiki Upload Wizard itself had the ability to upload file types, for example a non-tech savvy user has an ".MP4" file and doesn't know how to convert it to a ".webm" file. For many users this is reason enough to never upload a video as most (if not all) standard recording software saves videos as ".MP4" files (my camcorder (Google Pixel 4A) does that. There are several file types that aren't accepted, it might be better to improve the usability of the Wikimedia Commons for non-power users by creating built-in software that can convert non-free file formats into free file formats.

Let's say a user uploads an ".MP4" file, while the file is being uploaded the MediaWiki Upload Wizard automatically converts it into a ".webm" file, if multiple free formats exist the user may select and preview this before the publishing process. I'm not sure how feasible this would be, but this could essentially solve all issues with non-free file formats. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:46, 19 November 2023 (UTC)

@Donald Trung Hi, thanks for your suggestion and sorry if it took me this much to answer. Unfortunately, this goes outside the scope of our work in this fiscal year. We are focusing on improving the experience of UploadWizard, and while this could be an improvement, it just cannot be integrated in this fiscal year workflow, I'm sorry. -- Sannita (WMF) (talk) 15:35, 30 November 2023 (UTC)

Sannita, just curious, but how much money would have to be reserved for such a project? I could always try e-mailing various corporations that might want to donate to the Wikimedia Foundation (WMF) and if I could specify which projects need how much funding this might be easier. In fact, the Wikimedia Foundation (WMF) could create a long list of most requested features of Wikimedia websites and list what the estimated costs would be, this would make fundraising easier as people would then donate for specific and tangible things.
I think that the Wikimedia Foundation (WMF) could probably list all of its aspiring projects and then add a link for people to donate, us volunteers could then direct people to go to this page to donate to specific projects. Not only would this help fundraising for specific Wikimedia projects with highly specific technical needs like Wikidata and the Wikimedia Commons, but this would also add more transparency. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:49, 30 November 2023 (UTC)

It's not about money, but it's about time and priorities. This year's priority is to assist people with extended rights (admins and others) to reduce the burden of backlogs and actions that they have to do as volunteers. This is why we are working to improve the UploadWizard and why we are having conversations about copyright tags and (in the future) how to deal with Freedom of Panorama. This is also why this idea just can't be inserted in this year's work, since our schedule is already full and we're reserving space only for fixing urgent bugs, but not for completely new features like this one. Sannita (WMF) (talk) 11:54, 1 December 2023 (UTC)

Well, money is something that can be translated into personnel and resources. And therefore also in time and priorities. A software project cannot be accelerated simply by putting more staff on it. MediaWiki, however, has many open problems that are often independent of each other and can be tackled by more teams in parallel. You write that this year is about making the work of the admins easier and that is why work is being done on the UW. But it would also make the admins' work easier if, for example, audio files and webp files were to display their EXIF metadata on their file info page (as an example). Visible metadata helps to recognise COPYVIO. Currently, new users are not allowed to upload MP3s because these are particularly often COPYVIO. Among other things, this means that this question has to be answered again and again in the VP or HD, which also ties up admins' working time. Displaying this metadata would also be work on the upload process - but it would not conflict with the work on the UW, it would be completely independent of it. Recently @Bawolff implemented this display of metadata for webm (webm, not webp!): It was quick and easy, immediately improved the data quality of Commons - but it wasn't a WMF project (and could have been). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 09:17, 5 December 2023 (UTC)

@C.Suthorn Thanks, this looks more as something that can tie-in much better with this year's scope. I'll bring it up in the next meeting, and will let you know more about it. Also, can you link me Bawolff's work? It could be useful for the dev team. Sannita (WMF) (talk) 14:08, 5 December 2023 (UTC)

As @Bawolff has read my comment, he will probably contact you? C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 14:59, 5 December 2023 (UTC)

[unindent] @Sannita (WMF): That would be phab:T237154 / gerrit:977116 (Wasn't just me, TheDJ helped). If you or the dev team have questions about file metadata in MediaWiki I'm happy to answer questions. There is a lot of low hanging fruit for TMH formats, because some of them already have the metadata being extracted just not displayed. Bawolff (talk) 15:33, 5 December 2023 (UTC)

@Bawolff Thank you very much, that is very helpful! Sannita (WMF) (talk) 18:30, 5 December 2023 (UTC)

One more thing: The preview images of webm files on the file description page come without EXIF metadata even it the webm file itself has EXIF metadata. For jpg and png files the preview images do contain EXIF metadata if the original file contains EXIF metadata. As reused images are often downloaded preview images this is relevant. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 00:23, 7 December 2023 (UTC)

@C.Suthorn @Bawolff I've raised the issue to the team, and despite our best efforts, we cannot deliver on the point this year. I'll try to make the case for it for next Fiscal Year, as I do share your opinion that this needs to be addressed, but I can't promise you anything. I'm am truly sorry. Sannita (WMF) (talk) 16:42, 7 December 2023 (UTC)

Sannita: When does your Fiscal Year start? 108.58.166.134 12:56, 8 December 2023 (UTC)

The Fiscal Year starts on July 1 each year, but planning is already starting. Sannita (WMF) (talk) 12:58, 8 December 2023 (UTC)

Allow multi-line in the source and author fields

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)

Tracked in Phabricator
Task T352988

@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)

Is there an option to get the old "Not my own work" back?

I noticed that recently the "This file is not my own work" has been revamped, it moved "source" and "author(s)" to the bottom of the page and shrunk the fields where you can write. I'm not sure what these changes are supposed to improve, why list the license before the source? And why are all the creative commons licenses immediately expanded?

Instead of asking about the license in general it now first asks "Do you know what Creative Commons license this media was published under? (You may find this information on the page where you found the media.)" Why make the assumption that a work from a website is under a Creative Commons licence? I often work with very old works which are in the public domain, as far as I know, these are far more numerous than CC licensed works. While I like the fact that there are a number of options for the "Source" and "Author(s)" field that make it easier, namely the "This is AI generated media." and "This is public domain and the author is now unknown" buttons, why are the fields where you can write ✍🏻 the sources and original authorship so small now? Maybe this is just an issue with my device so I'll an image later, but this issue seem to persist on mobile.

As a mobile user, these changes seem to add more scrolling and actually make it more difficult to use (aside for the aforementioned improvement for unknown and AI authorship). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:22, 29 November 2023 (UTC)

Here are a few screenshots to illustrate the issues:

• 

  The design of these fields has made it impossible to read any long texts.

• 

  The design of these fields has made it impossible to read any long texts.

I often upload images from governments, for example "The government of the Nguyễn Dynasty" or "The government of the Qing Dynasty", now if I would write this down and made a mistake like "The governentf of the Qing Dynasty" (which could sometimes happen due to my oversensitive keyboard ⌨️) I won't be able to see the error until it's too late. A mistake like "https://commons.m.wikimedia.org/wiki/Special:UploadWizard MediaWiki Upload Wizard]" instead of "MediaWiki Upload Wizard" is also now more difficult to detect. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:30, 29 November 2023 (UTC)

Thanks for your feedback, I'll report it to the designer, and let you know about it. Maybe we can re-introduce public domain along the choices? Sannita (WMF) (talk) 15:36, 30 November 2023 (UTC)

That would be extremely helpful, yes. I am with Donald Trung on that one that we need this choice for many files. Kritzolina (talk) 20:03, 30 November 2023 (UTC)

@Donald Trung @Kritzolina I spoke with the designer and I have some news about what you were asking. There is going to be some more rework to the "release rights" step, so that it would allow for choosing public domain more easily. You can see the current prototype we are working on now, we're still discussing some of the wording, but it is fairly easy to use and it should solve the problem. The option for adding manually the tag will also be more prominent.

As for making the fields bigger, the designer told me it shouldn't be a problem to enlarge them -- I can't help you with the typo problem, but maybe enlarging the fields should help with that.

The only problem is that it's going to take time to see these changes. We are approaching the end of the year, and there will not be any upgrade to MediaWiki in the coming weeks, which means that all these changes will happen in January. I'm sorry for this, but there are good reasons to pause improvements during periods of festivity.

Hope this answers your question. Sannita (WMF) (talk) 14:39, 7 December 2023 (UTC)

Thanks, Sannita, I fully understand that these things take time and am happy as long as someone is moving forward with them. Happy holiday season to you and everyone working on this project! Kritzolina (talk) 17:34, 7 December 2023 (UTC)

Commons:Upload Wizard

This page is now linked from Commons:Upload Wizard and Commons talk:Upload Wizard. Those are the supposedly central places for discussion of the Upload Wizard. I see that this discussion has gone on for nearly two months with effectively no notice to people (like me) who watchlisted the supposed central place for discussing the topic. I only even heard about it because of off-wiki communication, and then had great difficulty finding where discussion was happening. - Jmabel ! talk 19:24, 4 December 2023 (UTC)

See my comments at "Commons talk:WMF support for Commons#Perhaps it would be a good idea to have a WMF village pump?", if the Wikimedia Foundation (WMF) wants feedback from the people that actually use the Wikimedia Commons it needs to advertise itself as widely as possible. My suggestion would have essentially made the "WMF support for Commons" directly visible next to the Village pumps, Administrators' noticeboards, Help desks, Etc. That way it would look less like they're "operating in the shadows" or "operating in the basement / attic where nobody can see them", they did announce it at the main Village pump once, but if you didn't catch that it's nearly impossible to find this page (like almost all of their other pages). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:23, 4 December 2023 (UTC)

It did not work at the English Wikipedia, I do not see any reasons to think it would work here. Ymblanter (talk) 07:33, 5 December 2023 (UTC)

@Jmabel I'm sorry we've failed to reach you, despite we used various channels to share our initiative. This is something we aim to improve with next iterations, but at the same time we're worried of creating a potentially inverse effect by "spamming" too much links in different avenues (as you probably know, we're trying to avoid to disturb the community too much with "unwanted stuff"). Maybe we can work together, and you can help us share the discussions or suggest us potential better avenues for our questions? Sannita (WMF) (talk) 14:21, 5 December 2023 (UTC)

@Sannita (WMF): Are you saying that you were aware of this page, but chose not to post there because you didn't want to post to too many places? Posting to the supposedly primary area to discuss the topic at hand would certainly not be spamming, and if you thought it would that does not show great judgement. - Jmabel ! talk 16:34, 5 December 2023 (UTC)

@Jmabel You're right at saying that we should have included that page as one of the venues, next time that will be our primary venue after Village Pump. Sannita (WMF) (talk) 18:28, 5 December 2023 (UTC)

@Sannita (WMF): Thank you. - Jmabel ! talk 18:37, 5 December 2023 (UTC)

@Sannita (WMF), if it's helpful for future reference, the way that foundation folks sometimes get in trouble for "spamming" is when you all post the same question in multiple places and ask for feedback in each of those locations, creating talk forks that make it harder to keep track of discussions and to build off other editors' comments. But when it's just notices pointing to a central forum (using {{Please see}} or language akin to it), it's very hard to go overboard, so feel free to err on the side of sending invites to everywhere potentially relevant. Cheers, {{u|Sdkb}} ^talk 05:48, 8 December 2023 (UTC)

Decision tree

A Wizard is essentially a decision tree. Is documentation of that decision tree (either as it stands or what we are moving towards) available anywhere, so that people do not need to navigate through the tool and try every path to understand what it does? It seems to me that would provide much more ability for people to comment usefully about important cases that might not be well covered, especially those of us who do not routinely use this tool ourselves. - Jmabel ! talk 19:28, 4 December 2023 (UTC)

Hey @Jmabel, the release rights step is still to be reworked in some of its aspects, so the "decision tree" is still not final. If you wish, you can see the current prototype, that I shared above. Feel free to try it out, and let me know your opinions about it. We're still looking for feedback and to improve our current work. Sannita (WMF) (talk) 16:51, 7 December 2023 (UTC)

@Sannita (WMF): I have a lot of thoughts and concerns about this (some just about wording, some possibly about the logic). Is there a chance that we could at some point set up a Zoom call or such, or would you need me to do this in a more formal write-up? The former would, of course, be much more convenient for me, but I realize I'd be shifting the burden of any write-up to you. - Jmabel ! talk 18:35, 7 December 2023 (UTC)

@Jmabel I've asked the designer if she was available for a meeting, and unfortunately she won't be before January. On the bright side, new updates are not going to be scheduled before next year, so there's no rush. You can feel free to share in writing your concerns, or we can set up a meeting for next month, or we can do both. Maybe you can give me in private your time zone, so that I can start working on a Framadate for our meeting. Sannita (WMF) (talk) 12:12, 8 December 2023 (UTC)

My time zone is no secret: I'm based in Seattle, and except for maybe week or two have no travel plans till late February. - Jmabel ! talk 19:30, 8 December 2023 (UTC)

Thumb/Preview image for videos

MediaWiki uses a VideoCapture from the middle of an uploaded video as the video's preview/thumb image. While it is possible to set a specific image as the preview image when using the file with [file:example.jwebm|... on the description page this autoselected image will be shown - and often it is not very representative for the video. Unlike mp4 webm has no way to include a preview image in the file itself. It would be really good, if it was possible to add an integer or a filename to the upload process and then this named file or the image from the video given by the number (interpreted as millisecond of running time or as frame number in the video) would be used as its default preview image (that can still be overriden if used on a wikipage with [File:example.webm|...). Or a possiblity to set the first or the last frame of a video as its preview image. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:16, 8 December 2023 (UTC)

Hi, This is already possible with the "thumbtime" parameter. See mw:Extension:TimedMediaHandler. Yann (talk) 13:45, 8 December 2023 (UTC)

You can use it in pages when using [File:... but not on the description page of the video (at least I don't know how, and the mw: page you linked to does not explain how - if at all- it is done). Also TimedMediaHandler only offers to use a frame from the video, not any image. And even if there is a way to use js or css or Lua to replace the preview image on the file description page with another preiview image, then still the upload process does not offer a way to set this frame or image. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:58, 8 December 2023 (UTC)