Commons:Upload Wizard feedback/Archive/2018/02

Links to license are broken

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 https://commons.wikimedia.org/wiki/%3C!----%3E//creativecommons.org/licenses/by/4.0/deed.fr . 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 [//commons.wikimedia.org/wiki/<!---->//creativecommons.org/licenses/by/4.0/deed.fr 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/deed.fr]. Does it work? Lofhi (talk) 14:06, 14 February 2018 (UTC)

@Verdy_p: A translatewiki.net admin doesn't seem to agree with you ([3][4]).

In any case, the translations fixed with [$2/deed.fr] were deployed a few days ago and the URL now shows https://commons.wikimedia.org/deed.fr, so this fix doesn't work. --Thibaut120094 (talk) 15:20, 28 February 2018 (UTC)

@Thibaut120094: I had already alerted that this [$2/deed.fr] would not work, and my solution was already correct and fixed it!!! Now you are reverting my solution (exposed in "/qqq" on TranslateWiki.net) 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 Translatewiki.net.

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 :

• Translatewiki.net wants the "$2" or makes the resource fuzzy (exported by Translatewiki.net 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)