This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
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?
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 ! talk00: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.
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).
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)
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 ! talk20:08, 5 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.
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:
How is the "caption" field being used right now?
Would it be better to move the "caption" field outside of the "core information" part of the form?
How frequently are "location" and "other information" fields used? What "other information" is used for usually?
Is the "date of creation" field used also to evaluate potential problems with Freedom of Panorama and/or copyright of the image?
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?
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}}talk17: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'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). SamWilson08: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.
@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)
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}}talk17: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 ! talk22: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 edits13: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}}talk17: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}}talk19:02, 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 ! talk22: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). SamWilson23: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?
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 ! talk22:39, 16 January 2024 (UTC)
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}}talk17: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 ! talk22: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}}talk18: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 ! talk22: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 edits13: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)
(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.
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.
I assumed that I did it wrong because when you are uploading to the Commons it asks you to upload it only for educational purposes. So I guess its ok if I did it for my userpage only. My cat, that aint for educational purposes. But its alright for my userpage. Am I correct?
What do you propose? I think adding a "or for you user page" would not be a good idea and would lead people to use Commons as a social media page. GPSLeo (talk) 17:56, 22 February 2024 (UTC)
I don't see this as a problem. We cannot prevent people from making mistakes by listing every single reason their upload might (not) be allowed in the upload form. —TheDJ (talk • contribs) 13:18, 6 March 2024 (UTC)
It does seem like a problem, but a very minor one. Personally, I don't think the benefit of addressing it is worth the extra complexity cost for the interface. If the UploadWizard actually explained everything perfectly, it would look like an Apple TOS agreement. Nosferattus (talk) 16:59, 26 March 2024 (UTC)
Feedback needed on proposed changes to Describe step
Hi all! We've concluded our evaluation of your previous feedback and we're ready to share with you our current mockups for a proposed change to the "Describe" step in UploadWizard.
We also have several questions for you to answer, as part of our request for feedback. I took the liberty of creating several subtopics for them, so that it will be easier for you to answer.
Now it seems everything is more compact and better organized. I think that the ideas will be more clear, and the overlap of information reduced. I would suggest to make the selection of license pre-filled with cc-by-sa-4.0, as it is the most commons one. This could be changed by default in the preferences for a user, if they prefer another one. From my experience, people don't understand the nuances of all the licenses, so giving one as default would make it easier. -Theklan (talk) 11:31, 12 March 2024 (UTC)
I think the caption should only be copied to the description (by default) if no description is provided with the default being showing the description field. The caption only allows for a short text. There's currently a big issue with images that are clicked on in the WMC search results only showing the description but not the caption where it should show both if they aren't the same (is there a phab issue for that?). As for the depicts statements – I think a large fraction of users enters at least partially problematic/inaccurate things there which are hard to find and correct while at the same time that metadata could mostly be inferred from the categories. Both the time spent on these (mostly redundant) by uploaders and the editors correcting their problematic data as well as the amount of misleading/poisonous/inaccurate data will likely increase with making these fields even more visible. Not necessarily a big problem, just not an improvement I think and something that probably will need to be dealt with at some point. Likewise, the same applies to encouraging users to enter more languages – what are people expecting them to do ideally…manually entering 300 translations? These should also be populated via modern tools that show dynamic correctable machine translations such as via the DeepL translator. --Prototyperspective (talk) 13:00, 12 March 2024 (UTC)
Every input field should come with a help text or even illustrations and not only a title line. the help text can be hidden with css or behind a (i) button, but there should be an explanation what the input field is about --C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 14:45, 12 March 2024 (UTC)
Oh, lots of thoughts!
Moving describe to the last step seems good.
Regarding Most users (especially new users) may find entering captions significantly easier than providing detailed descriptions — Well, yeah, people always find it easier to do less work rather than more work. But we want people to provide as much description as possible, since the purpose of Commons as a repository of knowledge means that images with detailed associated info are significantly more valuable to us. The "100" in the bottom right seems to indicate to me that you plan to impose a character limit on the caption, and while that makes sense for the caption, I worry that it'll push users who might otherwise be inclined to provide more detailed info away from doing so. Having to actively uncheck the "same as caption" box to access the description means that few users are going to do so. An alternative approach might be to make the description the field users fill out, and then have an autochecked "same as first sentence of description" prefill the caption.
Regarding Captions offer a more structured multilingual field, can you provide some additional info on this? I wasn't aware of structural differences between the fields, and if there are deficiencies in the description field, that seems like something we'd want to upgrade as part of this work. As myself and other editors have mentioned before, we consider the description field more important than the caption, so I am concerned to see it being deemphasized in these changes.
For the "Additional information" fields, I would suggest replacing (optional) with (recommended) in all cases.
The changes to the confirmation page look good. I might suggest adding some smallish text under the green bar that helps emphasize that contributing to Commons is a public service in a way that uploading to most other sites is not. Something like Your contribution adds to the sum of freely available media providing knowledge for the world.
I notice that the "Other information" generic field has been removed. Some users or tools may use it, so I'd check to see if anything is being impeded/lost there.
@Sdkb Thanks for your opinion. Just briefly on the "100 characters limit": that limit is already in place (even though is slightly higher, it should be 250 or something around that), we're just confirming it. Sannita (WMF) (talk) 12:11, 21 March 2024 (UTC)
A few thoughts:
Having to uncheck "Same as caption" to enter a description every time will mean an extra click for me, every time. My preference should be remembered (or be a user setting). How will this work with multi-image uploads?
Users should be strongly encouraged to enter a description, if not mandatory. (Remember also that description is wiki-text; caption is plain text.)
At least one category should be mandatory. Users should be invited to enter multiple (plural) categories, not just one.
We need to tighten the wording on "depicts", to ask people to be precise as possible, and not duplicate. If the user has provided "depicts=Mississippi", we don't also need "depicts=river".
Upload date is not necessarily the date taken, even for own works.
[I'd go a step farther than that: upload date is almost never the date taken, even for own works. Some people who use camera phones upload almost immediately. Almost no one else does. - Jmabel ! talk08:14, 13 March 2024 (UTC)]
@Pigsonthewing @Jmabel @C.Suthorn Thanks for this thread, I can also personally confirm this could be the case for some of my uploads with my volunteer account. This however begs the question: is date of creation/publication more important than date of upload? Should we change the name of the label accordingly? And in your experience, can dates of creation and publication differ? Sannita (WMF) (talk) 18:58, 22 March 2024 (UTC)
The indubitably can and often do differ; date of creation/ publication is the most important (although we need both) as it can effect the copyright status of the work. Date created is also relevant for a subject which has changed (Is this a picture of the building before or after restoration? A portrait of someone before or after their appointment to the position that made them famous?). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:33, 22 March 2024 (UTC)
Date of upload is always known, and is always reflected in the file history. We absolutely do not want the date of upload to Commons as the supposed date of the image unless it happens to be uploaded the day it was taken. We should never need to query the user for the date of upload. In fact, an ongoing problem is that people upload logos, old images, etc. with an inaccurate and implausible date, which turns out to be the upload date. - Jmabel ! talk21:42, 22 March 2024 (UTC)
We need "other information"; I use it often.
The current "use this image" options should be retained; but note phab:T299064 which should be resolved at the same time as this change (if not sooner)
The final screens should have a "go to image page" option.
@Pigsonthewing Thanks for your opinion. Just briefly on your first thought: we're thinking of making "same as caption" as a preference, but we still need to evaluate how much work it will be. About multi-image uploads, I can confirm it will work the same as today. Sannita (WMF) (talk) 12:15, 21 March 2024 (UTC)
On the final upload confirmation page, "xxxxx.asdgg" (the resulting text caption) could be replaced by the SDC caption entered previously. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:38, 12 March 2024 (UTC)
My main issue is that if you first (1st) type in the "File caption" field that it's much more difficult to detect any errors.
Regarding the idea that the "File description" field should be checked by default, personally I think that it would be better to have it checked by default. Also, I am not sure if we should move the focus to the "File caption" field first (1st), personally my issue with the "File caption" field vis-a-vis the "File description" field in the current iteration of the MediaWiki Upload Wizard is the fact that the "File description" field is much bigger and easier to correct, if you type a lengthy description in the "File caption" field or make a mistake earlier it's not easy to find. Let me give an example (see the attached screenshot - above on for mobile devices, to the right for desktop users).
Personally, I prefer to write the "File description" before I write the "File caption" for the very reason that it's extremely inconvenient to use the very narrow and short field. Since the MediaWiki Upload Wizard changed I also cannot stack multiple licenses for "This file is not my own work" anymore, before I could stack it like this:
PD-Vietnam
PD-US-expired
But now if I click on the "Enter" (or the "Execute") button then rather than letting me add the next license it just sends me to the next field.
Remember that public domain files are required to have both a license for why they are free in their country of origin and the United States of America (if the work is alien (from a US perspective) in origin). The current version of the MediaWiki Upload Wizard makes uploading alien works (from a US perspective) more tedious.
This same inconvenient software is used for the "File caption" field but not for the "File description" field. I don't mind the "File caption" field having this limitation, but I don't see why it should be expanded to any other field. For the aforementioned reasons I simply cannot support any changes that make it more difficult for people (especially novice contributors) to access the "File description" field, the "Same as caption" box should be unchecked by default.
Regarding the above comment "People who upload from phone will likely use the commons smartphone app, not the wizard, making it even more likely that uploads on the wizard were not created on upload day." (C.Suthorn (@Life_is@no-pony.farm - p7.ee/p), I'd go even further and state that the proposed changes solve nothing while they would create additional problems, the Wikimedia Commons already records when a file is uploaded to the Wikimedia Commons, every file has the "File history" field below, on top of that, the date of fixation for any digital photography is typically captured in a file's metadata, so any changes to the "Creation / Publication" field would inevitably create more problems than it solves as the current version can already read a file's meta-data and can be edited to be corrected. For example, a public domain document was scanned by a photocopy machine in 2006, but the original document is from 1825. With the current system the meta-data from the scanning device is captured and published, the date and time that the file was uploaded to the Wikimedia Commons is captured and published, and the uploader can correct the date by simply typing in "1825" in the "Creation / Publication" field. I genuinely don't see what's broken about the current system for recording the file's original creation and / or publication that needs to be fixed in any way.
To me, the solution for this is easy, (1) integrate the same software for redirect detection and automatic correct that HotCat utilises to the MediaWiki Upload Wizard, HotCat works amazingly well with redirects so the software has already existed for years, (2) add every Wikimedia Commons category to Wikidata and automatically import translations, redirects, and alternative names and / or spellings, obviously these would have to be at least 180 (one-hundred-and-eighty) days old or something to prevent cross-wiki vandalism, a robot 🤖 would automatically create all these redirects, and (3) create software that detects the display language of the viewer and translate category titles accordingly. This would mean someone with the default language as English would see "Category:Passports of Japan" but someone browsing this website in Japanese would see "Category:日本国旅券" (apparently the Japanese Wikimedia websites use the English word), a better example would be "Category:Moscow" Vs. "Категория:Москва".
Obviously, most of the above changes would be outside of the scope of changing the MediaWiki Upload Wizard, but implementing redirects for categories would work. I don't think that we should be making categories mandatory until we've made it convenient for speakers of every language to add them without having both an in-depth knowledge of the English language and the naming conventions of Wikimedia Commons categories, plenty of categorisers work with uncategorised media every day that have better knowledge of these subjects that might end up having to clean up heavily fragmented novice files in overpopulated main categories. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:48, 25 March 2024 (UTC)
TL;DR, I really like some of the changes but I don't think that we should disable "File descriptions" by default because of some display and typing issues with the way users can enter captions, I think that there's nothing wrong with the current way of noting years and specific dates and don't see what the proposed changes will improve in this regard, and while I think that adding categories should be strongly recommended, I don't think that they should be mandatory until we've found a way to improve category suggestions and multi-lingual category integration through software improvements. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:52, 25 March 2024 (UTC)
Do any of these proposed changes make your contribution flow more difficult? If yes, how?
...
Do any of these proposed changes help make your contributions easier?
Having caption and description together makes sense most of the time, as they are normally the same or very similar. Also, it makes way easier for new contributors to use, as the difference between both is only relevant for a small niche of files. Also, it would be really great if we could have a map with a pin to mark where the images were taken. This can be done now with external tools, but incorporating it would make way easier to find images of buildings that are uploaded but not geo-referenced. -Theklan (talk) 11:34, 12 March 2024 (UTC)
That's great! I have seen that now there's a map if we add coordinates to the file, but this is not draggable. I think that it will be a future feature, so I'm already waiting for it to happen. Theklan (talk) 19:01, 22 March 2024 (UTC)
I often upload multiple photos from one vilage/street/locality. So all these photos have almost same name and often same desription (eg. object in street XYZ). The only difference is by coordinates and later I sort most of these files to subcategories which are connected with wikidata item. But sometimes my phone GPS stucks and all files have sme cooordinates or very imprecise coordinates, so map displaying position of photo will be VERY useful, but it should be map with details (phab:T329852). JAn Dudík (talk) 10:13, 23 March 2024 (UTC)
The removal of those annoying "confirmation" buttons in the "Licensing" step would greatly make uploading easier. As these annoying checkboxes are gone in the concept images I assume that the team is actually planning on removing them which would mean a few less clicks. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:54, 25 March 2024 (UTC)
Is there anything else you would like to see improved / added / removed in UploadWizard? If so, why?
Choosing the right category is the most difficult part of the uploading process, as it is difficult to know if a category exists. New users normally add there tags, like "building", "person", "landscape" that are not relevant for a category, but they are for the structured data. I don't have a solution for that, but using the structured data and coordinates could be a good way for suggesting categories, like in the Commons App, which suggests nearby objects and loads the category from the Wikidata item. Also, loading a small category tree (similar to cat-a-lot) could be a good way to choose the relevant category: imagine you have a photo of the interior of a church in a Smalltown. You type the name of the village, there you get "Category:Buildings in Smalltown", you click and you have: "Category:Church of the Sacred Encyclopedist in Smalltown", and there you have "Category:Interior of the Church of the Sacred Encyclopedist in Smalltown". That's the right category, but it would be hard to find if you don't know beforehand that it exists. Also, it would reduce the burden to re-categorize for experienced users that don't know if this is the Interior of the Church of the Sacred Encyclopedist in Smalltown or, instead, the Interior of the Parish of Saint John in Smalltown". -Theklan (talk) 11:41, 12 March 2024 (UTC)
@Theklan @TheDJ @Jmabel Again on categories (and the difficulty of adding them): do you think it's a good idea to limit the possibility of adding a category only to existing ones? In other words, if a user tries to add a non-existing category, it would be prevented to do so. Would it be a good idea in your opinion? Sannita (WMF) (talk) 13:08, 29 March 2024 (UTC)
Maybe. I don't use the Upload Wizard myself, and I'm not its "target market" but I'd be frustrated on upload if I couldn't add, for example [[Category:April 2024 in Seattle]] if noone had already created it and then go about creating it later. But this is part of why I avoid coming through a "Wizard". I would think that nonexistent categories more call for a warning (and a link to an information page explaining why they are a problem) than a prohibition. Plus definitely some bot-based thing that would hit up the user's talk page if they haven't created the category in an hour or so. - Jmabel ! talk16:56, 29 March 2024 (UTC)
I think that's not a good idea. From my experience, I upload bulk images of the same object (for example, interior of a church), and then I create the categories if they don't exist. Also, the problem is usually the opposite for new users: the category exists, but it is extremely broad (people, portrait, building). So I think we would have more work for the users who know how to use categories than for those who don't. Theklan (talk) 17:01, 29 March 2024 (UTC)
Same answer as Theklan. Sometimes I create new categories while filling out the description step, but caching means the UploadWizard still warns me about the category not existing. I would be fine with an ignorable warning as we have now. the wub"?!"22:42, 29 March 2024 (UTC)
Regarding location information: just a reminder that we do distinguish between camera location and subject location. These can differ significantly. Also, camera heading becomes more and more important the longer the "zoom" on the camera. Both the georeferencing templates and SDC allow for the heading to be stored, but as far as I remember Upload Wizard ignores that information if stored in EXIF and does not offer a possibility to enter it manually. --El Grafo (talk) 13:08, 12 March 2024 (UTC)
Indeed, both could be asked: subject coordinates, and camera coordinates. And if the later is available via EXIF, still it could be a good option to add the option to add the coordinates of the object, which could be infered otherwise from the Wikidata item. Anyway, having the option to add the coordinates there could be make things way easier. Theklan (talk) 13:12, 12 March 2024 (UTC)
There should be also posibility to delete coordinates (or set no coords applicable) - If I made photo of some person / movable object, coords are usually not wanted/relevant. JAn Dudík (talk) 10:16, 23 March 2024 (UTC)
And people often want to remove coordinates for reasons of confidentiality, especially when photographing in private residences. - Jmabel ! talk17:51, 23 March 2024 (UTC)
if the browser or the tab crashed during the upload process all text entered should be saved and offered to the user again. Broken running uploads should restart at the position already uploaded so far.
if the resolution of the image is smaller than 4MP or the file size is smaller than 2MB a popup should ask if the user has a higher resolution of the image available and warn, that the license is valid not only for the uploaded file but for all higher resolitions also. It should also warn that small resolutions are often stolen from the web and are likely to get deleted as COPYVIO.
if there is no EXIF or the EXIF contain Facebook or Twitter IDs the user should be warned, that the image appears to be from social media and might be deleted, if the user has no prove of own work or free license.
category selection should not be with autocomplete but as a tree browser of the commons category tree.
categories are one language only. The category selection should not be by the actual category name, but the language localized wikidata name of the category should be used for selecting categories.
When uploading, you can choose that the file includes previously free files. It could be interesting to add there which ones, so they can be automatically cited if those are in Commons. -Theklan (talk) 22:27, 12 March 2024 (UTC)
My thoughts:
I know lots of people think that adding categories should be required, but I think it's a terrible ask of users. My idea would be to make a list of 'follow-up tasks', dump them in a db table and ask (with reminders) people to complete them at a later point in time. This could be done for categories, location, depicts, adding timed text etc. Auto-delete the tasks after 2 months, and use things like {{uncat|uploadwizard}} between upload time and follow-up tasks. I think that is much more scalable and you can provide dedicated UX that will help people through the tasks and educate them at the same time.
For creation date I also like the suggestion to make it possible to grab this from EXIF. "This file might have been created at xxxx. Use this value for this field?" something like that.
Same for location
There are several things that are only possible with advanced permissions. Uploading webp and mp3 are some of these. I think this should be handled in UW and explained to the user, because right now it can be very confusing when you encounter this.
One thing that I miss in the learn and the describe step (and something that the release step DOES explain), is WHY we are asking this of people. Maybe at the top of Describe we could have something like: "In order for media files to be re-usable, next to being allowed, they have to be discoverable. Please provide accurate descriptions and additional information to facilitate discovery by other users." Maybe someone has a better text, but the main point being that we should be explaining why this form works different from other upload forms that people might be used to. —TheDJ (talk • contribs) 13:27, 13 March 2024 (UTC)
"This file might have been created at xxxx" is a bad wording. We don't care when the file was created, we care when the content was created. At least for any image format (JPG, PNG, GIF at the very least) we should say "this image [emphasis mine] might have been created at xxxx." If it is a scanned old photo, a logo, a photo of a 2-dimensional work of art, that wording is better, and in no case that I can think of is it worse. - Jmabel ! talk18:00, 13 March 2024 (UTC)
If the file includes location metadata, UploadWizard should give the user the option to strip out the location metadata before the file is published. Nosferattus (talk) 00:49, 14 March 2024 (UTC)
Multi-lingual category redirects, well, just HotLink level redirect handling in general. I also agree with the suggestions made by users "TheKlan" and "TheDJ" above regarding the suggestions for more specific category through software suggestions and not making categories mandatory. I really love categories and hope that they can be improved in the future, but unless those improvements are happening we shouldn't be shoving a broken system down the throats of confused novice users, even experienced users don't know how to navigate every niche category tree.
Also, please make it easier to add licenses in multiple lines again (like before).
I also agree with user "GPSLeo" in "we need more flexibility for adding or removing fields and more URL prefilling functionality", a more customisable MediaWiki Upload Wizard for power-users would probably preferable. Perhaps any user with an auto-patrolled user right and higher should have access to a customisable version of the Wiz, that or any user as long as they're knowledgeable enough. Perhaps a "Build your own Upload Wizard" tutorial and functionality would greatly help everyone.
New users should be encouraged to write feedback, maybe anyone doing their first (1st) upload and anyone doing their initial 10 (ten) or so uploads without having previously left any feedback should be given a message telling them to write about their experiences with the MediaWiki Upload Wizard, what they liked and what they disliked about it. The people who browse and write on this page aren't the same people as the novice users that won't make their voices heard in any community spaces. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:06, 25 March 2024 (UTC)
What are your thoughts on the information we are collecting here?
As a moderator, what are your thoughts on the information we are collecting here? Is there anything else you would like to see in the way information is collected that could improve your moderating workflows?
...
Specific question about creation/publish date
What is the current way in which you use the "date published/created" field? Is this information required for both "own work" and "not own work"? Should this remain a mandatory field?
I think this is mandatory, but it could be more flexible, for example giving the possitibility to add only Year or even Decade for old works. -Theklan (talk) 11:44, 12 March 2024 (UTC)
Agree with Theklan, it should be possible to just enter a rough date such as a year; not allowing this probably has caused a lot of faulty data and a note could be displayed if one doesn't specify the day that is asking the user to enter a more precise date if possible. --Prototyperspective (talk) 13:00, 12 March 2024 (UTC)
date needs to be mandatory. However inputs like "between 1976 and 1981" or "15th century" should be possible.
an explantion is needed that the date of creation of the work is meant is needed
date from exif can be imported, but then a popup should ask "is this the date of creation or of changes by photoshop?"
You could ask for a level of precision for the date. There is a big difference between the year 1900, the 20th century, the decade 1900-1909, and ca. 1900. I have seen sources presume that just the year means 1 January of that year; please let us not make that mistake. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:50, 12 March 2024 (UTC)
Please don't remove this pencil ✏️.
"date needs to be mandatory. However inputs like "between 1976 and 1981" or "15th century" should be possible." (C.Suthorn (@Life_is@no-pony.farm - p7.ee/p)) That is already possible with the current MediaWiki Upload Wizard, in the mock-up's I didn't see the "pen" / "pencil" found today, which is a bit worrying, but this could just be an issue of the artist that made the concept image rather than a technical change. Personally I'm not a fan of moving the date 📅 to the "Licensing" step of the upload process, but I think that adding extra pop up's is a worse idea. While people should be better instructed on how to fill in dates, I am not sure if adding a pop up to files with EXIF dates to ask if Adobe Photoshop™ made it is a good idea simply because most novice users will probably try to upload their own photography rather than altered files. In case of the dates I'd rather say "why "fix" something that isn't broken?", especially since "I think this is mandatory, but it could be more flexible, for example giving the possitibility to add only Year or even Decade for old works." (TheKlan) Is already a feature of the current "Publication date" field. In cases where works that I'm uploading contain no date but the source indicates that it's from the 19th (nineteenth) century or a specific decade like the 1840's I already just type in "1840's" and the existing MediaWiki Upload Wizard has never had an issue with it.
While I really like "File:UploadWizard improvements - Published date.png" I only like it for removing the redundant checkbox that was added a few months ago, I don't see why the date should be moved from the "Describe" step to the "Release rights" step, now that I think about it, this makes even less sense if you're uploading multiple images at the same time. Let's say you upload a batch of images from an author whose works are in the public domain but they're not all published on the same date, if you upload multiple photographs of your own then will they all have the publishing / creation date based on the EXIF data of the first (1st) image? In the middle of writing this I suddenly had the realisation why this would absolutely not work, and that's because this wouldn't work for multiple files.
The "date" field should absolutely not be moved from the "Describe" step to the "Release rights" step for the very simple reason that when uploading multiple files it is more manageable in the current iteration, especially if they all have the same license and creator, but are made on different dates (which is also true for "Own work" files which all contain separate EXIF data like literally any batch of photographs).
Let's say Sally goes to a Wikimania event, she photographs 10 (ten) pictures at a presentation, they were all made on July 4th (fourth), but at different times, the EXIF data will record these differences often to the microsecond and that shows up at the current MediaWiki Upload Wizard. She would probably be very confused if all her photographs of this 2 (two) hour long event said that they were taken exactly at 16:23. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:34, 21 March 2024 (UTC)
If you are planning to do some kind of field tests or A/B tests please do not do this during the period of the Wiki Loves contests with WLE from May to July and WLM in September. If you are doing field tests during this time please exempt upload campaigns from the changes. The organizers can not give support if they do not know what version the uploader sees and some tutorials might become outdated. In case of a bug there is the danger that many contest contributions get lost or at least lose some important information. GPSLeo (talk) 07:05, 15 March 2024 (UTC)
@GPSLeo Thanks for the heads up. We're not planning to do tests during this period at the moment, but it could be possible that we will do some changes to the UI depending on how the current feedback period goes. Let's keep in contact on this. Sannita (WMF) (talk) 10:42, 15 March 2024 (UTC)
UW should use the attribution paramter in the license template. Re-users are told by the license template what license applys. In most cases the author has to be attributed. In most cases a re-user has to search for the author in the information template. but the license template has an mostly unused attribution parameter that can and should be automagically filled in by the UW for the benefit of re-users. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 17:56, 25 December 2023 (UTC)
@C.Suthorn Thanks for your comment (and sorry for taking a week to answer, but I was out of office for the holidays). Would you please file a Phabricator ticket for your request, so that I can forward it to the team for evaluation? If you don't know how to do it or can't do it, I can do it for you, but then I'll ask you to double check it, just to be sure that everything is in place. Let me know! Sannita (WMF) (talk) 11:35, 2 January 2024 (UTC)
@C.Suthorn Hi, we evaluated your ticket, and the original request you made was conflicting with Commons' guidelines on how the parameters should be compiled ("attribution" is deprecated, and should be used only if different from "author"), therefore we tried to change a bit the wording and the scope of it.
The team, in the end, decided to decline your ticket, because it isn't clear what benefit would it bring to use the "attribution" field in the template, and also because the info about who the author is is already present in {{Information}}. The ticket can be reopened, if you can make more clear your case about why this is needed, maybe presenting examples of use cases. Sorry to be the bearer of bad news. Sannita (WMF) (talk) 16:33, 20 March 2024 (UTC)
@Sannita (WMF): may I ask what Commons guideline that conflicts with? Because I think C.Suthorn is entirely correct here.
I certainly always use an explicit attribution in my uploads even of my own photos, as do at least several dozen of the more serious photographers here: there is a reason {{Self}} has an "author" argument. I've repeatedly seen that for people who do not do this, when their work is reused by third parties it is often misattributed to "Wikimedia Commons" or even "Wikipedia". Surely that is not desirable.
Also, many people often upload third-party work (as for example I did less than 20 minutes ago with File:Washington State Ferry Olympic beached on Ketron Island.jpg. For this, the attribution argument in the license is close to crucial: otherwise, it will often either be misattributed as in the first case I mentioned or misattributed to the uploader, again not at all desirable. - Jmabel ! talk20:05, 20 March 2024 (UTC)
@Jmabel Thanks for this message, evidently we interpreted in a narrower way the guidelines, and we were also lacking good examples for this. I'll try to get the ticket re-opened, even though it might take a while.
Just personally, my experience with external outlets (having worked with several) is that it's already something that they quote "Wikipedia" or "Wikimedia Commons" (or even "Wikipedia Commons"...) as source of the image. I don't think it has much to do with template attribution, but more likely with laziness and/or scarse knowledge about how to correctly quote something. But that shouldn't bring us to avoid new means to enforce that, I give you that. Hope to let you all know soon about this. Sannita (WMF) (talk) 18:38, 22 March 2024 (UTC)
Discussion about new tool for detecting logos
We're having a discussion at the Technical Village Pump about a new tool for detecting logos. Our intention is for you to discuss if it could be of use for the community and then, if consensus is reached, to integrate the tool in UploadWizard, in a way that would be beneficial for moderation workflow. If you're interested in the topic, please have your say! Sannita (WMF) (talk) 10:19, 9 April 2024 (UTC)
Honestly, I don't understand why you haven't tested it well.
We have WLE in order to create new content and to get new photographers that are used to other websites and we increase the number of clicks in order to upload content and we lose good functions. In real life I have to deal with software improvement but these things wouldn't happened. I'm sorry, I'm disappointed.
Do you deploy changes to the Beta-Cluster before you deploy them on the production system? If you already do this it would be good if you would make an announcement after you deployed a change there that we can test for such bugs. GPSLeo (talk) 16:52, 16 May 2024 (UTC)
Hi @Sannita Can the community expect the problems to be resolved in the next two days? Or is the development team waiting for Pentecost to be enlightened by the Holy Spirit? Then I suggest that you please set the wizard to the status of May 13th. back and give yourself plenty of time for proper testing. Then perhaps you can present the new version as a Christmas present to the community. Good luck! --Im Fokus (talk) 17:29, 16 May 2024 (UTC)
@Sannita (WMF) Well, that's what I assumed. It's nothing but a matter of course. But how long exactly will it take? A day, two days, a week, half a month? Or even longer?
And when things are finally up and running again, you should take precautions to ensure that something like this never happens again. Because that was incredibly sloppy. After all, the errors were not in some rarely used secondary function, but in the main application of the wizard. Sorry, but that's the truth. Greetings Im Fokus (talk) 19:36, 16 May 2024 (UTC)
@Z thomas @GPSLeo @Im Fokus We found the problem and put immediately a fix working. In a matter of days this will be fixed, just the time for the deployment train to be on. I once again apologise on behalf of the team for the disruption caused, and we'll take more care than we already do to double check all potential effects. Sannita (WMF) (talk) 08:59, 17 May 2024 (UTC)
I have a further problem. Maybe it's the same, maybe it will be fixed. But I want to report it
One of the problems was that the filename wasn't prefilled. Now this seems to be fixed - but only if I use the laptop. if i use the smartphone and the firefox-browser the filename isn't prefilled at the moment. it's strange, isn't it. Greetings Zthomas11:04, 22 May 2024 (UTC)
@Sannita (WMF) I want to raise your awareness on a bug in upload campaigns where the homeButton on the last page links to https://commons.wikimedia.org/w/ instead of https://commons.wikimedia.org/wiki/. This should be very easy to fix. GPSLeo (talk) 14:03, 29 April 2024 (UTC)
@GPSLeo Just so you know, a patch for this is currently being reviewed. If everything goes alright, it should be on next week or in a couple of weeks, just the time for the deployment train to happen. Thanks for your patience. Sannita (WMF) (talk) 10:15, 22 May 2024 (UTC)
Some filenames are not accepted (like numbers). When uploading a file with that filename the wizard asked to change it, and it was fine. However, now, the name doesn't even appear in the window and that breaks my workflow because I like to keep the numbers in addition to the descriptive part of the name - because depending on the camera, the numbers are the timestamp or at least show the order the photographs were taken.
Please return to the previous default where the original filename was always proposed in the box, even if that filename wouldn't be acceptable if unmodified. Pere prlpz (talk) 16:40, 18 May 2024 (UTC)
@Pere prlpz Thanks for your comment. This is a bug that has been already noticed to us, I'll open a ticket on Phabricator about it as soon as possible, and will put you as a subscriber too so that you can follow it (and potentially fix my description if needed). I'll keep you posted about it. Sannita (WMF) (talk) 17:59, 18 May 2024 (UTC)
@Pere prlpz I filed phab:T365345 just now and put you in copy. Please review the ticket, and double check that the malfunction has been correctly reported. I'll see to put it on dev's radar as soon as possible. Thanks for your patience! --Sannita (WMF) (talk) 09:03, 20 May 2024 (UTC)
.png/220px-Inconvenience_of_detecting_errors_in_the_%22File_captions%22_field_compared_to_the_%22File_description%22_field_(March_2024).png)
.png/220px-Please_don%27t_remove_this_pencil_-_WMF_feedback_(March_2024).png)
.png)
.svg/15px-Pictogram_voting_comment_(orange).svg.png)
TL;DR, I really like some of the changes but I don't think that we should disable "File descriptions" by default because of some display and typing issues with the way users can enter captions, I think that there's nothing wrong with the current way of noting years and specific dates and don't see what the proposed changes will improve in this regard, and while I think that adding categories should be strongly recommended, I don't think that they should be mandatory until we've found a way to improve category suggestions and multi-lingual category integration through software improvements. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:52, 25 March 2024 (UTC)
--Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:54, 25 March 2024 (UTC).png)
