MediaWiki talk:UploadForm.js/Archive01

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

Status

This is currently just a proof of concept. It only works on Firefox, but not yet in IE. Don't know about other browsers. If you have Firefox, try it out to see what it does. (Try clicking "Upload" without having entered a source...) Do not use in production! Lupo 12:23, 19 December 2007 (UTC)

Works now on IE6, and has been reported to work on IE7.[1] Lupo 09:37, 20 December 2007 (UTC)
Note that I have so far tested this only in the monobook skin. Lupo 11:01, 20 December 2007 (UTC)
Works in Konqueror too. One color-of-the-bikeshed remark: would you consider changing the seventies orange to a light red? --Dschwen 12:59, 21 December 2007 (UTC)
Sure, just edit the file. It's the errorColor "constant" property (I somehow thought people would want other colors). Any ideas on how to make this handle different languages? I don't particularly like to hard-code the strings (except for fallbacks). How about subpages at some place X, e.g. at MediaWiki:UploadFormLabels, MediaWiki:UploadFormLabels/de, etc, with a defined format (generated by a template UploadFormLabelGen, which would ensure that the labels were placed into containes with particular ids). The script could make a HTTP GET request to get the right page (based on wgUserLanguage) and extract the label texts from there. If the page doesn't exist, the hard-coded default is taken. Would that be an idea? Lupo 13:18, 21 December 2007 (UTC)
I thought about that some time ago when I was working on a generic i18n system, but a syncronous HTTP request just to get the translations seems to be a bad idea performancewise. If you want easy we could think about a bot (with admin rights) that could perform the I18N maintenance. If it's done right that would even enable us to make the translations user-editable. I'm thinking about inserting markers into the code and have the bot replace everything between the markers with a generated i18n class. Of course the bot would have to take care to sanitize teh translation strings to avoid code injection or invalid syntax. --Dschwen 14:39, 21 December 2007 (UTC)
Anyways the hash-style i18n is currently de facto project standard. And I find it more maintainable than the previous one subpage per language approach. But a bot-solution would be even better IMO. --Dschwen 14:41, 21 December 2007 (UTC)
Sorry, I just saw your comments now. I have implemented the scheme I mentioned, as it has the huge advantages of (a) being user-defineable without having to modify the JS, and (b), one can use Wiki-Markup for the labels. It's pretty fast for me, too. If it causes any problems, just revert back to this version from before my changes.
See also MediaWiki:UploadFormLabels and MediaWiki:UploadFormLabels/de.
The bot-approach appears rather complicated to me (sanitizing strings, etc.) Lupo 15:09, 21 December 2007 (UTC)
Here's the form with the German-language interface. If "Lokale Datei" is a link, the labels were read from MediaWiki:UploadFormLabels/de. Lupo 15:35, 21 December 2007 (UTC)
Hm, the i18n stuff is now the biggest part of the script (at least runtime- and sophisticationwise). This could be done easier. Putting the complicated logic into a bot which does an operation once a day still seems more sensible to me than putting it into client side javascript which is executed on every page impression. Also if the endresult is just loading a subpage this could be achieved a lot easier with a simple includePage() command. We'd just have to make sure the subpage is executed early enough (or that the script initialisation happens late enough). Instead of a DOM parser you could simply eval the subpage as well, and you could use the AJAX functions which are already included with MediaWiki. --Dschwen 19:06, 21 December 2007 (UTC)
You've lost me there. Eval a subpage? Do you mean there's an API command somewhere that gives me back a subpage in JSON format? And I'll have to hunt around to see what includePage() does. Lupo 19:25, 21 December 2007 (UTC)

It now properly handles loading of MediaWiki:UploadFormLabels (or supages thereof) also in IE 6. It also can deal gracefully with the "hacked" language settings such as "deownwork" used at Commons:Upload. A minor problem is that since the plain "deownwork" page uses German text but the English form, the the modified "deownwork" page uses a mixture of German and English labels... (because the script does not change or set all the labels, only those of the fields it modifies). As a side effect of the "uselang" handling, some more effects are possible: for "ownwork" forms, the source and the author are pre-filled with "~~~", and for "fromflickr" forms, the source must be a URL beginning with "http://www.flickr.com". For these "fromflickr" forms, we should also have a second warning message that clarifies this. Other than that, this seems to work rather well. Lupo 12:08, 7 January 2008 (UTC)

Comments

ownwork:

  • better to have "own work" or "self made" as the source rather than ~~~
  • better to put something in the permission slot such as "I release this file under the terms of the license shown below", or else remove it (not really used for ownwork cases)

fromflickr:

  • worth having separate fields for Flickr user URL and Flickr user name?
  • the permission field could also have some default thing in here

for all:

  • need a categories field!!!!!!!!!!!!!!
  • would be fantastic, but possibly complex, if we could split the description textbox up a bit, like this:

And then convert those to {{en|English description}} and so on, but only if they had changed from the default. Could also validate the lang codes against known language codes. By default only offer English + language of user interface + 2 blank slots. What do you think? pfctdayelise (说什么?) 12:44, 16 January 2008 (UTC)

On ownwork:
  • First can be done, would need to integrate the corresponding code from MediaWiki:Upload.js into this script. Which I haven't done yet, I wanted to find out whether people agreed in principle that going in this direction was a good idea.
  • Second: can both be done (fill in default, or remove altogether).
On fromflickr:
  • Could of course be done (both).
On categories:
  • Could be added. The obvious follow-up enhancement request is then of course to automatically make appropriate suggestions for categories. That I cannot do.
On Image:Commons possible upload form.png:
  • Descriptions may each be several lines long. If we add several multi-line input fields, the whole form gets huge. Maybe better leave it at one box visible. Automatically wrap the given description in this box by {{user-language|text entered}}, unless it already starts off with "{{". Then additionally have a drop-down button "Add description in other languages", showing a list of languages. When one is selected, a new multi-line text input field is added dynamically, and its content will automatically be wrapped by {{selected-additional-language|text entered}}. A bit more complex to program, but doable (I think), and keeps the default appearance of the form relatively small.
Lupo 13:02, 16 January 2008 (UTC)
I think if there was 3x 2-line boxes, it would be about the same size as now, not too bulky. We don't really need to encourage people to write a paragraph of just description, after all.
I also think having a separate box with the language code would be more transparent than the "magic" behaviour of guessing that they write text in the same language as their user interface - I don't think that is a reliable guess at all. pfctdayelise (说什么?) 08:19, 17 January 2008 (UTC)
Ok... but this interface would still need tweaking. I claim that the average user doesn't know or care about language codes (like "da" for Danish... I myself am never sure whether it's "da" or "dk"!). The language specification on the left should at the very least be a drop-down giving human-readable strings ("Danish"). The values used internally under the hood would be the language codes, of course ("da"). Lupo 08:40, 17 January 2008 (UTC)
Having a drop down list is brilliant, definitely. pfctdayelise (说什么?) 08:45, 17 January 2008 (UTC)

Update:

  • ownwork: both ✓ Done. Fills in source with "Own work/Eigen werk/travail personnel/etc.", and has no permission field.
  • fromflickr: I think having two fields for FLickr user page URL and Flickr user name is overkill. What should be the default for "permission"?
  • categories: field removed again, categories are to be added either manually in the description field, or through MediaWiki:Gadget-HotCat.js (which is loaded automatically if not present). HotCat has been fixed to work properly also on IE6.

Lupo 11:11, 21 January 2008 (UTC)

Safari

In Safari 3 I get the following error: Error: WRONG_DOCUMENT_ERR: DOM Exception 4 http://commons.wikimedia.org/w/index.php?title=MediaWiki:UploadForm.js&action=raw&ctype=text/javascript

I believe this is due to the line: src_label.replaceChild (UploadForm.getLabel ('local'), src_label.firstChild); TheDJ 13:12, 16 January 2008 (UTC)

Ok, that would be due to this. Could you try again? I've added a fix that should correct this. But I'm flying blind here since I don't have Safari (or a Mac). Lupo 13:26, 16 January 2008 (UTC)
Yes, it is fixed now. Wonderful I really like this idea. TheDJ 13:53, 16 January 2008 (UTC)
Ok, thanks for reporting back. Lupo 14:14, 16 January 2008 (UTC)
In fact, I've changed the fix slightly. Originally, it used document.adoptNode (DOM Level 3), but that is not yet widely supported. I've switched this to document.importNode (DOM Level 2), which should be available on a wider range of browsers. Lupo 16:01, 16 January 2008 (UTC)
Note that for even older browsers that know neither of these operations, it shouldn't matter. Such browsers typically don't enforce the rule that caused this exception. (As shown by the fact that it worked without this correction on FF 2, IE6, IE7, ...) Lupo 08:42, 17 January 2008 (UTC)

Feature requests

Needs the "other versions" field - I've been doing a lot of cropped versions of shots already on Commons).

The "other versions" field could possibly automatically do the right thing with the filename of existing Commons files - turning all of Example.jpg or Image:Example.jpg or [[Image:Example.jpg]] into [[:Image:Example.jpg]]. And leaving anything else (http:// links) alone. (What's JavaScript's regular expression performance like?) - David Gerard 10:34, 18 January 2008 (UTC)

Performance shouldn't matter, since the text won't be huge. Should be something like /\[\[Image/\[\[:Image/g, or in JavaScript string.replace (/\[\[Image:/, "[[:Image:");
I'll add the field and the handling over the weekend; no time right now. Lupo 10:47, 18 January 2008 (UTC)
Field added, but still without input text sanitation. That's actually a little bit more complex, but it's in the works. Lupo 13:43, 20 January 2008 (UTC)

Licensing options

I don't think we should give users the options to upload if they don't know what the license is or "found the image on Google or a random website". Are these are there to "catch" them? If the user is unfamiliar enough with Commons to actually use these options, it's likely they might interpret the fact they're given those options as something Commons allows (well, I guess we do, for a little while) and pay no attention to the template. And why are they listed under "PD/not copyrighted/free use"? What about PD works that really are PD but not because of age or because they were made by the US gov.? Rocket000 12:38, 18 January 2008 (UTC)

Great job, by the way. :) Rocket000 12:39, 18 January 2008 (UTC)

Thanks. The licensing options are not defined in this script, but in MediaWiki:Licenses (and subpages thereof for languages other than English). The options you mention automatically generate a "subst:nld". They're listed under PD, because the clueless uploader typically thinks such images were free to take. It was deemed better to have these options than not for fear that without them even more people would upload choosing any odd license. Lupo 12:50, 18 January 2008 (UTC)

Input text sanitation

Over a my test file MediaWiki:UploadFormTest.js, I have enabled text sanitation as requested by David above (#Feature requests) and by AnonMoos at COM:VP#The design of our upload form. You can test it out by replacing "withJS=MediaWiki:UploadForm.js" in the test links by "withJS=MediaWiki:UploadFormTest.js".

Like this: new Upload form, English, plain, test version.

Note that text sanitation is difficult, and without template expansion impossible to make unbreakable. (See also the comments in file MediaWiki:TextCleaner.js.) With enough malice, it's still possible to enter text that will result in not well-formed wikitext in the end. But the script should be good enough to catch most unintended wikitext errors that might corrupt the {{Information}}.

Try it out, throw your worst at it. (By not entering a local filename, you *can* actually upload: the server will then complain and send back a standard upload form with the {{Information}} as it received it. In that way, you can check the results of text sanitation without actually having to upload files.)

If you're using Firefox, keep the Error Console open (menu "Tools→Error Console"). If you see any error messages pertaining to either MediaWiki:TextCleaner.js or MediaWiki:UploadFormTest.js, report them here. If the sanitized input is still not good, report the original input and the resulting {{Information}} template here, and explain what you would have expected to see.

I'll be away over the weekend, which is why this feature is not yet in MediaWiki:UploadForm.js. Lupo 10:55, 25 January 2008 (UTC)

Now also in MediaWiki:UploadForm.js, so it should work with all the "normal" links posted at the VP about two weeks ago. Lupo 09:00, 28 January 2008 (UTC)

Descriptions

I have implemented User:pfctdayelise's suggestion (see the archive) to have separate input fields, one per language. Play around with it here. To get the interface in other languages, add "&uselang=languageCode" to the URL, like here (in French). Thoughts, anyone? Lupo 15:24, 30 January 2008 (UTC)

Mock-up

A mock-up of how Commons:Upload could look if this script goes live is available at User:Lupo/upload. The mock-up uses the "one description per language" forms, except for the "experienced users" forms. Comments, anyone? Lupo 10:59, 7 February 2008 (UTC)

I wish there was setting in our preferences to set to go directly to the upload form. I hate going through the extra screen. →Яocket°°° 20:50, 8 February 2008 (UTC)
I add a direct link to my toolbar using my monobook.js. The extra screen is useful for the many users who don't have much experience with licenses. Or just bookmark Special:Upload. But independently, I'll add a user preference to this new script such that experienced users can choose to have only the basic support by adding some flag setting to their monobook.js. Lupo 23:00, 8 February 2008 (UTC)
Yeah, I guess I can add a direct link via .js but it seems a common enough preference where it could be option.. Anyway, what do you consider basic support? I think the upload page itself is more than enough for experienced users (unless they like going through Commons:Upload). On the upload page itself, I wouldn't mind having a preference to replace the Uploadtext part with a simple reminder/copy'n'paste text box for various licenses and such. Something similar to the edit toolbar would be ideal. It would be great to add in templates by simply clicking an icon. Now that I think about it, we really should have a toolbar since we really are creating the whole description page this way. I wonder how much work that would be. →Яocket°°° 05:01, 9 February 2008 (UTC)
The "basic" support this script offers doesn't modify the layout of the form at all. It is just a target filename check, plus it tries to check that the {{Information}} template in the description does have a source, an author, and a description. Could add an attempt at a license check, too.
Your idea about buttons seems interesting, but I'm not sure I understand. Do you mean extra buttons for "add an empty {{Information}} template in the description" (that already is done by default by MediaWiki:Upload.js), "add an empty {{Painting}} template", and "add an empty {{Flickr}} template"? Any others? Lupo 08:14, 9 February 2008 (UTC)
Yes, precisely. Any of the major templates used could have a button. The ones you listed plus things like {{LOC-image}}, {{NASA-image}}, etc. And once the framework's there users can customize it with their .js. →Rocket°°° 00:12, 11 February 2008 (UTC)
Well, LOC, NASA, and so on are harder since they require an input parameter, and people should know what exactly needs to be given as the image ID. I would suggest that this is best done in a completely new script that people then could include through their monobook.js (or modern.js, or whatever skin they're using). Doing this as part of this script here would really overload it, especially since the functionality is independent of the one of this script. Lupo 07:55, 11 February 2008 (UTC)
Oh, I agree. I was just throwing some ideas out there. →Rocket°°° 16:58, 11 February 2008 (UTC)

Heh, I was in the middle of writing a little link replace script when I found MediaWiki:Replaceuploadlink.js. Looks like someone already had the idea. I didn't even know about experienced for the &uselang parameter. I need to look around more, save me some work. →Rocket°°° 04:19, 12 February 2008 (UTC)

Damn. I didn't know about that hack either. Now I'll have to code a special case to handle that uselang parameter, too. My script must go into basic mode on that form, and the language must be set to 'en'. Lupo 06:58, 12 February 2008 (UTC)

Beta-testing

Announced at Commons:Village pump#Upload form redesign: beta-testers needed, Commons:Help desk#Upload form redesign: beta-testers needed, Commons:Bistro#Nouveau formulaire d'upload, and Commons:Forum#Ein neues Design für die Hochlade-Maske: Beta-Tester gesucht.

There are three forms to test:

  • Original design with extra fields, but one single description field.
  • Alternate design proposed by Pfctdayelise here with extra fields and one description field per language (more can be added by clicking the "+"-buttton).
  • Basic form for experienced users: no additional fields, just input validation.

Documentation is at MediaWiki:UploadForm.js/Documentation. A mock-up of how Commons:Upload could look if this were enabled globally is at User:Lupo/upload (using the alternate design).

In particular, I'm looking for people who are using browsers other than Firefox/IE6 on a Windows PC. Are you using:

Opera? Konqueror? Safari? IE 7? IE 5.5? IE-Mac? other?

or using Linux or a Mac? It would be really great if you could help testing these forms. (Note: on old browsers like IE 5.5 or IE/Mac, I'm already happy if you still get any usable upload form. I don't expect the script to actually work on these browsers, but you should still get the plain old upload form.)

If you do test, please report your findings on this page here (browser and operating system (Win/Mac/Linux/other), whether it worked; and if not, which form failed and what exactly didn't work—see Reporting bugs). I will need precise problem descriptions as I myself have only access to Firefox and IE6 on a Windows PC. If your browser has some "error console" like Firefox, please use it to pinpoint the failure as good as possible. If you end up at a URL ending with "uploadformstyle=plain", there was some problem during the setup of the new redesigned form. In that case, you might want to try testing the development version here, which should fail hard and give us a chance to find and fix the problem. And if you report a failure, please be prepared to re-test once the problem is thought to be fixed.

Oh, and which one do you think is better: the original design with one single description, or the alternate design with the description-per-language fields? Remember that the new form is designed to prevent the most common mistakes inexperienced users make. I guess the old hands would use the "basic form" (link above). Thanks, Lupo 15:15, 11 February 2008 (UTC)

How to test

Do whatever you like. The script should not allow you to proceed with the upload if it detects any problem (illegal destination filename, no source, author, license, or description given). It should show you error messages on a pink background. If you're using an interface language setting the script doesn't know, the form labels and error messages should have a "translate this" link. The basic form should be able to extract source, author, etc. from correctly formatted {{Information}}, {{Painting}}, or {{Flickr}} templates. You should be able to actually upload a file if all the required information is filled in. If the upload succeeds, all the information you entered should be there. Malformed input (such as unclosed links or templates) should have been corrected. Categories can be added by clicking the "(+)" link from HotCat; these categories should also be on the image page. When you click the back-button of your browser, the forms should restore the previously entered values. (The basic form relies on the browser's built-in support for this, the other forms do this explicitly in the script. Note that the value of the "local file" input cannot be restored due to security restrictions.)

You can test error messages and so on (i.e., all the cases where an upload should not proceed) by not choosing a local file to upload, but otherwise filling out the form as if you were going to upload a file. The script does not check for an empty local filename, because the server treats "no file specified" and "empty file specified" in exactly the same way, and the script cannot test for "empty file specified" anyway due to security restrictions. If the upload that should not have proceeded does proceed (which is a failure of the script) without a local file specified, the server will send you back an error form without actually uploading. In this way, you can safely test that part of the script without running the risk of actually uploading something.

MediaWiki:UploadForm.js/Documentation/Compatibility

Reports

  • Tried all 3 forms, using Safari Version 3.0.4 (523.12.2) on OSX 10.4.11. Original & alternate design worked; Basic form fails (in the last few minutes) - it refuses to upload, telling me "Files of this type cannot be uploaded", highlighting the destination filename of "Macaw_hybrid_-_Syracuse_Zoo.jpg‎".
  • Comment: On the non-basic forms, I suggest labelling the Date field "Date of creation". I know it says that above, but too often I see newer users putting today's date on things like 80 year old photographs. --dave pape 17:08, 11 February 2008 (UTC)
  • Tested in Opera 9.26 and Firefox 2.0.0.12 both on XP SP2. Both worked fine. In Opera, there was a small glitch with the Licensing drop-down. It show the down arrow but absolutely no box and no text until I clicked on it, then it said "None selected..." I always use Firefox, so I don't know if this common for Opera users or what because every input field's box was slightly different. Other than looking worst than in Firefox, there were no real usability problems. (And I almost tested it in IE7, but all this crap about my Windows firewall and auto-updates being off started popping up. The hell with that :)) - Rocket000 01:48, 22 February 2008 (UTC)
    • Cool, thank you. Finally a confirmation for Opera! Don't know what that glitch was; the script doesn't change that dropdown in any significant way: it just sets some styles (which I have in the meantime added to MediaWiki:Common.css anyway) and sets up a function to be called when something was selected. Neither of these operations should interfere with that dropdown. Could you still check the behavior of that license dropdown of the upload form without this script? If it works there as expected, it's the script all the same, and I'll have to investigate... Lupo 10:30, 22 February 2008 (UTC)
      • Yeah, it's the same, but I do get text in both without having to click on it now. Weird. Still, there's no outline of the box. It's cosmetic but it does makes it easier to miss. No problems with the preview part, though. - Rocket000 11:25, 23 February 2008 (UTC)
        • There are other minor layout problems on IE6, too. The preview button is not separated by 0.5em (like specified!!) from the upload button, and the top border of the preview (the red line) doesn't show up. Instead, there's a (maybe 0.5em high) grey bar just below the uploadtext. No idea what's causing this, IE6 is so quirky that I really don't want to investigate such minor issues. :-( Lupo 13:20, 23 February 2008 (UTC)
  • IE 7 has now also been confirmed by User:Magnus Manske. Thank you! Lupo 20:13, 24 February 2008 (UTC)
  • Safari 2 is crashing on all of these URLs atm. This is a serious issue. I will investigate. TheDJ 09:57, 19 March 2008 (UTC)
    • Crashes on what? You mean, it crashes so badly it doesn't even redirect you to the normal upload form with the script disabled? Lupo 11:36, 19 March 2008 (UTC)
      • Afterthought: you tested that on a Mac, I suppose. The early Windows versions of Safari are known to be buggy; if these crash, we don't care. Lupo 11:42, 19 March 2008 (UTC)
      • Oh, and what does "crash" mean? Program freezes? Program crashes and disappears? Computer freezes? Computer needs to be restarted? Program keeps working, but doesn't display the page? Program keeps working, but displays a garbled page? Program keeps working, but displays a standard upload form? Something else? Lupo 12:04, 19 March 2008 (UTC)

Preview

I love the missing field highlighting and I love that there's now an edit toolbar. I do have one suggestion though, is it possible to have a preview button before you even upload? - Rocket000 01:24, 22 February 2008 (UTC)

Ehm... the edit toolbar isn't my doing... don't know where it comes from. But I agree it's good to have it. I'll see what I can do about a preview... should be possible. Lupo 07:24, 22 February 2008 (UTC)
Preview button ✓ Done. Could you please re-test to see whether it works for you, too? (I tested it already on FF 2.0.0.12 and IE6, WinXP Pro SP2.) Lupo 09:54, 22 February 2008 (UTC)
Thank you! However, now it's a little buggy in Firefox. :( (Or maybe it's because I tested it more thoroughly this time?) For one test, I typed something in each field, selected a license, hit preview, and it told me "Files of this type cannot be uploaded" so I selected a real file that ended in .svg and the preview worked but the DestFile box stayed pink. Another time, it wouldn't let me select a license. It wouldn't drop down until I clicked the arrow about five times. Now, I can't repeat this and I forgot exactly what I did (just clicking/typing randomly). I spent fifteen minutes trying to repeat but with no luck, so it might not be a major issue.
I was thinking what if you put the preview under the entry form and replace the license preview? Of course the license would then be part of the preview. Another thing, since a description is now required, the text box should turn pink when empty too. Now I'm off to test it in Opera. :) - Rocket000 10:50, 23 February 2008 (UTC)
I cannot reproduce the issue you described. Works fine for me, except that the error message stays up even if the fields are corrected. But that's a truly minor issue that would need quite a bit of programming around; the resetting of the background should be sufficient to indicate that this mistake has been dealt with by the user. As for putting the preview in place of the license preview: I didn't do that because then a subsequent change of the license selection would remove/overwrite the whole preview. As for the description field being highlighted: I take it that you tested the alternate design (with the language dropdown at the left? Yes, that form doesn't highlight the description fields. I'll change that, too. Lupo 12:55, 23 February 2008 (UTC)
Yep, it was UploadFormTest2.js. The original one works fine. - Rocket000 13:03, 23 February 2008 (UTC)
Description field highlighting in alternate design: ✓ Done. (Remember to force a reload.) Lupo 13:15, 23 February 2008 (UTC)
Works great. Thanks. - Rocket000 21:49, 23 February 2008 (UTC)

Suggestions

This Upload form is looking great. I've installed it in my monobook.js and modified two things. I changed all [[User:USENAME|USERNAME]] to {{User|USERNAME}} as I think that template does a neat job. The other thing is that I added a bit of javascript to fill in the date field with the current date. This can be a bit problematic, but I typically am uploading Own Work which is published the first time when I upload it to commons. so most of the time I'm entering the current date. Probably this should be the default for own work, but not for other work, as it might make people lazy. Ideally it would be a button that puts the current date in.

Also in the alternative layout, the + sign under the per language description is not to clear. once you click it you cannot remove the exta field. maybe the button should use an icon based on ISO 639 icons or else one of these:

--Inkwina 00:38, 26 February 2008 (UTC)

Note that once this will be enabled globally, the version in your monobook.js won't have any effect anymore. But I'll add some configuration stuff such that people can configure an initial value for author and date for "own work" uploads in their monobook.js without having to copy the whole file. I won't make a global default date = today, but people will be able to configure it thus in their monobook.js.
I don't think these icons are any clearer. "+" was the simplest I could come up that is internationally understood as "add". But maybe someone can come up with a better idea. I avoided a text button on purpose (i.e., not "Add another description in another language": that would need to be localizeable again...).
It's not necessary to remove a description field once added. If you don't want it, just don't enter any text in it (the form just enforces that there is a description in at least one of these fields), and if you want to change the language, just select another language in the dropdown. Lupo 07:17, 26 February 2008 (UTC)
Ok, configuration for own work uploads is implemented. You could change your monobook.js to the following:
importScript( 'MediaWiki:UploadForm.js' );

var months = new Array ("January", "February", "March", "April", "May", "June",
                        "July", "August", "September", "October", "November", "December");

function formatDate (d, with_timezone)
{
  if (!with_timezone) {
    return months[d.getMonth()] + ' ' + d.getDate() + ', ' + d.getFullYear();
  } else {
    var tzRaw = d.getTimezoneOffset();
    var tzHour = Math.floor( Math.abs(tzRaw) / 60);
    var tzMin = Math.abs(tzRaw) % 60;
    var tzString = ((tzRaw >= 0) ? "-" : "+")
                 + ((tzHour < 10) ? "0" : "")
                 + tzHour + ((tzMin < 10) ? "0" : "") + tzMin;
    return formatDate (d, false) + ' (' + tzString + ')';
  }
}

var UploadForm_ownwork_date = formatDate (new Date (), true);
var UploadForm_ownwork_author = '\{\{User|' + wgUserName + '\}\}';

No need to copy the whole MediaWiki:UploadForm.js file... ;-) and it'll continue working once we have enabled it globally. Lupo 09:24, 26 February 2008 (UTC)

OK WOW Great! and the response time is Flabbergasting. Now enough flattery and time to be bold. Please bear with me as I make a few extra suggestions. These are more like a brain dump, so consider them lightly:
1. So you can extend the above idea to allow users to chose a default license I guess.
2. What about a few default categories? Occasionally one might be working on a specific project and uploading images mostly relating to that category (or sub-categories of it). But user/monobook.js isn't the ideal place for this. Ideally a user/Default-Cat page would contain a list that is automatically added. But I think something like that you might want to leave for v2.
3. the license preview loads a boiler plate template which causes the form to be redrawn with a different width (and height). Maybe the "None Selected" option could have a boilerplate associated with it (based on Template:PD-Layout) that warns users they have not selected a licence yet
4. the error message when obligatory fields are left out: should the errors be bulleted to be clearer they are distinct erorrs? would it not be better if the message came Above the form?
5. As to a symbol to indicate localization that is not localized, you're right that's a tough one! But I still think the + sign is not very intuitive. It clearly means add .. but add what? another description? maybe it should sit next to the language filed not the description field. I don't know really.
6. I like to share my Inkscape handy work and add the {{Inkscape}} template. But with the new form I have to either put it in the description field (Ugly) or edit the upload (slow). There are a few possible solutions to this: a) Add an (advanced?) field for stuff that goes below the Information table) b) add a drop down/check list for the post most popular tags (finding which they are might not be easy Category:Marker_templates might be a good place to start) c) Tough luck on me, learn how to touch type or get a faster connection :-p
Cheers and thanks once more --Inkwina 16:56, 26 February 2008 (UTC)
On (1): I could, but that should be discussed with a wider audience first. This suggestion has come up before (not in the context of this script), and it was felt that this might increase the number of wrongly licensed images. Also, it's a bit more complicated to program, as the script would need to dynamically add an option to the license dropdown with this user default license, and by default this new option would need to be selected, and its preview should be shown.
On (2): doesn't need any script change. Put your categories in a user subpage, wrapped with <includeonly>, and subst that user subpage in the description. (Or in the new "additional info" field, see point (6) below). Also, if you want to upload a lot of related images, maybe a tool like Commonist is better suited to the task.
On (3): maybe not such a good idea, especially if people use the basic form. I basically never choose anything from that dropdown; I usually write my licensing templates directly. I'd hate to be shown a "you didn't select a license" pseudo-preview. I'll have to investigate why that license preview causes a re-layout of the whole table. The script is not the cause, it also happens on the unadorned upload form, and the warning messages the script adds also don't cause that. I suspect there's something in those license templates that causes this. If so, it could perhaps be fixed.
On (4): no, I think the placement is fine. When the user clicks the "upload" button, he has that part of the form in view, but not necessarily the top of the form. With the current placement, the user should see the messages immediately. I could maybe use a bulleted list, though.
On (5): if someone can come up with a great design, I'll happily replace that "+" button. But for now, I'd just leave it. When this is globally enabled and we get lots of complaints, we can still try to find a better solution. And if it means a text button with localization, so be it.
On (6): that is indeed a problem. Interestingly noone mentioned it yet, and I didn't notice that either. It's not just {{Inkscape}}, but also other templates like {{Retouched}}, or the geocoding templates {{Location}} and {{Location dec}}... the form will need one more input field for "additional information" that will be placed below the {{Information}} (your solution (a)).
Lupo 21:28, 26 February 2008 (UTC)
Additional info field ✓ Done. Lupo 23:31, 26 February 2008 (UTC)
On (2) Doh! and then (1) goes away too. :-)
On (3) I think its because the boiler plates are much wider than the form without preview. the form needs to be at least wide enough for the boiler plate to fit. Maybe a Blank DIV holder would be needed, or the labels should be pre-folded or the td id="mw-license-preview " should colspan=2
that said the boiler plates do need fixing to not use tables directly but a standard template. :-( --Inkwina 07:53, 27 February 2008 (UTC)
Yeah, I guess with (2) the default license also is covered. Well, we're not any worse off than currently.
The table re-layout occurs because there are no absolute widths specified on the table that contains the form. When the license preview is displayed, the table must be laid out afresh according to the specs. And since all license templates state "width=100%", they are made as wide as possible. However, I found a way to fix that in the script, by setting the width of the table cell (and the div within) explicitly to their current display width. Since then, both IE and FF still try to make the previewed license as wide as possible, but at most that number of pixels wide. As a result, the layout of the form table remains unchanged. I'm not 100% sure why it works on IE6: the script set both width and maxWidth, but IE6 doesn't have maxWidth, and width is according to the specs only a "recommended width". But work it does. Lupo 10:52, 27 February 2008 (UTC)
BTW, there's an even simpler way to get the current date (and time) into the date field:
var UploadForm_ownwork_date = '\~\~\~\~\~';
Lupo 10:57, 27 February 2008 (UTC)

I hope you don't mind some more feedback ;-). I noticed that when I tried to upload a new version of an existing image the new form wants me to re-enter all the information again. I don't know why Mediawiki deals with new versions of the same image like this, most of the time new versions are light improvements that hardly warrant more than a 1 line summary. But any way, I think it would be hand to have a link to the basic version of the form so that you can switch from one form to the other. Also the normal and 'internationalized versions should be cross linked. BTW, I could not resist trying to come up with a nice icon to replace that horrid "+", but ultimately I ended up resorting to a plus anyway:  :-p

--Inkwina 20:22, 1 March 2008 (UTC)

Not at all! Your suggestions are most welcome! Indeed... I could simply switch off the input validations if the overwrite warning is shown: whatever is input won't end up on the page anyway. So a solution might be not to build an information-template in this case but to simply use the description. (It's still visible in the upload summary.) Lupo 20:45, 1 March 2008 (UTC)
It now does the input validation only if we're not overwriting an already existing file. Lupo 10:53, 3 March 2008 (UTC)

Switch to V2.0

The upload form script has now been switched to V2.0. It uses the multiple description fields (one per language, the user can dynamically add additional description fields). It also has an integrated help. If you notice any problems, report them here.

Note: already the previous versions of this script crashed Safari 2. When this script will be enabled globally, we will make sure that it is not enabled for Safari 2 (i.e., for WebKit versions smaller than 420). Lupo 21:29, 25 March 2008 (UTC)

Swedish translation of translate

{{editprotected}} Please change översätta to översätt. The first is the act of translating the second is a request for translating. Also for MediaWiki:UploadFormTest.js. /Lokal_Profil 14:59, 27 May 2008 (UTC)

Thanks. /Lokal_Profil 21:30, 27 May 2008 (UTC)

{{ImageUpload}}

What's the purpose of the categories this adds? And wouldn't be better to subst this so it just leaves the appropriate category and not a template? Right now it's kinda bot/script unfriendly. Rocket000 16:06, 28 May 2008 (UTC)

It's just for tracking during the initial time this runs. First, it gives people an idea how many uploads were made through this form, and second, it's handy to know whether a particular file was uploaded through this script or not. Especially in the beginning, so I can see right away whether a problem might be caused by the script or not. I plan to replace it later on with a hidden HTML commentary. And then a transclusion is better for finding all the places where it's used if we want to remove it (by bot). Lupo 18:14, 28 May 2008 (UTC)
Ok, that makes sense, but couldn't we find it just as easy if it was in the [[Category:..]] form? Rocket000 08:38, 29 May 2008 (UTC)
Hm, yeah, I guess so :-/ I wanted the category names to be configurable on-wiki. I didn't want to hardcode category names into the script. As it is, the category names could be changed by editing the template and I have only one hardcoded name ("ImageUpload") in the script. What's bot-unfriendly about it? Lupo 08:52, 29 May 2008 (UTC)
The category names can still be configurable. All you need to do is subst the the template when adding to the page. If you give it {{subst:ImageUpload|{{{1}}}}} only the desired category will be left behind. I guess it's not that bot-unfriendly, it's just they're used to categories on the bottom and only interwiki links below that (AWB just gives up on Commons with our categories everywhere). You can't remove the category, with say HotCat.js, if it's in a template. It's not really an issue I guess, but it just seems the template shell is unnecessary. Rocket000 17:43, 30 May 2008 (UTC)

Catalan translation

Please change ca: 'traduïr' by ca: 'traduïu'. The first one is not correct. My congratulations for all that have made this greet job. --V.Riullop 21:39, 28 May 2008 (UTC)

Like this? Finn Rindahl 22:09, 28 May 2008 (UTC)
Right, thanks. --V.Riullop 08:35, 29 May 2008 (UTC)

Two edit requests

{{Editprotected}} 1) I understand there is an old upload form that is still available (possibly through the preferences?). Could we provide a prominent link to that page, or are the two integrated via Javascript? If so, we might want to separate them.

2) For newly uploaded images, of course the fields do not change, so all the filling them out is in vain. Is there any way we could reasonably collapse the whole thing if someone is trying to upload onto an existing image, with a note of why? If not, could we at least give a prominent note of "You're uploading over an existing image, and all of these fields will be duly ignored". Patstuart (talk) 19:01, 1 June 2008 (UTC)

  1. If you want a link to the basic upload form, put it at the bottom of MediaWiki:UploadFormQuickHelp. In that way, it'll be displayed only on the full form, and it'll be top-right of the form.
  2. No, we can't collapse the whole form when someone would be overwriting an existing image. We'd have to restore it, too, when someone edits the destination filename field to a new name. That's just too much work. There is already a rather large warning for the overwrite case (with a thumbnail, even). It appears just above the upload button. (This warning is not new behavior, BTW.) I'm not sure what more we could do... I would suggest dynamically displaying MediaWiki:UploadFormPreviewOverwriteError in red just below the destination filename field, and removing it again if the filename is edited to some new name. What do you think? Lupo 14:58, 2 June 2008 (UTC)
  1. I would if I could, but someone protected it. Patstuart (talk) 17:13, 2 June 2008 (UTC)
Done. Lupo 19:22, 2 June 2008 (UTC)

headings

The scripts automatically adds two heading "description" and "Licensing:". This is extremely useless in my opinion. Every part of the image description should be localizable and be in templates. The second heading "Licensing" will stay in English whatever language you use by default. Even worse, the first heading is in the preferred language of the uploading user. This makes the heading completely useless for most users. Couldn't we just get rid of those two headings? The user should be able to recognize "description" and "license template" without the headings, I think. --::Slomox:: >< 17:39, 6 June 2008 (UTC)

And by the way, why are categories placed above license templates? --::Slomox:: >< 17:41, 6 June 2008 (UTC)
That's not the script's doing. neither is it new behavior. The server adds these headings if a selection in the license drop-down is made. And because the server doesn't handle categories, the categories just end up above the "License" header when the server adds that header. There is no way around it currently, except adding the categories manually after the upload. It's always been like that. Lupo 10:38, 7 June 2008 (UTC)
I never used the drop-down until the script demanded it. Still, it doesn't make sense. Well, then I must report this somewhere else ;-) --::Slomox:: >< 16:01, 8 June 2008 (UTC)
The script does not demand using the drop-down. Put your license template in the "permission" field. Lupo 16:11, 8 June 2008 (UTC)

Please indent license selector to the left

At the "my own work" upload page I can't read all the options in the dropdown license selector. Some of the options extend past the right side of the screen and there is no way to scroll to the right to read those options. My monitor resolution is currently at 1024 by 768 pixels.

Maybe the license selector can be indented to the left. Since it is also the most important part of the form it might help to make it stand out this way. --Timeshifter 22:09, 10 June 2008 (UTC)

No, that wouldn't look good. Choose shorter item titles in MediaWiki:Licenses/ownwork instead. Lupo 06:32, 11 June 2008 (UTC)
They are multi-licenses. That may be difficult. Also, I am not an admin. I left a comment at
MediaWiki talk:Licenses/ownwork
Maybe the menu could be made to drop down to the left instead of to the right as it does now. I thought menus could be made to popup, dropdown, etc.. Why not to the left or to the right? In other words the right end of the dropdown menu would line up to the right of the monitor. And the left end would go to the left as far as necessary.
And I disagree that my first suggestion wouldn't look good. The main description area is kind of indented to the left if you look at how it combines with the language selector to the left of it. It is one long extended form area. --Timeshifter 08:20, 11 June 2008 (UTC)
BTW, it's also dependent on your browser's text size settings. Changing the drop-down to be right-aligned might break on RTL forms, for instance the Hebrew form (which has a minor but unrelated layout problem that is probably due to some bug in the CSS file for the Hebrew pages). Lupo 08:28, 11 June 2008 (UTC)
It looks like the initial problem has been resolved. The longer dropdown menu entries have been shortened. See the discussion here:
MediaWiki talk:Uploadtext/ownwork#License selector needs to be indented to the left --Timeshifter (talk) 00:26, 14 June 2008 (UTC)

Validation too strict

It would be nice to have a "yes, I know what I am doing" option to dismiss warnings like no author as sometimes there is no meaningful information to write to that field (e.g. for some domain images). --Tgr (talk) 16:21, 24 June 2008 (UTC)

Layout problem in FF2

In FF2, clicking on preview and then upload caused the form to fell apart (I tried it with this file), with the question marks appearing half a screen lower than they should. This doesn't hinder uploading, so it's no serious problem, but it's ugly. --Tgr (talk) 16:21, 24 June 2008 (UTC)

Override title blacklist

Admins should be able to override the check for bad files names (wpNondescriptFilenameError). Rocket000(talk) 21:35, 22 August 2008 (UTC)

Is this a request or a statement? You may wish to see MediaWiki:Titleblacklist and it's talk page.  — Mike.lifeguard | @en.wb 22:59, 23 August 2008 (UTC)

Own work by uploader

If I use "uselang=ownwork" for uploading own files, the source parameter is preset to "Own work by uploader". Could we change this to "{{Own}}"? That template localizes the string to the user's preferred language. --Slomox (talk) 14:37, 26 January 2009 (UTC)

The upload script uses MediaWiki:UploadFormOwnWorkLabel and subpages thereof. I won't make an invasive change in the way the upload form handles its message loading. You can get the desired effect by setting MediaWiki:UploadFormOwnWorkLabel to "<nowiki>{{own}}</nowiki>" (yes, include the "nowiki"!) and then deleting all subpages of this message. Whether it's clearer for the user if he has funny squiggly braces in the source field is doubtful, though. Lupo 12:16, 28 January 2009 (UTC)
And of course, before deleting the subpages, transfer their contents to the appropriate subpages of Template:Own. Seems the upload form has far more translations for this than that autotranslated template... Lupo 12:57, 28 January 2009 (UTC)
The template is updated with the additional Mediawiki messages.
We could of course create "{{Own work by uploader}}" as redirect to {{Own}} to make the meaning more obvious. But the funny braces will only go, if you change the code. We could just stay with MediaWiki:UploadFormOwnWorkLabel as default content and you could add a line of code that on submit checks whether the source line is identical to the content of the relevant subpage of MediaWiki:UploadFormOwnWorkLabel and replaces it with "{{Own}}" if that's the case. I don't think that that would be an invasive change. --Slomox (talk) 16:18, 28 January 2009 (UTC)
Ugh. That's a hack, especially for the basic upload form, where the script would have to try to extract the source from what is essentially freetext (it cannot rely on there being a well-formatted {{Information}} template). I'll think about how to do this. Lupo 07:39, 29 January 2009 (UTC)

Licence selector

It's often desirable to use a licence template not listed in the drop down licence selector (if one is using a custom tag, a personalised tag, or just one not listed). The default selection in the licence selector indicates that such templates can be entered in the "additional info" field. However, if that is attempted, then the javascript prevents the form from being submitted. Either the javascript should be changed to no longer block submission if the additional info field is empty, or, since that might create false positives, an option explicitly indicating an alternative template is supplied should be added to the licence selector. --bainer (talk) 08:32, 29 April 2009 (UTC)

What template was causing you trouble? Lupo 11:27, 14 May 2009 (UTC)
It's not the template, rather the upload form special page itself, which is causing trouble. Also, the available licenses are very limited and don't include 2.0 and earlier CC licenses. --Paul_012 (talk) 18:01, 30 July 2009 (UTC)
We should always lose the GFDL bias now that Wikimedia's gone CC-BY-SA. Rocket000 (talk) 20:44, 31 July 2009 (UTC)
Very much support this. It's not possible to includeevery possible licence, and so we get a lot of badly-licenced files. Better to link to the full list of licences, and provide (in the non-basic upload) a space that an alternative licence can be pasted in instead of the listed ones. Adam Cuerden (talk) 14:06, 23 August 2009 (UTC)

Annoyance!

Insistence on having the full upload form filled out, even while admitting that nothing put into the form will display!

Can we make it so that, if the image description page already exists, it skips the checks to see if the form is filled out? It's really annoying when you're trying to do a batch upload with links to each other, because the links to the other files (not yet uploaded) should begin with [[:File:..., and links of that sort open up the edit window, not the upload, when clicked on.

Suffice it to say that during a large batch upload the damn checks are quite enough to have me screaming at my computer. Adam Cuerden (talk) 14:04, 23 August 2009 (UTC)

First: yes, I'm going to look into this and fix it if I can, but it might take a few days until I have the time. The problem seems to be infrequent (otherwise, there's have been more and much earlier reports about that); apparently you're pretty much alone in doing uploads that way (creating the page before uploading the file).
Second, there is a simple work-around: Use a link to the upload form with "&uploadformstyle=plain" at the end. Lupo 06:55, 24 August 2009 (UTC)
Alright, thanks! There's no real rush, but it'd be nice to have it fixed (though I doubt many know where to complain about this, so it's probably not just me, but probably rare.) Adam Cuerden (talk) 11:07, 24 August 2009 (UTC)
Found some time already :-) ✓ Done. Just go to the normal upload form and refresh your browser's cache. After that, it should work. Lupo 14:36, 24 August 2009 (UTC)

Broken on re-uploads

The upload form is broken on reuploads because wpSourceType is not sent along. -- Bryan (talk to me) 20:40, 18 September 2009 (UTC)

I don't think so. Verified it on Firefox 3.0.5 using Firefox: wpSourceType is sent in the POST data. In fact, it fails for me even if I completely disable all JavaScript. See the e-mail I sent to you, and bugzilla:20677. And now I'm really off. Lupo 21:28, 18 September 2009 (UTC)
Fixed that one, now it is wpEditToken that is missing. -- Bryan (talk to me) 09:09, 19 September 2009 (UTC)
Fixed that one as well. -- Bryan (talk to me) 09:48, 19 September 2009 (UTC)

wpPreviewOverwriteError

{{Editprotected}} "wpPreviewOverwriteError" is the error message that appears when someone tries to overwrite another file. Currently it focuses on the absence of update of the file description page. Following the discussion at file naming, please update it as follows: 

    wpPreviewOverwriteError:
     +'You will upload over an already existing file. Please choose a different filename,'
     +'unless you are uploading a technically improved version of the same file.'
     +'Dont overwrite a file with a different image of the same topic.'
     +'If you overwrite, the information in this form will not appear on the description page.',

Thanks -- User:Docu at 12:56, 8 November 2009 (UTC)

And again I'm sorry that you needed to wait :(
its done now :)
Huib talk 21:14, 13 November 2009 (UTC)
Thanks for your help. There was no hurry. It looks like this isn't the text that is being used by the form. I will try to find it later. -- User:Docu at 10:17, 14 November 2009 (UTC)

{{Editprotected}}

The text that is used is in MediaWiki:UploadFormPreviewOverwriteError, would you copy it there too? -- User:Docu at 10:21, 14 November 2009 (UTC)
✓ Done -- :) -- Huib talk 10:30, 14 November 2009 (UTC)
Thanks. Much better :)) -- User:Docu at 11:44, 14 November 2009 (UTC)
You're welcome, you know that edit protected request would be handled much faster on my talkpage right? But the edit protected category is one of my pages I open on start up :) Huib talk 12:15, 14 November 2009 (UTC)

Localization

Hi, please, look at this. emijrp (talk) 19:39, 1 December 2009 (UTC)

Autoconfirmed check for basic upload form hacked out

After an IRC request by User:effeietsanders I have hacked out the check that disallows unautoconfirmed users from using the basic upload form, since it messes up the "NL Wiki Loves Monument" project. Effeietsanders has stated that he will work with User:Multichill to devise a proper fix as soon as possible. -- Bryan (talk to me) 12:57, 6 September 2010 (UTC)

user set standard languages for the description fields possible?

User:Romaine asked me in IRC:

How can I add automatically more languages to the uploadpage (for descriptions in plus two languages)? I would like to have four languages each time I open the Upload form http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=ownwork

MediaWiki:UploadForm.js adds the two standard languages to the form (if I see it correctly). The function call which adds a language seems to be: 

UploadFormFull.addDescField (table, lang, idx++, stored_form);
Solution idea:

Is it possible to query a user set variable (in monobook.js) which contains a list/array of preferred standard langages for the form. And then adde them instead of the two standard ones? Cheers --Saibo (Δ) 17:10, 3 June 2011 (UTC)

hmpf.. found: MediaWiki:UploadForm.js/Documentation#Initial_languages_for_descriptions ;-) --Saibo (Δ) 17:13, 3 June 2011 (UTC)

Changes to the code

Hey. Could someone from here take a look at this, please? Rehman 14:01, 2 December 2010 (UTC)

It's awful quiet in here... Rehman 03:48, 8 December 2010 (UTC)

The text of the script does not contain information about its documentation. I came across it by searching. Information in the discussion is not always an effective solution. I suggest placing a link to the documentation at the beginning of the script. Ency (talk) 15:11, 15 February 2011 (UTC)

Shortcut for preview button

{{Editrequest}}

Could somebody with the necessary rights and some JavaScript skills please add a shortcut for the preview button so it is on par with the preview button when editing articles as well as the upload button? This basically involves three easy steps:

  • Set the accesskey="p" attribute on the preview button. This will trigger the button when pressing the browsers default shortcut sequence and the "P"-key (e.g. Shift+Alt+P in Firefox). This should probably be done in the UploadForm.addPreviewButton function.
  • Update the localized tooltip texts (MediaWiki:UploadFormPreviewButton) to show something like Preview the final image page [p] (note the p in square brackets, this is important!).
  • Add mw.util.updateTooltipAccessKeys($('#wpUploadPreview')); to the function UploadForm.addPreviewButton (somewhere near the end). This updates the [p] in the tooltip to show the actual shortcut needed in the browser currently used.

Thanks in advance, --Patrick87 (talk) 02:14, 17 May 2013 (UTC)

Vorschlag: 

      previewButton.setAttribute ('style', 'margin-left: 0.5em;');
+      previewButton.setAttribute ('accesskey', 'p');
+      if (mw && mw.util && previewButton) mw.util.updateTooltipAccessKeys([previewButton]);
      uploadButton.parentNode.insertBefore (previewButton, uploadButton.nextSibling);

-- Rillke(q?) 23:09, 17 May 2013 (UTC)

Yes, that's exactly what I intended! --Patrick87 (talk) 23:28, 17 May 2013 (UTC)
✓ Done in this edit. Instead of manually changing MediaWiki:UploadFormPreviewButton and its umpteen localisations, the code adds the "[p]" if not yet present. Lupo 10:35, 20 May 2013 (UTC)
Great, thanks! Nice idea appending the title text automatically. This way the shortcut could always be changed without much effort (although I don't think this will ever be necessary). --Patrick87 (talk) 14:47, 20 May 2013 (UTC)

Flickr for HTTPS

{{Editprotected}}

Please change this form to accept HTTPS links to Flickr, as it is currently causing errors whenever I fill out the "Source" field of the Special:Upload for Flickr form.

The error is located here: 

      if (!UploadForm.verifyMandatoryField
            (src,
             function (src)
             {
                var flickr_ok = !UFUI.isFromFlickr ||
                                src.search (/http:\/\/(www\.)?flickr\.com/) >= 0;
                if (!flickr_ok) UploadForm.errorMsgs.push ('wpFlickrURLError');
                return flickr_ok;
             }
            )
         ) 
      {
        src.onkeyup = UploadForm.resetBg;
        ok = false;
      }

Thanks, --TeleComNasSprVen (talk) 06:26, 27 April 2014 (UTC)

✓ Done. Lupo 12:04, 27 April 2014 (UTC)

Possible bug: custom license templates not recognized

Hi, I just uploaded File:"Movbild-fizika" falo en Big Buck Bunny.webm. I used Special:Upload with this gadget to do so, and I think I found a bug in that it didn't recognize {{Big Buck Bunny}} as a valid license template; it told me to add a source, an author and a license (already when I tried to preview) although I had put that template into the permission field. I think this should either have a way for the user to dismiss that error (and still get a preview), or instead of checking whether it contains a valid license template, should check whether it is in a valid license category. darkweasel94 18:14, 17 May 2014 (UTC)

Create a redirect CC-Big-Buck-Bunny and use that. Lupo 19:00, 17 May 2014 (UTC)
Ah, it checks by the template name? I understand, I will do that the next time I have this situation. Thanks. darkweasel94 19:10, 17 May 2014 (UTC)

fileexists-extension warning incorrectly causes upload form to think the file is being overwritten

{{Editprotected}}

If you try to upload a file with the same name but different extension, this upload js incorrectly thinks you're overwriting the file due to the mediawiki:fileexists-extension message. It then greys out the preview button. One possible solution would be to replace the isOverwrite function with: 

  isOverwrite : function ()
  {
    if (document.getElementById ('wpUploadWarningFileexists') != null) return true;
    var destfile_warning = document.getElementById ('wpDestFile-warning');
    if (destfile_warning == null) return false;
    var dest_file = document.getElementById ('wpDestFile');
    if (dest_file == null || dest_file.value == null || dest_file.value.length == 0) return false;
    var lks = destfile_warning.getElementsByTagName ('a');
    if (lks == null || lks.length == 0) return false;
 
    var fn1 =
      dest_file.value.replace(/^\s\s*/, '').replace(/\s\s*$/, '').replace(/ /g, '_');
    fn1     = fn1.substr (0, 1).toUpperCase () + fn1.substring (1);
    var fn0 = 'Image:' + fn1;
    fn1     = 'File:' + fn1;
    // Trimmed, blanks replaced by underscores, first character capitalized
 
    for (var i = 0; i < lks.length; i++) {
      var href = lks[i].getAttribute ('href', 2);
      if ( $( lks[i] ).hasClass( 'new' ) ) continue;
      if (href.indexOf (wgScript) == 0 || href.indexOf (wgServer + wgScript) == 0) {
        var m = /[&?]title=([^&]*)/.exec (href);
        if (m && m.length > 1) href = m[1]; else href = null;
      } else {
        var prefix = wgArticlePath.replace ('$1', "");
        if (href.indexOf (prefix) != 0) prefix = wgServer + prefix; // Fully expanded URL?
        if (href.indexOf (prefix) == 0) href = href.substring (prefix.length); else href = null;
      }
      if (!href) continue;
      href = decodeURIComponent (href).replace (/ /g, '_');
      if (href == fn0 || href == fn1) return true;
    }
    return false;
  },

Specifically, I added the line if ( $( lks[i] ).hasClass( 'new' ) ) continue;. (Issue originally pointed out by User:Darkweasel94 on irc). Bawolff (talk) 23:22, 17 May 2014 (UTC)

✓ Done Thanks for pointing this out. Must have changed since this code was written... funny that is does give the same warning as for overwriting. I would have expected a separate warning message with better tailored text. Lupo 23:38, 17 May 2014 (UTC)

Misleading name

Hi!

@Lupo: Thanks for Special:Diff/146016158!

Could you rename that variable "globalUserLanguage" to not say that it is "global" (which it isn't)? Helder 16:41, 12 January 2015 (UTC)

It is a local copy of the "global" wgUserLanguage. Since that is used only inside a function, I think that name is fine. But I can also rename it to localReferenceToGlobalUserLanguageSetting. Lupo 18:06, 12 January 2015 (UTC)

Obsolete HTML

I believe this is the script which adds the obsolete HTML attribute "width" to the div with id "wpDestFile-warning" (and to the td element around it), in the page for uploading a new version of a file. Could someone update it to use CSS instead? Helder 21:40, 24 January 2015 (UTC)

Broken JavaScript

MediaWiki developers found that this page probably breaks JavaScript for users (example: not seeing the buttons when editing a page). You probably need to edit this .js page and/or MediaWiki:Gadgets-definition as in the examples at phabricator:T122755. List more pages to check.

If you have questions or need help, please ask at phabricator:T164242. You can login with your wiki account. Best wishes, Nemo 09:49, 14 May 2017 (UTC)

Switching between the Improved and Basic upload forms sets the UploadForm cookie, without a sameSite attribute. This behavior will soon not work. 

Cookie “UploadForm” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite index.php:89:40

(on Firefox 78.0.2). AntiCompositeNumber (talk) 17:10, 17 July 2020 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:UploadForm.js/Archive01&oldid=708101585"