Commons talk:WMF support for Commons/Upload Wizard Improvements

Archives Archive (Oct 23-Jan 24) Archive (Feb 24-Jun 24)

The 50 files limitation

Tracked in Phabricator
Task T349368

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

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

The wrong orientation bug

Tracked in Phabricator
Task T349369

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

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

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

Hey @Giftzwerg 88: , finally this bug has been resolved. A patch has been sent, and at the latest next week it should be included into code. Thanks for your patience! --Sannita (WMF) (talk) 08:32, 14 May 2024 (UTC)

Thank you for the update.--Giftzwerg 88 (talk) 10:36, 14 May 2024 (UTC)

Thank you, @Sannita (WMF). -- Ooligan (talk) 15:33, 14 May 2024 (UTC)

Two extra clicks again

Tracked in Phabricator
Task T353654

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

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

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

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

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

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

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

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

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

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

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

@Sannita (WMF) Also would it be possible to have a config in the preferences so that by default "Same as caption" is unchecked? Prototyperspective (talk) 22:12, 30 May 2024 (UTC)

@Prototyperspective I asked about it, it seems to be a bit more complicated than expected to have such a preference. I'll keep you posted about it, but it will have to wait. Sannita (WMF) (talk) 12:07, 31 May 2024 (UTC)

Thanks! I suspect the issue is mainly with providing preferences like that in general (which seems needed anyway), not about this particular preference which is just a boolean on the checkbox. Replying because I noticed one further issue: when copying "Caption" to other uploads, it checks the "Same as caption" checkbox even when one previously unchecked it and entered text into the description. Prototyperspective (talk) 15:32, 31 May 2024 (UTC)

Even worse, it rechecks the "Same as caption" checkbox even when not checking "Copy caption". Things like this should not happen as one should test and consider such basic issues before rolling this out and because it requires explicit rechecking in the code which one should have never added. Prototyperspective (talk) 16:37, 31 May 2024 (UTC)

@Prototyperspective Thanks for this thorough analysis. I'll report it to the devs, and try to see if someone can look into it soon. It's just that this bug catching is becoming a problem for other scheduled work, so it might take a while, just so you know. I apologise sincerely for the time you'll have to wait. Sannita (WMF) (talk) 15:53, 1 June 2024 (UTC)

V2C should integrated into MW

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

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

Tracked in Phabricator
Task T355340

Hi!

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

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

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

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

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

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

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

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

"Yes, the pre-existing work is not protected by any copyright law"

Tracked in Phabricator
Task T358354

Maybe it would be a good idea to allow people to (optionally) add license tags if they fill in this field. Currently, there is no difference between clicking on this and saying that a work is entirely your own, but why a photographed work is in the public domain varies from subject to subject. So there could be an OPTIONAL field where people can add license tags to explain why the work is (partially) free. These license tags can then appear at the bottom with a special field below the uploader's own license. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:40, 12 February 2024 (UTC)

Hey @Donald Trung, thanks for the suggestion. Can you please open a Phabricator ticket about it, so that I can put it on the devs radar? Thanks! Sannita (WMF) (talk) 09:23, 23 February 2024 (UTC)

Asking for prompt in AI-generated works

Tracked in Phabricator
Task T357806

AI-generated works are still a fairly small subset of Commons uploads, but tracking them, I'm seeing quite a few that are uploaded without making explicit the prompt that was used. That's a loss for us, as it's relevant metadata that is not possible to recover later. It should ideally be recorded using the recently introduced {{Prompt}} template; @Sannita (WMF), would it be possible to incorporate that template into the wizard when someone indicates they are uploading an AI-generated work? {{u|Sdkb}} ^talk 04:37, 16 February 2024 (UTC)

Hey @Sdkb, thanks for the ping. I'll pass it on to the team, and we'll evaluate the request next week. I'll keep you posted on this, but feel free to ping me again if I disappear. Sannita (WMF) (talk) 09:35, 16 February 2024 (UTC)

Hey @Sdkb, I have some updates on that. For the time being this request has been put on hold, since it is not entirely within scope of this year's work. I will keep an eye on it and see if in the next months this could be fixed. Sorry for the bad news. Sannita (WMF) (talk) 09:23, 23 February 2024 (UTC)

@Sannita (WMF), I appreciate the update, but I'm not quite sure what you mean by not entirely within scope. You are in the middle of the "Upload Wizard Improvements" project currently, yes? And as part of that you introduced the "I generated this work using an AI tool" option within the wizard, yes? And this task is directly related to that option, yes? I would have hoped that, when you budgeted time for the upload wizard improvements, you anticipated that there would be community feedback like this and built in some time to address such feedback. Sdkb ^talk 23:53, 25 February 2024 (UTC)

@Sdkb AI tool was introduced as an option, yes, but we don't have budgeted time this year to improve on this specific item of UW, since we are working also on other aspects of it. It is though on our watchlist, so I hope in some months the decision will be reviewed. Sannita (WMF) (talk) 17:24, 26 February 2024 (UTC)

I take your word about your team's resource constraints, and acknowledge that the Prompt template was introduced only more recently. But the ask to document prompts has been stated at Commons:AI-generated_media#Description over a year now, it says (in its current wording):

Whenever you upload an AI-generated image (or other media file), you are expected to document the prompt used to generate the media in the file description, and identify the software that generated the media.

I share Sdkb's surprise that this was apparently not considered when scoping out designing the recently added current message:

Enter the name of the AI engine used, followed by the name of the person who created the prompt:
Example: Author: Midjourney AI; prompted by Jane Doe

In fact, these budget constraints seem to be an argument for better, more informed planning in such matters, as it may be more costly to come back later and fix such omissions.

Regards, HaeB (talk) 22:12, 10 March 2024 (UTC)

@HaeB Thanks for your reply. I'll be sure to report this to the team, and ask them to correct this as soon as possible. Sannita (WMF) (talk) 11:36, 11 March 2024 (UTC)

@Sannita (WMF), just circling back to see if this has been taken up?

Overall, I share @HaeB's (and others') frustrations about the lack of collaboration on this project. Features like the workflow for AI-generated images appear to have been developed and launched without sufficiently consulting us, resulting in issues like this one (and much more basic stuff — have you noticed that the description field of every AI image credits the tool as the author but improperly links over the tool's name to the uploader's user page?). It is not a resolution to say that the problems introduced by your work are beyond the scope of your work to fix. Collaboration entails understanding what Commons needs from the upload wizard and letting that guide your overall direction/prioritization, not merely soliciting feedback to make small tweaks around the edges to designs whose core elements are already cast in place. Sdkb ^talk 21:20, 19 May 2024 (UTC)

Hi @Sdkb, unfortunately we haven't still reviewed this. I'll bring it up at the next meeting, and see if there is possibility of a review. Also, I'll ask for a review of the system message to bring it on par with guidelines. Sannita (WMF) (talk) 09:08, 20 May 2024 (UTC)

Adaptable release rights steps

Tracked in Phabricator
Task T357755

There is still no response to my feature request for making the release rights step adaptable through upload campaigns. We really need this for the Wiki Loves Contests where most of the questions asked in this step are irrelevant but might confuse the uploader prevent them from uploading anything. GPSLeo (talk) 15:03, 6 March 2024 (UTC)

@GPSLeo Apologies for letting you down. I'll raise this point in tomorrow's meeting, and let you know as soon as possible. Sannita (WMF) (talk) 15:24, 6 March 2024 (UTC)

Uploading files from Flickr with PDM

Tracked in Phabricator
Task T363493

— Preceding unsigned comment added by Sannita (WMF) (talk • contribs) 17:46, 25 April 2024 (UTC)

Thousands of files end up in Category:Flickr public domain images needing human review because files from Flickr that are uploaded with the wrong license.

I thought the users made mistakes during upload but I tested with File:Protecting U.S. Ambassador Linda Thomas-Greenfield.jpg and the license on Flickr https://creativecommons.org/publicdomain/mark/1.0/ is translated by the Upload Wizard to {{Cc-zero}} + {{Flickrreview}}. I had no chance to chose the license.

I can see there were an old discussion on Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements/Archive#What_happened_to_the_choice_for_Flickr_licenses_in_the_Upload_wizard? but I'm not sure if the problem was 100% the same.

If uploader think that Flickr user is the photographer it should be possible to chose {{PD-author-FlickrPDM}}. It would also be great if the uploader could chose another PD license tag. For example {{PD-old-70}} or {{PD-USGov}}.

@Ooligan, Leoboudv, Adeletron 3030, and Sannita (WMF): as info. --MGA73 (talk) 15:25, 25 April 2024 (UTC)

@MGA73 would you please file a Phabricator ticket for this? If you need help with it, I can help you with that. Sannita (WMF) (talk) 15:28, 25 April 2024 (UTC)

@Sannita (WMF) Reported as T363493. Hope I did it okay. --MGA73 (talk) 16:05, 25 April 2024 (UTC)

@MGA73 It looks good, thanks! Sannita (WMF) (talk) 17:45, 25 April 2024 (UTC)

@MGA73, @Sannita (WMF), Here: User talk:Ooligan#Public Domain images (PDM) photos from flickr is my recent reply to MGA73, which I wrote before reading this discussion here. -- Ooligan (talk) 17:48, 25 April 2024 (UTC)

@MGA73: Right, the wizard should offer {{PD-author-FlickrPDM}} by default for PDM-marked Flickr uploads per COM:PDM.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:38, 27 April 2024 (UTC)

I do not think this is a bug. While we might come up with another way to do this, the Public-Doman mark on its own does not tell us the rationale for being public-domain, which Wikimedia Commons requires. - Jmabel ! talk 18:54, 25 April 2024 (UTC)

Hello @Jmabel, if a "bug" to which you referred is a software bug, then this appears to be one.

From the Wikipedia entry, "A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways."

The Upload Wizard tool is certainly producing "errors" (changing to a different Creative Commons license than the license used at the file's source webpage) and its actions "produce an incorrect or unexpected result, or to behave in unintended ways."

Did you notice this phabricator ticket submitted by User:MGA73 https://phabricator.wikimedia.org/T363493[1]? Thanks, -- Ooligan (talk) 19:45, 25 April 2024 (UTC)

@Ooligan: I'm sorry: yes, CC-0 is a mistake; marking them as needing review is not. - Jmabel ! talk 23:54, 25 April 2024 (UTC)

@Jmabel, @User:Sannita, @MGA73, Yes, hopefully after the correct license is applied to "PDM" files being uploaded, that will eliminate the Flickr public domain images needing human review step.

Better would be a choice menu to add the more specific PD-USGov tags here: Category:PD US Government with the added ability to add that same specifically chosen tag to multiple files with one click before uploading with Upload Wizard. It is a good tool that will become even better. -- Ooligan (talk) 00:36, 26 April 2024 (UTC)

@Jmabel Humans should chose the license and that is why the uploader should add it. If user on Flickr uses {{Cc-by-sa-2.0}} it does not specify why it is cc. We just assume that the Flickr user is the photographer. Its the same here. We assume that the Flickr user is the photographer and chose {{PD-author-FlickrPDM}} unless we have reason to think its not own photo. For example if it is a photo or a painting from 1905 for example the license should be PD tag to tell copyright expired. I see no reason why the uploader should not have the option to chose the correct license during upload. If needed we could have the option that if uploader does not specify a license then the Upload Wizard picks cc-zero. --MGA73 (talk) 20:08, 26 April 2024 (UTC)

If the Flickr user put a PDM mark on their own photo, that probably signals the intent to put their file in the public domain, but it also suggests someone who does not understand copyright well. That is certainly not the intent of the PDM mark on Flickr: if that is your intent, you should use CC-0.

We absolutely should not put CC-0 on a photo where the rights-holder did not specifically grant it. {{PD-user}} would be much more on the mark, except that it is only for our own users. We probably should have an analogous {{PD-Commons-user}}. The problem with CC-0 is that it has a specific waiver and public license fallback that are in no way implied by PDM. - Jmabel ! talk 05:06, 27 April 2024 (UTC)

I think whoever made the upload wizard this way thought that CC-0 is a temporary template to use while someone (uploader) picks the right license. It would perhaps be better to create a "PDM-needs-check" to add on files where uploader does not pick another license (as a better temporary template than CC-0). If uploader pick a specific license I think the Flickrreview bot can pass them. If I upload a photo from the internet and claim PD-USGov for example there will in most cases be no review by someone else. So it's not a big problem if Flickrbot confirm that the file was uploaded as PDM. If anyone thinks the license is wrong they can add the correct license or nominate the file for deletion. --MGA73 (talk) 17:50, 6 May 2024 (UTC)

Enhancing Wikimedia Commons' Upload Wizard for Large File Handling and details

Tracked in Phabricator
Task T358982

Tracked in Phabricator
Task T355613

I am puzzled by the enhancements to the Upload Wizard given that uploading a new version of a file over 100Mb remains impossible. Additionally, the requirement to wait until after the upload to enter file details like title and description—potentially taking hours—feels unnecessarily cumbersome. In contrast, the Internet Archive allows for the seamless upload of large file volumes without such constraints. It's concerning that our upload wizard still does not support large files.

Here's how to replicate the issue:

1. Attempt to upload a new version of a file by clicking "Upload a new version of this file."
2. The process is blocked if the file exceeds the 100 MB limit, even though the original file may be larger.

What occurs is that the upload limit of 100 MB is inadequate for uploading a new version of a file originally larger than 100 MB. Ideally, the file should upload without such restrictions.

We are using Wikimedia Commons, and this has been an ongoing issue for years. It is frustrating. I suggest we implement a feature that allows entering all necessary details for files—such as file name, description, and category—during the upload process. This change would enable us to leave files uploading overnight without having to return to input details post-upload, streamlining the entire process. Related tickets: [2][3] Wilfredor (talk) 16:23, 2 May 2024 (UTC)

@Wilfredor: thanks for your message. As I said, I'll try to get both tickets on the devs' table as soon as possible, but I also asked you for clarifications on the second ticket. You can answer in Phabricator, so that I can update the ticket. Sannita (WMF) (talk) 16:42, 2 May 2024 (UTC)

When you upload an image to a platform, you typically follow a procedure where you first upload the image and then, only after it has been uploaded, you can add descriptions, tags, or other metadata. This can be inefficient if you have multiple images to manage, as you have to wait for each image (and all images) to upload before entering its information.

A better approach could be to allow users to input all relevant data for each image (like title, description, tags) at the same time they select the image for upload. This data would then be processed together with the image upload, streamlining the workflow and saving time, especially when handling multiple files. This method would eliminate the need to wait for each image to upload before entering information, making the entire process more efficient. Wilfredor (talk) 16:52, 2 May 2024 (UTC)

@Wilfredor: sounds like you'd rather use Special:Upload. Is there anything particular that you are getting positively out of using the Upload Wizard? - Jmabel ! talk 18:45, 2 May 2024 (UTC)

to upload a new version of the same file you need use the Special:Upload Wilfredor (talk) 18:46, 2 May 2024 (UTC)

The 100 MiB upload overwrite limit can be bypassed with User:Rillke/bigChunkedUpload.js --PantheraLeo1359531 😺 (talk) 15:46, 15 May 2024 (UTC)

@Wilfredor @Sannita (WMF) To clear this up: revision upload is not handled by the wizard. Files larger than 100MB can only be uploaded with chunked upload. There are some tools that handle chunked upload. If you do not want to use such a tool, you will need to click on the link to the right of "upload a new version" (which is limited to 100MB, as it is not chunked), that is called "chunked upload" and starts the bigchunkeduipload tool by Rillke and mentioned by @PantheraLeo1359531. Also, if you use this tool for uploads you need to enter all the information BEFORE you select the file to upload but this does actually not matter, as for revision uploads this information is disregarded anyway and only the upload comment is actually used. On the bright side: Rillke's tool is very stable (only Offroader is more resilient). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 16:26, 15 May 2024 (UTC)

Understood, correct :) --PantheraLeo1359531 😺 (talk) 16:28, 15 May 2024 (UTC)

This doesn't work, I've tried it hundreds of times in thousands of possible ways over the years. It is a well documented bug. A good example is this image that I had to upload several times [4][5][6][7][8] Wilfredor (talk) 04:00, 18 May 2024 (UTC)

One more extra click

Well, we got one more extra click in the Upload wizard. Three more extra clicks in half a year. I will invest my time into writing my own wizard, I consider this development extremely user unfriendly. I do not believe anymore that the developers listen to us. Ymblanter (talk) 18:41, 15 May 2024 (UTC)

Hi @Ymblanter, I'm really sorry to hear this. I'm trying my best to obtain from the devs the possibility of reducing the extra clicks for experienced users, but there is also a discussion ongoing about preference bloating that we're considering. I'll pass on your feedback anyway, and try to make the case for reducing the burden on experienced users once again. Sannita (WMF) (talk) 08:40, 16 May 2024 (UTC)

Thank you but for the time being I am back to the old form. I will probably still use the wizard for uploading several similar times files because the function of taking options from one file to the others is convenient, but for one file I think the old form is now faster. Ymblanter (talk) 09:59, 16 May 2024 (UTC)

+1 about the extra clicks. When using several times the upload wizard in a row, previous clicks were stored (ant it was nice) but that was lost some weeks or months ago.--Pere prlpz (talk) 16:35, 18 May 2024 (UTC)

+1 about the extra clicks. -- Ooligan (talk) 14:59, 17 July 2024 (UTC)

@Sannita (WMF), could you provide a link to this discussion refered to above where you wrote, "there is also a discussion ongoing about preference bloating that we're considering."

What is the current status of this discussion and its relation to the issue of "reducing the extra clicks for experienced users?" Thank you, -- Ooligan (talk) 08:26, 2 December 2024 (UTC)

@Ooligan The discussion was in internal channels, sorry I cannot provide you any link. As for the current status, we didn't discuss it further as we concentrated on other changes in UploadWizard. Will try to revive the discussion at the next meeting, but so far it seems that there will be little to no update before next year at least. Sannita (WMF) (talk) 13:36, 2 December 2024 (UTC)

Thank you for the answer and fact that Upload Wizard user will "no update before next year."

What is "preference bloating" @Sannita (WMF)? -- Ooligan (talk) 22:28, 2 December 2024 (UTC)

@Ooligan No, I said that on this topic there will be no update until the end of the year. Next year is to be seen, but it first needs to be re-evaluated by the team.

"Preference bloating" means putting too many options into users' Special:Preferences, over-customisation is a problem code-wise and it is usually deprecated if those preferences are used by too few users. Sannita (WMF) (talk) 23:04, 2 December 2024 (UTC)

Thanks for the clarification about potential updates to Upload Wizard and for explaining the meaning of preference bloating. Best regards, -- Ooligan (talk) 23:15, 2 December 2024 (UTC)

Speaking from my own experience as a (retired) developer, there are ways to allow a great deal of user configurability without overwhelming the user with choices. Basically, my policy was always:

1. Sane defaults; usually if there are issues of backward compatibility, the existing behavior should remain the default, unless the existing behavior is widely seen as problematic.
2. A single, easy place to configure what are anticipated as commonly customized features.
3. A button or link in that place leading to "advanced options" that a smaller number of users will want to choose.

Of course, supporting certain types of preferences leads to code bloat, but that should almost never happen when the preferences in question are:

• Default values for inputs, including "default to last used value."
• Heights of various input boxes (widths can be trickier because they more often deeply affect screen layouts)

That said: I still find it tremendously easier to copy-paste-edit-upload in Special:Upload than to work my way through the Upload Wizard, and I really recommend to experienced users who know just what they want to produce to consider that workflow. Of course, I will readily admit, the lack of serialization/unserialization for structured data means that approach is limited to creating wikitext and no structured data. - Jmabel ! talk 00:59, 3 December 2024 (UTC)

I also do not understand why such settings would be to complicated. Upload campaigns are already defined by json configs and not with a nice UI. It only needs one person to set up a campaign for a specific scenario like "only own works with cc-by 4.0" and then there is a link people use to use this campaign that skips all copyright related questions. GPSLeo (talk) 14:58, 3 December 2024 (UTC)

• +1 the extra clicks issue. Maybe we should have a customisable MediaWiki Upload Wizard, where there exists a "Settings" button where users can enable or disable certain features of the MediaWiki Upload Wizard. On top of that, it's highly unlikely that a novice user would simply mess around with the settings, I've met users that have been contributors to the Wikimedia Commons for over a decade that were oblivious to basic customisation options, so this "Settings" button should be clearly advertised in the MediaWiki Upload Wizard itself. An extra click is fine for someone's first few uploads, but we shouldn't be spamming someone with tens of thousands or more uploads with the same question every single time. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:04, 2 December 2024 (UTC)

  FYI, we removed the extra clicks in the "Describe" step for autoconfirmed users with the last update to UploadWizard, so this should be solved finally. @Ymblanter @Jmabel @Ooligan @GPSLeo @Donald Trung can you please confirm? Sannita (WMF) (talk) 13:47, 5 December 2024 (UTC)

  Yes, this works, thanks. Ymblanter (talk) 20:16, 5 December 2024 (UTC)

Vorbelegung

Hi @Sannita (WMF), in de.wp we use the prefilling of the UW with information taken from the lists or from wikidata. In some cases it doesn't work to prefill the description.

• de:Liste der Kulturdenkmale in Meldorf doesn't work - https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=CHM-DE-SH&fields%5B%5D=45043&fields%5B%5D=54.09132%2F9.070947&descriptionlang=de&description=Nanny-Peters-Stift%2C+Norderstra%C3%9Fe+1%2C+1-1a&categories=Nanny+Peters+Stift
• de:Liste der Baudenkmäler im Kölner Stadtteil Bickendorf - doesn't work https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wlm-de-nrw-k&fields%5B%5D=8024&fields%5B%5D=Bickendorf&descriptionlang=de&description=Siedlung+Bickendorf+II%2C+Ahornweg+4%E2%80%9310&categories=Siedlung+Bickendorf+II

• de:Liste der denkmalgeschützten Objekte in Laab im Walde works - there is the "caption" in the url https://commons.wikimedia.org/wiki/special:uploadWizard?campaign=wlm-at&fields%5B%5D=129674&fields%5B%5D=48.15640/16.19409&captionlang=de&caption=Diebsgrabenaqu%C3%A4dukt+%28BDA-HERIS-ID%3A+111685%29%2C+Laab+im+Walde&descriptionlang=de&description=Diebsgrabenaqu%C3%A4dukt&categories=Diebsgrabenaqu%C3%A4dukt%2C+Laab+im+Walde
• de:Liste der Kulturgüter in Blauen works - https://commons.wikimedia.org/wiki/special:uploadWizard?campaign=wlm-ch&id=01402&description=R%C3%B6misch-katholische+Kirche+St.+Martin&categories=R%C3%B6m.-kath.+Kirche+St.+Martin.+Blauen%2C+BL

I guess it should be fixed, that you can prefill the description.

@Herzi Pinki @Enhancing999 für euch zu Info, auch wenn AT und CH wohl nicht betroffen sind @Raymond @GPSLeo für euch zur Info. vielleicht können wir irgenwas von AT und CH lernen. Ich kann es leider nicht fixen. Ich seh ein paar unterschiede, groß- und Kleinschreibung in den Urls, aber ich weiß nicht, ob das der grund ist

@Quarz ich hab den Bremer Express-Upload nicht getestet. Schau mal, ob du auch davon betroffen bist. Viele Grüße Z ^thomas 11:18, 20 May 2024 (UTC)

There is a bug report at Commons:Upload_Wizard_feedback#Caption_same_as_Description:_boring_and_confusing.

The difference between Campaign:wlm-de-nrw-k and Campaign:wlm-ch seems to be that the later doesn't use captions/wikibase. Reminds me that I wanted to edit Campaign:wlm-ch, but then got overwhelmed by it. Enhancing999 (talk) 11:59, 20 May 2024 (UTC)

Campaign:wlm-at also has "wikibase": {"enabled": false}, so "caption" in the url isn't actually used. Enhancing999 (talk) 12:11, 20 May 2024 (UTC)

Hi @Z thomas, as @Enhancing999 already said, we know about this and we're working to fix the bug. We apologise for the disruption, hopefully in a couple of days the patch will be on. Sannita (WMF) (talk) 12:06, 20 May 2024 (UTC)

Moin Z thomas, vielen Dank für den Hinweis. Nein, der Bremer Express-Upload umgeht den Wizard und ist daher nicht betroffen. Gruß Quarz (talk) 13:27, 20 May 2024 (UTC)

The prefilling tool should contain more prefilling fields like another descriptions in different languages --PantheraLeo1359531 😺 (talk) 19:05, 22 May 2024 (UTC)

New changes to the "Depicts" step in UploadWizard available on Beta Commons

Hi all! I wanted to announce that on Beta Commons a new version of the "depicts" step of UploadWizard is available for testing.

A brief note about the changes:

• basic "depicts" annotations (and other statements set up in campaigns) without qualifiers or references can now be added on the same page where the user is entering captions, locations, etc
• the separate extra page for adding structured data is removed from UploadWizard
• qualifiers and references can still be added on individual File pages as before (and that will take only one extra click)

The reason for us doing this is that we're hoping that by simplifying depicts annotations we'll make it easier to spot copyvios (and in particular FoP violations). The drawback from a user perspective that we already know of is mostly for users who might be uploading multiple images at once with non-depicts statements and/or qualifiers and references, and copying those from the first image to all other images in the upload. This functionality is no longer available - as far as we can tell it's not used much, but if there are people using it then we'd like to hear from those users who use it.

This new version will be available on Beta Commons until Monday afternoon. We're waiting for your feedback on it! --Sannita (WMF) (talk) 10:23, 19 June 2024 (UTC)

As I've brought up previously (and seems to have been ignored), I think it'd be better to use (recommended) than (optional).

I am a user who has uploaded multiple files with non-depicts statements before, as well as qualifiers for multiple statements before (functionality which is also being lost). It'd be nice if that functionality were still available under a more-hidden menu, but I also understand what you're going for with the simplification. I would prefer to see some indication that the structured data is coming from Wikidata, though — sometimes there are errors in the structured data (or a lack of details/descriptions that requires further investigation to determine the appropriate tags to use) — and it should be easy for editors to figure out where to go for that when needed. Sdkb ^talk 15:26, 19 June 2024 (UTC)

Additional thought: The gray text in the input box should be chosen carefully, and perhaps include more than just one example. Cheers, Sdkb ^talk 19:02, 19 June 2024 (UTC)

@Sdkb: Thank you very much, as always, for your comments. About the wording, we decided to go with "optional" because using "recommended" for some fields and "optional" for others can create confusion about their differences. It might even make "recommended" fields appear more important than mandatory ones. To counter this, we might then have to add a "required" tag for mandatory fields, which would add visual clutter and still not resolve the ambiguity between different tags. However, in the usability test, we noticed that people chose to enter the "depicts" field, because it was clear what was being asked for. They also understood that entering "depicts" would make their media more discoverable, which further motivated them to fill in the field.

As for the other improvements, we'll keep these suggestions as potential improvements for next iterations. -- Sannita (WMF) (talk) 14:10, 20 June 2024 (UTC)

@Sdkb A little update on the indication that the structured data comes from Wikidata: we opened phab:T368051 about it, and we're going to include it in one of our next iterations. Sannita (WMF) (talk) 16:59, 24 June 2024 (UTC)

For me this looks fine. One suggestion I would made is to add longer explanations for captions and categories they are displayed as overlay or a collapsed box and shown on hover or when clicking a button. The text should be stored in MediaWiki namespace so that it can be edited by the community. Similar to the bad file name warning but always available. GPSLeo (talk) 18:37, 19 June 2024 (UTC)

@GPSLeo: Thank you very much, as always, for your comments. I think that if the community writes the text first, we can find a way to add it to the designs pretty easily. -- Sannita (WMF) (talk) 14:10, 20 June 2024 (UTC)

Use captions for descriptions: Why only in English?

Tracked in Phabricator
Task T371514

My apologies if I've missed a long conversation on this topic – I tried to look through the archive. Please feel free to point me to a previous discussion I might have missed.

For some time now, the default option for descriptions when uploading images through the UploadWizard is to use the captions. To write new descriptions, one has to uncheck the box. So far so good. But why, if I add captions in multiple languages, does it only add a description in English, and not in the other ones? Julle (talk) 04:49, 30 July 2024 (UTC)

Hi @Julle, thanks for your comment. I need to double check this, but it might have to do with your preferences: if you selected English as language for your interface, then it gives English as first language for caption/description. Sannita (WMF) (talk) 11:09, 31 July 2024 (UTC)

Sannita (WMF): Much appreciated! Let me clarify, so you might be able to point me to any previous conversations or documentation I haven't been able to locate.

I just uploaded a mobile snapshot I took a few days ago to illustrate popular feelings related to the ongoing war in Gaza. I added captions in two languages. When I get to description, I left the "Same as caption" box checked. It added descriptions in two languages. This is what I considered to be expected behaviour.

A couple of days ago I uploaded a photo of a local park. I added captions in four languages, and left the "Same as caption" box checked. It added the English description only. This confused me, and led to my question above. Julle (talk) 12:21, 31 July 2024 (UTC)

@Julle Oh, this is completely different from what I understood. This is probably a bug, I'll file a ticket on Phabricator about it, and hopefully let you know as soon as possible. Sannita (WMF) (talk) 13:48, 31 July 2024 (UTC)

My apologies for being unclear in my first question, Sannita (WMF), and thank you. Julle (talk) 13:54, 31 July 2024 (UTC)

@Julle not at all! :) Anyway, I filed phab:T371514, it will likely be triaged next week, but mind that part of the team will be at Wikimania, so we might take a bit more of time. Sannita (WMF) (talk) 15:30, 31 July 2024 (UTC)

As MarkTraceur mentioned, it looks like an intended behavior of MediaWiki:Gadget-LanguageSelect.js. The collapsing is enabled by default: MediaWiki:Gadgets-definition. You can disable it in Special:Preferences#mw-prefsection-gadgets persistently, and on the file page dynamically ("Language select: show all" under the image). whym (talk) 01:05, 1 September 2024 (UTC)

Markup in caption field

@Sannita (WMF), another thing I just noticed that makes it perilous to make the caption field autopopulate to the description field: The description field can handle wikitext markup like italics, but the caption field cannot. Sdkb ^talk 01:16, 16 August 2024 (UTC)

@Sdkb Hi, sorry to answer this late, I just got back from a vacation, and I'm finally able to answer to notifications and messages. What do you mean by "perilous"? I wouldn't go that far to describe it... Sannita (WMF) (talk) 13:48, 26 August 2024 (UTC)

I would describe it as "plainer".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:06, 26 August 2024 (UTC)

I mean it in the sense that, if we're going to prioritize one field over the other, as the current design clearly does for the caption over the description, we want it to be the most capable field. And the inability of captions to handle markup indicates that may not be the case. I'll note relatedly that you never answered my question about what makes captions a more structured multilingual field. Sdkb ^talk 14:11, 26 August 2024 (UTC)

The UploadWizard is intended to be easy to use and markup is not easy to use compared to plain text. If you want to add markup it is still possible to set a different description text. I think I can also answer your question why captions are more structured. If you want to get the descriptions you have to write a parser for the wikitext of the page. With the caption you only need to make a simple API request to get the caption without any processing needed after the request. And as the data requested is much less it should also be much faster. GPSLeo (talk) 14:50, 26 August 2024 (UTC)

Couldn't and shouldn't the caption field automatically remove wikitext like wikilink syntax when the user adds such or at least ask the user to remove it? And what about the issue that many if not most files do have a description but no caption or descriptive/explanatory text only in the description field but not the caption?

For example, one could automatically add the first paragraph and/or some sufficiently short machine summary of the description and/or the whole file description if it's short enough into the caption field. In such cases one would currently have to remove all the wikitext markup. I don't know if for files that don't have a caption in the MediaViewer the description is shown at the top including the wikilinks which probably are useful to have in most cases. Prototyperspective (talk) 15:20, 26 August 2024 (UTC)

@Sdkb Apologies for never answering to you, I must have lost that question when it happened. Anyway, my answer is the same as GPSLeo's: descriptions (since they allow wikimarkup) must be parsed, while captions are just accessible without any processing. Sannita (WMF) (talk) 16:15, 26 August 2024 (UTC)

Descriptions are also licensed differently than captions.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:38, 1 September 2024 (UTC)

New round of proposed changes to UploadWizard: we are looking for your feedback!

Hi all! The Structured Content team will continue, in the following months, to improve the current user experience with UploadWizard. For this reason, we published on our project page the mockups of our proposed changes to the "Release rights" step.

In short, starting from your feedback received with our first round of improvements carried on in Fiscal Year 2023-2024, we suggest making some more changes to the step in which users select if their media is an “own work” or “not own work”. This includes also changes requested by you regarding adding custom public domain tags or license options, as well as a space to clarify AI prompts for AI-generated media.

We are looking for your feedback. What do you think of our proposed changes?

Thanks in advance! Sannita (WMF) (talk) 13:57, 18 September 2024 (UTC)

Tracked in Phabricator
Task T376522

Hi @Sannita (WMF)! Looking over all that, overall it all seems good!

The screenshots don't provide a full picture of all the possible paths through the workflow, though. I'm particularly curious about what happens in the new design when someone selects one of the "I don't know" options. Has that been built yet? If so, can you share?

Also, I think the list of reasons a work might be public domain could use some refinement. The tag {{PD-textlogo}}, for simple logos/wordmarks below the threshold of originality, is extremely commonly used (I'd say much moreso than {{PD-USGov-NASA}}). I would prioritize creating a workflow in the wizard that'd allow people to use that tag more easily. (This would involve teaching them a bit about the TOO; perhaps "Is your image simpler than these examples?") And I'd look around to see if there are any other PD tags that ought to be incorporated. Sdkb ^talk 03:46, 19 September 2024 (UTC)

Hi @Sdkb and thanks again for your feedback. About the first question, it will display some kind of warning to the user to either not upload or do more research. About the second question, the creation of a mini-wizard for selecting the PD tag would require quite some time, so in the meantime maybe we can just put a link to a list of PD tags, so that the user can choose freely which one to use? Sannita (WMF) (talk) 14:23, 23 September 2024 (UTC)

@Sannita (WMF), on the first question, sounds good; I'd love to see it specifically once it's ready.

On the second question, a link to the list of tags would be a small improvement, but it'll still be something that only more experienced editors will be likely to use. So I'd still encourage you to add a workflow for {{PD-textlogo}}. You've already added a workflow for AI images, so evaluating and refining the options in the list of license tags seems very much within the scope of the project you're doing, and would have a significant impact. Sdkb ^talk 09:44, 24 September 2024 (UTC)

@Sannita (WMF), would you be able to create a Phabricator task for this? Sdkb ^talk 14:18, 27 September 2024 (UTC)

@Sdkb To be completely honest, I'd prefer that you create a task (just because you have it more clearly defined in your head) and you link it to me, so that I can add the necessary tags and do the necessary tweaks to it. If you need help, then I can step in -- but early next week, before Monday I just can't create it. Sannita (WMF) (talk) 15:55, 27 September 2024 (UTC)

This looks fine. If someone chooses the option "I have the permission from someone else" the license and author selection should be fully available but the {{Permission pending}} template should be placed on the page. Maybe it would be good to add an additional check mark that the E-Mail to the VRT will be send soon after the upload. GPSLeo (talk) 06:21, 20 September 2024 (UTC)

Hi @GPSLeo, thanks again for your feedback. I've already relayed your idea of adding automatically the template, and it seems it can be done easily. We're also discussing the additional check mark, but I have a question: maybe it would be better to secure the authorization first, instead of uploading and then send the authorization mail? Sannita (WMF) (talk) 14:27, 23 September 2024 (UTC)

With authorization conformation first it is a problem to make sure that the permission covers exactly that file that was uploaded with the license the file was uploaded under. Of course people need the permission first but confirming the permission in the VRT process should be done after the upload. GPSLeo (talk) 14:50, 23 September 2024 (UTC)

I agree with GPSLeo. The process is a bit of a mess however it is approached, but this is usually simplest. It may not minimize the number of deleted files, but it minimizes the number of confusing and ambiguous cases, which means saving effort for the (always understaffed) VRT. - Jmabel ! talk 20:32, 23 September 2024 (UTC)

@GPSLeo @Jmabel Ok, just one more question: let's imagine that we allow users to upload medias without permission first, and {{Permission pending}} is automatically inserted in the description. What happens to the file if the PP template is not updated in, say, one month? Does it goes to speedy deletion, normal process of deletion or stays that way?

Also is the current phrasing for "please refer to VRT" good as it is or does it need changing? Sannita (WMF) (talk) 13:51, 26 September 2024 (UTC)

Yes the template changes by itself to the missing permission template and the photo shows up in the corresponding category after 30 days. Just to make sure that you are aware of this: The Wizard has to fill out the full template with {{Permission pending |year= |month= |day= }} I am not sure if substituting using {{subst:PP}} works with the Wizard. I think the wording is fine but to be able to change this if needed it would be good if the text would be taken from MediaWiki namespace like other interface messages. GPSLeo (talk) 14:30, 26 September 2024 (UTC)

@GPSLeo Is there a particular message that we should be aware of? Just to be sure to be on the same page. Sannita (WMF) (talk) 15:51, 26 September 2024 (UTC)

I meant on how the {{Permission pending}} works and that it requires the date added into the template. GPSLeo (talk) 15:54, 26 September 2024 (UTC)

Got it, thanks. I'll see what we can do about it. Sannita (WMF) (talk) 17:07, 26 September 2024 (UTC)

@GPSLeo We worked on your feedback and we updated the mock for the new VRT text. You can check the preview on Phabricator (also the ticket is phab:T370106, if you want to subscribe to it). What do you think? Sannita (WMF) (talk) 08:41, 7 October 2024 (UTC)

Looks good, I made some suggestions on the phab ticket. GPSLeo (talk) 13:49, 7 October 2024 (UTC)

Alternatives to {{Information}}

Is there a way to make the template being filled configurable? (see Commons:Village_pump/Technical#upload_wizard_for_books, ideally also artworks)
 ∞∞ Enhancing999 (talk) 09:04, 21 September 2024 (UTC)

Hi @Enhancing999, thanks for the question. I'm afraid this goes outside the current perimeter of what we are working on. This would be a significant change to UploadWizard, that would require quite some work, and it's just not in our scope for the moment. Sannita (WMF) (talk) 14:28, 23 September 2024 (UTC)

I imagine, though making the template being filed a configuration parameter for campaign wizard shouldn't be that much work? The reminder should be covered by some flexibility in the fields being filled (or optionally available).
 ∞∞ Enhancing999 (talk) 21:44, 23 September 2024 (UTC)

Placement of additional information outside {{Information}}

Some campaigns add information that should be outside {{Information}}, such coordinates at sample image added by Campaign:CHM-DE-SN, but currently there is no option to do that. Can this be added? @Z thomas: FYI.
 ∞∞ Enhancing999 (talk) 09:08, 21 September 2024 (UTC)

 Oppose Please do not add any functionality that enables or makes people add image outside that template. Instead, please at some point develop something that moves content outside into the Information template (e.g. after adding new needed fields). For example, if all the info is in that template that it could be fetched, searched, acted on etc in standardized ways without missing any info. One example is that people put location info outside the Information template and it should be moved into the Information box. Infos on campaigns could also go into a field of the information box if not into the description field. Prototyperspective (talk) 14:23, 21 September 2024 (UTC)

"makes people add image outside that template": What does that even mean?
 ∞∞ Enhancing999 (talk) 16:58, 21 September 2024 (UTC)

Sorry typo: meant info, not image. Prototyperspective (talk) 17:00, 21 September 2024 (UTC)

You might have noticed that {{Location}} has a layout that doesn't fit into {{Information}} and most current uses are outside {{Information}}. So the suggestion might be theoretically appealing, but isn't workable at Commons.
 ∞∞ Enhancing999 (talk) 17:27, 21 September 2024 (UTC)

Well if it's not included in the Information template but another standardized template then it's not a problem. Good point. So my objection is revised to that the only info added outside the Information template should be standardized expectable template like {{Location}} which has the same benefits as just described. For example, the display of the info on it could be displayed in certain ways in the mobile app or data from selected well-known template fields be shown in some external UI. Prototyperspective (talk) 17:42, 21 September 2024 (UTC)

I think this is can be guaranteed by making a guideline for admins and campaign editors. A technical measure to enforce this is not needed. GPSLeo (talk) 18:39, 21 September 2024 (UTC)

While I would support technical measure that e.g. move content into standardized templates, that is not what this discussion is about – this discussion is about Upload Wizard capability to add info outside the Information template and I'm just opposing that something like that is added (revised to any content that is not an established template like a campaign template). Prototyperspective (talk) 19:17, 21 September 2024 (UTC)

I usually just slap {{Location}} in the "description" (see File:Securité Gun Club from Sammamish River Trail 02.jpg and no one has ever complained. I don't use the Upload Wizard, I use Special:Upload). It can also be added with "other fields" parameter, e.g. other_fields= {{InFi|Location|{{location|47.757903|-122.178217|prec=40}}}}, which gives it row of its own in the table produced by {{Information}}. The Upload Wizard could do that systematically when camera location is available. - Jmabel ! talk 19:38, 22 September 2024 (UTC)

More infos to fill in {{Information}}

Often I want to put the content of the Exif-Field ImageDescription into the description= field. And it would be useful if I could pre-define a content of the "permission=" field (see File:20050227S08 770.jpg as an example) Gürbetaler (talk) 20:35, 22 September 2024 (UTC)

Hi @Gürbetaler, thanks for your feedback. I have a question: which kind of info from Exif you usually want to import in Description? I'm not sure I got it right. Sannita (WMF) (talk) 14:32, 23 September 2024 (UTC)

From Exif I would like to import, apart form the date, which is already possible, also the Exif-Field "ImageDescription" and put this content as description=. Gürbetaler (talk) 21:12, 23 September 2024 (UTC)

In ExifTool I have to use the name "ImageDescription". In WikiCommons this field appears as "ImageTitle", in German as "Bildtitel". Gürbetaler (talk) 21:17, 23 September 2024 (UTC)

@Gürbetaler Ok, can I ask you to file a ticket on Phabricator and then link it back to me, so that I can put it on the devs' desk? Thanks! Sannita (WMF) (talk) 13:55, 26 September 2024 (UTC)

I will do so, as soon as I find the place to do it. The Wiki search doesn't bring me a useful result for "Phabricator ticket". Gürbetaler (talk) 16:00, 26 September 2024 (UTC)

Found it. -- Gürbetaler (talk) 11:15, 27 September 2024 (UTC)

Thanks! I added the relevant tag, so that now the team can evaluate it. Sannita (WMF) (talk) 15:56, 27 September 2024 (UTC)

Tracked in Phabricator
Task T375864

@Sdkb, GPSLeo, Jmabel, Prototyperspective, and Enhancing999: We've got some more questions for you about this step, can you please clarify this?

1. If users say they don't know if it is free to share in USA or not, should we tell users to not upload or just flag it (if the latter, how)?
2. If users say they don't know which license this is released under, but it is indicated that it was released under a free license, should we tell them to not upload or just flag it (if the latter, how)?

Thanks in advance! Sannita (WMF) (talk) 14:02, 26 September 2024 (UTC)

I think the first question should not be asked as it is way to complicated for most users to answer. The Wizard should only take care of the copyright status in the country of origin. This results in some deletions but always with a undeletion date within a reasonable time. In the second case the users should not be able to upload the file and only get a link to the licensing page and to the help desk. When we have the growth tool adapted for Commons there could also be a link to ask the mentor. GPSLeo (talk) 14:40, 26 September 2024 (UTC)

I basically agree with GPSLeo here. U.S. vs elsewhere is usually only a question when the rationale is 'PD', not license (license should be OK anywhere). PD in the U.S. is hard to work out. If you want to ask anything, it is year of first publication, and even then let them say, "don't know." If it is more than 95 years ago we are good for {{PD-US-expired}}. Otherwise probably just mark it with a (new) maintenance category. If you want to do anything more, explain that legally speaking we are based in the U.S., and that someone will need to check the upload to make sure it is OK in the U.S. One step further (I don't recommend this, but would not object) would be to remark that U.S. copyright law is "very complicated," with that last phrase linking to the Hirtle chart. Jmabel ! talk 11:41, 27 September 2024 (UTC)

On question 2, flag it with a (new) maintenance category. Jmabel ! talk 11:24, 27 September 2024 (UTC)

I struggle to think of a circumstance in which someone would legitimately know that a piece of media was released under a free license but not be able to figure out which license if asked to check. I suspect that 90% of the uploads in this category will be instances of "I don't actually know if this image I found on the web is freely licensed but I want to upload it so I'll check whatever box will let me do that". As such I'd lean toward not letting them upload it. Of course, if we're sufficiently nimble, we could run an experiment to see whether my 90% guess is at all accurate, and then make a call based on that data. Sdkb ^talk 14:24, 27 September 2024 (UTC)

I agree with @Sdkb. You can only know, if a work is under a free license, if you know the rationale (which means the license, or in case of PD, why it is in the PD). Otherwise it is an uninformed guess. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:23, 28 September 2024 (UTC)

@GPSLeo @Jmabel @Sdkb @C.Suthorn Thanks for your feedback, we're working on it and we will try to include it as much as possible in the new improvements. We'll keep you updated about it. Sannita (WMF) (talk) 08:42, 7 October 2024 (UTC)

Crashes

Tracked in Phabricator
Task T375778

I use FF the newest version and Windows 10. I repeatedly experienced crashes of the upload wizard. Fire Fox freezes and after several minutes it resets to square one. I happens unsually at the end of the upload process, just before you enter the metadata. Sometimes after you submit the metadata. You need to go back to square one. It is not all the time, but often enough to be really bothered. It seems to be more frequently in the last couple of days, maybe one out of 4 upload attempts and more often with a longer file list (50+). Is it just me? Giftzwerg 88 (talk) 19:35, 23 September 2024 (UTC)

Hi @Giftzwerg 88, can you please file a bug on Phabricator and please put me in the list of subscribers? Or to link it here? I'll try to put it on the devs' desk as soon as possible. Sannita (WMF) (talk) 13:56, 26 September 2024 (UTC)

I never filed a bug on Phabricator, sorry. It is just not what I do.--Giftzwerg 88 (talk) 14:47, 26 September 2024 (UTC)

Never mind, I'll file one for you and then link it back here. I'll keep you posted about it. Sannita (WMF) (talk) 15:35, 26 September 2024 (UTC)

Thank you for taking care.--Giftzwerg 88 (talk) 22:50, 26 September 2024 (UTC)

Checkbox has no effect to other fields

There's is a checkbox description same like media description (sorry I don't know the correct English names of the fields)

If I activate the checkbox and use copy all information to the following files (cats, name, description etc) everything is copied except the information of the checkbox and so no information in the description field.

I realized the problem after uploading a lot of pictures with no description. :-)

It's useful to copy the checkbox information too. Z ^thomas 10:31, 27 September 2024 (UTC)

@Z thomas: You are welcome to use the names of the fields in other languages, like my guess of German.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:51, 27 September 2024 (UTC)

@Jeff G. thanks :-)

I add the information to the field "Beschriftung" and via checkbox I decide if the value is copied to "Beschreibung"

If I start the classic campaign all checkboxes are activated. If I copy and then recheck all checkboxes, it isn't possible to check all checkboxes via c&p

The problem occurs by wlm campaigns like Campaign:wlm-de-sn Z ^thomas 12:31, 27 September 2024 (UTC)

Hmm... I fixed it in the wlm-campaign. There was a space as default in the description. It was there from ancient times to prevent the box from collapsing :-)

It this case the new feature helps to improve the campaign

So in my opinion the problem I described with copying and unchecking is a minor problem :-) greetings Z ^thomas 13:22, 27 September 2024 (UTC)

@Z thomas Thanks for intervening so quickly! Sannita (WMF) (talk) 15:57, 27 September 2024 (UTC)

Text isn't shown correctly

Tracked in Phabricator
Task T366602

I don't know if the problem only existes in the german language version because it seems to be related to the formal and informal way you talk in German

If you want do upload more than one picture and you open the Copy-section at the end of the first picture you got a text with hashtags and brackets.

the "copy-section" has the german caption "Informationen in die anderen hochzuladenden Dateien kopieren".

the shown text is "{{#FORMAL|Wähle|Wählen Sie}} die Informationen aus, die {{#FORMAL|du in die anderen hochzuladenden Dateien kopieren möchtest|Sie in die anderen hochzuladenden Dateien kopieren möchten}}:" Z ^thomas 10:44, 30 September 2024 (UTC)

@Z thomas Thanks for reporting this. I think, but I might be wrong, it's a problem with Translatewiki. It should be fixed there, by removing the "formal" tag, and importing the formal version of German inside the de-formal version. I would love to do it, but I don't speak German at all, and I'm afraid I would mistake the formal version for the normal version and viceversa. Sannita (WMF) (talk) 17:59, 30 September 2024 (UTC)

@Sannita (WMF) Thanks for the answer. Do you know anybody who can do this?

@GPSLeo can you do it? Greetings Z ^thomas 18:11, 30 September 2024 (UTC)

I just removed the #FORMAL formatting from the translation. But I did not find any documentation on the usage of this #FORMAL @Raymond who created the translation. GPSLeo (talk) 18:54, 30 September 2024 (UTC)

@GPSLeo @Z thomas I have created MediaWiki:Mwe-upwiz-copy-metadata-subtitle/de to avoid the error locally. More details later when I am back online. Raymond (talk) 18:59, 30 September 2024 (UTC)

@GPSLeo @Z thomas: #FORMAL was introduced ~ 6-8 months ago to simplify translations for "Du"-and "Sie"-Anrede. I used it several times in translations, but I did not know at these moment, that #FORMAl does not work in messages used by Javascript. See task linked now. Raymond (talk) 20:55, 30 September 2024 (UTC)

Default text in description field

Tracked in Phabricator
Task T376476

@Sannita (WMF), I'm still not fully on board with the direction you've gone with the caption/description fields in the new upload wizard, but since it's the direction you're going, one suggestion:

When I fill out the caption field and then uncheck the "same as caption" box, the description field appears and is initially blank. Since the description will generally be an expanded version of the caption, the first thing I do is almost always to copy and paste what I had put in the caption field into the description field. It would be more convenient if, when I uncheck the "same as caption" box, the starting text in the description field was what I had put into the caption field. This behavior would also help make it clearer to users that, if they leave the "same as caption" box checked, the two fields will indeed be the same.

Cheers, Sdkb ^talk 20:29, 3 October 2024 (UTC)

Hi @Sdkb, thanks for the suggestion. Would it be a problem if you file a "requested feature" ticket on Phabricator about it, and then link it back to me? If you have problems, I can do that for you. As soon as we're ready, I'll relay it to the team (even though, being a new feature request, it's probably going to take some time to be evaluated). Let me know! Sannita (WMF) (talk) 08:30, 4 October 2024 (UTC)

Done! Sdkb ^talk 14:22, 4 October 2024 (UTC)

@Sdkb Thanks, I already flagged it to the team. Hopefully I will let you know soon. Sannita (WMF) (talk) 17:05, 4 October 2024 (UTC)

Automated population of metadata for derivative images

When uploading a new image, if the user selects "This is someone else's work and is free to share.", it would be great if one of the resulting options was "this is a derivative image of an existing Commons image", with a field to enter the relevant file name. The Wizard should then populate the upload form with data from the source image, then allow the user to modify it before submitting. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 13 October 2024 (UTC)

That would be useful and imo even better would be a button to "creative derivative". Either or both should also set the {{Extracted to}} or e.g. {{Other version}} template at the source file which is currently missing in a roughly estimated half of files that have derivatives or other versions. Prototyperspective (talk) 10:42, 14 October 2024 (UTC)

Yeah, this would be awesome (see also COM:VP#Best way to upload a derived image?). Not only would a tool like this save me time, but it would save other people time. I generally do just enough to make the upload wizard happy (perhaps not ideal, but that's life) and I often see somebody else come along and fix up my descriptions, add the right templates, etc. It's great that they do that, but if that could all be automated, so much the better. RoySmith (talk) 13:06, 14 October 2024 (UTC)

By the way, the right pairings of templates are {{Image extracted}}/{{Extracted from}}, {{Derivative versions}}/{{Derived from}}, and {{Derivative versions}}/{{Retouched}}. There might be some other pairing I am not thinking of. There is also {{Extracted from deleted}}. - Jmabel ! talk 04:49, 15 October 2024 (UTC)

Other versions

Would be good to add better support for specifying other versions, e.g. if the user uploads multiple versions of a file and would like to link to each other. Currently, the |other_versions can't even be filled at all with the UW – ideally this wouldn't only be enabled but one could also do something like do a multiselect for a file to select other versions from the files one has uploaded at the same time (maybe also already existing files). It should make use of <gallery>. Example. Prototyperspective (talk) 12:51, 14 November 2024 (UTC)

CropTool currently provides decent support for this, but there is a fundamental problem in that, currently, every crop is treated like a fork and thereby increases the maintenance burden. Fixing this is something I'd classify as high-effort but high reward. Sdkb ^talk 15:22, 14 November 2024 (UTC)

It does not allow users to specify other versions in the UploadWizard, does it? Prototyperspective (talk) 16:20, 14 November 2024 (UTC)

Not in the Upload Wizard, no, as CropTool doesn't run through the Upload Wizard. I haven't ever needed to specify another version when I'm using the Upload Wizard — what sort of workflow do you have (or, more significantly, might a new user have) that creates that need? Sdkb ^talk 21:27, 14 November 2024 (UTC)

See e.g. if the user uploads multiple versions of a file and would like to link to each other and Example (other example). Not "new" user, any user. Prototyperspective (talk) 21:32, 14 November 2024 (UTC)

In this case I'd say that the best solution would be by creating more "add-on's" for users using the MediaWiki Upload Wizard rather than include these options by default. There are already an incredible number of clicks and options added the make the MWUW difficult to understand for new users, as an experiment, I showed a friend the MediaWiki Upload Wizard a few days ago and asked him what he thought a step meant, this is someone who has never made any edit on any Wikimedia website in his life and it was just a topic of conversation, most options that look "common sense" to us only made "Commons sense" to him, in other words, they were confusing because he didn't really understand the Wikimedia Commons, and this guy is a math PhD. So, what would a new user think "Other versions" might mean? Well, they could mistake it for meaning a related file (something MediaWiki categories Wikidata depicts function for). It's no different than new users not knowing how to properly overwrite files.

Now, if the MediaWiki Upload Wizard was customisable to the point where users who commonly upload alternative versions could add this option it would be preferable, as having to include this might confuse people and the amount of text needed to explain them would annoy experienced users. I genuinely believe that the Wikimedia Foundation (WMF) should work on adding more optional tools for power users, there should be no user right or minimum uploads associated with enabling these options, simply the knowledge that they exist and where to find them, preferably in user settings but advertised somewhere in the MediaWiki Upload Wizard itself. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 04:50, 2 December 2024 (UTC)

It could be a preference. Better than that would be showing it as a field in the Additional information field that is collapsed by default which new users would not uncollapse or even notice. Prototyperspective (talk) 15:18, 2 December 2024 (UTC)

Import video by URL

A couple of months ago I found a Chinese film from the 1920's that was in the public domain, I wanted to upload it to the Wikimedia Commons but the website I use to download videos from Google's YouTube service didn't work on a mobile device, the Video2Commons service couldn't import it because it has had issues with Google's YouTube service for a while now. I waited and waited and now the channel that uploaded it and countless of other extremely old films got deleted. The main issue with the above story is simply that it's not easy to import videos to the Wikimedia Commons, this is something that the Wikimedia Commons has struggled with since its inception.

I propose that there should be an "Import from URL" option that works akin to the Flickr import options for Autopatrolled users now. Works uploaded through this method should have a template where they new to be reviewed and verified by a license reviewer. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 04:58, 2 December 2024 (UTC)

Simply run yt-dlp url from the console or the command here. Integrating video2commons and improving it like at least making it importing subtitles would be great. Prototyperspective (talk) 15:15, 2 December 2024 (UTC)

Minor changes coming to UploadWizard

Hi all! This week we will release some minor improvements to UploadWizard, mostly concerning the “not own work” option in the “release right” step.

More specifically, we will:

• improve slightly information about CC licenses (phab:T375494)
• add a “I don’t know” option (phab:T375790)
• fix the style of the warnings (phab:T374165)
• remove the question about “personal use” for auto-confirmed users (phab:T370104)
• remove the checkbox about media not including copyrighted material (phab:T370105)

We will also do some more revision of the texts of the “own” and “not own work” section, to give more information to the user about the options they are choosing (phab:T370103), and to match the new “describe” step style (phab:T361055). Plus, we are improving the options to choose a custom license/PD-tag (phab:T371050), and fixing some minor bugs (phab:T373567, phab:T373568 and phab:T380922).

If you have questions, suggestions or comments, please feel free to reply here. Thanks in advance! Sannita (WMF) (talk) 11:38, 4 December 2024 (UTC)

@Sannita (WMF), regarding phab:T370105 ("Remove the copyright confirmation checkbox from the not-own work flow"), it states, This will be covered by new machine detection flow. I'm very intrigued to hear that, if I understand correctly, you are planning to use machine detection to identify when someone is trying to upload an image already on the web. But this needs to be handled very carefully, and we should absolutely not be removing the current safeguards until it's ready to roll out. Can you explain more what's happening here?

phab:T375790 ("Add 'I don't know' option to a list of licenses in not-own-work flow" is related to the questions you were asking us above here (I wish this conversation were linked from the Phab task). We indicated a preference that, when someone indicates they don't know the license, they not be allowed to upload the work. Have you adopted that?

phab:T375494 ("Improve the copyright question in the not-own-work") appears directly adjacent to the changes I requested in phab:T376522 ("Add PD-textlogo to list of default reasons an image might be in the public domain in the Upload Wizard"), which makes it disappointing you have not taken up the latter. Can you provide a status update there?

phab:T370104 ("Hide 'this is for my personal use' question for auto-confirmed users") seems reasonable and should resolve some complaints. Sdkb ^talk 20:21, 4 December 2024 (UTC)

Hi @Sdkb, thanks for your questions.

Regarding phab:T370105, the ticket reports outdated information in fact: what we're doing is adding structured data to the media to notice it is possibly copyvio.

Regarding phab:T375790, we decided not to go immediately for stopping them from uploading the media, because we thought there is a non-zero possibility that people will just choose a random option and upload anyway if we do it; anyway, I raised the point with the team and created phab:T381575, to which you’re already subscribed.

Regarding phab:T376522, no progress so far, but it’s unlikely that that option will be added to the prompt, because the team is worried about making available too many options and confusing uploaders; there is still the custom license field to add that one.

Hope this helps. Sannita (WMF) (talk) 14:07, 5 December 2024 (UTC)

@Sannita (WMF), regarding phab:T370105, that work sounds promising. But it doesn't seem like it's been deployed yet, and I'm concerned about removing the current safeguards before it has been rolled out and shown to work. What is the ordering?

For phab:T375790, so long as the "I don't know" responses produce a warning for the uploader and a tag for moderators, that should be something we can work with.

For phab:T376522, which licenses the Commons Upload Wizard should suggest is a question that should be under the control of the Commons community. I will plan to run an RfC on that matter and will expect you all to abide by the community's consensus. Sdkb ^talk 21:31, 5 December 2024 (UTC)

Soliciting uploads

I have recently noticed a new 30-pixel square icon File:Camera-photo Upload.svg (displayed on the right or visible here) on each and every category, that solicits Upload Wizard uploads for that category with a German-language tooltip, even if the category bears {{Global maintenance category}} or is hidden (indicating that it does not need uploads). This icon, and the surrounding whitespace all the way to the right edge (including a perverse amount of whitespace below), take valuable screen real estate from our screens. How may we stop it from displaying or hide it, on global maintenance categories, hidden categories, or both?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:53, 8 December 2024 (UTC)

@Jeff G.: I don't see that at all, I wonder what is different in our configurations. Can someone say under what circumstances this is displayed? - Jmabel ! talk 18:48, 8 December 2024 (UTC)

@Jmabel: It took me a while to find, but it's in User:Herzi_Pinki/GeoTools.js. I'm not using that any more. Sorry for blaming WMF.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:34, 9 December 2024 (UTC)