Commons talk:WMF support for Commons/Upload Wizard Improvements

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

The 50 files limitation

[edit]
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)[reply]

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

The wrong orientation bug

[edit]
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)[reply]

I agree, I fall into this trap myself. Ziko van Dijk (talk) 20:22, 13 October 2023 (UTC)[reply]
Hey @Giftzwerg 88: , thanks for raising this issue too. I’ve opened another Phab ticket about it, and the team will take a look at it in one of the next meetings. I’ll keep you posted on this, but also in this case you can subscribe to the ticket and be aware of what’s going on there. Also, feel free to edit the ticket if I made some mistakes. Thanks again! --Sannita (WMF) (talk) 10:49, 20 October 2023 (UTC)[reply]
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)[reply]
Thank you for the update.--Giftzwerg 88 (talk) 10:36, 14 May 2024 (UTC)[reply]
Thank you, @Sannita (WMF). -- Ooligan (talk) 15:33, 14 May 2024 (UTC)[reply]

Two extra clicks again

[edit]
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)[reply]

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)[reply]
It is discussed in detail above on this page, and my comments are also there. Ymblanter (talk) 20:38, 14 December 2023 (UTC)[reply]
@Ymblanter Do you mind helping me translating your request into a Phabricator ticket? I guess we can work at making the two extra clicks pre-defined in the users' preferences, or at least I can ask the team if this would be feasible. Sannita (WMF) (talk) 14:54, 18 December 2023 (UTC)[reply]
Yes, sure. User preferences would indeed solve the problem. Ymblanter (talk) 14:59, 18 December 2023 (UTC)[reply]
For experienced users who happen to know how to tweak user preferences. There are some people who have edited here for years and don't know things that seem "basic" to others, like a WikiGraphist that has been here 17 (seventeen) years, but didn't know how they could change their signature in user preferences. While many "power users" could circumvent the 2 (two) extra clicks, this would still be a hassle for the vast majority of users who don't know about this. It might be best to link to user preferences somewhere directly inside of the MediaWiki Upload Wizard then. Especially since the vast majority of people who would become regular volunteer uploaders here might not like to constantly confirm that the image of an archeological museum exhibition isn't a selfie 🤳🏻. Ease of use should be accessible to everyone, not just the more experienced users who happen to know where and how to tweak things. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:06, 18 December 2023 (UTC)[reply]

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

Great, thanks a lot. Ymblanter (talk) 17:13, 18 December 2023 (UTC)[reply]
Another similar issue for which I don't think creating a new section would be due:
  • Copy information… default selection: Would it be possible to somehow store the recently used checked boxes under Copy information to all uploads following … or to specify a default?
    • I sometimes upload images from multiple CCBY scientific studies in a row and then always need to change the default selection to Copy caption, date, categories and nothing else. Until there is some kind of Study2Commons tool where you just enter a URL to e.g. a paper on nature.com and it prefills all the title and description etc fields that you then only edit as needed.
Also I'd like to briefly express support for Ease of use should be accessible to everyone, not just the more experienced users who happen to know where and how to tweak things – this often gets overlooked where things are considered 'solved' if somewhere there is an unknown barely used external script/nondefault gadget for it. Prototyperspective (talk) 15:39, 28 December 2023 (UTC)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]

V2C should integrated into MW

[edit]

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

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

[edit]
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)[reply]

I would support assuming it does not take much resources. Ymblanter (talk) 20:11, 17 January 2024 (UTC)[reply]
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)[reply]
Thank you, I will add it :) --PantheraLeo1359531 😺 (talk) 15:35, 18 January 2024 (UTC)[reply]
✓ Done Task added --PantheraLeo1359531 😺 (talk) 15:43, 18 January 2024 (UTC)[reply]
Fantastic, thanks! Sannita (WMF) (talk) 20:09, 18 January 2024 (UTC)[reply]
[edit]
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)[reply]

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)[reply]

Asking for prompt in AI-generated works

[edit]
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)[reply]

Hey @Sdkb, thanks for the ping. I'll pass it on to the team, and we'll evaluate the request next week. I'll keep you posted on this, but feel free to ping me again if I disappear. Sannita (WMF) (talk) 09:35, 16 February 2024 (UTC)[reply]
Hey @Sdkb, I have some updates on that. For the time being this request has been put on hold, since it is not entirely within scope of this year's work. I will keep an eye on it and see if in the next months this could be fixed. Sorry for the bad news. Sannita (WMF) (talk) 09:23, 23 February 2024 (UTC)[reply]
@Sannita (WMF), I appreciate the update, but I'm not quite sure what you mean by not entirely within scope. You are in the middle of the "Upload Wizard Improvements" project currently, yes? And as part of that you introduced the "I generated this work using an AI tool" option within the wizard, yes? And this task is directly related to that option, yes? I would have hoped that, when you budgeted time for the upload wizard improvements, you anticipated that there would be community feedback like this and built in some time to address such feedback. Sdkb talk 23:53, 25 February 2024 (UTC)[reply]
@Sdkb AI tool was introduced as an option, yes, but we don't have budgeted time this year to improve on this specific item of UW, since we are working also on other aspects of it. It is though on our watchlist, so I hope in some months the decision will be reviewed. Sannita (WMF) (talk) 17:24, 26 February 2024 (UTC)[reply]
I take your word about your team's resource constraints, and acknowledge that the Prompt template was introduced only more recently. But the ask to document prompts has been stated at Commons:AI-generated_media#Description over a year now, it says (in its current wording):

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

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

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

In fact, these budget constraints seem to be an argument for better, more informed planning in such matters, as it may be more costly to come back later and fix such omissions.
Regards, HaeB (talk) 22:12, 10 March 2024 (UTC)[reply]
@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)[reply]
@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)[reply]
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)[reply]

Adaptable release rights steps

[edit]
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)[reply]

@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)[reply]

Uploading files from Flickr with PDM

[edit]
Tracked in Phabricator
Task T363493

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

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)[reply]

@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)[reply]
@Sannita (WMF) Reported as T363493. Hope I did it okay. --MGA73 (talk) 16:05, 25 April 2024 (UTC)[reply]
@MGA73 It looks good, thanks! Sannita (WMF) (talk) 17:45, 25 April 2024 (UTC)[reply]
@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)[reply]
@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)[reply]

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)[reply]

Hello @Jmabel, if a "bug" to which you referred is a software bug, then this appears to be one.
From the Wikipedia entry, "A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways."
The Upload Wizard tool is certainly producing "errors" (changing to a different Creative Commons license than the license used at the file's source webpage) and its actions "produce an incorrect or unexpected result, or to behave in unintended ways."
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)[reply]
@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)[reply]
@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)[reply]
@Jmabel Humans should chose the license and that is why the uploader should add it. If user on Flickr uses {{Cc-by-sa-2.0}} it does not specify why it is cc. We just assume that the Flickr user is the photographer. Its the same here. We assume that the Flickr user is the photographer and chose {{PD-author-FlickrPDM}} unless we have reason to think its not own photo. For example if it is a photo or a painting from 1905 for example the license should be PD tag to tell copyright expired. I see no reason why the uploader should not have the option to chose the correct license during upload. If needed we could have the option that if uploader does not specify a license then the Upload Wizard picks cc-zero. --MGA73 (talk) 20:08, 26 April 2024 (UTC)[reply]
If the Flickr user put a PDM mark on their own photo, that probably signals the intent to put their file in the public domain, but it also suggests someone who does not understand copyright well. That is certainly not the intent of the PDM mark on Flickr: if that is your intent, you should use CC-0.
We absolutely should not put CC-0 on a photo where the rights-holder did not specifically grant it. {{PD-user}} would be much more on the mark, except that it is only for our own users. We probably should have an analogous {{PD-Commons-user}}. The problem with CC-0 is that it has a specific waiver and public license fallback that are in no way implied by PDM. - Jmabel ! talk 05:06, 27 April 2024 (UTC)[reply]
I think whoever made the upload wizard this way thought that CC-0 is a temporary template to use while someone (uploader) picks the right license. It would perhaps be better to create a "PDM-needs-check" to add on files where uploader does not pick another license (as a better temporary template than CC-0). If uploader pick a specific license I think the Flickrreview bot can pass them. If I upload a photo from the internet and claim PD-USGov for example there will in most cases be no review by someone else. So it's not a big problem if Flickrbot confirm that the file was uploaded as PDM. If anyone thinks the license is wrong they can add the correct license or nominate the file for deletion. --MGA73 (talk) 17:50, 6 May 2024 (UTC)[reply]

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

[edit]
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)[reply]

@Wilfredor: thanks for your message. As I said, I'll try to get both tickets on the devs' table as soon as possible, but I also asked you for clarifications on the second ticket. You can answer in Phabricator, so that I can update the ticket. Sannita (WMF) (talk) 16:42, 2 May 2024 (UTC)[reply]
When you upload an image to a platform, you typically follow a procedure where you first upload the image and then, only after it has been uploaded, you can add descriptions, tags, or other metadata. This can be inefficient if you have multiple images to manage, as you have to wait for each image (and all images) to upload before entering its information.
A better approach could be to allow users to input all relevant data for each image (like title, description, tags) at the same time they select the image for upload. This data would then be processed together with the image upload, streamlining the workflow and saving time, especially when handling multiple files. This method would eliminate the need to wait for each image to upload before entering information, making the entire process more efficient. Wilfredor (talk) 16:52, 2 May 2024 (UTC)[reply]
@Wilfredor: 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)[reply]
to upload a new version of the same file you need use the Special:Upload Wilfredor (talk) 18:46, 2 May 2024 (UTC)[reply]
The 100 MiB upload overwrite limit can be bypassed with User:Rillke/bigChunkedUpload.js --PantheraLeo1359531 😺 (talk) 15:46, 15 May 2024 (UTC)[reply]
@Wilfredor @Sannita (WMF) To clear this up: revision upload is not handled by the wizard. Files larger than 100MB can only be uploaded with chunked upload. There are some tools that handle chunked upload. If you do not want to use such a tool, you will need to click on the link to the right of "upload a new version" (which is limited to 100MB, as it is not chunked), that is called "chunked upload" and starts the bigchunkeduipload tool by Rillke and mentioned by @PantheraLeo1359531. Also, if you use this tool for uploads you need to enter all the information BEFORE you select the file to upload but this does actually not matter, as for revision uploads this information is disregarded anyway and only the upload comment is actually used. On the bright side: Rillke's tool is very stable (only Offroader is more resilient). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 16:26, 15 May 2024 (UTC)[reply]
Understood, correct :) --PantheraLeo1359531 😺 (talk) 16:28, 15 May 2024 (UTC)[reply]
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)[reply]

One more extra click

[edit]

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

Hi @Ymblanter, I'm really sorry to hear this. I'm trying my best to obtain from the devs the possibility of reducing the extra clicks for experienced users, but there is also a discussion ongoing about preference bloating that we're considering. I'll pass on your feedback anyway, and try to make the case for reducing the burden on experienced users once again. Sannita (WMF) (talk) 08:40, 16 May 2024 (UTC)[reply]
Thank you but for the time being I am back to the old form. I will probably still use the wizard for uploading several similar times 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)[reply]
+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)[reply]
+1 about the extra clicks. -- Ooligan (talk) 14:59, 17 July 2024 (UTC)[reply]

Vorbelegung

[edit]

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.

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
The prefilling tool should contain more prefilling fields like another descriptions in different languages --PantheraLeo1359531 😺 (talk) 19:05, 22 May 2024 (UTC)[reply]

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

[edit]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
@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)[reply]

Use captions for descriptions: Why only in English?

[edit]
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)[reply]

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)[reply]
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)[reply]
@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)[reply]
My apologies for being unclear in my first question, Sannita (WMF), and thank you. Julle (talk) 13:54, 31 July 2024 (UTC)[reply]
@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)[reply]
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)[reply]

Markup in caption field

[edit]

@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)[reply]

@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)[reply]
I would describe it as "plainer".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:06, 26 August 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
Descriptions are also licensed differently than captions.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:38, 1 September 2024 (UTC)[reply]

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

[edit]

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)[reply]

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)[reply]
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)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements&oldid=926508701"