Commons talk:WMF support for Commons/Upload Wizard Improvements/Archive

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)

Why would CCBY-SA be recommended instead of CCBY which causes less issues due to incompatible licenses and is less free…I very much doubt the majority of admins let alone contributors would favor that license. I think most would favor CCBY. Since CCBYSA-NC is not even allowed the more likely better pick, even when not considering the extra hassle and reduced usefulness, would be CCBY. Agree with RuinDig there and would set that either that (preferably) or nothing as the default license at the license-selection step. Prototyperspective (talk) 15:23, 27 December 2023 (UTC)

@Prototyperspective: For those of us who are firmly committed to the spread of Free Culture, the -SA (Share-Alike) component ensures that derivatives of our work remain free in a viral manner. "If you remix, transform, or build upon the material, you must distribute your contributions under the same or compatible license as the original."   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 15:52, 27 December 2023 (UTC)

I disagree with this conclusion. If you'd like to use images in other contexts or combined with other images you can't do so if they are licensed under CCBY-SA. This can affect countless applications from disaster response to commercialized medicine, science education, and beneficial corporate activities. What if you'd like to use the image in a MIT-licensed software or in a video which you can't put on YouTube under its CCBY3 license since it also features non-CCBY images? Or what if you're unsure whether you can license a work featuring some modified CCBYSA images under CCBYSA?

It only reduces the usefulness in practice and causes a lot of extra work, incompatibilities, nonstandardization, and inefficiency. I get the idea behind SA in theory and support that but in real-world practice it's nothing but a burden and doesn't have any positive impact. Prototyperspective (talk) 16:17, 27 December 2023 (UTC)

@Prototyperspective: Then you lobby YouTube and other such organizations to support SA licensing. Or you negotiate a special license from the copyright holder for use in a particular work in a particular medium with a particular reach. I am open to such negotiation for my works.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 16:25, 27 December 2023 (UTC)

Interesting ideals but consider that I also argued that the benefit of this is zero while the real-world in practice needs to be considered where it reduces the usefulness in practice and causes a lot of extra work, incompatibilities, nonstandardization, and inefficiency, especially considering a) feasibility and b) time-requirements.

The impact of CCBY-SA over CCBY is negative, which should be even clearer from your comment, even if YouTube for unknown reasons added the option for CCBYSA. A better use of time would be to make other media sharing sites like reddit/imgur/artstation/500px/x enable licensing original content media under CCBY instead of Google being in the lead there by allowing users to easily specify that. Prototyperspective (talk) 16:37, 27 December 2023 (UTC)

@Prototyperspective: "make"? That sounds super-difficult. "lobby" is much more realistic.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 16:45, 27 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)

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)

+1 Z ^thomas 14:14, 28 December 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)

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)

It definitely continues to be an issue that this page is not linked directly from Special:UploadWizard. Instead, the "leave feedback" button goes to Commons:Upload Wizard feedback, which is marked as historical (but editors are still leaving feedback on the talk page there since they don't know where else to go). This really needs to be resolved given the ongoing work. {{u|Sdkb}} ^talk 05:17, 21 December 2023 (UTC)

@Sdkb I don't think this page should be linked directly from the UploadWizard, since it's just a page for internal coordination, but maybe we can establish a new page for feedback? Do you know why the old feedback page was marked as historical? Sannita (WMF) (talk) 14:52, 21 December 2023 (UTC)

I'm not sure why the historical tag was added, but the editor/summary for adding is somewhere in the page history (which is incredibly long due to tons of test posts from new users, which probably also has something to do with why it was abandoned). And yeah, maybe not a direct link, but there should be some path that leads those wanting to give feedback on the changes to the wizard to here, as this page seems to be the place to do it. The community tends to be more accepting of changes where discussion is widely advertised (since there's less possibility of local consensuses) vs. those that are perceived to have been done quietly behind the scenes. {{u|Sdkb}} ^talk 16:09, 21 December 2023 (UTC)

Or we could simply revive Commons talk:Upload Wizard. - Jmabel ! talk 19:15, 21 December 2023 (UTC)

@Jmabel: That would require someone or a group of someones at the WMF to actually care about the feedback and reply; it appears that has been sorely lacking on such pages for many years.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 13:05, 22 December 2023 (UTC)

@Jeff G.: absolutely. @Jeff G. and Sannita (WMF): We need the team at WMF in charge of this to commit to monitoring some page. I was just suggesting it might be better to revive an existing one than to create yet another new one. - Jmabel ! talk 16:17, 22 December 2023 (UTC)

At least for the coming months I can do some help with it, and then make a case to keep someone to watch feedback. And actually, I'd prefer to revive the existing page instead of creating a new one too. It's just that it's already there, and it's less work for everyone. Sannita (WMF) (talk) 15:35, 23 December 2023 (UTC)

@Sannita (WMF): Great! Just to be clear, are you talking about reviving Commons:Upload Wizard feedback, rather than using Commons talk:Upload Wizard?- Jmabel ! talk

@Jmabel: Yes. But I can keep an eye on both, FWIW. --Sannita (WMF) (talk) 12:29, 25 December 2023 (UTC)

As mentioned above, keeping everything centralized in a single venue would be better than having two. {{u|Sdkb}} ^talk 17:48, 25 December 2023 (UTC)

@Sannita (WMF): resuming monitoring of Commons:Upload Wizard feedback would be simplest, since that is where the Wizard says to leave feedback. - Jmabel ! talk 18:42, 25 December 2023 (UTC)

Commons:Upload Wizard feedback and Commons:Upload Wizard feedback/Header edited accordingly. People (especially Sannita (WMF)) may want to review and make sure you are fine with what it now says. - Jmabel ! talk 19:06, 25 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)

Changes to the MediaWiki Upload Wizard decision tree (December 2023)

Recently a number of changes were implemented to the MediaWiki Upload Wizard, instead of making it easier to use or better for content creators these changes seem to make it more seem like "a filter", a number of these changes have also made the technical aspect of the MediaWiki Upload Wizard less user friendly.

I will start with the technical issues these changes introduced, as illustrated here:

• 
  There is now this very "short" field for typing in the copyright tag, if you want to add multiple copyright ©️ tags by pressing "Enter" (formerly "Execute") it doesn't actually allow you to place a tag below it but it forces you to go to the next field.
• Here is a video of me attempting to split copyright ©️ tags.
• In this instance I've attempted to first copy the copyright ©️ tags with spaces and then paste it, unfortunately the new GUI doesn't allow this either.

I prefer to add spaces between copyright tags, for example for a Vietnamese photograph published in 1930 I would use:

• "PD-Vietnam"
• "PD-1996"

Unfortunately, now this isn't possible, the only thing the current field allows is this:

• "PD-Vietnam" "PD-1996"

As I've illustrated in the videos above, I cannot simply click between the copyright tags either, if I accidentally write "PD-Vietnan" "PD-1996" I cannot click on the correct letter and correct my mistake, I now have to delete "PD-1996", correct the mistake, and manually write the correct license again.

To me, these recent changes make it seem like the people who work on the MediaWiki Upload Wizard probably don't use it much, or at least don't use it often enough to notice how these changes affect the upload process. Another issue I have with this is something that reminds me of what Jimbo Wales said: "The primary issue is how seriously we take our chosen obligations to people in the developing world who do not have Internet connections. … Frankly, and let me be blunt, Wikipedia as a readable product is not for us. It's for them. It's for that girl in Africa who can save the lives of hundreds of thousands of people around her, but only if she's empowered with the knowledge to do so.." - Foundation-l mailing list (23 October 2005), well in 2005 Jimbo Wales probably couldn't have predicted it, but today billions of people in Africa and South Asia have access to the internet in ways they didn't have back then, this revolution was spearheaded by 4G (fourth generation) mobile internet and the vast majority of these new internet users exclusively have mobile telephones and other mobile devices to access the internet, while people outside of Africa and India primarily access the internet via laptops, desktops, and smartphones and use these devices for different things (in fact, I wrote this on my wife's laptop because last week's update made it very difficult to write on a mobile device), people in the developing world often exclusively use smartphones for all their computer-related tasks and web surfing.

Despite a vast majority of the world's computer and internet accessible devices being smartphones and related devices (iPods, other MP3- & MP4-Players, tablet PC's, netbooks, Etc.) and laptop and desktop sales having seen a global decline, almost every website seems to prioritise laptop and desktop traffic and "handicaps" mobile users in a lot of ways. The mobile experience of Wikipedia is utter shit and when I pointed this out people told me to shut up or ignored me, Wikipedia isn't unique in this, basically every "mobile website" can at best be described as a mobile app wrapper spending most of its time trying to direct you to Google Play to download their application programme, certain websites like Twitter/X and Reddit are unusable if you only use the mobile browser, Pinterest basically opens a message telling you to download their application programme every time you go to another page, and Meta's Instagram basically tells you "Download our app" every 30 (thirty) seconds. Compared to almost all other mainstream websites Wikipedia isn't as bad, but the mobile experience on Wikimedia websites are very, very bad. The MediaWiki Upload Wizard is definitely not an exception to this, for mobile on Wikipedia talk pages don't exist, navigational templates don't exist, categories don't exist, and unless you happen to have clicked on a pencil you probably didn't even know Wikimedia SUL Accounts existed, rather than being welcoming to billions of people from India and Africa, Wikipedia has shown mobile users that they are not just second (2nd) class citizens, they and their contributions are very much not welcome. This mobile unfriendliness seems baked into the MediaWiki software and is also often found at the Wikimedia Commons, while some improvements to the mobile interface have been made for Beta testers (users who have enabled "Beta features"), it is far from the "Desktop" experience, but even using the "Desktop" interface has been made more difficult this year as letters no longer scale to the size of the device but have become impossibly small to read.

With the above in mind, I sometimes think that the lack of spaces and organisation between templates is probably something that "just makes sense" if you're a desktop user but can be quite a hassle to work with if you're on a mobile device.

These changes aren't for uploaders, they're a filter to supposedly help patrollers.

These changes are clearly meant to reduce the workload of "advanced rights holders" (admins and the like) and patrollers, it's not designed to be either user friendlier or make the upload process easier for anyone. I know that the stated message of the Wikimedia Foundation (WMF) this fiscal year is to make it easier for admins dealing with deletions and not for uploaders, but that seems to have been the stated goal of the Wikimedia Foundation (WMF) for many years now and it has actively made content creation more difficult, have a higher learning curve, made content deletion and user exclusion much more easier, while having the (un)intended effect of attracting less new users. I would recommend people to read this essay.

One of the reasons why I have always hated the Wikimedia Commons application programme from Google Play is that it makes some very weird claims, such as the claim that you cannot upload any content that you yourself did not create (basically assuming that the public domain or free media created by others doens't exist). While this would keep noobs from uploading copyrighted works by others, people who have never used the website, only have a mobile device, and use the Google Play app to upload works might believe that a 400 (four-hundred) year old painting is "out of scope" for the Wikimedia Commons because someone developing the Google Play app thought that it was a good idea to write that. Of course, some of that was / is (I haven't used the mobile app in years) due to technical limitations, you simply couldn't upload non-own work files to the mobile app, but in some cases the new interface is very much a deterioration and not an improvement.

The recent changes to the MediaWiki Upload Wizard basically assumes that every user who uses this tool is new and introduces a number of clicks to upload works. Before, if I wanted to upload photographs I took myself all I needed to do was click "Next", that was one (1) click, now a number of extra steps were added, a few of which are illustrated here:

• 
  If you took 100 (one-hundred) photographs in a museum you now have to check this box 100 (one-hundred) times. Despite this, the text is also a lie, per "COM:SELFIE". 🤳🏻 Which reads "The uploading of small numbers of images (e.g. of yourself) for use on a personal user page of Commons or another project is allowed as long as that user is or was an active participant on that project.".
• 
  If I want to upload a 100 (hundred) different photographs of ancient Roman coins I now have to confirm 100 (one-hundred) times that these ancient Roman coins don't contain an album cover from Metallica.

Instead of being a simple process for "Own work" files the MediaUpload Wizard now you need to click an additional two (2) times, but it's the questions that are both to oversimplified to be useful, and so vaguely worded that they can easily be misleading.

Here are some of the questions:

• 1. Is this entirely your own work?
  • This is entirely my own work
  • This work contains the work of others
    • Examples: if someone else's work is visible in the work you are submitting, or if you have mixed someone's work with your own

• Is the pre-existing work free to use and share?
  • Yes, the pre-existing work was published under one of these free licenses
  • Yes, the pre-existing work is not protected by any copyright law
  • No, it is copyright protected
  • I am not sure

• I generated this work using an AI tool
  • Enter the name of the AI engine used. If someone else’s original work was used to generate this work, list them as well.
  • Example: Author: Midjourney AI; Photograph by Ansel Adams; colorized with Colorme AI, etc.

Well, it's rarely to find any photograph that is entirely the work of the photographer, how they will answer this question will then be based on what they think they know about copyright and how they interpret this question. If you take a photograph of a museum is this then your work or the architect's work? Legally speaking it's the architect's but most novice users don't know that. In fact, if you take a picture of a museum it isn't just the architect's work either, there could be small images of banners and the like which would fall under de minimis or other artworks that are covered by that country's freedom of panorama laws or are too small, this isn't "not protected by any copyright law", it just means that this work in this specific context is an exemption to the country's copyright laws but cutting out any part of this work makes it copyrightable. These nuances are completely lost in the current decision tree.

Furthermore, if you click "I am not sure" it just straight out tells you to not upload it, before these changes if a new user was unsure it would automatically tag the file as unlicensed and allow patrollers with more knowledge of copyright to tag it. Obviously, the old model was more collaborative, the old model encouraged users to help each other, the new model just tells new users "you're a burden, don't bother us with your bad uploads".

My main issue with this is that it will discourage good faith contributors from making mistakes they can learn from and learning about copyright by reducing both the project scope and the licensing policies into oversimplified misrepresentations of what they really are. Worse of all, the bad faith users that simply don't care about copyright likely won't be discouraged by this, the people who don't understand that a photograph of a monument in a country without freedom of panorama isn't "completely their own work" won't understand this, we'll just end up filtering more future contributors out by being a more uninviting place.

Later this now default unselected decision is introduced:

• 3. Please select the option that best describes the purpose of this work.
  • This work provides knowledge, instructions, or information to others.
  • This work is for my personal use e.g. photos of myself, my family or friends, or I am required to upload it for my job.

Not only is this annoying to check for every upload, it is outright wrong. "COM:SELFIE". 🤳🏻 Which reads "The uploading of small numbers of images (e.g. of yourself) for use on a personal user page of Commons or another project is allowed as long as that user is or was an active participant on that project." clearly states that there are some instances in which these images are in scope. Furthermore, we would want celebrities and other notable people to upload selfies of themselves. "I am required to upload it for my job" is also a terrible sentence to have here, do we really want to exclude every file uploaded by employees of the Swiss National Library?! Paid editing isn't against the rules, this sentence won't discourage people promoting their small business, it will discourage people who work for libraries and museums and a part of their job is to upload educational content here. Also, we should want for people who work for a major company to upload a new logo of better images of their corporate headquarters to be used on Wikipedia, we should direct them to the VRTS process and not just bluntly tell them that their images are not welcome because they were paid to upload here.

Fun fact: Any employee of a Wikimedia chapter isn't allowed to upload anything either, because they would have to state "I am required to upload it for my job.", so Wikimedia chapter employees shouldn't be uploading anything according to this logic either.

Everyone gets treated equally... as a noob.

Another issue I have with these changes is that they just assume that you're a newcomer and don't understand the rules. Option 3 (three) for "Own work" files is always left unchecked, this makes sense as not every upload is the same, but should this question really be asked of every user for every upload?

I completely understand why this team tries to make the uploading process more difficult and raise the bar, but while most copyright violations come from most newcomers, most uploads in general come around a thousand (1000) or so highly active users that use this tool way more than a few newcomers, and not only does this make the upload process more tedious, it also sends the wrong message by oversimplifying a lot to the point of just being plainly wrong. I very much encourage actual improvements to the MediaWiki Upload Wizard, I don't see why the upload process must be made more difficult for everyone.

Just like how "Special:Upload" still exists for users who prefer this old timey upload GUI over the MediaWiki Upload Wizard, could we please have an alternative MediaWiki Upload Wizard from September 2023 for those of us who do not prefer this version? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:00, 14 December 2023 (UTC)

Ask for general feedback

After implementing changes like last week's it might be wise to have an additional step after the upload process to all users who have had at least 1 (one) upload in the past 6 (six) months. This message could ask "We changed the MediaWiki Upload Wizard, what did you think of these changes?" And then either direct them here or direct them to a survey (or a general feedback page for a batch of changes) and then here. That way the Wikimedia Foundation (WMF) would have more direct feedback from uploaders, especially uploaders that rarely or never edit meta-pages like these. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:53, 14 December 2023 (UTC)

@Donald Trung I already had in mind to conduct a survey, but as you said, it's too early to have one. I'll tentatively schedule it for May-June. Sannita (WMF) (talk) 13:39, 18 December 2023 (UTC)

Problem in the question that asks if you used software

I have this second-hand, and it was in broken English (and I personally don't use the Upload Wizard) but I gather from a recent exchange on the Help Desk that the Wizard now asks question about whether you used software to help you make the image, and that if you did it presumes that means Artificial Intelligence and tags accordingly. This particular user used paint.net; I often use Hugin to stitch panoramas out of my own copyrighted photos; I've also been known to use GIMP to manipulate a photo (color levels, perspective correction, Gaussian blur over a copyrighted element, etc.). There are presumably quite a few other programs someone might use to create or manipulate an image where the work does not become a public-domain piece of AI work. - Jmabel ! talk 23:26, 14 December 2023 (UTC)

Further clarification, it sounds like just a wording issue. The user adds: 'This option writes "Bu çalışmayı bir YZ aracıyla oluşturdum" that can translated to English as "I created this work using an AI tool" and i cannot figure out that "YZ" stands for "Yapay zeka" ("artifactial [sic] intelligence" in english), and i think not only i falled this misunderstoodate. I think it must write the full word "artifactial [sic] intelligence" (or "yapay zeka" in turkish), also indicate that: this work will be public domain if it created with an artifactial [sic] intelligence tool.' I don't necessarily agree that we need to explain the copyright consequences of it being created with artificial intelligence, but if "YZ" was opaque to a native Turkish speaker, then it's a poor choice. - Jmabel ! talk 23:54, 14 December 2023 (UTC)

Addition by user: i assumed it means "any", like this "i am created this image with a blah blah blah program". This is because YZ are the last two letters and they are sometimes used like "if they said you are wrong because you did xyz". RuzDD (talk) 00:24, 15 December 2023 (UTC)

@Jmabel I'm not sure if I got it right, so please bear with me: the user is lamenting that the current wording is not correct, am I right? I guess this has something to do with the way the interface was translated in Turkish, since in English the reference to Artificial Intelligence is pretty clear. If it's a translation issue, I guess I can ask some contacts of mine to intervene on the translation and make it more clear. Sannita (WMF) (talk) 10:14, 18 December 2023 (UTC)

Yes, i think it should be write "yapay zeka" words instead of "YZ". Also, read if you want: Probably you know English better than me: i understood you think "AI" is pretty clear, but does "AI" not also means "Adobe Illustrator"? RuzDD (talk) 13:05, 18 December 2023 (UTC)

@RuzDD no, it only means "Artificial Intelligence", but I can see that it could be misunderstood. I'll note it to the designer and will ask to fix it in the next deployment (probably mid-January, not before that, sorry).

Meanwhile, I think the Turkish message should be changed in Translatewiki in order to make it more clear. You can help us doing so clicking on this link and correcting the message. Or I can see if I can find some Turkish user that can help us with that.

Thank you very much for raising this problem, it is one of those cases where everything seems to be "clear" when designing, but it's not clear at all when applied. :) Sannita (WMF) (talk) 13:48, 18 December 2023 (UTC)

@RuzDD: if you look on the page Sannita linked for where it says "I generated these works using an AI tool", you can modify the Turkish translation. - Jmabel ! talk 20:32, 18 December 2023 (UTC)

@Sannita (WMF): However: when I set up an account on Translate Wiki, hoping to understand this better, and tried to arrange to translate some content into Spanish (where I'm near-fluent), I (1) could not work out how to make the "test" edits that would demonstrate my proficiency and (2) appear to be unable to edit either the "Support" page or my own user talk page there. I'm a 20-years-experienced wiki user, so I'm pretty comfortable in saying that getting approved there is unnecessarily unusual and obscure. Shouldn't people who create an account get some sort of automated "greeting" on their talk page that is clear about mandatory next steps? Shouldn't it be easy to find the mandatory test you have to go through?- Jmabel ! talk 20:55, 18 December 2023 (UTC)

@Jmabel I share your frustration, I had to underwent some hassles too back in the days with that website, which is not very userfriendly sometimes... Unfortunately, it is not run by WMF so we can do very little, I guess you have to ask the local admins to set up a more friendly welcome. :( Sannita (WMF) (talk) 08:42, 19 December 2023 (UTC)

Own works: Uploader's name, not username, as author

Hello, I use to upload my works giving my name as author and for attribution, not my Commons username. I can't find the option to enter my (the uploader's = author's) name in the wizard any more. Could we please have this option back again? --Cephyr~commonswiki (talk) 11:29, 16 December 2023 (UTC)

@Cephyr~commonswiki: I'm not sure about the upload form, but it's still possible to set your name in the UploadWizard preferences at Special:Preferences#mw-prefsection-uploads. Sam Wilson 11:57, 16 December 2023 (UTC)

What happened to the choice for Flickr licenses in the Upload wizard?

Yesterday I uploaded File:Plumber James (Berkshires in MA,2007).jpg with the Upload wizard. But apparently the Upload wizard has been changed, and I could not find the box to tick for Flickr licenses anymore. And (perhaps even worse) after uploading there was nothing in the file about a Flickreview (I posted this question first at Commons:Village pump and after that Adeletron 3030 added {{flickrreview}} to the file and changed the license, and then the FlickreviewR 2 did its work, so for this file it is OK, but I still want to know for other uploads). Should I (and all the other uploaders) now ask for a Flickr review for each uploaded file myself (since a Flickr review is still needed)? JopkeB (talk) 04:12, 20 December 2023 (UTC)

@JopkeB I just did a couple of test uploads and I didn’t experience any issues. For both, I used copy-pasted the Flickr link into Upload Wizard.

File:Plumber under kitchen sink.jpg is from the same Flickr user. Upload Wizard did not give me an option to select a license, I assume because it already has a specific CC license.

I did have the option to choose a license for File:Hudson vs Medina high school boys soccer 2023.jpg since it has a Public Domain Mark non-license.

In both cases, Flickrreview was added automatically. Adeletron 3030 (talk) 12:38, 20 December 2023 (UTC)

Minor point: {{PD-author-FlickrPDM}} should be a license option for Flickr PDM files? Adeletron 3030 (talk) 15:15, 20 December 2023 (UTC)

Thanks, User:Adeletron 3030. So you have to add {{cc-by-2.0}}{{flickrreview}} (or another license) in the correct field, while before you could just click on a box for Flick and then choose the right license. For me this falls into the category "not every change is an improvement". I might make a note and have a lot of experience on Commons, but random end users don't, they do not know these codes. And it would have been nice when this would have been communicated to the community or at least to people who regularly upload Flickr photos. Is there a possibility to get back the part of the old interface about Flickr (and keep the rest because that looks good at first glance)? JopkeB (talk) 16:41, 20 December 2023 (UTC)

@JopkeB It's weird that your experience is different from mine - the templates loaded automatically for me. Adeletron 3030 (talk) 16:46, 20 December 2023 (UTC)

So you do not fill in any code? What box do you tick? What do you do with question 1, Do you know under which Creative Commons license this work is published?? JopkeB (talk) 16:54, 20 December 2023 (UTC)

@JopkeB Here's my workflow for uploading a Flickr file with Upload Wizard:

1. Select "Share images from Flickr"

2. Type a Flickr link into the URL box.

3. If the file has a Creative Commons license, there's nothing to choose because you just use the license that the Flickr uploader selected. I just see a note that reads: The file is under the following license on the source site "Flickr": Attribution License.

If the Flickr user selected PDM or a government license, then I'm asked to select a license (though curiously, neither {{PD-author-FlickrPDM}} nor {{PDMark-owner}} is an option). Adeletron 3030 (talk) 17:39, 20 December 2023 (UTC)

@JopkeB Thanks for reporting this. Our work on UploadWizard should not have touched the Flickr part, so it's weird that it acted the way it did with you. Can you please replicate the bug step by step here? Sannita (WMF) (talk) 17:32, 20 December 2023 (UTC)

I now see that I have overlooked the link Select "Share images from Flickr" on the front page of the Wizard. Thanks Adeletron 3030 for your patience and writing out the actions.

So, Sannita (WMF), that is what I did: I immediatement clicked on "Select media files to share" instead of "Share images from Flickr" and went on. That is what I was used to.

For me the problem has been solved now. JopkeB (talk) 04:23, 21 December 2023 (UTC)

This renewed Wizard form indeed is an improvement, for Flickr uploads (much easier) as well as for the main stream uploads. I hope there will be much less copyright issues to deal with. JopkeB (talk) 06:12, 21 December 2023 (UTC)

@JopkeB I'm glad it solved for the better. And thanks for the compliments. :) Sannita (WMF) (talk) 14:46, 21 December 2023 (UTC)

Affirmation issue

I'm uploading a simple logo under {{PD-textlogo}}, but the affirmation I have to check says "I confirm that this work does not include material restricted by copyright, such as logos, posters, album covers, etc." {{u|Sdkb}} ^talk 05:13, 21 December 2023 (UTC)

@Sdkb: and the problem is...? It doesn't include material restricted by copyright, so the answer is "yes," you confirm that. - Jmabel ! talk 07:07, 21 December 2023 (UTC)

The "such as logos" is the issue. The disclaimer implies that all logos are copyrighted/not allowed on Commons, which is not fully true. Balancing all the nuances/exceptions with simple instructions is always a challenge. {{u|Sdkb}} ^talk 07:15, 21 December 2023 (UTC)

@Sdkb Thanks for noticing. Unfortunately, as you say, balancing the need for simple instructions with the need of providing help to navigate the nuances and exceptions of Commons' rules is very difficult. I'll make a note for the designer, to see if we can solve this. Sannita (WMF) (talk) 11:32, 2 January 2024 (UTC)

Default settings for content creators

I'd like to see an option for content contributors to create default settings. I upload my photos always under the same license and they're always being created for educational purposes. On Flickr, I can mark CC-BY SA 4.0 as my default license and their interface doesn't ask me the same question over and over again whenever I upload a new file. I find that more convenient and would like to see the same feature here. Best, --Frank Schulenburg (talk) 16:29, 28 December 2023 (UTC)

See #Two extra clicks again. You can already choose the default license in the preferences, but there are still other choices where there is currently no possibility to default. Ymblanter (talk) 18:38, 28 December 2023 (UTC)

Thanks Ymblanter! I have “choose standard license (whatever that is) per default” enabled, but whenever I upload an image, I get asked under which license I'm planning to release my photos. So it seems like whatever I set in the preferences will pre-fill the license options, but not get rid of the which-license-would-you-like-to-use question during the upload process. Flickr is smarter: I told their upload system years ago that it should set CC-BY SA 4.0 as my default license and I've never been asked about licenses again. Also, hiding the default license settings in our user preferences here on Commons doesn't seem the most user-friendly way to handle this from a UX experience. Furthermore, I agree that we need to be able to set default values for all the other options as well in order to make the upload process smoother. Best, --Frank Schulenburg (talk) 19:32, 28 December 2023 (UTC)

If I go to preferences -> upload wizard, I do not see "standard license" as an option. For myself, I have chosen "own work - cc-by-sa 4.0" as default, and by every upload it gets pre-filled. I agree that the upload wizard can be more user-friendly, but I have a confidence that Sannita, who (in his volunteer role) is a fellow Wikidata administrator, has sufficient understanding of these issues. Ymblanter (talk) 19:48, 28 December 2023 (UTC)

@Frank Schulenburg Thanks for your comment. Unfortunately, Mediawiki is not Flickr, so the only way to make a default for this kind of information is the user preferences. And yes, there is plenty of stuff that doesn't have a preference right now, but I'm lobbying the dev team to create more, to reduce the number of clicks a user should do. I can't promise they will be shipped in time, but I'm trying. Sannita (WMF) (talk) 11:39, 2 January 2024 (UTC)

Uploaders statistics

2056350 account uploaded one or more files to commons.

1 file was uploaded by 1063435 accounts

2 files were uploaded by 321023 accounts

3 files were uploaded by 159280 accounts

4 files were uploaded by 96620 accounts

5 files were uploaded by 65712 accounts

6 files were uploaded by 46939 accounts

7 files were uploaded by 34888 accounts

8 files were uploaded by 27434 accounts

9 files were uploaded by 22018 accounts

10 files were uploaded by 18621 accounts

11 files were uploaded by 15102 accounts

12 files were uploaded by 12954 accounts

13 files were uploaded by 10777 accounts

14 files were uploaded by 9512 accounts

15 files were uploaded by 8427 accounts

16 files were uploaded by 7318 accounts

17 files were uploaded by 6457 accounts

18 files were uploaded by 5893 accounts

19 files were uploaded by 5356 accounts

1937766 accounts uploaded less than 20 files (94,2% of all acounts that uploaded one or more files)

118584 accounts uploaded 20 or more files

The 315 most prolific uploaders uploaded 58 million files (58% of all uploaded files, between 40000 and 6.6million files per account)

IMHO the upload wizard is a tool for the 5% of users, who upload between 20 and 40000 files, but 94% of users are better up with other upload tools. (i.e. 50% of users, who only ever upload a single file). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 20:23, 28 December 2023 (UTC)

I already uploaded 26 files today. Could you provide a link please. Thanks. Ymblanter (talk) 20:31, 28 December 2023 (UTC)

C.Suthorn, um darauf zu schließen, für wieviele Beiträger der Upload Wizard die beste Version ist, müssten wir da nicht wissen, wieviele Menschen ihn bei obigen Uploads benutzt haben? Ich verstehe momentan nicht, wie man aus der Zahl der in einer Sitzung hochgeladenen Fotos auf die Verwendungsmuster des Upload Wizards schließen kann… --Frank Schulenburg (talk) 20:58, 28 December 2023 (UTC)

Nicht in einer Sitzung - insgesamt. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:26, 28 December 2023 (UTC)

Entschuldigung, aber ich verstehe das immer noch nicht. Warum meinst Du die Nützlichkeit des Upload Wizards daran messen zu können, ob jemand weniger oder mehr Fotos hochgeladen hat? --Frank Schulenburg (talk) 21:38, 28 December 2023 (UTC)

Per Ymblanter, please add the source. Also it would be nice if somebody made a chart out of that as well of a variant that also considers how heavily files are used (and/or viewed) (see Category:Commons statistics).

Moreover, this info seems irrelevant here because the Upload Wizard is even more important and useful for those who haven't already uploaded many files here. Prototyperspective (talk) 21:30, 28 December 2023 (UTC)

I am pretty sure there is a tool for usage (I can look up there all usage of my files in Wikimedia projects - obviously not the external usage), but I do not have a link at the moment. Ymblanter (talk) 21:52, 28 December 2023 (UTC)

I know that there is a tool for that but that wasn't what I proposed. It's here: (views & file-uses) (the latter, petscan, is dysfunctional for me). Btw, I'm interested in alternatives to these two and it should differentiate between types and degrees of uses per file. I just wanted to note that a chart showing the above statistic would be useful but should be complemented with a possibly even more useful chart(s) that also considers file-uses. Prototyperspective (talk) 22:23, 28 December 2023 (UTC)

For usage of already uploaded files there is the pageview api: pageviews.wmcloud.org It offers a number of statisics for individual files, but also for general usage, and top viewed items. But this page is about uploading the content, that can later be downloaded or viewed. The upload wizard or other upload tool do not influence how often the files are viewed, after they have been uploaded. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 01:31, 29 December 2023 (UTC)

Forgot to mention it. It's not useful/relevant here since you can't make it show the statistics of files uploaded by a user for example. Again, I just mentioned that just like edit-counts are insufficient for charts about contributors, number of uploaded files also isn't enough – things like file-uses would also need to be considered and it would be interesting to see charts of that. Prototyperspective (talk) 12:14, 29 December 2023 (UTC)

@C.Suthorn: are you saying that the Upload Wizard isn't useful for people who upload a single file? If so are you saying it isn't intended for that, or jus tdoesn't serve that purpose well? I personally never use it (I copy-paste and then edit in Special:Upload) but certainly Commons:First steps seems to suggest the Upload Wizard for new users, and when they ask about how to upload on the Help desk, that's pretty consistently where we aim them. Are you saying that is wrong? - Jmabel ! talk 22:34, 28 December 2023 (UTC)

Ich sage, dass der UW, der es ermöglicht, 50, 150 oder 500 Dateien in einer "Session" hochzuladen, für Leute, die zur einen Hälfte in ihrem Leben nur eine einzige Datei hochladen, und beinahe zur anderen Hälfte weniger als 20 Dateien im Laufe ihres Lebens hochladen (also häufig eher 20 mal eine Datei, als 1mal 20 Dateien), für diese Leute überdimensioniert ist. Es ist wie mit einem 40-Tonner zum Einkaufen zu fahren und dann nur eine Flasche Mineralwasser zu kaufen, das geht zu Fuß, per Rad oder mit einem Kleinwagen viel besser. Andererseits werden 58% des Contents von (315) Leuten hochgeladen, für die der UW unterdimensioniert ist, die daher meist andere Upload-Tools nutzen. Ein Tool wie der UW ist in erster Linie nützlich für die weniger als 200000 Leute, die mehr als 20 und weniger als 40000 Dateien hochladen, aber auch von diesen laden die meisten eher 20 Dateien im Laufe ihres Lebens hoch, als mehr als 50. Daher ist es sinnvoll, ein Tool zu haben, das darauf optimiert ist, bis zu 20 Dateien hochzuladen, während der UW (wenn der UW denn auf irgendetwas optimiert ist) darauf optimiert ist mehr als 50 oder 150 Dateien (in einer Session) hochzuladen. Das ist für die meisten Leute überdimensioniert, aber für die zahlenmässig meisten Uploads unterdimensioniert. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 01:22, 29 December 2023 (UTC)

Für den Upload großer Mengen an Fotos gibt es meines Wissens nach bessere Lösungen. Meinem Verständnis nach ist der Upload Wizard vor allem ein Weg, leicht und ohne großes technisches Wissen Dateien hochzuladen. Ich persönlich benutze ihn seit seiner Einführung ununterbrochen, sowohl für das Hochladen von einzelnen Fotos als auch für dasjenige mehrerer Bilder. Der Upload Wizard ist die ideale Lösung für Menschen, die neu auf Commons sind, oder diejenigen, die – wie ich– ein eleganteres User-Interface bevorzugen. Als Werkzeug für den Massenupload von Dateien habe ich den Wizard nie gesehen. Und ich glaube auch nicht, dass er jemals dafür konzipiert wurde. Beste Grüße, --Frank Schulenburg (talk) 02:57, 29 December 2023 (UTC)

Stimme F.S. zu und finde den Upload Wizard besonders nützlich für Leute die beispielsweise nur eine Datei hochladen und sonst nichts. Außerdem weiß ich nicht wieso man hier auf Deutsch schreibt. Eine Quelle zu den oberen Stats fehlt übrigens weiterhin. Prototyperspective (talk) 12:17, 29 December 2023 (UTC)

Eine große Bedeutung hat der Wizard vor allem auch für die Wiki Loves Wettbewerbe, wo von den neuen Usern in der Regel auch einstellige Zahlen an Fotos hochgeladen werden. Ohne den Wizard bräuchte es für die Wettbewerbe eigene Tools, die dann aber von den normalen Tools abweichen würden und somit das Dabehalten der Neuen erschweren würde. Der Wizard muss also einfach nutzbar und zugleich flexibel anpassbar sein. GPSLeo (talk) 12:58, 29 December 2023 (UTC)

Unknown author added in wrong place

Tracked in Phabricator
Task T354182

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

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

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

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

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

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

Uploader not linked

Tracked in Phabricator
Task T354529

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

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

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

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

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

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

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

Allow multi-line in the source and author fields

Tracked in Phabricator
Task T352988

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

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

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

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

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

@SCP-2000 (and @PantheraLeo1359531 too), this problem should be solved now. Can you please confirm me it is? Sannita (WMF) (talk) 15:57, 26 January 2024 (UTC)

It is. Thank you! --PantheraLeo1359531 😺 (talk) 16:03, 26 January 2024 (UTC)

Line breaks in the textfields for author and file source

Tracked in Phabricator
Task T352988

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

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

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

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

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