Commons talk:File renaming/Archive/2023

Filemovers, please dont move files if some ongoing discussion pages depend on the name, unless necessary

including but not limited to COM:DR, COM:FP, COM:POTY etc. bad example: https://commons.wikimedia.org/w/index.php?title=File%3ABuffalos_at_H%C3%BCrmet%C3%A7i_Wetlands%2C_Kayseri%2C_T%C3%BCrkiye.jpg&diff=prev&oldid=751270652&diffmode=source , causing disruption to POTY voting.

if it's being DR, and the result ends up as deletion, then the move is pointless. in any case, moving files in these situations often cause confusion. please use common sense and exercise caution. only criterion 5 would justify immediate action. RZuo (talk) 13:02, 17 April 2023 (UTC)

This should be easily handled by the redirect left behind. I fail to see the problem here. Some of the discussions about images can go on for months and it's clearly unacceptable to refuse to process a legitimate move request for a long time, just because someone, somewhere on Commons is discussing the picture. The only specific mention of not moving files due to external factors, is in case the image is marked as a potential copyvio.

edit: That said, the referenced file rename is clearly not a Criterion 4 rename and I do wish people would stop abusing Criterion 4 to make all files in some random set adhere to their preferred naming scheme, and I do wish file movers would stop actually moving images with such requests. TommyG (talk) 05:58, 18 April 2023 (UTC)

not all discussions depend on the name. the examples i mentioned create pages using the filename. it's always confusing when the page is at "commons:.../file:a.jpg" but the file is at "file:a xyz.jpg" . redirects wont prevent the confusion. only solution is to also move the discussion page, which many filemovers neglect. still, that should be discouraged.

only discussion about file that can go on for months is DR. as i said, those moves are often pointless. RZuo (talk) 08:58, 18 April 2023 (UTC)

Renames per privacy reasons

Hello mates, Three files have been asked to be renamed (under Criterion 6): File:Peer Zada Mohammad Iflaq at WCI 2023 (1).jpg, File:Peer Zada Mohammad Iflaq at WCI 2023 (2).jpg and File:Peer Zada Mohammad Iflaq at WCI 2023 (3).jpg. The requestor says, "Reducing fingerprints per privacy reasons". It does not meet Criterion 6 but I am inclined to accept the request because we at Commons care for the privacy. Any other observations? Pinging @511KeV if he has any thing else to offer. Should we have another criteria for renaming that takes care of privacy of Wikimedia contributors or so? ─ The Aafī (^talk) 15:06, 9 May 2023 (UTC)

I didn't see this discussion before now and declined those requests, since as you say, they are obviously not criterion 6 renames. This would more easily be resolved by this user asking the original uploader to file rename requests removing his name from the filenames. TommyG (talk) 17:18, 9 May 2023 (UTC)

We have (5) "To change a filename that would be a violation of Commons’ policies and guidelines if it appeared elsewhere on the project as text. This includes [...] cases where revision deletion would be authorized." I think the privacy concern fits the description and I see no reason not to accept the request. The files do not seem to be in use (other than in the list of declined rename requests), so the renaming will not break any links on Wikimedia projects, and we shouldn't name contributors who wish not to be named. –LPfi (talk) 17:18, 9 May 2023 (UTC)

@LPfi, thanks, this looks pretty much clear. "Non-public identifying or personal information" #5. Thanks a lot. ─ The Aafī (^talk) 05:08, 10 May 2023 (UTC)

I have renamed the files and asked for a revdel. ─ The Aafī (^talk) 05:16, 10 May 2023 (UTC)

Ajoute d’une candidature

Hello everyone

I'm having trouble finding the page to apply as a file renamer.

Bonjour a tous

j’ai du mal à retrouver la page pour porté ma candidature en tant que renommer de fichiers. —Aboubacarkhoraa (talk) 07:55, 12 May 2023 (UTC)

That would be here: Commons:Requests_for_rights#Filemover. TommyG (talk) 07:57, 12 May 2023 (UTC)

Objecting to a renaming request

I've spotted a file renaming request that I'm pretty sure is inappropriate ([1]), but it's not clear from reading this policy whether there is a way for me, as another editor, to add an objection to this request, or whether I'm allowed to simply remove/revert the request myself? Could someone clarify the appropriate way to proceed? R Prazeres (talk) 19:09, 25 July 2023 (UTC)

I'm not sure of the "proper" protocol, but if you removed the rename template and included your objection in the edit summary, I think that would be transparent enough that it would meet any reasonable objection to a possible breach of the standard course of action. VanIsaac (en.wiki) 19:46, 25 July 2023 (UTC)

Ok, thank you! R Prazeres (talk) 19:56, 25 July 2023 (UTC)

Thanks. I was considering declining the request a couple of days ago when I was going through rename requests, but wasn't quite sure so I left it. It's always helpful to filemovers when people who know more about a subject voices their opinion if a rename request is inappropriate, so please don't hesitate to remove rename requests. If the issue is more complicated, there's always the posibility of taking it up on the talk page of the file. TommyG (talk) 06:31, 26 July 2023 (UTC)

jpg/JPG

Is there any protocol for renaming files with identical names except for whether the extension is lower vs upper case? Example: File:Himeodorikosou.jpg and File:Himeodorikosou.JPG are two different files by different uploaders. Not all computer systems using Commons files distinguish 'jpg' and 'JPG'; such systems will not recognise these as different images. Should one, or both, be renamed, to more distinct names?

Also, when renaming a file, the system automatically converts '.JPG' to '.jpg' - what should one do with trying to harmonise a set of filenames, where their extension is uppercase? Suppose there is an obvious set of files Abcdef 1.JPG, Abcdef 2.JPG, Abcdef 3.JPG, Bcdef 4.JPG, Abcdef 5.JPG, Abcdef 6.JPG; here #4 is clearly a typo (didn't hit the 'A') so it won't index with the rest of the set in categories. But if renamed to add the A, then it will be auto-converted to Abcdef 4.jpg, still out of full alignment with the rest of the set. Is there any way to force retention of the uppercase JPG, or should the entire set be renamed to make them all .jpg? - MPF (talk) 11:55, 11 September 2023 (UTC)

IMO, Commons should not accept .JPG as a file extension, and they should be automatically renamed on upload as .jpg. Idem for .PDF, .TIF, .PNG, etc. This would avoid this kind of issues. Yann (talk) 11:59, 11 September 2023 (UTC)

@Yann: sensible; not sure it doesn't already apply in recent times? But it doesn't help with older files uploaded years ago! - MPF (talk) 12:35, 11 September 2023 (UTC)

I renamed the .JPG file to File:Lamium purpureum (non-native).jpg. Yann (talk) 13:33, 11 September 2023 (UTC)

@Yann: Thanks! Any thoughts about the second part? The names there aren't actual examples as it's a while since I saw the situation crop up and can't remember the actual files involved, but I do meet it from time to time - MPF (talk) 13:53, 11 September 2023 (UTC)

yes, at least 1 file should be renamed to properly distinguish them. i asked previously but no one answered Commons:Village_pump/Technical/Archive/2023/06#Filenames_that_differ_by_capitalisation_of_extension. but i think it's quite obvious that such renames are essential.

there are also cases when files differ by capitalisation of filenames, e.g. file:Danta.JPG file:DanTa.jpg. i also support renaming those files.

i think renaming only 1 of the files while auto-correcting extension is fine. they still appear together in a category in the correct order, because everything up to the dot before extension is enough to sort them nicely.

i think ideally mediawiki should disregard capitalisation of extensions, i.e. all 8 possibilities of jpg should be recognised as the same thing. RZuo (talk) 16:56, 11 September 2023 (UTC)

@MPF: I don't think that names differing only in case warrant renaming under the current criteria, any more than other small differences do. No computer system using Commons files can assume that it can just use the names it finds on Commons in its local file system anyway. Even if they were all guaranteed distinct under case folding (which is impossible because Commons and the local system might use different versions of Unicode that have different case-folding rules), there are characters that Commons permits that other systems do not, such as :.

I don't think the phrase "character handling problems" in criterion 6 covers this case. It's there to handle w:Mojbake and similar things that have damaged a filename on the way into Commons.

It's probably possible to override the case of a renamed file by using the Special:ApiSandbox to hand-craft the correct API operation. Turning off the "AjaxQUickDelete" gadget might also do it. In either case, you'd need to fix up incoming links by hand. I think if you're in a situation where one file of a set having a different extension will actually break things (and not just look inconsistent), I think criterion 4 would justify renaming the entire set. --bjh21 (talk) 23:36, 11 September 2023 (UTC)

@Yann and RZuo: Thanks! Shall I add an example to this effect to Reason #6: Non-controversial maintenance and bug fixes, including fixing double extensions, invalid or incorrect extensions, character handling problems, and other similar technical issues? I'd think it's fair to call it a "character handling problem" - MPF (talk) 17:51, 11 September 2023 (UTC)

Yes, fine. Yann (talk) 17:55, 11 September 2023 (UTC)

no problem. RZuo (talk) 18:16, 11 September 2023 (UTC)

@Yann and RZuo: Done! I used RZuo's Mookcake examples from the village pump archive - MPF (talk) 20:55, 11 September 2023 (UTC)

Is 12 hours of discussion among three people really an appropriate basis for a policy change? --bjh21 (talk) 23:38, 11 September 2023 (UTC)

s/he merely added an example to Template:File renaming reasons/layout. there's technically no changes to the policy. RZuo (talk) 04:38, 12 September 2023 (UTC)

Full width letters

example: File:Ｌｉｆｏｒt Higahsiura store.JPG. should it be renamed to using half width letters? RZuo (talk) 09:12, 15 November 2023 (UTC)

This is a tricky one. It definitely doesn't qualify under criterion 4. It might just about fall under criterion 3, if you claim that the shop is called "LIFORT" and not "Ｌｉｆｏｒt". But that's really only a small change and falls within FRNOT #1. I think the best argument is under criterion 6: the request says that those characters are likely to get mangled and I think that's (a) believable and (b) probably a case of "character handling problems, and other similar technical issues". It's pretty close to the border-line though, and I may be being influenced by the ugliness of the half-width "t" there. --bjh21 (talk) 11:16, 15 November 2023 (UTC)

personally i'm also inclined to rename such files with probably unintentional mix of full and half width chars. even though browsers' find function appears to treat full and half width chars the same, they are not the same in mediawiki. the mix might cause problems.

on the other hand, if the entire filename except the extension is full width, i think such a move would be unnecessary. it's like converting allcaps, which is not appropriate. RZuo (talk) 11:32, 15 November 2023 (UTC)