Commons talk:Upload Wizard/Archive 1

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

Invitation to Upload Wizard bug triage on 2011-11-17

bug - shhhh!
bug - shhhh!
  • Topic: “just want to go over bugs with the devs and triage them for fixing”
  • People: Anyone from the community who'd be good to talk to about upload wizard
  • Time: 17 November 2011, 21:30 (UTC)
  • Place: #wikimedia-dev on freenode
  • Food and drink: BYOB
  • Initiator: Bugmeister MarkAHershberger (IRC: “hexmode”)

From #wikimedia-commons to here by --Saibo (Δ) 22:50, 15 November 2011 (UTC)

This section was archived on a request by: Saibo (Δ) 02:37, 18 November 2011 (UTC)

Upload Wizard is broken

User agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

I posted this on the Upload Wizard feedback page by mistake, so I copied it here as intended.

It seems that the Upload Wizard has been broken for several weeks. I filed a Bugzilla report #34387 On Feb 14, but so far I haven't heard of anything from anyone. I am aware that there are numerous problems with this gadget for many users, and I was wondering why can't it be restored to an earlier working version? I have hundreds of images waiting to upload. Does anyone know what is happening? I am cross-posting this to the Village pump as well. - Ineuw talk page on en.ws 08:46, 21 February 2012 (UTC)

Well, the upload wizard feedback page was not really wrong (see the intro here on top)  :-) --Saibo (Δ) 14:58, 23 February 2012 (UTC)

solved - also see the threads spread over VP. --Saibo (Δ) 14:58, 23 February 2012 (UTC)

This section was archived on a request by: Saibo (Δ) 14:58, 23 February 2012 (UTC)

batch of three, though at various points the wizard said they were six ...

(split by Saibo from above --Saibo (Δ) 03:40, 24 February 2012 (UTC))

It worked for me a few minutes ago in a batch of three, though at various points the wizard said they were six, five and four files. Perhaps I failed to notice some change in selection procedure since last week. Jim.henderson (talk) 19:41, 23 February 2012 (UTC)

Hi Jim! Some updates were made to upload wizard some hours ago. Please try again. If you still suspect a problem please describe in more detail how you selected the files and which browser you use. Cheers --Saibo (Δ) 03:40, 24 February 2012 (UTC)

This slight error was yesterday, using Google Chrome 17.0.963.56 m under Vista. I opened the picture files by shift-click to mark and hit the Open button. I don't remember at which points the wizard said first there were six, then five, then four but it indeed ended up doing four including one duplicate. Today, three more using the same computer and software. This time I selected the files differently, with shift-click and drag to the indicated drag target that the wizard created in the browser. All uploaded correctly with no duplication and no indication that the number of files was other than three. Tomorrow I expect to be ready with four or five more pictures and will upload them with the exact method I used yesterday or as well as I can remember unless someone suggests differently. Jim.henderson (talk) 21:43, 24 February 2012 (UTC)

Yes. A few minutes ago I did that. These five pictures have various problems due to my misunderstanding of my editing program but the upload went exactly as it ought. Jim.henderson (talk) 22:32, 25 February 2012 (UTC)
This section was archived on a request by: Saibo (Δ) 03:40, 24 February 2012 (UTC)

Commons:Categories - Only experts can get this right?

Main bugs:

  • bugzilla:31292 Make Category permanently visible, not obscured behind a "more options" link
  • bugzilla:24704 Upload wizard: Category adder enhancements


“ categories moved back into "more options..." section; since it seems only experts can get this right, will be hidden by default. ”

by NeilK on SVN about the Category-Selector of Upload-Wizard

Because we get tons of uncategorized images now, let's discuss: -- RE rillke questions? 16:21, 6 October 2011 (UTC)

Other previous disc. locations: bugzilla:31292. And: Commons:Prototype_upload_wizard_feedback#need_categories_at_top_level , Commons:Prototype_upload_wizard_feedback#Option_to_add_Categories_missing, (before deployment) comment 4 - but no answer by neil --Saibo (Δ)

Is this assumption really right?

If yes, what could we change?

  • Let the user add keywords instead, and let a bot sort out an initial category, keep all uploads that use this system in a special category for category experts to go wild on. Reasoning, the average newcomer doesn't think in "Blue chevrolets produced before 1970 with a diesel engine". He thinks "blue car". TheDJ (talk) 16:46, 6 October 2011 (UTC)
  • One thing that newcomers can do it to add the category of the country (or a more specific location if possible) where the photo has been taken. For many photos this is a relevant piece of information. From a photo it is more easy to see what the subject is, than where it has been taken. This will make it easier for others to find the right category. Another possibility is to put a photo in a high level category. Better in a high level category than no category or a completely wrong category. This subject has been discusse before elsewhere, but I don't remember where. Wouter (talk) 18:32, 6 October 2011 (UTC)
  • Anything that would encourage uploaders to put more information in the description would help, even if it's in a foreign language. A better description would at least make it easier for somebody to add categories later. ghouston (talk) 05:41, 22 August 2012 (UTC)

Disable upload wizard / gadget defaults

No shock, I don't intend to ;) (even if this "wizard" ate up a lot of my time and made me sad).

I'd like to ask you whether you would contradict if we change the current non-default upload-wizard-opt-out gadget to a default-opt-in gadget and changing MediaWiki:Upload-url back to COM:Upload after the gadget is ready, activated and works. This has the following advantages:

  1. Intuitive settings — no opt-out gadgets
  2. For people without JavaScript enabled or incompatible browsers the upload-link would point to the old COM:Upload which at least presents a guide how to proceed (Flickr, Own work, ...) while the upload-form integrated in UploadWizard does not and has a unplausible Ajax-Spinner in the bottom of the page.

No reaction is implied consent. Thank you. -- RE rillke questions? 12:00, 2 November 2011 (UTC)

Thanks for making an effort to clean up the preferences and to improve the experience for no-JS uploaders.
I agree this makes sense as an interim solution, unless Neil sees situations where it might cause problems. As a long term solution, I'd prefer it if UW itself 1) managed uploaders' form preferences (which could include parameterized versions of UW itself), 2) presented an improved no-JS experience (without spinner, and with a prominent link to the case-by-case Commons:Upload process).--Eloquence (talk) 21:12, 7 November 2011 (UTC)
That doesn't sound like a bad idea for an interim solution. Long term I would rather that we consider UploadWizard to be the main interface that we try to improve, rather than constantly falling back to Commons:Upload. I am aware that there are a lot of problems there, in that the community doesn't have as much ability to alter UploadWizard's behavior; I'm hoping that will be largely addressed in the next iteration of "campaigns", which should be far more community-friendly. I will add a customized non-JS experience to the list of features we should support.
Also, I find it somewhat perplexing that you would consider that the AJAX spinner now seen on the non-JS version of UploadWizard is some kind of unfixable problem. That's just a bug. I admit I don't test non-JS much. -- NeilK (talk) 22:36, 7 November 2011 (UTC)

Discussion is now here: Commons:Village_pump#MediaWiki:Gadget-NoUploadWizard.js --Saibo (Δ) 15:16, 4 January 2012 (UTC) Archived: Commons:Village_pump/Archive/2012/01#MediaWiki:Gadget-NoUploadWizard.js. Copied below. --Saibo (Δ) 15:14, 11 February 2012 (UTC)

MediaWiki:Gadget-NoUploadWizard.js

... will be removed soon from the gadgets and will be replaced by the default gadget MediaWiki:Gadget-UploadWizard.js, which you can disable if you do not like Upload-Wizard. technical background, logical background. -- RE rillke questions? 16:55, 2 January 2012 (UTC)

One further "pro" is that UploadWizard can now be much more simple deactivated when there are known incompatibilities for certain browsers. -- RE rillke questions? 18:55, 2 January 2012 (UTC)

Please point me in the right direction: Where on Commons did you get consensus to disable the upload wizard in German by default? Multichill (talk) 20:48, 2 January 2012 (UTC)
I didn't do so, MediaWiki:Upload-url/de &action=history. But I endorse Saibo's decision as I do not see consensus to activate it. If I am missing anything, let me know, please. Otherwise we will run a survey on COM:Forum how to deal with. I just had no time, yet. -- RE rillke questions? 21:07, 2 January 2012 (UTC)
But why singling out people who access Commons in German? That's a completely arbitrary criteria. Why not Linux users, users whose IP starts with 64, users who live in the UTC+3 timezone, etc. Maybe they don't like UploadWizard either, but they can turn it off on their own, we should not assume that a whole arbitrary group of people want Commons to treat them differently. Prof. Professorson (talk) 22:03, 2 January 2012 (UTC)
How about, errr, how about, shall we say, what if, what if the developer's native language is German? Do you think that could be a reasonable motive? --Fred the Oyster (talk) 22:23, 2 January 2012 (UTC)
Upload-Wizard is perfectly acessable through Commons:Hochladen. It is the first option. Please note, that Upload-Wizard suffer(ed)(s) from too many bugs as I would recommend it to my best friend at this stage. Currently there is one in german language only Bugzilla: 33338 which causes that MediaWiki:Mwe-upwiz-deeds-macro-prompt is not shown as text. But this is only one of many. I am going to ask the German community now. -- RE rillke questions? 11:43, 3 January 2012 (UTC)
There may be remaining issues with the JS parsing library, but your message update has since been deployed, causing the specific issue in bug 33338 to no longer appear, as far as I can tell.--Eloquence (talk) 00:50, 4 January 2012 (UTC)
Note: the discussion about the German interface is now here: Commons:Upload Wizard Gadget Polling (de). Thanks Rillke! --Saibo (Δ) 03:27, 4 January 2012 (UTC)
Prof. Professorson, I would have changed the xxx interface too - but I didn't get the same feedback like from the German community. And: it is a long time standard now for the xxx interface. But, sure - could be discussed. Especially why it was activated without a legitmation. --Saibo (Δ) 03:27, 4 January 2012 (UTC)
@Multichill: It is the other way round: where did Eloquence get consensus to (try to) enable UW per default? --Saibo (Δ) 03:05, 4 January 2012 (UTC)

Upload Wizard, to-date, has been used to successfully upload more than 600,000 files, including more than 170,000 in Wiki Loves Monuments, with many thousands of new users uploading for the first time. In addition to being vastly more user-friendly, it has many features that aren't included in the standard upload form, including multi-file selection / multi-file licensing / multi-file description editing; geo-data extraction; support for upload campaigns; more understandable licensing instructions. Its usability has been tested repeatedly in both lab tests and online tests with new users. It's also been compared with the old upload forms, which are regarded by new users as horrible manifestations of evil.

So, it's the right default. It links to the old form, as well, and falls back to a simple upload form if no JS is available.

When we compare making UW the default to not doing so, we have to take into account that not doing so is likely to lead users down a path they'll find confusing, that'll be less efficient for many cases, in short, that'll bear its own frustrations and annoyances. Moreover, the old forms have both known and unknown bugs, and some of the bugs in UW are in features that don't even exist in the old forms.

With that said, although it may seem that WMF has tons of resources to throw at problems like this, we're as always very stretched thin. I'd love to have a team of 5 people working on nothing but media uploads, but our current engineering resources don't allow for that. So, while I'm happy with the quality of the product overall, it would have been great if we could have smashed through bugs faster, and I understand the frustration with breakages over the last few months. It's also the case that UW's tests aren't yet integrated into our continuous integration server, which would help surface issues and regressions more quickly.

That means that in practice, folks like Saibo and Rillke have done lots of the testing and reporting of issues which -- in a better world -- WMF would have surfaced well before deploying code. I'm grateful for that, in spite of the occasional snarky or aggressive remark.

Thanks in part to their help identifying issues, UW today seems generally pretty mature. There are only four bugs left with severity "major", and one of them is arguably an enhancement request. (If other bugs deserve the "major" severity, please say so.) The rate of feedback about broken uploads has slowed down significantly, while UW's built-in feedback system generally leads to problems becoming visible quickly. The arguments for not sending users there directly in any language are IMO pretty weak.

From anyone who has reservations about UW that aren't fundamental, I'd love to know what the main bugs or wishlist items are that they'd still like to see addressed before they feel that they can wholeheartedly enjoy using it. While it may take us a while to work through all of them, my goal is for the uploading process to really become more and more user-friendly over time.

I know my own mental wishlist: 1) fixing remaining browser issues (either by blacklisting broken features or repairing them), 2) supporting simple batch-application of metadata, 3) fixing remaining upload errors/API issues. What's yours?--Eloquence (talk) 08:43, 4 January 2012 (UTC)

Woohooo! Be aware: "we have to take into account that not doing so is likely to lead users down a path they'll find confusing, that'll be less efficient for many cases," .... Why? What is wrong with the decision the users can do at Commons:Hochladen? I do also recommend the UW for newbies - but I tell them that they need to be aware that it can fail, contain bugs or be just not suited for their usecase. I would like to see the UW gadget as a non-default gadget for those users who want to always upload with UW (knowing through the gadget's description that they use a alpha/beta version).
You're asking for a wishlist? Do a redesign of UW and bring it back to where it should be - inside the wiki with us rather than this WMF-pushed foreign object. In the meantime you could fix the big buglist. --Saibo (Δ) 15:10, 4 January 2012 (UTC)
Hi Saibo,
1) Whenever you introduce additional decision-making complexity into a piece of software, you lose users in that complexity. The problem is that a user is not a machine. That is, they will not robotically review the entire page they're looking at, weigh different options against each other, and then choose the "correct" option. Instead, they will scan the page for cues which will allow them to complete the task they were looking to accomplish. This means that if their eyes happen to first track "my own work" and not "assistant for uploading files", that's where they're going to click without further thought.
Even if they notice both options, they're not going to necessarily be in a position to consciously evaluate them against each other. Similarity and ambiguity of different options always causes confusion. That's precisely been an issue that's been hitting us in the uploading process again and again (even in UW if you remember the "Free Art License" problem). You know all about how users are willing to just click through the fastest apparent path to upload a file, so I'm surprised you seem to think that adding decision-making complexity is a good idea.
2) You also know very well that the bulk of MediaWiki's code isn't JavaScript or accessible beyond the version control system. This includes essential elements of the upload code, e.g. the upload API which provides all the functionality utilized by the various upload forms. So to characterize a piece of software as "foreign" just because it's not a gadget is simply incorrect. Indeed, even complex JavaScript gadgets are sometimes managed through version control because it's a more suitable way to keep track of changes (cf. Twinkle's GitHub repository).
Would it be a good idea to attempt an UW-to-gadget port? Perhaps, and you're welcome to give it a try, although there would be many technical considerations. Even if such a port was fully successful, you'd likely want the code to be in version control regardless, and you'd likely want to distinguish between an experimental/staging version of the code, and the current default-deployed version. Moreover, you'd want to have test-runners perform unit and integration tests as code is committed, report test results against specific revisions, etc.
All this could be accomplished within the current model. It might be nice to shortcut the deployment cycle by having an on-wiki hosted version at least of the experimental codebase, but we could, for now, simply set up an automated code push to a staging environment. The barrier to directly participating in development isn't very high. You simply request commit access. In future, we'll be using git, which will make it easier for any user to push code changes for review.--Eloquence (talk) 18:02, 4 January 2012 (UTC)
There is no question: Upload Wizard has been improved. Thanks for that.
And you are right saying that lots of bugs are caused by the new features. But this is no excuse. If an uploads fails due to such a buggy feature, you don't have won anything. Upload Wizard is nice and has potential but the old upload form is robust.
Just to give you an example (don't know whether this is still an issue): Upload the maximum number of allowed files, choose custom license for all uploads, describe and hit publish. Now it is very likely that your browser becomes unresponsive for some time.
While multiple-file-upload is a feature, if the upload fails and images+categories+descriptions are lost for lots of files, it is more and issue than if it fails for only one file. And I saw users, e.g. Nevit who uploaded some 50MB-files and then upload wizard hang up while publishing.
This is my current view on the things and I am happy to correct it. -- RE rillke questions? 15:31, 4 January 2012 (UTC)

New UW version deployed (Multi-file selection and more)

With multi file selection, custom license and "internet file" license. Please discuss at Commons:Village_pump#Multi-file_selection_and_more_for_UploadWizard for needed Commons process changes. Cheers --Saibo (Δ) 01:00, 11 November 2011 (UTC)

Now (Saibo (Δ) 15:13, 25 November 2011 (UTC)) copied form Commons:Village_pump/Archive/2011/11#Multi-file_selection_and_more_for_UploadWizard to below:

VP section

We have a few new features we're working on in UploadWizard. Please help us test them!

Multiple file selection. In browsers which support it, you can now select many files from your filesystem at once.

By multiple file selection, we mean you can press the "Select a file to donate" button, then select a lot of files from your computer, and they will be all added at once. Unfortunately, we had to turn off the instant file preview when you do this, because it was just too slow, and that work can't be put into a 'background' task, with the current generation of browsers. You can still get a preview for individual files by clicking the preview button. Kudos to Raindrift for leading the development of this important feature!

Custom license You can enter a custom license for your files in wikitext.

We're trying to mitigate a number of problems here. The main one is that we don't offer enough choice, for people who need a different license. But, we also don't want to give naive users another way to do the wrong thing (they are magnetically drawn to picking the option that we explain the least -- at the moment it is the Free Art License). There is also a less frequent problem where users go crazy and just click multiple checkboxes to multilicense everything.
So, several changes have been made: a "trap" has been reintroduced. If the user does nothing, it tags the file as Uploaded without license. A field for custom wikitext has been added, but it won't allow you to type random stuff; it tries to figure out if the wikitext you have entered really is valid, and if it contains a template that really in a subcategory of License tags, before publishing. (This won't work for all licensing tags used on Commons -- some people use stuff in their personal namespaces that invoke other templates -- but this is the best I can do for now.) And finally, the wizard now only allows you to pick one license at a time. If you need multilicensing you can use the custom wikitext box.
A question: sometimes we can determine that the wikitext is syntactically valid, but we're not sure it has a correct license. So perhaps we should submit it with problem tags. What problem tags, if any, should be added?

Geocoding If your photo has location information, the Wizard will now try to write geocoding templates for you. You have the option to change the latitude and longitude information before submitting.

Maplebed really wanted to see this feature, so he took the lead hacking this together at the NOLA hackathon. Jeroen De Dauw did some cleanup work. Right now you only get input fields for latitude, longitude and altitude, but we really want to see a map-based interface, more like this spec for geocoding in UploadWizard. Volunteers welcome!

Some of these features still require polish and bug fixes, but we wanted to get your feedback on them now. We are also having some other issues with the test server which may make page loading slow. Please bear with us. I'll be updating it continuously based on your feedback and as I fix stuff.

Check it out at the UploadWizard prototype wiki.

NeilK (talk) 20:11, 4 November 2011 (UTC)

These are very good news. Thank you! What do you mean with "sometimes we can determine that the wikitext is valid, but we're not sure it has a correct license"? Why you are not sure? Is the selected template not in category license-templates or a common misused license template or ...? Sincerely -- RE rillke questions? 20:34, 4 November 2011 (UTC)
The lookups are done with API requests, and for various reasons I have to stop the user from progressing while it does these checks. So for UI reasons that sets a maximum possible delay, maybe 30 seconds or so. And it is possible that the API requests will not complete. Or, that it will not find its way up to "License Tags" within five hops (that's the maximum depth I allow). Also, there is the case I mentioned earlier where the wikitext entered into the form doesn't contain any template under License Tags, but somehow generates it anyway. I am only doing a "shallow" parse here, not a deep one. That said it should work for wikitext like {{Eso}} or even {{free screenshot|license={{BSD}}}}. -- NeilK (talk) 23:06, 4 November 2011 (UTC)
Except, there's a bug where I accidentally normalized the template title, so "BSD" doesn't work -- it is looking for "Bsd". I have to fix that... NeilK (talk) 23:17, 4 November 2011 (UTC)
Is this feature perhaps trying to be too smart? As far as I can tell, there are basically two groups of users: the ones who know nothing about licensing or templates, and who just want to upload, and the ones who know what template they want to use. If we implement just a check for whether a template -- any template or transclusion -- is added to the form, wouldn't that be sufficient to deter most misuse, while retaining maximum flexibility?--Eloquence (talk) 23:56, 4 November 2011 (UTC)
Yes, this is the point of the question I posed to the community above. I'm going to relax it a bit. It might be better to allow anything that seems to be valid wikitext that has at least one template. But we do a secondary check with a simple parser, and if we find that there is a valid license, then great. If not, then and only then do we add a problem template. -- NeilK (talk) 01:07, 5 November 2011 (UTC)

Well, guys, the new UW version is live without any new or adjusted processes here in Commons (or am I missing something)? I am not really happy about this - but, well, WMF decided...

Btw: here is a list of currently open bugs - those errors are already known. → no need to report again.

{{subst:uwl}} is added by UW for files without a license and {{Custom}} is added for files which were uploaded with a custom license template.

  • 1: do we fully trust Nikbot to tag files without licenses or do we directly want to insert something in template:uwl (which gets substed on uploads by users who select the "internet file and I have no clue of COM:L" option? We could redir uwl to {{Nld}}. Or: do we copy nld to uwl but add a template which informs the user how to help himself? Read COM:L, provide all information about author's date of death or publication he can find? Ask at Help Desk? Or write his questions directly on the file page?
  • 2: should custom license files be tagged in any way (for review?). I think not. We do not have the manpower to do additional checks. I do think that the custom license files are not high risk like the files without license (because I guess this will be the option of all FAL uploaders now). And: we should rather try to check (whatever such a check should include/how deep it will be) all files by non-autopatrolled users (at some day in the future). So my answer to "2" is: no tag needed. What do you think? Cheers --Saibo (Δ) 00:41, 11 November 2011 (UTC)
  • 3: if we would pull Category:License-related_tags out of Category:License tags (→ not anymore a subcat) Upload wizard wouldn't accept this custom license anymore: "{{own}} foobar". Also semantically useful: License-related_tags are simply no license tags. Maybe we make a new supercat for both: Category:License and license-related tags. Does anybody see problems? Cheers --Saibo (Δ) 03:12, 11 November 2011 (UTC)
    • 2: Currently we haven't the manpower but it's not bad if they have a tag. It is also interesting just to see, whether this option was used. Some piece of information that is not evil. -- RE rillke questions? 11:04, 11 November 2011 (UTC)
    • 3: For the tools at all it would be the best if we would add an additional category to all real-license-templates. Then, no recursion would be required. -- RE rillke questions? 07:30, 11 November 2011 (UTC)
      • Thanks for your comment Rillke!
      • 1: I think the nld template (+its use talk page notification tmpl) is sufficient. In addition, for statistics or tracking (Catscan?), we should insert something in uwl - the question is what? {{uploaded with initially no license|yyyy-mm}} which would display nothing but only contain a hidden cat Category:Uploaded with initially no license yyyy-mm? So we could catscan (negative cat "Copyright statuses|5") after a month to look if there are files which were not detected by nikbot. The question is: who does it? ;-) Anyway, even if no one does it - the possibility would be there. Disadvantage: those templates need to be removed at some time in the future. n.b.: {{ImageUpload|full}} (which we still see in file desc. pages today...). ;-)
      • 2: ✓ Done Yes, having categories or tags for statistics would be nice. currently we have 11 "custom licensed" files. But ASA the template is removed by whomever the information is gone. Since we have (and probably will not have) no review process I think it would be best if the template just contains a hidden category. That way it gets not removed too early. If we decide one day that we want to clean up all file pages we can run a bot to kill it everywhere. But having not really useful clutter on the file page (and a uploader who is, maybe, waiting for his file to be reviewed is not useful).
      • 3: Yes, sure. A flat cat would be best. Do you think it is manageable? It is already hard to have all license templates somewhere in the current cat tree there. ;) Are there lic. templates in Category:License tags (except the l. related templates) which are not "real licenses"? I had a quick look: Except the subcat "Category:Translated license tags‎" and "Category:License tags non-free" (although this would disable the WMF copyright tags) I would say that all should be accepted. Leaving those two categories in is no big harm, I would say. For UW the traversing parser is already written - for other tools maybe we could make a bot-updated plain list of all tags in Category:License tags for easier checking? Otherwise most license tags need to have one additional, redundant category. Do you agree to pull out the Category:License-related_tags? Cheers --Saibo (Δ) 15:00, 11 November 2011 (UTC)

Location template and geo entry boxes

Split from #VP section above

So many changes to be discussed in one section? Very well. The multifile picker was pleasant when it worked yesterday. Today it didn't but it's no big loss. The geotagger is definitely a big improvement because it works immediately. Like the old daily bot geotagger it often fails to find the locations in my image files added or adjusted by Picasa that MS Pro Photo Tools and Google Earth can read, but better to know it sooner than later. Jim.henderson (talk) 16:52, 12 November 2011 (UTC)

Tested it on prototype. Minor points:
  • {{Location}} should be added below {{Information}}, not above.
  • The longitude / latitude fields only accept points as separator of decimals. In France (at least), we use the comma. Maybe this should be considered valid as well and replaced at upload time.
Jean-Fred (talk) 14:37, 15 November 2011 (UTC)

COM:OTRS and subst:OP

The UW misses a option pointing to COM:OTRS and placing {{subst:OP}} on the file. The good old upload form has it. Do you agree that this option should be added in the "not own work" section? Cheers --Saibo (Δ) 00:26, 23 November 2011 (UTC)

A campaign for enterprises would be a possibility. I've often seen them uploading product photos (good ones) but they did not know about OTRS and therefore the talk-page was spammed immediately or nothing happened because no one was patrolling the new files. The problem is how to populate this so it is used. After creating an account, where do they click? Or do they come from Wikipedia? Making OTRS an option is also possible. However, we have to be careful to prevent abuse. -- RE rillke questions? 10:41, 23 November 2011 (UTC)
Well, the upload option Es stammt von woanders did also work. ;) It just mentions the OTRS and subst:OP on top of a text box. As UW already offers to upload "not own work" it should also supply the correct tools to do it right without getting spammed with no permission since notices.
Currently there is only "Der Urheberrechtsinhaber hat dieses Werk gemäß der richtigen Creative Commons-Lizenz lizenziert". But we need an option "Der Urheberrechtsinhaber möchte dieses Werk gemäß der richtigen Creative Commons-Lizenz lizenzieren und wird dazu eine E-Mail an mailadressse@example.com senden. Zu beachtende Anleitung: COM:OTRS/de"
Of course, again, we have the problem that UW is not for Commons but is a MediaWiki extension which doesn't allow such process specific notes. This is a design mistake. --Saibo (Δ) 15:37, 23 November 2011 (UTC)
Options with additional templates could be added in localsettings.php. Such as "and follow COM:OTRS/de" is more difficult. -- RE rillke questions? 15:59, 23 November 2011 (UTC)

Will the OTRS mail and link be added to the UploadWizard? --WikedKentaur (talk) 08:50, 10 February 2012 (UTC)

It should be - but we are locked out, we cannot change most parts of upload wizard. Only Wikimedia can. --Saibo (Δ) 14:35, 11 February 2012 (UTC) Added to bugzilla: bugzilla:34332. --Saibo (Δ) 14:49, 11 February 2012 (UTC)

Comments at the bug (or here id you do not have a bugzilla account) are welcome!. --Saibo (Δ∇) 11:47, 6 June 2012 (UTC)

Upload wizard - community hackers edition

What about simply copying UW's js code (or parts of it) to our MediaWiki namespace (maybe not now - but later when it is a bit more bug free) to get back control over our software? ;-) Wouldn't this work? The restricted way of UW is annoying. --Saibo (Δ) 15:37, 23 November 2011 (UTC)

If we manage to assemble all the script-pieces and find maintainers, yes. But I fear we don't have enough volunteers. Otherwise multi-file upload would have been available before. Something we could take into consideration is just injecting some code; such as "set all descriptions to"... "add a category to all uploads"... "don't have to hit save to add a category that was entered". This should be possible right now with gadgets. -- RE rillke questions? 16:05, 23 November 2011 (UTC)
Despite the convenience, I don't think it's a good idea to keep large quantities of code in wiki pages. Anyway, it's not clear to me that the problem is the location of the code. If you have someone who can write JS and/or PHP they can also commit to the repository, and if you tag it for review by me or raindrift I don't see why it wouldn't be deployed soon. As Rillke states, you could also develop some gadgets and if they could ultimately be brought into UW. I know that Eloquence in particular would like to see that feature done. NeilK (talk) 00:55, 29 December 2011 (UTC)
"code in wiki pages" - why not? Otherwise the code if off-wiki and not changeable by us but pushed with WMF's interests. Cheers --Saibo (Δ) 01:08, 29 December 2011 (UTC)
Well, neilk is not a dev anymore (IIRC) - 109 bugs are open. Where does upload wizard go to now? And: we cannot add the needed OTRS hint. --Saibo (Δ) 14:59, 11 February 2012 (UTC)

"Upload this file without copyright information for now. I understand this file may be deleted."

The Upload Wizard fails to give any sort of notice that uploading non-free files off the Internet constitutes copyright infringement, is illegal, violates Commons policies, and may lead to the uploader being blocked. Some users are demonstrably interpreting the option to upload files without copyright information as a green light to do so repeatedly and let "someone else" sort it out for them. That the file may be deleted is obviously a risk they can live with. The copyvio warnings that these users inevitably receive as a result of taking this risk then seem unreasonably harsh, even though they simply reflect the law and Commons policy.

I understand the temptation of having an option that attracts those who are determined to upload files without caring about whether they're free or not. I understand the reluctance to make that option "too" discouraging for fear that determined copyvio uploaders will pick other, less identifiable options. However, the current wording misleads well-meaning but uninformed uploaders into thinking that they have no responsibility to ensure that their uploads are legal, that Commons has unlimited resources to deal with these files, and that uploading such files has no consequences.

This obviously needs to change. —LX (talk, contribs) 18:17, 24 November 2011 (UTC)

I agree that the wording / instructions in UW need to be improved. However, as you can see in #COM:OTRS_and_subst:OP changing stuff is not very easy. Suggest a wording and if we are luck we can have it in UW in some weeks. ;-)
In addition: Maybe you have some ideas to improve at least the {{Uwlsubst}}? As I see from some COM:HD sections (those with the "copyright help regarding" sections) at least a part of the uploaders reads the template which directly is on the file page after upload. Cheers --Saibo (Δ) 15:21, 25 November 2011 (UTC)
Suggested wording for "no information" option: "Upload this file without copyright information for now. I understand that this file will be deleted if I do not provide the required information. I understand that uploading non-free content to Commons constitutes copyright infringement and is grounds for blocking." I actually think {{Uwlsubst}} is quite good. It probably just needs more translations. —LX (talk, contribs) 15:50, 25 November 2011 (UTC)
Every uploader is already forced through a comic strip tutorial that explains what's acceptable and what isn't. If an uploader is going to ignore that simple presentation, it seems unlikely they'll follow along some text next to a radio button. The people we're most trying to stop are likely simply clicking through any option that allows them to get through (we see this all the time in user tests).
On the other hand, adding further instruction creep to the interface is a temptation we have to resist unless it is unavoidable. Where text keeps getting longer, it adds perceived weight and complexity to the user experience for all users. This incremental addition of instructional weight led to the usability nightmare of the old upload forms. Similarly, adding language like "grounds for blocking" is language that will have to be seen by all users, and changes the emotional tone of the user interface. Where right now the user experience emphasizes thanking the contributor, this would add an emotional tone that could be perceived as hostile and threatening by good faith contributors.
I agree that the "may be deleted" language is too weak, and I would suggest focusing simple improvement on that point. How about: "Upload this file without copyright information. I understand that this file will be deleted if I do not provide copyright information later."--Eloquence (talk) 22:54, 28 November 2011 (UTC)
"Upload without copyright information because this file is assuredly compatible with Commons' licensing. I notice it will be deleted if I do not provide copyright information immediately after uploading." -- RE rillke questions? 23:15, 28 November 2011 (UTC)
The comic strip is of course overly simplistic. (It states that works by others are accepted "with two main exceptions." This indicates that there are other exceptions, which are not mentioned. It also fails to mention images that are too simple to be considered copyrightable works.) There are many uploads not covered by the comic strip which are perfectly fine, while others are illegal and against policy. We don't need to explain the difference during the upload process, but we need to mention the importance of understanding the difference. Making the whole upload process overly simplistic only serves to deceptively hide complexity inherent in the problem domain. There is no use in making the "emotional tone" of the upload wizard more forgiving than reality. It needs to be made clear that uploading files without any idea of whether or not they are free (or what that means) is disruptive regardless of whether or not it's done in good faith. —LX (talk, contribs) 07:23, 29 November 2011 (UTC)

'donate' vs 'upload' - how to fix the uploadwizard text?

Current discusion → Commons:Village_pump#.27donate.27_vs_.27upload.27_-_how_to_fix_the_uploadwizard_text.3F --Saibo (Δ) 04:21, 5 January 2012 (UTC)

Archived: Commons:Village_pump/Archive/2012/01#.27donate.27_vs_.27upload.27_-_how_to_fix_the_uploadwizard_text.3F. I do not really see a conclusions - but someone might want to continue that discussion here (sending not to archive for now). Content copied to below. --Saibo (Δ) 14:54, 11 February 2012 (UTC)

Hi all. The upload wizard has a button which states 'Select a media file to donate'. This phrasing doesn't make any sense to me, since when someone uploads a file to Commons they're making it available as free content for anyone to reuse, rather than "donating" it to anyone or any organisation. So this phrasing needs to be changed, e.g. to "Select a media file to upload", or alternatively "share" or "release". I've tried to raise/address this issue multiple times via the feedback form [1] [2] [3], but this doesn't appear to be leading towards a solution.

Others have also raised this issue e.g. [4], [5], [6], [7], again without success. It also doesn't seem to be something that can be raised as an issue on translatewiki since that just tells me that "Translations to this language in this group have been disabled".

So, if the feedback tool, the mediawiki extension page or translatewiki aren't the best places to raise this ... is this page the place to raise the issue? Or is there a better page for this discussion? I've spent several hours trying to figure this out, but have yet to figure out which page this should be raised at in order to lead to a discussion and, ideally, a fix to the problem... So if this isn't the appropriate page, please could someone point me towards the right one? Thanks, and yours frustratedly.... Mike Peel (talk) 20:54, 4 January 2012 (UTC)

I think it could be kept here since Commons talk:Upload Wizard is not a very prominent place. Or you move it there and link from here.
The button must clearly tell the uploader that he/she makes the content freely available. -- RE rillke questions? 23:41, 4 January 2012 (UTC)
Yeah, that's the intent of the word "Donate". Although the nature of the release is stated several times, in general, in user interface design, it's good to employ redundancy in order to make a point clear.
But, I'm not sure the word "donate" really is that clear. We've never specifically user-tested it, as far as I know. A user could just as easily come away with the impression that they're donating a picture "to Wikipedia" as opposed to the public. Moreover, the user may upload files which have already been "donated", which makes it somewhat awkward.
So I'd be fine with changing it to "upload" if folks feel that's generally preferable. We can think of other additional ways to bring the point across. Unless someone wants to design a scientific experiment to see whether it makes any difference, I'd say let's just run a quick straw poll to see what the Commons community prefers and change it to that.--Eloquence (talk) 01:11, 5 January 2012 (UTC)
"Publish freely"? - Jmabel ! talk 01:15, 5 January 2012 (UTC)
Donate could mean "donate [certain rights] to the public" but I doubt anyone would think that instead of "donate your media file to us" so it's misleading at best. In many cases it's simply incorrect as people upload other's work, public domain, and their own work that has been previously licensed (donated publicly). Likewise they can't "publish freely" or anything other than upload/add files if they're not the rightsholder. (Rocket000 (talk) 03:36, 7 January 2012 (UTC)

"Donation" is an extremely misleading term, which chapters are also avoiding to use when defining partnerships with institutions, for countless reasons: see for instance "[ cultural-partners ] 'donations' vs. 'partnerships'", where I wrote «When I saw the language on the UploadWizard I was quite shocked. Funnily enough, I was told that the Upload Wizard had that strange word by a person who works in a cultural NGO which has a cooperation with WMI[T] [8], while I was helping her to make her first edits on wikis». "Share", proposed above, keeps the point (they're not private uploads, they're shared with the public) and lets translators choose the best fit for their language, which – we must consider – doesn't always have a good equivalent. --Nemo 08:35, 15 January 2013 (UTC)

Filed and patched with bugzilla:43984. --Nemo 09:13, 15 January 2013 (UTC)

PD-old files via UW

Currently it is not possible to upload PD-old-70 works via UW (except if you use the custom option). This should be changed!? Please comment at bugzilla:34531. I would like to disengage there. Cheers --Saibo (Δ∇) 12:00, 16 May 2012 (UTC)

What about works created before URAAAAAAAAA was adopted? Do you really want to tell the user all this difficult stuff? (How to find out whether copyright was renewed in the U.S.?) Or are there facts / changes, I am not aware of? -- RE rillke questions? 13:35, 16 May 2012 (UTC)
I am not talking anywhere of URAAAA, do I? I am not adopting URAA. I just want to enable users to upload based on non-US laws of the source country. Currently the laws of the source country are totally disrespected. I think someone (Magog?!) had developed a PD-chooser template - of course we could ask a load of questions (when first published, where, what was the name of the dog of the author, author's shoesize?)... but I wouldn't recommend. I am not URAA fan. ;-) Cheers --Saibo (Δ∇) 22:41, 16 May 2012 (UTC)

Watch uploads?

→ COM:VP#UploadWizard auto-watch feedback -- RE rillke questions? 17:44, 12 June 2012 (UTC)

UploadWizard not working

Hi. Could someone look into this please? Thanks. Rehman 10:40, 29 July 2012 (UTC)

Derivative works

The current wizard deals with only two extremes: items that are entirely your own work or entirely someone else's work. There is no option for derivative works i.e. works you have modified from someone else's work. There already is a tool, derivativeFX, that can cope with such uploads where the original is on Commons. The old uploader, Commons:Upload, would send you to derivativeFX in the appropriate circumstances. Could the new uploader ask the appropriate question and redirect to derivativeFX?

As it is, users are asked a question, neither of the possible answers they are given ("This file is my own work" & "This file is not my own work") is correct, and then they probably haven't a clue what they should do next. At the very least, there could a third option "neither of the above" that takes you to the old uploader. -- Dr Greg  talk  15:01, 12 August 2012 (UTC)

passing parameters from other projects

I am looking at adding an upload button to Image Requested template on English Wikipedia, see en:Template:Image requested/sandbox. Need a little advice on passing parameters through for description and categories. First what is the best way to get square brackets around the description for a link and secondly what is the delimiter when wanting more than one category? --Traveler100 (talk) 11:39, 1 October 2012 (UTC)

mw:MediaWiki:Upload Wizard#Usage. No developer of UpWiz is watching this page AFAIK. -- Rillke(q?) 14:00, 1 October 2012 (UTC)
Thanks, but that is not a particularly heavily used page, so who will be watching that?

Upload Wizard incorrectly marks file as uncategorized

I uploaded File:Nikolai II Hietalahdessa Verkkokaupan näköalatasanteelta.JPG with Upload Wizard after having problems with the old upload form. Despite having multiple correct categories the image has been marked as uncategorized. I was too lazy to select categories one at the time, so I simply pasted a list of categorylinks into the "other information" field. Upload Wizard should check if the file is actually uncategorized, not simply check if the user filled the category field. (crossposted from Village pump). MKFI (talk) 14:10, 8 October 2012 (UTC)

To avoid that, I often paste categories into the last line of the description, and return next day to add more categories and group them all at the bottom of the page. As seen in File:Fresh Pond Terml 68-01 Otto Rd jeh.jpg and others. Jim.henderson (talk) 03:29, 10 October 2012 (UTC)

PD-Art-related changes

Please see Commons:Village_pump#Upload_Wizard. Rd232 (talk) 22:00, 5 December 2012 (UTC)

Time to test chunked uploading again

See [Commons-l] Time to test chunked uploading again. --Nemo 06:10, 9 January 2013 (UTC)

Seems broken

The wizard seems broken. Sort of. I choose files to upload, input details, and most come out something along the lines of

Bath_Spa_railway_station_MMB_07_158957.jpg
[api-error-internal_api_error_UploadStashFileNotFoundException]

They still upload (well, one didn't, and refused to when retried) but... -mattbuck (Talk) 04:16, 12 January 2013 (UTC)

Just out of curiosity, are the files that failed in Special:UploadStash? -- Rillke(q?) 13:14, 12 January 2013 (UTC)
There are two files there, but neither will open for me.
New day, new error, I'm now getting "Internal error: Could not determine if the copy succeeded." Also the ever-informative "An unknown error occurred." All files uploaded though. -mattbuck (Talk) 18:10, 12 January 2013 (UTC)

Filename in use

Suggestion - don't cache filename checks. Currently, if you want to upload to say XYZ.jpg, and XYZ.jpg exists, it reports an error and tells you so. Then you delete XYZ.jpg, change it to upload to XYZA, then back to XYZ, it still reports that filename as in use, even though it now isn't. -mattbuck (Talk) 18:12, 12 January 2013 (UTC)

PD-art & the Wizard

I've been using the {{PD-art}} licensing template quite a bit, and it's one of the options using the Upload Wizard. However, PD-art needs additional information (cf. {{PD-art|PD-US-not renewed}}, and files that I upload using the Wizard and this license option end up with licensing flaw notices in red and boldfaced letters. I imagine that other uploaders often fail to fix the problem, and diligent administrators have deleted my files before I could make the needed modification. I'm not sure what the right approach is for the Wizard, but I wanted to mention the issue. Easchiff (talk) 10:14, 2 March 2013 (UTC)

"own work"

The following discusion has been moved here from Commons:Village pump.

It's a pretty well known issue around here that uploaders are woefully misinformed when it comes to the subject of "own work". Well, many are misinformed, some just don't care and upload anyway. It's the first group I suggest we try to further inform and maybe cut down on all the incorrectly attributed "own work".

I propose on the Upload Wizard (release rights tab) we add the following after "This file is my own work":

This file is my own work. (Own work means you took the picture, you painted the painting or you drew the drawing. Photocopying or scanning a picture is not "own work". Copying and/or editing a picture you found on the internet is not "own work". The simple act of uploading a picture to Commons is not "own work".)

Granted, my text may viewed as a little testy, so I'm open to making it a *little* more friendly.

– JBarta (talk) 21:06, 13 March 2013 (UTC)

You've identified the problem with phrase "own work". Perhaps a less ambiguous statement altogether would be better, such as "I created this file from scratch" (I think this idiom is the shortest way to convey this meaning in English; it can probably be said as concisely in other languages). Though this may be confusing for photos because there is a disconnect between "taking a photo" and "creating a file from scratch", even though that's what you're doing. There are a huge number of files uploaded as "own work / CC-BY-SA 3.0" - it seems this is the closest the Upload Wizard comes to having a "default" --moogsi (blah) 22:35, 13 March 2013 (UTC)
I think it's not enough to state what "own work" or "from scratch" is... we must also state what it is not... based on what uninformed uploaders end up uploading and why they think it's their own work. – JBarta (talk) 22:45, 13 March 2013 (UTC)
I find Jbarta's phrase clear and explicite - perhaps not very friendly, but clear, and easy to translate in other languages, which would probably not be the case with "from scratch". Also, about photos, there is a distinction to make between "taking a picture of a scene, people, animals, flowers, etc.", which is "real creation", and the mere reproduction of a 2D artwork (that fall under {{PD-art}}.
also, in the case of artwork, it would be necessary to specify that "Author" is the author of the artwork, not the photographer (even less the uploader) - the photographer should be placed in "Source" - Hundreds of thousands of picture are wrongly attributed - sometimes, the original artist is not even cited in the description (which is not a concern for Leonardo da Vinci or Van Gogh, but is much painfull for less well-known hungarian or chilean painters (I have nothing against these or those, just had to correct dozens of files where they were the right author).--Hsarrazin (talk) 22:54, 13 March 2013 (UTC)
I think this is a separate issue, too complicated to explain in the UpWiz... the ideal situation would be some kind of expert system which asks a series of questions of the uploader and pick the right license/s for the media. 19th-/20th-century artwork is horrendously complex when it comes to licensing. I'm not suggesting we can make an automated Stefan, but it could definitely be a bit smarter, instead of expecting the user to read and understand everything. --moogsi (blah) 23:10, 13 March 2013 (UTC)
“I'm not suggesting we can make an automated Stefan” → :DD --Jean-Fred (talk) 23:50, 13 March 2013 (UTC)
"Expert system" would be nice of course. But until such a thing is implemented, I think a simple low-tech solution would be very useful. A great solution is better than a good solution and a good solution is better than no solution. – JBarta (talk) 23:19, 13 March 2013 (UTC)
I suggested "from scratch" because you don't have to state what it doesn't mean. "I created this file from scratch" is false if anyone else had anything to do with the creation of the file. That's not true for "This file is my own work" → "well, I did some work". Special:Upload uses the phrase "entirely my own work" which is less ambiguous. I can't look at what the Upload Wizard says exactly, it's not cooperating with me right now :) Maybe what we want people to declare is something like "I created this file entirely by myself", which is not idiomatic. --moogsi (blah) 23:00, 13 March 2013 (UTC)

As an alternative to my initial suggestion, maybe a bulleted list of blurbs directed at the most common "own work" attribution errors...

  • In the case of a photograph, own work means you took the picture.
  • In the case of a painting, own work means you painted it.
  • In the case of a drawing, own work means you drew it.
  • In the case of music, own work means you composed it.
  • If you photographed or scanned an image that you did not personally create, it's not your own work and the author is whoever created it.
  • If you found a picture on the internet, it's not your own work and the author is whoever created it.
  • If you found a picture on the internet and edited it in some way, it's not your own work and the author is whoever originally created it.

– JBarta (talk) 23:15, 13 March 2013 (UTC)

  • "If you found a picture on the internet and edited it in some way, it's not your own work and the author is whoever originally created it." Not quite. It is a derivative work. If the original was in the public domain, then you would be the only rights-holder. Similarly (for example) for a photograph of a sculpture that is in the public domain. - Jmabel ! talk 00:21, 14 March 2013 (UTC)
I was thinking of someone grabbing a photo of Nicki Minaj, cropping it, then thinking it's their "own work". Somewhere between my blurb and your correction is a statement that will work. I just can't think of it at the moment. – JBarta (talk) 00:36, 14 March 2013 (UTC)

Won't change anything at all, 'own work' is the path of least resistance for everyone trying to skip the crappy interface and TLDR rubbish. Pretty much any improvement that could be made won't be made. Ideas for effective solutions have to be taught to a disinterested crowd here who don't care at all about crowd dynamics and if you do teach them successfully they'll take even LESS interest in supporting it as a result. The best thing to do is see if you can go get another several hundred thousand dollars to implement your own version through the WMF grants. It's trial and error at what, $400,000 a pop ? and there will be the statistics after each change to support using the least crappy until they get it in their heads that no improvement is possible or they find some other way to squander the oversupply of cash.

Pointless discussing it here because it can't be edited from here. Penyulap ☏ 02:54, 14 March 2013 (UTC)

Where (if anywhere) would you suggest discussing it? – JBarta (talk) 03:21, 14 March 2013 (UTC)
I shudder to send anyone into the doldrums of the meta and mw projects, and I can't see it would do any good either. I'd predict that the idea would pretty much die in the ass because it's a designated gravy train, so plantation slaves will be kept off it by greedy pigs. I guess you can counter the depressing things you can't fix by fixing the things that you can. It's programming anyhow, not editing. On a side note, I often make half hearted attempts to study programming, so as to replace the broken projects the same way I draw so easy now after learning that. I guess it's knowing which mistakes are built to last. Like the way en.wiki is poisoning editing for thousands of new editors every month/year, they'll be put off the dream for life and even a new project won't get them back into it. Penyulap ☏ 03:46, 14 March 2013 (UTC)

Well, I've moved this here and I have a feeling this may be the end of it. "Die in the ass" as Penyulap says. As much as I'd love to see a few issues fixed/improved around here, I'm not one to force a horse to drink or help those who don't wish to be helped. To those who have access to the Upload Wizard... the suggestions are here. Use them if you wish. Good night and good luck... – JBarta (talk) 21:28, 14 March 2013 (UTC)

  • I disagree, we don't need more instructions for new users. We had a wall of text before and no one actually read it. We have a serious problem with instruction creep and also one with intuitive workflows. This problem is so bad that the WMF had to force it upon us and from here, that's not actually a bad thing. Mono 02:58, 15 March 2013 (UTC)
A "wall of text" is not the same as a few concise and targeted instructions to deal with an arguably serious problem. That said, I get what you're saying. But somewhere between nothing and "wall of text" might be a useful solution... probably better than the nothing that exists now. – JBarta (talk) 03:10, 15 March 2013 (UTC)

How many times do we have to have this discussion ? It comes up about every year or so. "We should educate more". The people don't care. And the only result of stonewalling them with informative text is that everyone thinks "what an unpleasant upload interface, I'm going to flickr/FB/Instagram etc". No, what we actually mean to say here is that we as a community are too lazy to do the cleanup after those of the community who do not yet understand or do not want to understand. Well tough luck, you will never get rid of the maintenance and if you don't want to do it, then don't. The better solution here is always to enable those who DO understand and do want to do maintenance. So building better tools, filters etc. There are millions of people on Foursquare and Facebook who have no clue about how to maintain locations, but those companies have build tools to enable the few idiots who do know/care/have too much time and it works surprisingly well. In terms of crowd sourced information, we are a lot alike with them. If we want to have public uploads, we will always have to do maintenance. If we want to stay relevant, we should be a welcoming community, so we don't decline. TheDJ (talk) 09:17, 15 March 2013 (UTC)

We should also be building tools to make it easier for uploaders to do the right thing in the first place. Throwing walls of text at them is off-putting, yes. But asking more detailed multiple-choice questions of uploaders than the Wizard currently does need not be, if appropriately structured so that irrelevant questions don't appear. For example, ask if it's "own work", and if the user says "yes", present choices on what kind of own work it is, together with a "not sure" option that will tag the upload so experienced contributors can have a closer look (giving a "not sure" option is better than encouraging uploaders to choose something that doesn't apply). Rd232 (talk) 12:56, 15 March 2013 (UTC)

License choice in preferences ignored

Tracked in Phabricator
Task T54611

A while ago I selected CC0 as my default license choice for uploads, and at some point it silently reset to CC-BY-SA, even though I still have "Own work - Creative Commons CC0 Waiver (release all rights, like public domain: legal code)" clearly selected in my preferences. Is this a bug or were the preference settings obviated at some point? Dcoetzee (talk) 05:59, 31 August 2013 (UTC)

At some point this fixed itself. I now see: "I, ____, the copyright holder of this work, irrevocably grant anyone the right to use this work under the Creative Commons Public Domain Dedication". As I noted a while ago, this text is incorrect - the CC PD dedication is a separate document from CC0 and not intended for licensing of one's own works. (The external link is correct, however). I'm not sure how to fix it. Dcoetzee (talk) 23:38, 5 September 2013 (UTC)
  1. It didn't fix itself. Things tend to never fix themself. I thought you would see the bug number… Yesterday 18:42, Reedy deployed the patch to the WMF cluster.
  2. Suggest a new wording at translatewiki:Thread:Support/About_MediaWiki:Mwe-upwiz-source-ownwork-assert-cc-zero/en, please or submit a patch against the UploadWizard i18n file directly. -- Rillke(q?) 09:11, 6 September 2013 (UTC)
I submitted gerrit:83567. Turns out that "Public Domain Dedication" is the official title in the deed, though not in the legal code, so we can only add "Zero" to clarify the name. --Nemo 22:05, 9 September 2013 (UTC)
Sorry, I wasn't expecting a fix that quickly. Thank you for looking into it. You're mistaken regarding the deed - the official title is "CC0 1.0 Universal". The subtitle "Public Domain Dedication" is a descriptive term and is not part of the official title, nor is it generally used to refer to this license (that is to say, the "CC0 1.0 Universal" is a "public domain dedication" but that is not its name). I mention this because it's important to avoid confusion with the Public Domain Mark and the Public Domain Certification, both of which are CC tools distinct from CC0. Dcoetzee (talk) 18:53, 10 September 2013 (UTC)

My broken Upload Wizard

Tracked in Phabricator
Task T56392
See also: Commons:Upload help#My broken Upload Wizard.

Since August 18th I cannot upload files per Upload Wizard. The problem is, that I choose the file, the start uploading, then I see the minimalized photography. but there is no icony "Further" (or Go on - i don't know how it in English version but in Polish it is "Dalej") on the right side. So I stick by this moment and cannot go further with the uploading. Can anybody od You help and say what could be the cause? I reinstalled lately the Windows system on my notebook by it did not help for it. Lowdown (talk) 16:11, 20 September 2013 (UTC)

I have submitted a patch. It can take up to one month until it gets reviewed and deployed, unfortunately. -- Rillke(q?) 20:31, 20 September 2013 (UTC)
In the meanwhile you can use one of the other methods suggested at COM:UPLOAD. -- Rillke(q?) 09:01, 21 September 2013 (UTC)
Does it work now? -- Rillke(q?) 10:29, 21 September 2013 (UTC)

Possible future improvements

Hi! Even if I am one of the most active uploader of Wikimedia Commons, I started using Wizard upload just a month ago for the latest WikiLovesMonuments campaign... at the beginning I was a bit reluctant about it, but now I am totally in love with it, and I can hardly imagine how I made without it so far! By the way, I found out there are many little improvements possible: my point of view is realted to a user who uploads lots of files, so please keep that in mind...

  1. Knowing how many files I am uploading: when I select the files to upload there is no way to know how many they are, unless I count them manually (boring). It would be useful to have an automatic counter, i.g, if I am uplaoding 30 files I could decide pick up more files, if they are 49 already there is no reason to try. It could be something near the "Add new files botton", like "Uploading 39 files, 11 more possible"...
  2. Alert: the best part of the Wizard uploader is that you can let it work and do something else. It would be useful to have an alert when the upoload is finished and you are supposed to do something to go on, like a sound, a change of the color of the screen, or a java pop-up. This would be useful also at the very end of the session, when you can start a new one.
  3. Work it during the progress: it would be great you could already pick up licence, and start putting categories while it is uploading files, just like on Facebook albums. I know this might be a difficult improvement, and that it already gives problems in facebook uploads, so, you could keep that in mind for a beta version, maybe?
  4. Fixed categories: some users have a personal category of uploads, could it be possible on request to have it automatically added to new uploads? Otherwise I'll have to copy and paste it every time.
  5. Hot-cat facilities: you can find category exhistance only by the name. It would be usefull if there would be the possibility to navigate up and down the category tree like with HotCat, in order to always find the most proper category available.
  6. Copy undo: when you add descriptions and categories you can copy them from the first files. If you mistake, it would be really, really useful to have an "undo" option. For instance, I take great care about naming the files and sometime I accidentally forgot to deselect the option "copy title with automatic numbering"... as a result it takes me less time to start the uploads over again, instead of manually correct all the filenames one by one. Undo option would really help a lot, in case.
  7. Add bottons to top as well: after adding cats/descriptions, sometimes you have to scrool the list all to the end, sometimes you need not, so it would be useful to have the "continue" botton at the top of it too (now it is at the bottom only). Also, when you finish uploading it takes you all the way up: if you do not need to revise all the images, it will be useful to have the "Upload more files" botton at the top too.

Thanks! --Sailko (talk) 15:58, 5 November 2013 (UTC)

About 4., if it isn't too cumbersome for you, Commons:Upload Wizard/Editing#Custom tags and categories may be of help to you. -- Rillke(q?) 19:51, 5 November 2013 (UTC)
Thank you. I tried and it did not work :( Could somebody give a check please? Thanks! --Sailko (talk) 14:50, 6 November 2013 (UTC)
In File:Hans clemer, madonna del coniglio, 1490-1510 ca. 01.JPG, I see no second edit and I see [[Category:Photographs by User:Sailko]]. Is this not what you did expect? Does it not always work? -- Rillke(q?) 19:04, 6 November 2013 (UTC)
I've added that manually, as always.. Should I try not? --Sailko (talk) 12:13, 12 November 2013 (UTC)
I thought it was supposed to appear during the uploading process. It works! Thank you!! --Sailko (talk) 13:40, 12 November 2013 (UTC)

Think it should be easier to upload photos and videos from the context of the article page?

I'm working on an individual grant to improve this leveraging existing elements of the wizard to upload that is currently only accessible on Commons. Have ideas/feedback? Check out my proposal here: http://meta.wikimedia.org/wiki/Grants:IEG/Easy_Media_Uploader

Timestamp for archive -FASTILY 05:12, 5 June 2014 (UTC)

Translation

I can't find translation block for "The campaign editors functionality can be used to customize Upload Wizard for multimedia competitions like Wiki Loves Monuments and other purposes." sentence. Is it missed? Okras (talk) 19:36, 30 April 2014 (UTC)

Timestamp for archive -FASTILY 05:12, 5 June 2014 (UTC)

Licensing tutorial

Hi. I'm trying to translate to Danish. But that made me think of the naming of File:Licensing tutorial en.svg. Is this a tutorial of "Licensing"? Is it not more a tutorial about FOP and DW and not about which license to choose? --MGA73 (talk) 07:32, 19 September 2014 (UTC)

It's probably called that way because it explains what can have a license in the first place. --Nemo 22:01, 21 September 2014 (UTC)

New tool needed

It would be very useful to WikiProject BSicon if there was a tool available that would allow the uploading of multiple files at one time (similar to the UploadWizard), instead of having to click on [Upload a new version of this file] for each individual file that needed to be revised or updated. In order to prevent misuse and abuse, I would suggest that it be restricted to those editors with Filemover or greater privileges (and possible be set so that it only works on files that start with BSicon_ and have a filetype of .svg). Useddenim (talk) 20:53, 9 January 2015 (UTC)

@Useddenim: That would probably be something that you could add to Commons:Bot requests rather than to the Wizard which is a different beast. It may be something quite specific that needs to operate out of toollabs: and be specifically designed for needs, and have an OAuth entry login interaction to work with your thoughts about rights entry level.  — billinghurst sDrewth 11:36, 10 March 2015 (UTC)

"known bugs" link returns 404

The "known bugs" link above to https://phabricator.wikimedia.org/tag/MediaWiki-extensions-UploadWizard/ returns a 404 error. If you go to a UW-related bug on phabricator (Example) and click on MediaWiki-extensions-UploadWizard in the "Projects" section, you get the same 404. Strangely, bugs tagged like this still show up at the project. There has been some adding and removing of tags at that project, which might have caused this? (pinging @Nemo bis: ) --El Grafo (talk) 13:36, 21 September 2015 (UTC)

Fails to upload because of similar names

I tried to upload an image, but nothing happened after I had completed all fields and clicked next. The "Next" button disappeared, so I couldn't do anything. When I tried the old upload form, I realized the problem, since it told me that there was a file with a similar name. I hope the Upload Wizard can start telling such things instead of just refusing to upload. --Årvasbåo (talk) 08:10, 30 March 2016 (UTC)

Commons:Categories for discussion/2016/08/Category:Uploaded with UploadWizard

Hi. Since this CFD is regarding one of the most populated categories on Commons, I am cross posting here for wider reach. Rehman 10:46, 3 September 2016 (UTC)

Too long file names

I wanted to upload this Flickr image[9], but then I got a message saying the file name was too long. The problem is, there is no file name, the upload wizard just uses the image title as default file name, and it isn't even possible to shorten the name in the wizard... So this means that if a photo has a too long title on Flickr, we can't upload it, which seems pretty silly... At least make it possible to edit the file name shorter before uploading. FunkMonk (talk) 13:02, 9 August 2017 (UTC)

That sounds like phabricator:T151776, but that's supposedly been fixed. In any case, it's unlikely that Mediawiki developers would read anything posted here. —LX (talk, contribs) 16:33, 9 August 2017 (UTC)

Where to place feature requests about the Upload Wizard?

I would like to place a feature request, what's the best place to do that? I think the Upload Wizard should remember the most frequent categories that I'm using. For example I'm using the category "Taken with Samsung Galaxy A5 (2017)" for all the images I'm uploading so it should suggest it when I'm typing "Taken". -- Fructibus (talk) 23:24, 23 October 2017 (UTC)

Your request is more or less already fulfilled by your web browser, but to answer your question:
https://phabricator.wikimedia.org/tag/uploadwizard/
You should be able to use your MediaWiki account to post your feature request there, there's a "New task" menu item under the star next to your avatar at the top. Be sure to verify that your request has not been posted already by someone else.
--Tactica (talk) 13:15, 4 December 2017 (UTC)

The "Next button" in the last screen of the Upload Wizard

IMO, the "Next button" in the last screen of the Upload Wizard should be named "Publish", because there's nothing to do next after pushing that button. -- Fructibus (talk) 11:46, 19 November 2017 (UTC)

I agree. Jim.henderson (talk) 02:44, 7 December 2017 (UTC)
Good point, I created ticket phab: T182307 to answer this question. —TheDJ (talk • contribs) 10:53, 7 December 2017 (UTC)

Categories

I often upload a batch belonging to a neighborhood or other existing category. It would speed things and probably diminish the number of new uncategorized uploads if we could upload more directly to the cat, for example with an "Upload to this category" button on the category page, or an option within the Wizard. Also a tree-walking category picker as in Cat-A-Lot, in the page for describing all files, or otherwise after upload and before "publish". Jim.henderson (talk) 23:05, 5 February 2018 (UTC)

"Please describe your image three times"

Note: I started a thread at the Village Pump regarding the Upload Wizard's profusion of fields asking for some kind of description. Gestumblindi (talk) 00:15, 2 March 2019 (UTC)

FYI, that thread is now in the archive. Gestumblindi (talk) 02:00, 17 March 2019 (UTC)
It's indeed an unjustifiable mess. Nemo 09:49, 17 March 2019 (UTC)

ERR_SPDY_PING_FAILED

Chrome ADSL 256/64 users can expect ERR_SPDY_PING_FAILED on all but the smallest files. Even on Special:Upload&uploadformstyle=basic . Jidanni (talk) 07:10, 21 May 2019 (UTC)

Do you have such a connection to test with, or do you just use the "artificial" slowing down in the developer tools? It would be interesting to know the latency to Amsterdam and whether uploads of similar size succeed on other websites over HTTP or HTTPS. Nemo 06:22, 22 May 2019 (UTC)

Why there is no Hindi help me wiki Jitp33 (talk) 02:49, 28 June 2019 (UTC)

Update needed

The Upload Wizard should have been updated by the end of the year. It still offers "The copyright has definitely expired in the USA: First published in the United States before 1924" instead of 1925. --Jan Kameníček (talk) 23:28, 4 January 2020 (UTC)

Unusable from 3rd world countries

The Upload Wizard/Archive 1 is unusable from 3rd world countries with slow upload rates.

The upload will fail, even for small files.

Test it with slower and slower connections, with bigger and bigger files, until you find the breaking point. Thanks. Jidanni (talk) 13:31, 19 August 2021 (UTC)

EXIF warning

The upload wizard warned me about EXIF data (in Swedish), saying that included EXIF data in "the file" could disclose things I wouldn't like have disclosed. Otherwise a good warning, but I deleted the data with exiv2 before starting the wizard, and after getting the warning I checked that at least exiv2 didn't find any EXIF data in the files in question. Also, I cannot see any metadata section in the file description page.

Does the upload wizard warn regardless of whether there is such data or is there some oddity in the files? (I used another camera than I'm used to).

In the former case, is the wizard unable to check whether there is EXIF data present? In that case at least the Swedish translation should get adjusted.

–LPfi (talk) 17:53, 17 December 2021 (UTC)

Categories

Commons has a really robust system of categories and with the cat-a-lot add-in, it is quite easy to edit them. By contrast, the upload wizard's category system is very clunky. It is not even possible to copy a category that I have added to one uploaded image to the other images in a queue - once a category has been entered it is impossible to select it in order to copy-paste into the other category fields (why?!). Nor is it possible to start from a broad category (e.g. "portrait paintings") and follow the category tree down to a most specific category (e.g. "20th century portrait paintings from Belgium"). It would be great if something could be done about this. Furius (talk) 22:40, 19 March 2022 (UTC)

Public Domain Mark at Flickr

What is the current default procedure for the Wizard when it imports files from Flickr where the licence is the Public Domain Mark? We do have {{PDMark-owner}} now, but I just learned of a massive batch of uploads where the Upload Wizard may have used CC by-sa 4.0 instead. De728631 (talk) 15:50, 24 May 2022 (UTC)

What's the point of the "Add data" step on the Upload Wizard?

The 5th stage of the Upload Wizard is labeled "Add data", and asks me to select items from Wikidata that appear in the image (as well as whether they are prominent). What is this information used for?

For example, I recently uploaded File:PRR D10003 at AC.png. In it, the d:Pennsylvania Railroad Odd D 10003 appears prominently, and I labeled it as such. But I don't see any link to the PRR "Odd D 10003" Wikidata item on the final Wikimedia Commons image page, nor, does the Wikidata item appear to link to the image. Where does that metadata go? Bernanke's Crossbow (talk) 09:51, 30 August 2022 (UTC)

@Bernanke's Crossbow: Hi, and welcome. See the "Structured data" tab on the file description page, and more generally COM:SDC.   — Jeff G. ツ please ping or talk to me 11:14, 30 August 2022 (UTC)
@Jeff G.: Oh! Cool; I see it now. Thank you! Bernanke's Crossbow (talk) 11:57, 30 August 2022 (UTC)
@Bernanke's Crossbow: You're welcome.   — Jeff G. ツ please ping or talk to me 12:06, 30 August 2022 (UTC)

Permission template

Is there a way to add my |permission= template in Upload Wizard without putting it in the |description= / information part? Examples: CORRECT placed / WRONG placed. Regards Vasmar1 | Marius Vassnes (talk) 19:10, 19 February 2023 (UTC)

select language for all pictures

It should be useful if we can select something (for example the language or the title) for all pictures. Random photos 1989 (talk) 17:38, 12 September 2023 (UTC)

Where is the upgrade to Upload Wizard being discussed?

I gather (from completely informal, off-wiki conversations) that there is current work on major changes to the Upload Wizard, and other places on Commons point to this page as the central place to discuss the Upload Wizard, but until this post there was not so much as a mention here. Where (if anywhere) is this current round of work being discussed? Or have I been misinformed, and perhaps no such thing is under way? - Jmabel ! talk 03:42, 4 December 2023 (UTC)

@Jmabel you're looking for Commons talk:WMF support for Commons/Upload Wizard Improvements (which really should have been linked from somewhere around here). El Grafo (talk) 11:07, 4 December 2023 (UTC)

New discussion about UploadWizard

Hi all! We are collecting feedback regarding the usage of the "Describe" step in UploadWizard, and its challenges to newbies. You are kindly invited to participate! Sannita (WMF) (talk) 14:30, 16 January 2024 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Upload_Wizard/Archive_1&oldid=861228481"