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.

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.

In T236348#5629042, @zhuyifei1999 wrote:

I can do a Chinese translation as a last resort tomorrow, but it might not be great / idiomatic and will probably sound weird.

On a side note, it's interesting to see how presenting an actual problem creates completely different discussions.

In T236348#5628882, @Masumrezarock100 wrote:

@Majora Just to clarify, do you mean a notification to you?

@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.

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.

@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.

In T226672#5288494, @Aklapper wrote:

Going to a random file, it's displayed for me:

Unfortunately there are no clear steps to reproduce including specific links in this task.
I assume this is about Monobook skin? Any problems with other skins?

Please also try safemode, see https://www.mediawiki.org/wiki/Help:Locating_broken_scripts

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.

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

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.

@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?

In T214003#4895043, @Zoranzoki21 wrote:

Is here still consensus for doing this?

In T214003#4889298, @AlexisJazz wrote:

@Zoranzoki21 as you claimed this task, do you agree the proposal included all autopatrolled users, so also patrollers and bots? If not, I'll just request for those 687 users to be granted autopatrol.

While deployment of this request, extended-uploader can be migrated to autopatrol via this script.

@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.

In T214003#4888247, @AlexisJazz wrote:

In T214003#4888199, @DonTrung wrote:

Would this then also automatically give these permissions to "patrollers"?

Autopatrol is included in patrol.

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.

In T150826#4776565, @MusikAnimal wrote:

I'll note the relevant recent vandalism has occurred on wikis other than just enwiki. It stands to reason the account compromises that enwiki saw can and will happen elsewhere.

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.

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.

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

In T125459#2265814, @tom29739 wrote:

In T125459#2262499, @Josve05a wrote:

In T125459#2262353, @kaldari wrote:

@Tnegrin: Yes, we are still considering Google. If nothing pans out with Microsoft on Monday, it seems like it will be the only option still available. And yes, we'll need to talk about funding for it.

How about an impromptu (is that the right word?) fundraising banner (read 'edit notice') and all money generated goes directly to this...😋

That would be a good idea, but it would have to be not intrusive. Massive banners asking for people to give money would annoy people. A sitenotice could be used too.