Commons:Upload Wizard feedback

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

Share your feedback
Report bugs
Your feedback about the Upload Wizard

This page is a place for you to share issues you encounter when using the Upload Wizard interface. However, this page is not frequented by developers.

Add a new comment

Other important resources:

To resolve issues, it helps us to have exact steps to reproduce. Please also read the Questions and Answers page and check the archives.

Archives (older archive dates indicate date of initial comments and may span several months; newer archives span one month per archive and are generated by MiszaBot):


Not sure how the heck of the day before yesterday Rio de Mon iPhone Android

— Preceding unsigned comment added by Theonlyson (talk • contribs) 11:39, 08 December 2016 (UTC)

North Korea Lambarst United States Foreign Policy[edit]

The universe is looking atentively at the two pride propeled:nations! the intimate North Korea and the Great American fingerpointing/warning.But its going to take us another decade,to change our thoughts behind the hazing/mesmirising attitudes/behavaiors of the main land USA/CHINA to "twist the tiger" by its tail/tale.For the law of the jungle is nay/near,no its occuping the physio/psycho,psychatric arteries/artilaries of an avarage heart/brain mind of an independent/sovereign itelect, expects/ —Preceding unsigned comment was added by (talk) 12:44, 18 April 2017 (UTC)

Photo upload Wizard problem[edit]

Good day Admin

I have been trying to submit my pictures for wiki loves Africa however, the photo upload wizard is stuck on release and is not moving to next for the description. What can i do?



— Preceding unsigned comment added by Bnkaw1 (talk • contribs) 09:47, 30 November 2017 (UTC)

Cannot upload a file via MediaWiki UploadWizard[edit]

Hi All,

I've tried to upload a file to Wiki Commons using the MediaWiki UploadWizard I've just installed but any upload stalls. I'm trying to upload a 15kb file size but hangs - no errors and the progress bar time keeps on climbing.

Below is the environment I'm trying on with versions:

Upload Wizard 1.5.0 GPL-2.0+

Product Version MediaWiki 1.26.0 PHP 5.5.9-1ubuntu4.17 (apache2handler) MySQL 5.5.46-0ubuntu0.14.04.2 ICU 52.1

Thank you in advance :-)

— Preceding unsigned comment added by Francke1 (talk • contribs) 10:21, 8 February 2018 (UTC)

Links to license are broken[edit]

Hi, when I click on Upload a new file, then I select a file I want to upload, the next page ask me whether I ma the author of the file. If not, then the tool ask me to sepcify the origine of the file, its author and its license . About the license, there are some links to the right that are supposed to point to the creativecommons website. However, if I click on of them, the link does not work. Indeed, the link points to!----%3E// . Do someone know how to fix that? Pamputt (talk) 14:54, 11 February 2018 (UTC)

Pamputt: The error seems to be specific to the French translation. I'm guessing there's something wrong with translatewiki:MediaWiki:Mwe-upwiz-license-cc-by-4.0/fr. Maybe User:VIGNERON or User:Verdy p know something. LX (talk, contribs) 20:35, 11 February 2018 (UTC)
Note that the German translation looks similar to the French one. Do they experience the same issue? For the reste, I let VIGNERON or Verdy p do something. Pamputt (talk) 20:39, 11 February 2018 (UTC)
I tried to fix it last month but I'm not sure what is going on here and I'm dont understand why Verdy p replaced [http:// by [// (the same thing was done for other messages like translatewiki:MediaWiki:Mwe-upwiz-license-cc-by-4.0/de). Cdlt, VIGNERON (talk) 20:45, 11 February 2018 (UTC)
an URL starting by "//" is protocol relative and useful for those that have problem connecting with HTTPS: if a user is on a wiki loaded with HTTPS and see this message it will link to the external site with HTTPS too, other wise it will link with HTTP. Note that Creative Commons allows navigating their site in both HTTP and HTTPS. The reasons why HTTPS may fail is that it requires a certificate that may be rejected in some browsers or juridictions, or it could use an encryption algorithm or strength not supported or refused by a proxy (considered as insufficiently secured, or on the opposite considered too strong and locally illegal). Normally HTTPS includes a mechanism to allow negociating the level of security and algorithms supported, but sometimes it will fail if there's no way to match the same minimum support and requirements by both sides, notably if they don't have the same set of algorithms (this is rare but this happens: we have browsers not implementing SHA384 or SHA512 and servers not allowing less than SHA384, same thing about cyphers, block encoding, signature strengths... Normally a server certificate incldues several mechanism but none of the proposed options will work from the client; if all fails, HTTPS requires not falling back automatically to unsecure HTTP; as well this may fail if a server certificate suddenly expires and was not renewed by a new certificate: the client won't be able to connect because an invalid or expired certificate is equivalent to a certificate proposing no secure algorithm at all, so the lcient will not even attempt the connection further). verdy_p (talk) 20:54, 11 February 2018 (UTC)
See fr:Wikipédia:Le Bistro/17 janvier 2018#Upload Wizard sur Wikicommons, the problem comes from <!--$2--> [1][2].
And yes, the German translation and all translations that have this comment have this problem. --Thibaut120094 (talk) 08:13, 12 February 2018 (UTC)
Ok, so this seems to be a bug. Is there already a Phabricator ticket about it? Pamputt (talk) 08:51, 12 February 2018 (UTC)
No, we just need to remove this comment. --Thibaut120094 (talk) 08:52, 12 February 2018 (UTC)
Actually no! the top banner in this resources (existing since the begining in 2011) instructs users to replace the URL in parameter to localize it. This have been since the begining (at least since 2011) used to translate a regular Mediawiki template (and this is still the case: that resources is not jsut used by the new (incorrectly tested) version of the UploadWizard, which incorrrectly parses the Mediawikicode using its own broken parser, in order to generate the HTML itself by locatin the URL.
Then it performs an additional check under an incorrect assumption: if the "weakly parsed URL" does not start by "//" or "http:" or "https:", it incorrectly assumes that this is an internal link, as if the translated resource was containing a wikilink (this has NEVER been the case here, this assumption is false). So the new incorrectly tested UploadWizard recently deployed on Commons now incorrectly transforms the URL given by prepending the base URL of wiki pages, so you recently got the final URL [//<!---->// texte légal]: only the new version of the UploadWizard (recently installed on Commons) transforms the given valud URL by prepending the base URL of Commons, as if the URL given by the transaltion was a wiki page name (this has never been the case!)
  • This is a regression bug on this new version of the UploadWizard (currently only used on Commons as a "testbed" and nowhere else on other wikis, and many more bugs pending in this new code) because it makes the confusion between wikilinks and external links in this case in a resources where it has ALWAYS been an external link, so where there should not even exist any case where you'll prepend the base URL of local wikipages !
If the new version wants to permit the specification of URL or "full pagenames" here, it has to support the basic MediaWik syntax to detect it correctly (the translated resource includes only the Wikisyntax for external URLs as [$2 legal text] and not wikilinks as [[$2|legal text], and to allow such automatic transforms to permit the use of full pagenames would require more work. But anyway, you should use correct parsing, and a <!--$2--> has never meant in Mediawiki that it was the start of a pagename, the code [<!--$2-->//domain/path text] being still valid since ever in MediaWiki for external links and never meaning an internal link !
How to solve it: we can workaround immediately the fake detection of a local pagename by the new implementation of the UploadWizard: the commented placeholder <!--$2--> can be placed outside the link. But it remains necessary in the translation because its absence will cause TranslateWiki to instantly mark the submitted translation as "FUZZY", if the "$2" placeholder is missing (TranslateWiki is currently not hinted by instructions for its internal "Linter" to ignore some missing placeholders that could be optional).
Translatewiki can still export fuzzy resources, but using fuzzy resources in any project is a very bad idea when they should be completely ignored (using fuzzy resources instead of valid fallbacks or instead of the default untranslated English) means that you'll introduce severe bugs in various places, and anyway any translator on TranslateWiki will see that these resources are fuzzy and will want to correct it.
The solution I propose is a workaround for the current bug existing only on the new (incorrectly tested) version of the UploadWizard (used only on Commons), it does not break previous implementations of the UploadWizard used in all other wikis. And it won't pollute TranslateWiki by fuzzy translations that we should NEVER use anyway (and that we should not need to export at all from TranslateWiki, except for debugging/investigations).
Until now, it was sufficient to place the <!--$2--> placeholder in comments exactly where the $2 was present in the untranslated string in English, and no other change was necessary. But now the instructions are more clear about where and how to place the $2 placeholder in HTML comments: not within the link itself.
  • And you should ask to TranslateWiki to add support of hinting instructions for its linter, in order to be able to specify how many (min and max) occurences of a placeholder are required (by default all placeholders should be present once and only once in the translated resource to avoid that translated resources to be immediately marked as "fuzzy", and shown with strong alert notices about the absence of "$2$2 if you've replaced it, when selecting it the resource in the translate tool and editing it: you immediately see the instructions saying that the URL should be localized (this strong red banner has always been there at least since 2011 when it was first created or imported on TranslateWiki), and the yellow bar just above it saying that $2 is missing (we have a contradiction and we must find a way to solve it).
I've found a correct solution with the workaround recently updated to precise where we can safely place the missing $2 placeholder if we really want to honor the translators instructions given since 2011. Reverting this solution does not work (it goes against the initial objective of having the URL localized to show the correct translated "deeds" on CreativeCommons site, instead of letting the CC site decide which language to display, which is not necessarily the same and not necessarily the language effectively prefered by the user, because browser's settings are not necessarily transmitted to the visited website, or bcause these settings are unaviailable in his browser, or they are staically set to another language than the language prefered by the user !).
But before claiming that "my solution does not work", you should really test it (this is not what is currently currently in Commons where the commented placeholder is still at start glued before the replacement URL).
  • Reverting to the version using only [//modified-URL legal text], i.e. removing the comment completely, will not work: the fuzzy translation from the TranslateWiki export is ignored, a fallback or English message will be displayed instead of the missing tranlation, and the link will go to the deeds page written in an unspecified language, as can be seen for example in the current Chinese version where the clicked URL will display an unspecified language !).
The $2 must be present in the translated source because it is present in the original text and there's no other instruction given to the Translatetool to indicate that the absence is valid. Please don't do that, because it just has the effect of canceling the translation completely (the message will then not be translated). Removing only the HTML comment marks also forbids you to loclaize the URL (as this has been the case since many years and it is still the case on all other wikis using the previous version of the UploadWizard). verdy_p (talk) 21:14, 12 February 2018 (UTC)
Or just try [$2/]. Does it work? Lofhi (talk) 14:06, 14 February 2018 (UTC)
@Verdy_p: A admin doesn't seem to agree with you ([3][4]).
In any case, the translations fixed with [$2/] were deployed a few days ago and the URL now shows, so this fix doesn't work. --Thibaut120094 (talk) 15:20, 28 February 2018 (UTC)
@Thibaut120094: I had already alerted that this [$2/] would not work, and my solution was already correct and fixed it!!! Now you are reverting my solution (exposed in "/qqq" on for something that still does not work, and messages are fuzzy once again and ignored if you don't use a "$2" anywhere in the translation. And you are looking at the effect on commons, where the code is not in sync with the translations in
I had made a correct fix, everyone wants to ignore it, and every one seems satisfied by the fact the translators are asked to replace the URL... but they can't, as the translation is then ignored completely, showing the message in English and the link to the English deeds!
My solution was not complicate (yes it was a workaround, but not harmful at all, and it had no cost at all). This fixed the bug that occurs ONLY in Commons and not anywhere on other wikis where an older (non-beta) version of the Upload Wizard is used. Unfortunately you are fixing things in TranslateWiki because of a bug in the new beta version of the UploadWizard deployed on Wiki since January, a bug that does not exist anywhere. My workaround was compatible with both the older (stable) version (deployed everywhere else), and the new (beta) version used only by Commons without any prior tests ! You are now breaking all wikis (including Commons!) that will only display the English text and the English link in their local upload wizard.
May be an admin still does not agree, but he is wrong because he does not look at the correct place to test it (if he looks at the results in Commons, this is not the same resources that are loaded there)... This admins hould look by trying editing the message locally on Commons to see the result, and test it on other wikis not using the new beta version now in Commons. He will see himself that I was right :
  • wants the "$2" or makes the resource fuzzy (exported by but ignored by the import tool, like all fuzzy resources).
  • So there must be a way to insert $2 in the string in a safe place. Yes this works if "$2" is in HTML comments (but not within the place where the URL is inserted, only outside of it: before or after the brackets, it does not matter).
This bug occurs in the new beta UploadWizard which does not parse HTML comments correctly where it expects an URL after the opening bracket as it expects only "http://" or "https://" or "//", and otherwise thinks it is a pagename possibly with interwiki or namespace prefixes: this beta makes a confusion between external links in single brackets and internal/special/interwiki links in double brackets, because it uses a function normally used only for the "link=" parameter in images where you can specify both and there's a "guesser" to see if the link is internal or external; in both cases, this "guesser" should first strip HTML comments, then compress whitespaces and remove leading and trailing whitespaces !).
verdy_p (talk) 18:54, 28 February 2018 (UTC)

Uploading files while adding descriptions[edit]

Now the Upload Wizard has two steps for uploading files and then adding descriptions. That means you have to wait the wizard to fully upload all files before you start to fill in a form. These two steps could simply be unified. Uploading process could be simultaneously ongoing while adding descriptions. Many minutes of working (actually waiting) could be saved I believe. --Janezdrilc (talk) 20:28, 24 April 2018 (UTC)

That would be pleasant. Whether it will happen . . . Jim.henderson (talk) 18:14, 26 April 2018 (UTC)