Leaving redirects section criteria #5 improvement

There's a time-expensive problem exists while situations covered by Renaming criterion #5. From the view of COM:NOT there have not to be any objects with names containing violation of any rules at Commons. And COM:FNC#Which files should be renamed? really have corresponding criterion, but actions allowed to be provided there is irrelevant as not strict (despite COM:NOT that is usually can be it's reason really is).

COM:FNC#Leaving redirects have a common instruction about when suppression of redirects is allowed including the criterion #5 cases, however it would be much better for criterion #5 cases not to just allow such suppression but request it as mandatory, as if file mover have doubts there's #5 violations exists he can just not to make a renaming, but if he's clear about it really have place - suppression have to be mandatory according to COM:NOT. Example of problem when everything is done according to current policy text, creating the same, but new, issue) is:

1. Added criterion 5 rename request.
2. Rename is done but with creating redirect (that way not suppressing it's creation while moving, that is not restricted by current text, because suppression meant to be as just an option and not a mandatory action)
3. proposed deletion of excessive newly created redirect using G2 criteria of COM:SPEEDY.
4. SD declined with unknown reason
5. (from another case, but still relevant as example as was similar) Decliner approved he did it on mistake and redirect still was later deleted after one more excessive action - SD template restoration.

Here's steps 3-5 are not just time-expensive but obviously excessive and can be easily avoided if policy about rename criterion #5 will be changed to something more strict, i.e. at least here the phrase "When the original file name contains vandalism. (Renaming criterion #5)" have to be moved from "Suppression of redirects is only allowed in the following cases:" to newly formed paragraph telling the next: "Suppression of redirects is mandatory in the following cases:".

That way, if file movers will follow the new policy text, steps 3-5 will never be needed/have place anymore.

Why is it important? Cases, when file name violate policies is not rare at all and such change can dramatically reduce the time needed to finally fix the criteria #5-connected policy violations with no need of any excessive actions including fixing other editor's errorous activity that now just multiple each other exponentially, that really hinders the improvement of Commons.

Also here's told why it can be a good idea.

Any more ideas or other solutions of such issue? 201.150.118.26 22:31, 23 April 2025 (UTC)

mismatch: why the uploader is not informed before/during name change?

Having no problem with name changes by the Bot - I do not understand why the uploader of the original image is not informed before the name adpation; may be he lknows a better sdescription? br Commander-pirx (talk) 12:38, 3 July 2025 (UTC)

@Commander-pirx: It might help if you say what file you're referring to. If a file has been renamed but you know an even better name, it can still be renamed again if necessary. But in general terms, once a file is uploaded here, it no longer belongs to the original uploader and anyone can work with it. -- Auntof6 (talk) 13:30, 3 July 2025 (UTC)

It is just a general note - it happens with two files of me uploaded and the name change is o.k., and yes I know your second statement, but beeing polide to each other and friendly is possible. And renaming without asking is someething unprofessional in my eyes. br --Commander-pirx (talk) 18:01, 3 July 2025 (UTC)

@Commander-pirx: What template would you have us use? How long would you have us wait for an answer? Uploaders are supposed to watch their uploads for rename requests.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:50, 4 July 2025 (UTC)

Yes, that's what I do. Every pic that I upload remains on my watchlist forever. That's only about 10,000 but some have sent many more and may find this more difficult. Jim.henderson (talk) 11:27, 6 July 2025 (UTC)

As someone who has uploaded thousands of BSicons, where technical name changes and corrections are incredibly common, getting a notification would be an absolute nightmare for me. If I disagree, I can respond to the name change on my watchlist. But my talk page would be flooded with meaningless templated messages if this were to be the norm. VanIsaac (en.wiki) 18:31, 6 July 2025 (UTC)

problem with the rename template

I have a problem with the rename template, please see at the technical village pump. I’m not quite sure, if this really is a technical question or if the template shall show the target name like this, if it’s supposed to do this or why the name is shown this way. Therefore, I’m not sure which page is the right one to ask this. If anyone here has an idea about that, please post it on the other page. But I also think, if this is not a technical issue, then it would be better here instead. —176.1.3.87 18:57, 12 July 2025 (UTC)

The file has been renamed now without a problem despite this error (see permanent link to village pump now). The error can’t be seen anymore after renaming, neither on the file page nor in the version history. I’m quite sure now that this has been a technical problem and that it was not supposed to do this, otherwise the renaming itself would also have been problematic, but noone seems to have any idea about it that could really be the reason for it. This case should be watched in the future, if the display problem occurs again with the rename template especially when renaming from one extension .jpeg to another .jpg or something like that (.JPG to .jpg or .JPEG to .jpg or whatever else someone can imagine, if not complete different formats are used). —176.1.3.87 13:14, 13 July 2025 (UTC)