Mar 6 2020
This problem was originally mentioned in T200173 which was never assigned to anyone. It has to do with the special characters (in this circumstance the pipes) in the file name that cause the rendering to fail.
Nov 6 2019
It appears that @Roy17 completed the translation the other day. Thank you! @DannyS712 looks like you are good to go unless there are any other issues. I've taken the liberty of switching the task back to open, hope that is alright.
Nov 3 2019
Nov 2 2019
@DannyS712 If there could be some sort of notification before this is implemented I would appreciated it. I have email notifications enabled so just a simple post in this ticket would be fine. That way I can time the mass message to when this is deployed. Don't want people to accidentally stumble into this right before they understand what is expected of them. We also don't have the message translated fully. A Chinese translation is still being sought.
Oct 7 2019
https://commons.wikimedia.org/wiki/Special:AbuseFilter/216 appears to be doing the work of this requested change already. It is only catching anon edits though and is set to tag and log anything less than 9 characters.
Aug 2 2019
@Aklapper: Do we know if anyone is taking a look at this or if there is even a rough ETA? Otherwise I can just grab the deleted version and reupload it for the time being so that the projects can have their image back.
Aug 1 2019
Jun 27 2019
This seems on par, if not worse, than not being able to move galleries (T224303) which was tagged as high priority. Sorry if I'm overstepping but as this is Commons and files are our thing this seems appropriate. Also, this appears to have started when T224303 was solved so probably directly related to that.
Jun 26 2019
So, whatever fix you all implemented to fix the ns 0 issue now appears to have broken moving files. I'm getting the same permission error I got with the gallery namespace. It is not just me either per https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Moving_files
May 2 2019
Well at least I know it isn't just me. Thank you for that. Just for minor troubleshooting notes I tried it on one revision, multiple revisions, text revisions, image revisions, small pages, large pages. Nothing seems to work. Always times out.
Jan 28 2019
@Tgr Would it be possible to also add the upload_by_url right to the patroller group per https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=336738154#Make_the_%22more_upload_options%22_proposal_apply_to_all_user_accounts_with_autopatrol_flag? Or should I create a new ticket for that?
Jan 20 2019
Jan 17 2019
@AlexisJazz Obviously there was some confusion between user groups and user rights which is understandable. I personally don't have a problem with including the patroller user group in this request since, as you said, patroller is an "upgrade" to the autopatrolled group as it is currently defined on Commons. I didn't read your original proposal as meaning "add upload_by_url to every group that has the autopatrol flag" but I guess I could read it that way also. If another RfC is required to grant the flag to the patroller group as well then so be it. But that would be up to the devs who actually make those changes whether or not they want to include the patroller group since it is set up to be an extension of autopatrolled on Commons.
Nov 27 2018
I would have to agree that the ability to block the person who blocked you would mitigate the problems with small wikis that have very few admins that the removal of this permission presents. At least with that there is the ability to stop the damage being done if the entire admin staff is blocked by a compromised account. Non-compromised accounts can be easily unblocked and the vandalism would be stopped. As for rate limits I really don't think that is a good idea. The limit would need to be set so high as to be rather useless as to not interfere with the normal administrative duties that occur.
Why was this done globally instead of just to enwiki as requested? No other project requested this as far as I'm aware. To remove unblockself from all wikis, especially smaller ones where there are only one or two admins, raises a bunch of problems. It would be better if the devs only did this on the projects that requested it instead of extending the massive paranoia to every single project.
Nov 10 2018
Not to put a damper on this idea but did we all forget about cascading semi-protection? That was removed because it would have allowed non-admins to perform admin actions. Unless we were to restrict adding and removing categories to admins only this would allow anyone to block people under this type of partial block from additional pages. Which is something that should probably be avoided.
Oct 18 2018
Apparently this is greater than one image. So far 15 images could not be successfully deleted per https://commons.wikimedia.org/wiki/Category:Deletion_bug