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

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

Another confusing message

Now, I understand why the Wikimedia Foundation (WMF) tries to add these additional clicks to the MediaWiki Upload Wizard, but as I demonstrated before, many of these just contain either factually incorrect or just confusing information, here is another one:

  • Please confirm the following statement before proceeding.
    • I confirm that this work does not include material restricted by copyright, such as logos, posters, album covers, etc.

Well, if you came this far in the upload process you 1. (One) already included a free license, and 2. (Two) already provided a source and authorship. But now imagine you're a new user to the Wikimedia Commons and you see logos on Wikipedia, you see that one has a free license and emulate it. Then suddenly you see this box that explicitly tells you not to upload any logos, images like this are not out of scope, but the current wording makes it sound like these images should not be uploaded here.

Again, I'm getting the impression here that these changes were made to lessen the "burden" of admins and patrollers and not to actually make it easier or better for the uploaders themselves. Especially since the wording doesn't seem to be based on any existing policy or guideline and is completely redundant to the rest of the fields in the decision tree.

But still, the wording is "I confirm that this work does not include material restricted by copyright"... Isn't this redundant? The process literally starts with "You can upload someone else's work as long as it is published under a free license or its copyright has expired." and then immediately asks for a license, so what use does this extra box have other than to irritate uploaders? A free logo is a free logo, a copyrighted logo is a copyrighted logo, the status of the word is already established in the very first (1st) step of the process. So what use does this extra click have?

Note: I wanted to post this earlier, but a software issue is making this website very mobile-unfriendly for me so I refrained from engaging in many discussions for some time. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:47, 7 January 2024 (UTC)

I would suggest that this particular question makes sense (at least as a reminder) when people claim to be licensing their "own work" with a CC license, but it's probably not useful when someone has asserted that they are uploading something under a particular PD rationale. I'm guessing that we get far fewre bogus claims of PD than of "own work" for non-trivial logos, posters, album covers, etc. (though I don't have statistics to back that). - Jmabel ! talk 00:28, 8 January 2024 (UTC)

Novice Upload Wizard

I wanted to propose this last year, but I didn't have the time yet to work out the idea. I still haven't completely worked it out but here is the general outline... What if "we" create a "Novice Upload Wizard" separate from the standard MediaWiki Upload Wizard where (relatively) new and inexperienced users get a much more detailed and helpful version of the MediaWiki Upload Wizard which takes way more steps to complete and kind of acts like a tutorial.

This would make sure that more experienced uploaders don't get constantly forced to have to click on messages intended for novice users and by making this for new users this will also help familiarise them more with how copyright ©️ works, what the rules are, and how to categorise, Etc. The question asking "Is this your own work?" Will lead users into separate 2 (two) tutorials that explain what is and isn't allowed, I think that these tutorials should also explain difficult concepts like de minimis, the threshold of originality, how to know if the copyright ©️ of a work has expired (yet), and what to look out for. The current wording is just too exclusive and doesn't explain the subtleties of copyright ©️ leading to many to believe that a PD-textlogo is still unsuitable to be uploaded here when it is not. Maybe there should also be lists to various Freedom of Panorama (FoP) resources with example images of what is and isn't covered by it (we can simply use free images to demonstrate unfree images), users can select their country as well. This "Novice Upload Wizard" could be called the "Upload Tutorial Tool" (UTT) or the "Commonswiki Tutorial Wizard" (CTW). I think that such a detailed tool can prevent more copyright ©️ violations than a couple of "clickable boxes" ever would.

I could work it out in more details, but I'd first like to hear whether others also agree with this idea or not. I haven't really set "a hard limit" on when users stop seeing it, that could be discussed later, it should be seen long enough to make users familiar with the complexities of global intellectual property laws but brief enough to not make uploading here regularly a tedious experience for new users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:34, 12 February 2024 (UTC)

Here is a broad concept:

  • Is this your own work?
    • Yes.
    • Yes, but I was commissioned.
    • No.

If yes.

  • What country does your work originate from.
    • [Select country].
  • What does this work contain:
    • Buildings (exteriors).
    • Buildings (interiors).
    • Statues, public art, Etc.
    • An object.
    • A person or people.
    • [Could be more options.]

If the user selected "Statues, public art, Etc. " they should be asked if it's permanent or temporary, they should have a message about the country's FoP with examples of what is and isn't allowed. For example, here in the Philippines statues wouldn't be allowed because there is no FoP. If they selected "a person or people" they are told what pictures are and aren't in scope, we can use some random selfies from Wikimedia Foundation (WMF) staff or Jimbo Wales to illustrate out of scope images, we should also direct them to information about personality rights and how those are protected.

Each option should show visual examples of what is and isn't acceptable to upload. We'll just use a statue from a country with freedom of panorama to showcase what isn't acceptable for the Philippines and then underline it with (this photograph was taken in [COUNTRY] where photographers enjoy freedom of panorama).

Each step should include both scope and copyright ©️ information and it should be made clear and simple enough. For countries with a low threshold of originality we simply use logos from countries with a high threshold of originality to showcase what is and isn't allowed.

If we make the initial steps as clear as possible people will be familiar enough with the rules to not make copyright violations in the future. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:15, 12 February 2024 (UTC)

  • Is this your own work?
    • Yes.
    • Yes, but I was commissioned.
    • No.

If no.

  • What country does your work originate from.
    • [Select country].

Now we can explain PMA + 50 (fifty years), PMA + 70 (seventy years), Etc. we ask when it was first (1st) published, for example a Vietnamese work published in 1935 is safe to upload but a Mexican work from the same year (I think) isn't. It should ask if the uploader knows when the creator died if it's published after the date that current works may still be protected.

Here we also explain the country's TOO, DM, Etc. for non-own works. Each and every step should have visual examples, for example, "Juan de la Cruz died in 19XX which is why his works ascended to the public domain in 2011". I think that creating a tutorial will do way more than constantly asking questions which don't even universally apply. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:21, 12 February 2024 (UTC)

@Donald Trung Thank you for your proposal, but there is no plan to create a second UploadWizard for newbies, and I sincerely doubt there would be any consensus on duplicating what we already have. Sannita (WMF) (talk) 15:55, 12 February 2024 (UTC)
Guess I can start a proposal. 🙂 --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:35, 12 February 2024 (UTC)

Comment on goal

Speaking as an admin, the goal to "reduce the number of bad uploads" may not be nearly as important as it would be to be able to tag potentially bad uploads for review. Any effort to prevent bad uploads (other than exact matches to known bad files) is also going to prevent some good uploads, which actually creates tremendous amounts of admin work helping people around the restrictions. - Jmabel ! talk 20:08, 5 February 2024 (UTC)

@Jmabel Thanks, this is really helpful. Maybe we can revisit the goal accordingly? Sannita (WMF) (talk) 11:04, 6 February 2024 (UTC)
@Jmabel Hey, quick update on this. I discussed your feedback with the project's manager, and we agreed that your proposal will probably make its way to our objectives for next fiscal year. Since we're only four and a half months away from the end of the current fiscal year, and that this year's project is almost halfway through, it would have made little sense to change this year's goals, but for the next one will surely be considered. I'll keep you posted about it anyway.
Thank you very much for being a considerate, stable and constructive partner in all of this. Cheers, Sannita (WMF) (talk) 11:40, 16 February 2024 (UTC)

Improvements to the "Describe" step in UploadWizard

Hello everyone! As a next step in improving UploadWizard, we want to focus on the "Describe" part, where our usability findings have identified several criticalities:

  • users involved in the tests had difficulties in understanding the difference between title, caption and description;
  • adding categories to the media was described as challenging;
  • other fields may result confusing and therefore left unused by the users.

We want to try to simplify the page, so that users (especially newcomers whose media is often flagged for deletion) would find it easier to provide the key information moderators need to evaluate the media.

Our questions are the following:

  1. How is the "caption" field being used right now?
  2. Would it be better to move the "caption" field outside of the "core information" part of the form?
  3. How frequently are "location" and "other information" fields used? What "other information" is used for usually?
  4. Is the "date of creation" field used also to evaluate potential problems with Freedom of Panorama and/or copyright of the image?
  5. How correct and useful are the categories added by users while uploading the media? How much work has the community to do to eventually fix them usually?

Thanks in advance for your help! Sannita (WMF) (talk) 14:23, 16 January 2024 (UTC)

Use of captions

How is the "caption" field being used right now?

Good questions! I'll add some quick responses to start us off.

I use it as basically a shorter form of the description field. Basically, the description field should answer any information that anyone might want to know about the photo, whereas the caption field should be what we'd expect the caption to be in a normal use of the photo (meaning no more than a line or two). The caption field becomes the default caption when an image is used on Wikipedia.{{u|Sdkb}} talk 17:32, 16 January 2024 (UTC)

When I explain to students what each field is for, normally I have a problem to explain the difference between title, caption and description. Title and caption many times end being exactly the same text, and sometimes the three are the same. I think that with structured data and the description it should be enough, given that the title of the image is normally very similar to the title... or it should. We may encourage uploaders to be descriptive (caption-like) in the image title, so it can be easily found. Theklan (talk) 18:53, 16 January 2024 (UTC)
I see a lot of new users using the caption field as the only description - which is not really what we want. Kritzolina (talk) 18:57, 16 January 2024 (UTC)
I'm guilty of using the caption as the only description sometimes, when there's not much that I want to say about a file. The thing about UploadWizard however is that it mandates a description and not a caption, so I sometimes just put the same text as both and then go back and remove |description= (letting it be filled by {{Information}} with the caption; since that functionality came along I must admit I thought it was an indication that the caption should be done first, and the description only added if there was more info needed). Sam Wilson 08:58, 17 January 2024 (UTC)
I personally also use it as a short form of the description. I see that sometimes, especially with GLAM uploads, the description is quite extensive, often it contains templates, then a short caption is needed. Ymblanter (talk) 08:23, 17 January 2024 (UTC)
May I remind you all that Commons is a multilingual project?
  • "Title" (the file name) is a field that contains the caption and description in ONE language only (and in most cases it is a dialect of Tibetan language that was mostly spoken between 1446 and 1476 in a small village in the Himalaya).
  • "Caption" is a collection of translations of that "title" into only that languages that got a language code assigned by the MediaWiki software, but you will only see the one language selected by your web browser preference.
  • "Descripton" is a collection of translations in languages that come with a template:de, template:de-at, template:de-li, template:de-lu, template:de-formal or template:de-li-formal template and you will see all translations unless you activate a dropdown box that selects only one language, but of your own choice.
However mostly title, caption and description are all in Tibetan or sometimes in a language named english (who understands that anyway?) but never both. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:20, 17 January 2024 (UTC)
@C.Suthorn: Which file has caption and description in "a dialect of Tibetan language that was mostly spoken between 1446 and 1476 in a small village in the Himalaya"?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:04, 17 January 2024 (UTC)
@Jeff G.: which contributor has a sense of humor? - Jmabel ! talk 19:19, 17 January 2024 (UTC)
@Jmabel: I was humoring C.Suthorn.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:01, 18 January 2024 (UTC)
I use the caption field to describe the file as succicently as possible, the title usually for the title of the work or to incorporate the important info in the caption of the work, and I use description to transcribe the captions that originally accompanied published photos, maps or drawings in newspapers or to copy the caption field if that's what's best. Abzeronow (talk) 19:40, 17 January 2024 (UTC)
I generally use the filename and caption for a succinct description of the subject and its location, and for the filename I will add elements to make sure it's distinct e.g. date and/or a sequence number. For the description I will sometimes use the same as the caption if there isn't much more to say, but will often expand with extra non-crucial info, or more precision about the location e.g. saying just "Morecambe" in the file name but "Morecambe, Lancashire, England" in the description.
(I have to admit to being negligent of captions for a while, they often seemed to make the process even more slow and unreliable when uploading a large number of files, but that problem does appear to have been solved) the wub "?!" 19:51, 17 February 2024 (UTC)

Move the "caption" field?

Would it be better to move the "caption" field outside of the "core information" part of the form?
  • If I had to choose, I'd say that having a comprehensive description is more important than a caption, since a short caption can always be derived from a good long description, but not the other way around. But both are important. {{u|Sdkb}} talk 17:32, 16 January 2024 (UTC)
  • I think that "caption" is repetitive, and information should be encouraged more, with a clear focus on what information means there. Lot of people also add the original files if the image is derivative in the information, but this could be another field if you choose to inform that the file is derivative. Theklan (talk) 18:54, 16 January 2024 (UTC)
  • Here and on the prior question: the description is essential. A caption is nice to have, but not nearly as important. - Jmabel ! talk 22:39, 16 January 2024 (UTC)
  • I would say some explanation what is a description and what is a caption (like popups) would likely help (not to me, but to new-ish users).--Ymblanter (talk) 11:32, 17 January 2024 (UTC)
  • No. Since when did SDC become unimportant? For the purposes of ease of understanding, it might be better to label the wizard's caption field something like "Short description (one sentence)"; and the current description field as "Long description". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 18 January 2024 (UTC)
  • I personally don't see anything wrong with the "File captions" field as they are now. You can add shorter more direct information if the description is long and they better integrate multilingualism than "File descriptions". If things get moved around then we should have an option for an "Old style" MediaWiki Upload Wizard without these unnecessary changes. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:23, 27 January 2024 (UTC)
  • If it's to be kept then I quite like it in the current location, as I'm often copy pasting between filename/caption/description fields. the wub "?!" 19:54, 17 February 2024 (UTC)

Location and other information

How frequently are "location" and "other information" fields used? What "other information" is used for usually?
  • Quite frequently. Often, the description/caption don't include proper location information, so that is then derived from the location field. It's also potentially useful for categorization (e.g. there's this landmark at these coordinates, so let's see if we have any photos from those coordinates). And all metadata is very useful for identifying copyright violations, since it tends to be scrubbed from images just downloaded from the web. {{u|Sdkb}} talk 17:32, 16 January 2024 (UTC)
    Oh, I thought we were talking about location information in the file metadata. The location field in the description is generally derived from that. It's still often useful, though. {{u|Sdkb}} talk 19:02, 16 January 2024 (UTC)
  • Other information is also often used by experienced users to put templates like the personality rights warning there. --Kritzolina (talk) 18:54, 16 January 2024 (UTC)
  • I barely use them when uploading. The coordinates can be filled automatically from the image, or suggest a procedure where you pin the image in a map when uploading. I normally add the "other information" suggested here in the description itself. -Theklan (talk) 18:59, 16 January 2024 (UTC)
  • Location, however it is derived, is very useful when other info is short-changed. It gives someone else a fighting chance of working out what is going on. - Jmabel ! talk 22:39, 16 January 2024 (UTC)
  • I often use "other information" when I'm uploading a scan of a photograph and I've got files for the front, back, and some cropped/tweaked versions as well. These aren't quite "other versions" but it's still useful to have them all listed on each file (although come to think of it, if "other versions" was editable in UploadWizard it could probably be used instead). Sam Wilson 23:44, 16 January 2024 (UTC)
  • I always use location if it make sense (obviously not when uploading artwork etc), it can not be derived from the metadata of my files. However I am not sure everybody knows that location is the camera location, not the object location (and the object location would be problematic if there are many objects on the picture). I do not think I ever in my life used "other information", and I have several dozen thousands of uploads.--Ymblanter (talk) 20:14, 17 January 2024 (UTC)
  • These are often automatically filled in from metadata and I would advise against removing them, it's better to have too many options that some individuals use than to remove them because a few found them slightly inconvenient. Unlike the extra clicks that were added you can ignore these fields and still upload if a file doesn't have a geographic location, as most uploads tend to be photographs it's wise to keep this field. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:25, 27 January 2024 (UTC)
  • Including locations is very helpful metadata for a lot of photos. I don't often use the uploadwizard field to set location manually, but it's a helpful reminder if I forgot to include the location in my files' metadata (or vice versa, if there's location metadata when there doesn't need to be). Not sure I've ever used "Other information" personally, but I expect others might have good use cases for it. the wub "?!" 19:59, 17 February 2024 (UTC)

Date of creation

Is the "date of creation" field used also to evaluate potential problems with Freedom of Panorama and/or copyright of the image?
  • Yes. {{u|Sdkb}} talk 17:32, 16 January 2024 (UTC)
  • There is an enormous problem that people often give the date of the upload, or the date they scanned or photographed a much older 2-dimensional work, where their derivative work would have no copyright of its own. If we are in a scenario where we know already that we are dealing with a scan (or equivalent) of someone else's 2-dimensional work, it would be very useful to underscore that the date we care about is the date of that 2-dimensional work. - Jmabel ! talk 22:39, 16 January 2024 (UTC)
    Perhaps we should show a notice here if the user picks today's date? the wub "?!" 20:01, 17 February 2024 (UTC)

Categories

How correct and useful are the categories added by users while uploading the media? How much work has the community to do to eventually fix them usually?
  • Often quite bad. The core problem, in my view, is that we have a very complex system of diffusion, where you're (generally) supposed to place an image only in the most specific categories it belongs to (so e.g. don't add an image to Category:Men when it's already in Category:Fred Rogers, which is a subcategory — several layers down — of the men category). This system is often difficult even for experienced editors to work in, let alone newcomers, for whom it is completely non-intuitive. Often they will place images in overly broad categories that then need to be diffused. This isn't the worst problem in the world, as there are lots of wikignomes who do category diffusion, but if your goal is to help newcomers categorize well enough that others aren't needed to clean up after them, this is your main problem.
    The way out of this mess, in my view is to focus on structured data, which doesn't have the mess of diffused categories combining topics, and from which categories can theoretically be derived. So, for instance, rather than knowing that, say, Category:Fred Rogers in swimming pools is a diffused subcategory of Fred Rogers, users would just enter Depicts: Fred Rogers and Depicts: swimming pool, and if we really wanted a Fred Rogers in swimming pools category the software could derive it automatically from the structured data. Doing this would solve the awful redundancy of asking users to first add categories and then add structured data, which is what we currently have. The rub is that the process of deriving categories from structured data is currently just theoretical, so additional technical work is needed there, and that categories have been deeply entrenched in Commons for many years, so shifting from them to structured data will require a shifting the community to orient around them. I expect those blockers to be dealbreakers for you, but still want to raise them, as I think it's important to look forward to the vision of where we ultimately want to end up.
    Hope all that's helpful! Cheers, {{u|Sdkb}} talk 17:32, 16 January 2024 (UTC)
    I agree that we probably won't get most beginners to do a great job of categorization. If they add more-or-less reasonable categories, the wikignomes can take it from there. It is very important that we get at least one somewhat appropriate category; anything beyond that is gravy. Also, in my experience, beginners don't do any better with "depicts" than with categories. I believe I've seem more really bad "depicts" than really bad categories. Both are folksonomies that take some time to learn. But in my opinion categories are much more important than "depicts". - Jmabel ! talk 22:39, 16 January 2024 (UTC)
    I think the problems beginners have with "depicts" currently are rooted largely in the fact that the structured data interface hasn't been optimized for newcomers at all yet. And I'd say that categories are certainly more important in the current Commons environment, but that they're a legacy system that's going to become less important over time as we transition toward using structured data given its inherent advantages. That transition could be several years away, but for purposes of improvements to the Upload Wizard, I think the forward-looking/future-facing approach would be to not neglect structured data. {{u|Sdkb}} talk 18:44, 16 January 2024 (UTC)
    Disagree that structured data is the solution. Often the more specific categories aren't known to people and also having an image in a broad category can be useful when it's fitting into not only one subcategory but multiple. A larger current issue is that people hide away media in a subcategory which then is gone from a level above while the subcategory is by some arbitrary strange characteristic and the media is then missing in other cats where it would be more useful.
    Now in regards to solutions, I think that would be specifying more (relations etc) and more automation. I thought of proposing my idea regarding that in the WMC tech survey but decided to propose it another time and maybe on Wikidata. Structured data could be useful for that but it's not the solution anyway and currently the structured data on media is a) little used / very incomplete b) not useful in practice unlike categories which have category pages and c) often contain hardly maintained problematic/misleading/false contents. Cats and sData should in sync (automatically) and currently sData mainly drains valuable time resources rather than adding anything. Support for the software could derive it automatically from the structured data but more useful than that are the categories set plus you need to consider that the sData is often false so it should be proposed changes (to quickly confirm) rather than auto-categorize things etc. Prototyperspective (talk) 18:04, 10 February 2024 (UTC)
  • I support what it has been said there. Most of the newbies add very generic categories, normally in their own language, so they upload photos to categories like: "People" or "House". The idea we should push is the depiction itself, and try to suggest categories based on that. Theklan (talk) 19:01, 16 January 2024 (UTC)
  • Many categories don't belong as "depicts", and I'm constantly seeing people put content in as "depicts" that doesn't belong there. Examples:
    • a country should never be "depicts" except something like a map of the country
    • a city similarly, or maybe OK in a distant skyline (but most skylines show a downtown district that has its own distinct Wikidata item)
    • similarly when a photo of one item in a museum's collection is said to "depict" the museum.
    • (etc.)
    • person who the image is somehow related to but is not shown (a picture of someone's house or signature does not depict that person)
    • a medal does not depict a regiment, etc.
    • dates
    • information about the medium ("depicts black-and-white photograph")
    • information that is really about provenance
    • and really things like "depicts cultural heritage" or "depicts [some branch of] physics" are not quite right, either.
  • All of these things can, at least potentially, be covered by categories (and by other SDC properties that aren't, and probably don't need to be, in the UploadWizard). - Jmabel ! talk 22:55, 16 January 2024 (UTC)
  • The commonest error I see from new users is adding multiple levels of a category hierarchy ("Shops in London", "Shops in England", and "Shops in the United Kingdom"). Software could detect this.
    Other issues could be reduced by using a HotCat-like display where child categories of the current selection are shown. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 18 January 2024 (UTC)
  • Ok. I personally find the Upload Wizard very convenient for adding categories, basically because of the dropdown menu, though in many cases I have to look up the main category, to put it on a hotkey and then upload it from the hotkey to the category field, otherwise I will not be able to find it - for example how could I know that the correct category is Category:St Magnus Cathedral, Kirkwall and not Category:Saint Magnus Cathedral (Kirkwall) or Category:Kirkwall Cathedral? But this is not the point. The point is that I am not even close to an average Commons uploader. Unless I am mistaken, we are pretty much the only file depository in the world which still uses categories, everybody else uses tags. One possible conclusion is that we should be moving closed to tags and away from the categories, which is conveniently done with Structural Commons, but for many reasons this is probably not going to happen. Another possible conclusion would be to use categories as tags - to ask uploaders to add as many they want (most of which naturally are going to be redundant) and then find some automatic or semi-automatic way to bring them to align them with our category system. For example, no uploader would ever have an idea to add a category Category:Women photographed from the back against the light in Ontario (and it is unfortunate that we have such categories at all), however, if categories (tags) "woman" and "Toronto" are added everything else should be somehow possible to move down the category tree using fully automatic means, certainly after the AI has become available.--Ymblanter (talk) 19:36, 18 January 2024 (UTC)
    May be useful to add my own practice. I upload mostly my own photographs which are landscapes and cityscapes. The categories which I add are: (i) what is on the picture (down the category tree), sometimes one, sometimes two, sometimes five categories, as precise as I can; (ii) category of the type "August 2025 in Beijing", sometimes down to a year, sometimes down to a month, whatever is available/reasonable; (iii) "Taken with <camera model>" (iv) "<Country> photographs taken on <date>" - these categories some categorizers diffuse to the administrative divisions, but I believe there is community consensus against such diffusion; (v) my personal categories, "Photographs of <Country> by Ymblanter", so that I can find the upload later. All my rant above is about (i), bots should be able to add (ii), (iii), and (iv) fully automatically. Ymblanter (talk) 19:43, 18 January 2024 (UTC)
  • It would be very helpful, if uploader can choose between possible categories based on EXIF coordinates like in commons mobile app. Many people uploads mainly photos of places and object. JAn Dudík (talk) 21:45, 18 January 2024 (UTC)
  • I've been saying for years that the main issue with the MediaWiki Upload Wizard and categories is the lack of using redirects. If you use HotCat you can write anything and it will automatically add the correct category because of a redirect, this is not the case for the MediaWiki Upload Wizard. Why not just look at the software code from HotCat that recognises redirects and add these to the MediaWiki Upload Wizard? This would allow us to create multilingual category names to redirect to the English-language name and it will make the upload process more welcoming to people that don't speak English. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:27, 27 January 2024 (UTC)
    I would like to boost this suggestion. The main problem is that, because of technical limitations of MediaWiki, categories don't have "normal" redirects like other pages; they have soft redirects using {{Category redirect}}. The Upload Wizard should recognize this, and when a user enters a redirected category such as Category:Deutschland, the software should read the redirect template and correct the entry to Category:Germany. I operate RussBot, which empties pages out of redirected categories into the correct categories. Due in part to the Upload Wizard not recognizing redirects, Commons has a ridiculously large load of pages needing to be moved by the bot. I run the exact same script here as on enwiki -- on enwiki, it typically runs for about 5-10 minutes per day, and generates a log file of about 20 kb/week; here on commons, it runs for about 5-6 hours per day, and the log file is about 700-800 kb/week. --R'n'B (talk) 18:43, 10 March 2024 (UTC)

Closing discussion

@Sdkb, Theklan, Kritzolina, Jmabel, Ymblanter, Abzeronow, Samwilson, Pigsonthewing, C.Suthorn, Jeff G., JAn Dudík, Donald Trung, and Prototyperspective: , I wanted to thank you very much for your explanations and interventions. This has been a fruitful discussion, and we'll be sure to use your feedback for our proposal of revamping the "Describe" step in UploadWizard. We'll keep in touch with you and in the coming months we'll submit to you our design proposals, in order to gather more feedback on it. It's going to take some time, so we'll ping you directly when it's gonna be time. Of course, you're more than welcome to expand the list of pings, by calling other experienced users who you think can provide us with useful insights. Until then, I hope you have a great day and happy editing! Sannita (WMF) (talk) 11:35, 16 February 2024 (UTC)

Sannita, Just please also post it to "Commons:Village pump" to get an as wide as possible audience. Many people still don't know that this page exists and would benefit from seeing occasional updates there. — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:38, 16 February 2024 (UTC)

Concerns about overall language

(I'm translating so I will be adding sections as I find problematic language)

"Required to upload it for my job"

Hello, in the section on "Describe the purpose of this work", the following message appears: "This work is for my personal use, e.g. photos of myself, my family or friends, or I am required to upload it for my job".

If you select this option, the upload wizard suggests that you don't upload the media. However, all this messaging is very confusing. You could be uploading a work that provides knowledge AND that you are also required to upload it for your job: a person working for a GLAM institution might be required by his/her employer to upload a work that provides general knowledge and that is not necessarily in the public domain.

Moreover, a personal and a work use are very different in nature, there are tons of examples of this. But the "I'm required to upload this work for my job" opens up several options.

Option 1: "I'm staff at an affiliate or I'm hired by an affiliate to produce a given work (i.e., graphic design)". That's an entirely valid reason to upload a file, and it's expected that affiliates have someone from staff uploading works.

Option 2: Someone is required by his/her employer to upload a work that they have produced in the course of their employment, meaning that for them to be able to upload the file, the employer should have given permission to do so (unless it is otherwise stated in the law, as in the case of works produced by US federal government employees).

In any case, option 1 & 2 would need some sort of clearance for uploading. But they are a radically different use case than "personal photos" and I'd argue that we do want works for hire to be uploaded to Commons, because there are a lot of scenarios where this would be desirable, and the current phrasing introduces a lot of unnecessary confusion. Scann (talk) 13:15, 10 February 2024 (UTC)

"Album covers"

The following message reads:

"I confirm that these works do not include material restricted by copyright, such as logos, posters, album covers, etc."

Instead of "album covers", I propose we use the more generic "art covers" or "illustrated covers", which is a more precise term for the work protected by copyright. There are some covers that are so generic that wouldn't meet the originality threshold and can be safely uploaded.

Media under copyright

"Do not upload these files! Wikimedia Commons does not host media under copyright. Only media with free licenses or in the public domain are permitted on Commons."

It is actually "media protected by copyright" or "with all rights reserved". Media under a Creative Commons license IS under copyright, it's just that the creator has released it under a license.

CC0 license / waiver

Where it reads:

"By clicking "publish", you agree to the terms of use, and you irrevocably agree to release your contribution under the Creative Commons CC0 License."

It should read "Creative Commons CC0 waiver". It acts as a fallback license in countries or jurisdictions where waivers are restricted by law, but technically speaking it's a waiver and this should be made super clear to people using the waiver.

Thank you @Scann for these comments. I'll pass them on to the designer and see if we can amend the messages accordingly. Sannita (WMF) (talk) 12:16, 12 February 2024 (UTC)
Tracked in Phabricator
Task T357481
@Scann Hey, just FYI, the designer is working on the suggestions you made. They will be probably resolved and deployed in a few weeks time. I'll keep you updated about it, but if you wish you can subscribe to the Phabricator ticket. Thanks again! Sannita (WMF) (talk) 10:57, 14 February 2024 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements/Archive2&oldid=863772312"