Revisionism

i've seen quite a lot of rename requests, that seek to change a filename, which is correct as of the time of creation or upload of that file, to a new name that's adopted later. a rather notable example is changing "god save the queen" to "...king".

these file renames should generally be declined. this practice should be mentioned in the guideline.

the exception is those files that are meant to be kept up to date. RZuo (talk) 12:49, 16 December 2023 (UTC)

@RZuo: You are welcome to suggest exact changes.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 15:42, 16 December 2023 (UTC)

@RZuo: Modern alternatives could include "monarch", "regent", and "parliament". However, none of them are one syllable.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 03:32, 8 January 2024 (UTC)

Alternative romanisation

https://commons.wikimedia.org/w/index.php?title=File:Wunshan_Hot_Spring_Closed.jpg&action=history

non-latin languages may have plenty of romanisation schemes. they should not be regarded as "wrong" and therefore renamed. even if someone titles a file of shinzo abe "anbei jinsan" (hanyu pinyin for the kanjis as if they were in the chinese language), a file of beijing "peking" (postal romanisation)... they are still valid names. they are not wrong. they are not meaningless. they are not typos. they are not spelling mistakes. RZuo (talk) 19:52, 6 January 2024 (UTC)

There is certainly an underlying principle that romanization schemes should not be categorically prioritized over each other, in the same way that the choice of which language a file is named in should never be preferred under policy. However, unlike the complete deference to the uploader's choice when it comes to the language of a filename, being consistent in the romanization of a particular name is ab initio a good practice unless given a compelling reason to name a particular file differently than the default romanization from its category and its other files - e.g. the title of an artwork uses "Bombay" while depicting a scene in "Mumbai", or the image is taken from a government report on expats living in "Peking" instead of "Beijing". Having the spelling in filenames consistent with the romanization used for the other files about the subject and the subject category can be important when guiding editors into recognizing that an image actually represents the subject they are writing about when creating wiki content.

For this particular instance, it was certainly in good faith asking for this rename under obvious error, even though it is debatable whether it truly qualifies. The fact that the image itself includes a spelling from a different romanization means this can't be firmly considered wrongly applying correcting an obvious error. It fundamentally was nevertheless harmonizing a filename with others, even though it is out of the technical bounds of criterion #4.

• Now whether there should be a larger conversation on harmonizing the romanization when spelling a particular name is definitely one that might yield some additional clarity for this guideline, and I would absolutely welcome a robust conversation on whether that should be explicitly included here. VanIsaac (en.wiki) 21:01, 6 January 2024 (UTC)

  the initial filename is picked by the uploader.

  users often do not have knowledge of all the romanisation schemes in the world. they only know of the ones associated with their language, the ones they use.

  suppose a german speaking user uploads a photo of Volodymyr Zelenskyy, but the german language has a unique way of latin transliteration of cyrillic: Wolodymyr Selenskyj. can other users claim that it's wrong? it should be renamed because it differs from other files in the category?

  also, even if they know of the other romanisation schemes, they are still free to choose the ones they prefer.

  i dont think filemovers should pick which ones should be preferred over the uploaders' choices, as long as the filename makes sense for some people (not all people. romanisation schemes often only make sense for a specific group of users in a specific language.) RZuo (talk) 10:18, 7 January 2024 (UTC)

  Alternative romanizations can go into the description field, and be found there with a search. As a child, I accepted my parents' names for an item from "Bombay" and a dish named "Peking Duck" at a Chinese restaurant in New York City (hey, that's what it said on the menu).   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 14:49, 7 January 2024 (UTC)

  That's kind of exactly the question. What is the point of filenames? If it's simply to have an ID for accessing the file, then it doesn't matter what the filename is as long as it's unique. I think we can all agree that the existence of this guideline proves otherwise. So what are the other considerations we should be taking into account? I think that there is an argument that "Wolodymyr Selenskyj" is a less than ideal part of an English language filename whose subject is normally rendered in English language contexts as "Volodymyr Zelenskyy". If the filename is in German, e.g. "Wolodymyr Selenskyj auf einem öffentlichen Platz.png", then you're not just talking about simple romanization of the name, you're talking about the language of the filename, where deference to the uploader is much more important. VanIsaac (en.wiki) 19:55, 7 January 2024 (UTC)

  There is no English rule for filenames (just categories). They don't need to be romanized in the first place. I would tend to agree that any romanization the uploader wants is fine. The actual criteria is To harmonize the names of a set of images so that only one part of all names differs (noting that simply being in a category does not cause it be a set), meaning that type of rename is outside the policy. However, that particular policy rule has long been, um, generously interpreted to change filenames that people want to. I would tend to prefer to keep the original filename far more often. Carl Lindberg (talk) 21:56, 7 January 2024 (UTC)

  I think you will find that I explicitly said it falls outside of criterion #4, and I have been pretty clear that this would either be an explicit expansion of that criterion or a new one. That's fine that you think original filenames should be deferred to more often, but do you have an actual reasoning behind that beyond just a mechanical application of the guidelines as currently written? If we are talking about what the rules should be, I really can't know if my perspective is truly as strong as I think it is unless I know your "should" as well. VanIsaac (en.wiki) 00:19, 8 January 2024 (UTC)

  One of the project goals is to provide images elsewhere -- as the guideline notes, we aim to provide stable filenames. If someone links to a file externally, it breaks on a move. The redirects do not help them, I don't think. Maybe that has changed, but the general goal has always been to keep renames to a minimum. Fixing incorrect information makes sense, but getting into stylistic arguments over the filename usually doesn't. If the uploader had it one way, it's usually best to leave it. It's not like moving article names. Adding a file redirect if we want an additional alias should always be fine. But yes I tend to prefer minimizing breaking stuff. Perhaps I've just been annoyed too often at other people renaming my uploads :-) Carl Lindberg (talk) 00:48, 8 January 2024 (UTC)

  That's a very good point - filename stability is certainly a valid goal to have in our priorities. I didn't realize there were issues with file redirects when used outside of wikimedia projects. If that remains an issue, it could very well be important enough of a reason to forgo an expansion of file renaming criteria. Do we know if this is still an issue or if it's been solved? I still think the original file move that brought on the conversation was pretty justified by not matching the literal writing in the image, but maybe that's really the only thing that might be justifiable as incorporating into the guideline in some way. I'd still like to see some others' thoughts, though. VanIsaac (en.wiki) 01:58, 8 January 2024 (UTC)

  

  here's a picture that captured french names of countries. does that mean, if the filename were to include those names but written in english, german, arabic, japanese..., that will be not ok, because the filename "not matching the literal writing in the image"? RZuo (talk) 15:39, 4 March 2024 (UTC)

  

  would it therefore be a problem, if i rename this to "representatives of cook islands and of sri lanka..."? RZuo (talk) 15:46, 4 March 2024 (UTC)

  

  RZuo (talk) 15:49, 4 March 2024 (UTC)

Participate in the vote & discussion on the proposed File naming guideline

Participation has been relatively low and it's becoming stale despite of it not being clear whether or not the draft will be adopted. This relates to file renaming in that this would be required less often since people have a guideline on how they and others should name files.

Commons:File naming – discussion and vote on this is here at VillagePump/Proposals. Prototyperspective (talk) 08:28, 17 April 2024 (UTC)

Please participate. Thanks, Prototyperspective (talk) 11:43, 29 April 2024 (UTC)

Word choice in criterion 3

Normally I wouldn't be super-picky about a single word, but given that it appears in the templates and is a major policy and is put in bold, figured it'd be better to talk it over first. Currently criterion 3 reads:

3. To correct obvious errors in filenames, including misspelled proper nouns, incorrect dates, and misidentified objects or organisms

Now, I think this works in practice. But... why the word "obvious"? Shouldn't it be "major" errors, or perhaps "noncontroversial" errors? If, hypothetically, a picture saying it's one obscure species of beetle is in fact a similar-looking but different species of beetle, this kind of error may be deeply non-obvious. But it should still get fixed, right? Or, in the event of a credible dispute between good-faith editors, moved to a more general term (maybe kicking it up to the genus or family level, say). I brought the issue up in the Wikimedia Discord, and the feedback I got was that it was closer to "noncontroversial" in practice, i.e. undisputed. I'm not sure if that's perfect either - you could imagine a good faith but misguided editor kicking up "controversies" and thus blocking moves - but that would probably be fine 99% of the time.

(This came up because I requested a move that required quite a bit of research to realize that the source was indisputably wrong, but it involved text in Coptic, a language few people read. So a misidentification just stood for a decade+. Now, the image moved after all, so it clearly worked out, but I would not have called the error "obvious".)

Given the above, I'd like to recommend a new wording of:

3. To correct noncontroversial errors in filenames, including misspelled proper nouns, incorrect dates, and misidentified objects or organisms.

SnowFire (talk) 05:13, 8 June 2024 (UTC)

wikt:obvious covers what we are trying to explain. I don't see that your change improves the situation.  — billinghurst sDrewth 10:45, 8 June 2024 (UTC)

Are you actually advocating that only obvious in the sense of "Easily discovered, seen, or understood; self-explanatory" files should be moved, or are you invoking that page in some other way? Because the case of there being a major error that is self-evidently not easily discovered (i.e. it takes 10 years to notice) absolutely comes up. SnowFire (talk) 18:19, 10 June 2024 (UTC)

The way that I've always handled this as a filemover is that it's the requestor's job to make the error obvious to me. If the error isn't obvious from the file then that will usually require providing extra evidence. For the beetle, that might be a link to an authoritative explanation of the differences between the species, or a discussion on a Wikipedia talk page, or a tweet by an eminent entomologist saying we've got it wrong. Once I've seen the evidence, I can decide whether that's enough to make the error obvious and hence justify the renaming.

"Noncontroversial" is much harder for the filemover because it means that they have to somehow work out whether anyone disagrees with the request. I'm not sure how you'd determine that. Maybe by announcing every criterion-3 rename in advance and having a period for objections? That would certainly make the process more cumbersome. Without an objection period almost every request would appear to be noncontroversial, even those where a small amount of research would demonstrate that the current name is correct.

"Obvious" is probably not quite the right word, since it doesn't really capture the "given the information at hand" part, but I can't currently think of a better one. --bjh21 (talk) 12:26, 8 June 2024 (UTC)

agreed.

even with the current wording, far too often requesters give non-obvious, very brief reasons, and assume other users will understand. RZuo (talk) 16:16, 8 June 2024 (UTC)

Maybe proven errors, or provable errors, would be a better choice of words, as, in my experience, it is not rare that some people will not accept something as obvious even if it has been logically or empirically proven. Abderitestatos (talk) 11:12, 9 June 2024 (UTC)

I would be fine with changing to something like "Clearly explained errors" instead, or some variant, if the goal is to encourage requesters to make their case. SnowFire (talk) 18:19, 10 June 2024 (UTC)

Redirects for misidentified people

File:Georg Andreas Sorge.jpg was a picture of Georg Andreas Reimer that was uploaded in 2015 and corrected in 2016, being renamed to File:Georg Andreas Reimer.jpg. However, the redirect means that the picture still shows up in search results for "Georg Andreas Sorge" (resulting in it being added to Wikipedia biographies of him by inattentive editors since the rename).

This guideline suggests that the redirect shouldn't be removed as the file wasn't "recently uploaded" at the time of the rename. Is there another way to handle this kind of belatedly-realised misidentification so that Commons doesn't perpetuate the confusion? Belbury (talk) 11:08, 1 August 2024 (UTC)

i often ignore that rule and move files without the erroneous redirect.

otherwise, com:csd g2. RZuo (talk) 11:17, 1 August 2024 (UTC)

I don't think G2 applies, since the whole problem is that it is a used redirect. VanIsaac (en.wiki) 00:19, 2 August 2024 (UTC)

where? RZuo (talk) 06:32, 2 August 2024 (UTC)

There's a caveat in this guideline that urls to thumbnails of the old file name will also redirect (however, direct links to the full size version of the file will not redirect), meaning that other websites which had embedded the old thumbnail directly would be affected, if we cared about that. But is that statement about redirection actually correct? Trying to access a 75px thumbnail of File:Georg Andreas Sorge.jpg gives an error message rather than a redirect to a thumbnail of the Reimer filename. Belbury (talk) 08:09, 3 August 2024 (UTC)

@Belbury: The guideline only says that the redirect should be created. It doesn't stop you proposing it for deletion immediately after creation, either speedily under G2 (which I think applies in this case) or as a full DR. Essentially, invalidating a long-standing filename is a matter that should be escalated to an administrator. --bjh21 (talk) 14:59, 2 August 2024 (UTC)

Incomprehensible wording

About file-redirects it says, "Policy never requires you to suppress the redirect, suppression of redirects is entirely optional" and then just below it, "Suppression of redirects is only allowed in the following cases". Can't we have a better wording? _Regards, Aafi ^(talk) 07:17, 14 December 2024 (UTC)

Hi @Aafi, this wording confused me at the beginning and makes no sense at all if you read the rest of the section carefully. "Policy never requires you to suppress the redirect, suppression of redirects is entirely optional" should simply be removed. A redirect should always be left and the redirection should only be suppressed for the three points mentioned. Redirects also don’t take up a lot of storage space. In other words, on other Commons help page is mentionend "redirects are cheap and don't take up a lot of web space", but I can't currently tell you where I read that. איז「Ysa」 • For love letters and other notes 10:26, 14 December 2024 (UTC)

@Ysabella, yes redirects are cheap but everything doesn't usually need a redirect, particularly when the previous name is vandalism/ or if it would never ever be used again (orphaned redirect?). However, if we say leaving a redirect is optional, we cannot mandate "three must-only places" beneath it. Perhaps better to say, redirects should usually be kept, unless they're blatant typos/vandalism/or meet any CSD criteria. _Regards, Aafi ^(talk) 10:50, 14 December 2024 (UTC)

Great! Hahahah, cool you found it, thank you. Then I was wrong and it wasn't here but in the English language Wikipedia. This sentence would definitely be a useful addition at the beginning to this section. Your new suggestion for the description sounds also good for me. איז「Ysa」 • For love letters and other notes 11:27, 14 December 2024 (UTC)

@Aafi: I agree with you on this.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:27, 14 December 2024 (UTC)

@Ysabella: I think your interpretation is correct. I think the first half of the sentence is fine, "Policy never requires you to suppress the redirect." I think the second half of the sentence is re-stating the same thing but it seems that it's ambiguous so I'd be quite happy to lose "suppression of redirects is entirely optional". --bjh21 (talk) 12:58, 14 December 2024 (UTC)

Correct, in the end this sentence seems to lead to some file movers generally suppressing a redirect if the image is not used in a project and others, like me, always creating a redirect. I don't think that adjusting the sentence will therefore cause a major change, those who want to suppress a redirect will continue to do so. איז「Ysa」 • For love letters and other notes 20:23, 14 December 2024 (UTC)

I'd like to point out a use case for suppressredirect where its usage could or should be required or even be mandatory, in opposition to what the policy currently says: COM:FR#FR3 cases, at least concerning biological species names. There, leaving a redirect may even be harmful for other people who can be lead to believe that an old filename is a synonym for the correct one. I'd would be wise for our project to incur the small risk of breaking some external links (who are in the editorial responsibility of the external party anyway) instead of propagating false knowledge (or, sardonically, alternative facts). This could be an example for my reasoning. N.b., I did not blindly trust the requester there, but checked the circumstances of the request before I processed it (through the edit history of the requester to gauge his proficiency in entomology and the Anthrenus (subgenus) Wikipedia entry), being ready to disapprove it should need be. Here, the reasoning seemed valid and plausible, so I went on and approved the renaming. Of course, this makes for a thorough but slow working style, but as we renamers shoulder an important part of enhancing Commons' quality, we should IMHO accept this fact. Regards, Grand-Duc (talk) 02:57, 15 December 2024 (UTC)