Please stop revert war

There is way to have Translate not mark translations with unused variables as not fuzzy if this is reported . There is also a possibility that this issue will be fixed in UploadWizard if it is reported to the developers in Phabricator.

Again, it's not my duty to fix UploadWizard.

Again, qqq is not the way to communicate with developers. That's what the "Ask question" button is for. It will leave a message in this wiki, which can then be relayed to Phabricator, if necessary.

But all my time goes into trying to make you understand this. I am going to revert the changes to the message documentation since you did not do it. I will block you if you will try to add them back again.

This question is not manage here but on the actual project where this is discussed. If there's a way to mark translations as not fuzzy, you should document it and explain that to project maintainer (how can they instruct your linter). For now there's no problem at all with the solution exposed, the bug reported on Commons only affects Commons where the new UploadWizard is still in testbed and has various other bugs reported. It start appearing only in January with the recent new version deployed there (but not on other wikis). The need to localize the link is there since the beginning in 2011. The workaround using the commented placeholder has been working since long (except since January on Commons with the new version deployed only there and that has other problems).

No I did not make an edit war, because there's been a precision added on where the commented placeholder (still needed) can be placed (not within the link itself, which was working for many months before and stopped working only in the new UploadWizard only in Commons, but after it: until now this placement was not explicitly indicated because it was not necessary): it was a different solution: There's been a change to place the comment after, and really it works as a workaround for the new UploadWizard bug, but still also with the previous version used everywhere else.

Your revert will just cancel the documented requirement and desire to localize this URL which is there since at least 2011 (not added by me, present since the beginning where it was initially part of an autotranslated template that was present on Common since much longer than just 2011) and this has not been removed.

We currently cannot honor both the 2011 requirement and the (fuzzy) absence of the $2 placeholder when instructions already request to replace the URL.

And asking to Wikimedia developers to use fuzzy translations is a really bad idea you had it is a severe trick when this resource has always been (and remains) a resource in MediaWiki syntax where HTML comments are still safe (and documented as a core feature used everywhere in all MediaWiki wikis).

There will be further bug fixes in the new UploadWizard but the workaround for this case is simple and it really works (those that say the opposite have actually not tested it, they just see the current bug when the comment is at start just gkued before the wanted repleced URL.

I have implemented an alternative workaround where a missing parameter will no longer cause these messages to be fuzzy. However, since you disobeyed my instructions, I have given you 24 hour block.

And you've not followed the actual bug which was finally recognized in the code and just corrected today ! Before that there was a need of workaround (for the previous version that worked since 2014, only the new version deployed in Commons in January was affected by this bug).

There were also bugs (still remaining) in the way the resources on Translate wiki were imported into the new version (by jenkins-bot) directly as JSON strings with incomplete pars ing.

However the new version still requires Javascript and the classic server-based form still uses the MediaWiki parser which correctly strips the HTML comments and still require them.

The confusion was also in the wrong instructions given at top of the message, asking to adapt the URL, something that actually have NEVER worked and will now NEVER work with the new client-side Javascript-based upload wizard.

So all I did was to signal the bug, and find a workaround for the current standard version (working in the legacy version, before the beta that was deployed in Commons in January without having been really tested!). Only Commons was in trouble (because of the early deployment of this beta), not any other wiki !

Still the beta now on Commons does not work correctly, as it now requires Javascript and the legacy code (which was entirely server-based) has been broken ! This new UploadWizard is then not part of standard MediaWiki, it canot be deployed elsewhere.

The "jenkins-bot" tool that import and convert these strings to JSON files on the repository still needs fixing to correctly support both versions (the new "cute" javascript version, and the classic form processed by the server and not requiring any javascript but with less assistance for selecting licences.