Commons talk:File renaming

From Wikimedia Commons, the free media repository
Jump to: navigation, search
This talk page is automatically archived by MiszaBot. Any sections older than 180 days are automatically archived. Sections without timestamps are not archived.
Archive of file renaming proposal and activation: Here

criteria revision[edit]

Based on rename requests I have reviewed I have come up with some suggestion related to file renaming criteria:

  • Higlight completely in criterion #2 (Change from completely meaningless names into suitable names, according to what the image displays).
  • Remove criterion #3 (Correct misleading names into accurate ones): Names such as File:MY_CUTE_MOUSE.JPG or File:1BIGGest_nOSE_everS33n.JPG can either be considered as completely meaningless (#2), an obvious error (#5) or simply vandalism (#7).
  • Change criterion #7 (Remove pejorative, offensive or crude language that would not be appropriate in the file description) to vandalism, which that kind of language can be considered on Commons, but also other kinds of vandalism.
  • Make criteria #4 (Change meaningless bio-names into binomial scientific names; → criterion bio) and #6 (Harmonize file names of a set of images (so that only one part of all names differs) to ease their usage in templates (e.g. diagram symbols, scans of pages of a book, maps); → criterion template) "special" criteria so that it's obvious that criterion #6 can only be used for files used in templates.
  • Remove decline criteria #1 (Files should NOT be renamed only because the new name looks a bit better.) and #2 (Files should NOT be renamed only because the filename is not English and/or is not correctly capitalized (Remember, Commons is a multilingual project, so there's no reason to favor English over other languages).) as they are obvious and might lead to filemovers renaming all files not matching these criteria (#3 and #4 should get moved out of the table into the "Which files should be renamed?" section).

   FDMS  4    12:05, 15 March 2014 (UTC)

I see no need... --Steinsplitter (talk) 12:53, 15 March 2014 (UTC)
I just wanted to check which number should be used for correcting misidentified species. In my opinion at the moment you can use either 3, 4 or 5 and none of them will really fit... (misleading sounds as if the uploader intentionally chose a wrong name; while the name is changed into the correct scientific name, the misidentified name is not meaningless, and the error is in most cases not obvious for non-specialists)
Perhaps the texts could be adjusted a bit? Regards, Anna reg (talk) 16:23, 27 March 2014 (UTC)
"4. Change meaningless bio-names into binomial scientific names". No need to rename to a binomial name if the vernacular name is correct. Jee 16:39, 27 March 2014 (UTC)
Of course - but I'm not talking about generally wrong names. I just had a discussion that calling a misidentified name misleading could be taken in the wrong way by the uploader (and I think meaningless would be worse) - our discussion started with this picture - named Hylotelephium erythrostictum which could be correct, but according to Sminthopsis84 is not the case - it is misidentified and should be Hylotelephium spectabile. The name is not meaningless - it's just not correct. (And I had chosen 3 as the 'best fit') Anna reg (talk) 17:06, 27 March 2014 (UTC)
"Change unidentified or misidentified organisms to correct binomial names" may more suitable. While renaming, I simply states "correct ID" in "reason for renaming". Jee 03:27, 28 March 2014 (UTC)

Criterion 8: Remove spaces before file extensions[edit]

Per this discussion at the village pump, can we formalize something like a new criterion, or add to an existing one? One of the arguments there for example was to simply ease usage of the file in wiki syntax, so others don't have to remember to add a space before the file extension to call the file. TeleComNasSprVen (talk) 01:08, 9 April 2014 (UTC)

Why not modify criterion #5?    FDMS  4    14:36, 9 April 2014 (UTC)

Criterion 7: add something to do with blatant promotional material?[edit]

I realize this would have to be worded carefully, but as it currently stands, none of the criteria really apply to File:Vendo jeep liberty 2002 en buenas condiciones, tiene 112mil millas eléctrico a-c, 4x4 ---$4750 o mejor oferta 2014-05-06 21-21.jpeg, whose name translates roughly as "I am selling a 2002 jeep liberty in good condition, it has 112 thousand miles electric a-c, 4x4 ---$4750 or best offer 2014-05-06 21-21.jpeg". It's not really a misleading name, but at least to me, the name seems inappropriate enough to move it. Storkk (talk) 09:15, 27 May 2014 (UTC)

Similarly, File:I_got_my_Honda_Accord_1990_4_door_4_cylinder_power_windows_power_door_lock_run_good_engine_and_transmission_good_120,000_miles_do_you_want_to_contact_me_text_me_or_call_me_8608406395-_2014-05-28_20-07.jpg. Storkk (talk) 13:36, 13 June 2014 (UTC)
Well, aren't they meaningless?    FDMS  4    08:33, 14 June 2014 (UTC)
Including his contact number; so #7 + COM:ADVERT. Jee 08:39, 14 June 2014 (UTC)
Honestly, I think these photos could realistically serve an educational purpose. File:I got my Honda Accord 1990 4 door 4 cylinder power windows power door lock run good engine and transmission good 120,000 miles do you want to contact me text me or call me 8608406395- 2014-05-28 20-07.jpg isn't actually a bad photo of a 1990 Honda Accord. I'd keep the photos where they are. The name doesn't bother me so much. The name is incredibly not misleading, I mean it describes the car perfectly. Its a 4 door Honda Accord from 1990 with a 4 cylinder engine, power windows, and a door lock. It has about 120,000 miles of wear on it. The name to me actually, besides the phone number, which I can live with being in there, a really fantastic file name (if a bit long). Anyhow, I'd keep the photos and I'd keep them at their current locations, though if someone dropped out the phone number I wouldn't be bothered either. I've got to say seeing those definitely made me laugh though and I printed one of them out to just keep around. Zellfaze (talk) 19:08, 7 July 2014 (UTC)
  • Renamed and redirect deletion as promotional. Yann (talk) 20:12, 7 July 2014 (UTC)

How to request renaming[edit]

Please add a description on how to make a request for a file to be renamed. Editors searching for how to do this are likely to find this article. I think the request should be made using Template:Rename on the file page, but someone more familiar with the process should add the note. Verbcatcher (talk) 14:21, 2 June 2014 (UTC)

By default, users have a gadget which adds a rename link that can make rename requests for them, is it enabled in your Special:Preferences#mw-prefsection-gadgets?    FDMS  4    14:37, 2 June 2014 (UTC)
I eventually found the gadget, well hidden underneath a small triangle at the top of the screen. I doubt if I'm alone in searching for how to request a file rename and ending up here. Verbcatcher (talk) 23:00, 2 June 2014 (UTC)

Revise Criteria 2 and 3[edit]

I think that those two are kind of redundant at least as far as the examples go since the ones for 3 are also meaningless. On the other hand my current case is not covered at all. This Name File:Redaktionsgebaeude.jpg is neither meaningless nor misleading because Redationsgebäude means editorial building which this building is in fact. But it is easy to see that regardless it is almost completely useless because way to unspecific.

I propose to merge them into one criterion which would be frased something like this:

"Change from completely meaningless or much to unspecifc names into suitable names, according to what the image displays"

--Saehrimnir (talk) 18:01, 8 June 2014 (UTC)

Proposed overhaul of the "Which files should be renamed?" section[edit]

Below is the proposed overhaul. The "Additional information" section is part of the proposal, and would be included with the rest of the table should this be adopted. Everything outside of the yellow box would not be included with the rest of the table should this be adopted.

# Aim Examples (old name) Examples (new name)
1. At the original uploader's request.[1]
2. To change from a completely meaningless name to a name that describes what the image displays.[2] File:DSC 1342.jpg File:Pretoria Venningpark.jpg
3. To correct obvious errors in file names, including misspelled proper nouns, incorrect dates, and misidentified objects or organisms.[3] File:Ayres Rock 3.png
File:Van Gogh portrait 1787.jpg
File:Unknown insect 02.jpg
File:Ayers Rock 3.png
File:Van Gogh portrait 1887.jpg
File:Hogna radiata 02.jpg
4. To harmonize the file names of a set of images (so that only one part of all names differs).[4] File:Bhf-BS-Icon.svg
File:Icon HST bs 1.svg
File:Dst symbol.svg
File:BSicon BHF.svg
File:BSicon HST.svg
File:BSicon DST.svg
5. To change a file name that would be a violation of Commons' policies and guidelines if it appeared elsewhere on the project as text. This includes gratuitous vulgarity, personal attacks/harassment, blatant advertising, and cases where revision deletion would be authorized.[5] File:Stupid fat idiot.jpg
File:Buy now NEW PAINT! 555-6200.png
File:<Name of the person>.jpg
File:2007 pink Honda Accord.png
6. Non-controversial maintenance and bug fixes, including fixing double extensions, invalid or incorrect extensions, character handling problems, and other similar technical issues.[6] File:Map of Asia.svg.png
File:Computer mouse.jpe
File:Map of Asia.png
File:Computer mouse.jpg

Additional information[edit]

  1. Within reason. Most uploader requests would fall under one of the other criteria anyways.
  2. Note that the standard here is "completely meaningless", not "not specific enough". This criterion is aimed at random strings of letters and numbers, not at non-specific names like "File:Building in Riga 4.JPG" or especially short names like "File:RAS.jpg". You can always add additional detail in the file description page and through categorization.
  3. If an object or organism was incorrectly identified in the file name (such as calling a Sylvilagus floridanus by the name "File:Sylvilagus audubonii.jpg", this criterion covers renaming the image. If the file name includes words like "unidentified" or "unknown" when describing an object or organism, and that object or organism has been identified, this criterion also covers the change. This criterion does not, however, cover moving a file from its common usage name to its scientific or technical name.
  4. Just because images share a category or a subject does not mean that they are part of a set. There are two scenarios that this criterion is designed for. First, certain complex templates (such as those that use BSicons or that display football kits) assume that the images used in them will follow a specific naming convention. Wikisource also uses a specific naming convention for the source files they transcribe. Second, files that form parts of a whole (such as scans from the same book or large images that are divided into smaller portions due to Commons' upload size restriction) should follow the same naming convention so that they appear together, in order, in categories and lists.
  5. Note that Commons' neutral point of view differs significantly from that of English Wikipedia. A file like "File:Taiwaneese Tiaoyutai islands map.png" would be acceptable on Commons, even though it is not neutrally titled (see here). This does not mean that all non-neutrally worded titles are acceptable, however. An image of a person with the name "File:1BIGGest_nOSE_everS33n.JPG" would not enjoy the same protection.
  6. This is not a catch-all for anything that doesn't fit one of the above. This is for specific technical problems, generally which have a bugzilla bug and have been the subject of community discussion.

What is changed in this draft[edit]

  • Criterion 1 remains essentially unchanged, although "within reason" is added to the errata at the bottom.
  • Criterion 2 remains unchanged, although the errata at the bottom now explicitly states that "not specific enough" is different from, and not covered by, this criterion. There have been problems with this before.
  • Criterion 3 from the old version has been removed, as it is redundant to the new criteria 2, 3, and 5.
  • Criteria 4 and 5 from he old version have been rolled together to from criterion 3 in this proposal.
  • Criterion 6 from the old version has moved up two places, and is now criteria 4 in the new version. The errata maintains the original rationale while also expanding it to cover image sets such as book scans, that have a legitimate reason to follow an naming convention as well.
  • Criterion 7 from the old version has been expanded, and makes up the core of the new proposal's criterion 5. The new criterion is significantly broader, giving file movers the latitude to change names that are entirely out of scope (such as blatant advertising), and gives stronger policy cover to OTRS agents when they are asked to remove personal information from files. Neither of these additions are truly new: since this is a guideline and the revision deletion and scope pages are policy, there was already cover. Rather, this codifies what as already allowed and ongoing practice.
  • Criterion 6 from this proposal is new. It covers things like User:Dispenser/Double extension and User:Dispenser/Wrong Extension‎ (note on the latter, currently the ones that are there are false positives, the actually problematic ones tend not to last more than a day or two after the report is run). It would also cover the "space between the end of the name and the extension" problem that was brought up elsewhere on this page.


Symbol support vote.svg Support seems reasonable --Jarekt (talk) 19:37, 8 July 2014 (UTC)
Symbol support vote.svg Support can't foresee any problems with this. Rodhullandemu (talk) 20:24, 8 July 2014 (UTC)
Symbol support vote.svg Support Present version isn't wrong, but it's often misused. This proposal seems clearer and therefore easier to enforce. Anyway, we still need that the community and ours sysops want to abide and enforce it.--Pere prlpz (talk) 20:48, 8 July 2014 (UTC)
  • Pictogram voting comment.svg Comment: I do foresee a lot of problems with the new criterion #4, because a lot of people won't read the explanation and instead consider every category a "set". Also, I think it would be better to add criteria and remove old ones (similiarly to en.WP CSD) instead of significantly changing them.    FDMS  4    23:53, 8 July 2014 (UTC)
    • Pictogram voting comment.svg Comment Regarding the wording issue, I don't think the old #6 was any better. What wording would you suggest, FDMS4? My suggestion would be: "To harmonize the file names of a closely related set of images (so that only one part of all names differs they all share a common prefix)." And then at the end of the note under "Additional information": 'Note that categories do not automatically constitute a "closely related" set.' (insertions and deletions noted for the purpose of this discussion only) OBTW, the filename "File:1BIGGest_nOSE_everS33n.JPG" in note 6 should be in italics, for consistency with all the other filenames. - dcljr (talk) 02:26, 9 July 2014 (UTC)
      • I don't know why the italics were there in the first place, so I pulled them out. As for your changes, I've revised that footnote to incorporate part of your idea (edit). I don't like the word "prefix", however, because the football kit naming convention, for example, technically uses several components. It's "Kit [segment of the kit] [team][season][letter indicating home/away/third] (example: File:Kit body fcbarcelona1213a.png). Sven Manguard Wha? 05:08, 9 July 2014 (UTC)
    @Sven Manguard: Thanks, the explanation definitely got more explicit now. What do you think about the criteria numbers?   FDMS  4    13:59, 9 July 2014 (UTC)
    Ah, and I think that copyright holders should have the same rights as uploaders when applying criterion #1.    FDMS  4    14:03, 9 July 2014 (UTC)
    I think that the criteria numbers are fine. A few people will have to adjust the edit summaries built into their scripts, but by far the more important thing is the rationale, not where it appears in the list. As for copyright holders having the same rename rights as uploaders, I've actually never seen a rights holder (that wasn't also the uploader) actually care about the fine name. In principle, if the rights holder has an objection to the file's name, it should be taken into account. In reality, most people that aren't editors don't look at that sort of thing, and if a name was bad enough to get the rights holder upset, it would likely quality as something that would need renaming under new criterion 5 anyways (i.e. it is defamation or contains personal information that would warrant a revision deletion). Sven Manguard Wha? 19:20, 9 July 2014 (UTC)
Symbol support vote.svg Support.    FDMS  4    22:03, 9 July 2014 (UTC)
Symbol support vote.svg Support Makes sense. Regarding the concerns raised by FDMS4: I see your point but so far we haven't had much trouble with the old wording. And there's always the decline button. --Hedwig in Washington (mail?) 03:21, 9 July 2014 (UTC)
Symbol support vote.svg Support Jee 03:28, 9 July 2014 (UTC)
Symbol support vote.svg Support - Jmabel ! talk 07:24, 9 July 2014 (UTC)
Symbol support vote.svg Support but with suggestions for improvement In principle this sounds very good, as files are renamed far too often right now, and at least this new proposal will clarify that "London DSC 1234.jpg" should not be renamed to "Tower Bridge seen from a boat.jpg". But I think criterion #6 needs some revision. I see no problem at all with double extensions like "Map of Asia.svg.png" (indeed, these kinds of filenames could make it clearer that it's a PNG version of an existing SVG file, not a separate SVG map), and ".jpe" appears to be a valid filename extension for JPEG files (do a web search for 'jpe file extension'), so that example isn't good, although I do agree that if the software ever doesn't catch an actually invalid/wrong filename extension, the criterion should cover that.
I also fear that criterion #6 could be misinterpreted for doing things like changing "foo .jpg" to "foo.jpg", which someone recently did with a bot without any basis whatsoever in policy.
I'm not sure "uploader request" is a good criterion as-is. We should accept that (as a sole reason), if we're going to accept it at all, only in similar cases in which we accept uploader-requested deletion: for recently uploaded unused or little-used files. This criterion appears to violate the spirit of COM:OWN: if there is no other reason for renaming the file except that the uploader likes it better that way, then why should they have a special right just because they are the uploader?
I'd also suggest that we put in a recommendation to keep the filename in the same language that it was originally in when applying criteria #3 and #5. So if a photo of FooTown is called "BarCity nachts.jpg" then it should be renamed to "FooTown nachts.jpg", not "FooTown at night.jpg". This obviously can't always apply if the filemover can't write in that language, but if they can, they should make an effort to preserve the language. darkweasel94 08:24, 9 July 2014 (UTC)
About uploader's request, since we give uploaders the right to name their files when uploading, we should keep giving them the right rename files. Furthermore, usually uploaders know best their files and the mistakes they can have made when naming for first time, so they are expected to be able to make good choices for names. Of course, new name needs to be appropriate, but this is another question. Have ever been controversial renames by "author's request"?
Deleting files is a very different thing, because deleting files prevents other people to use them. Anyway, courtesy deletions are often performed on uploader's request, if files are not very important - not used, not unique, borderline scope or copyvio cases...--Pere prlpz (talk) 17:12, 9 July 2014 (UTC)
Regarding the .jpe extension, yes it is valid, but it's not part of our whitelist (see bugzilla:65437). You would have to speak to someone more technically minded about if/why it is problematic.
Regarding double extensions, I rather strongly disagree that they are a good thing. The proper way to indicate that an image was derived from another one, regardless of the format, is to note that in the proper field of the {{Information}} template (source or other versions, depending on the specifics). Double extensions are confusing, especially if someone copies the first and not the second, and can't figure out what's wrong. This is likely the same reason behind the renaming of space-before-the-dot files, although I haven't followed that issue. Your concern about the bot is the reason why the errata says "This is for specific technical problems, generally which have a bugzilla bug and have been the subject of community discussion.".
Regarding uploader request, Pere prlpz has it largely right. This is generally for when uploaders make mistakes with their initial naming. I can't think of any cases where it has been abused in the past, but the new "Within reason" in the errata would cover declining a move if, for example, someone wanted to give all of their uploads useless or confusing names as part of a ragequit.
Regarding the issue of changing languages, see the second item in "Which files should not be renamed" in the existing policy. That section would not change as part of this proposal.
I'll be back after the World Cup game if you have any other concerns I can address. Sven Manguard Wha? 19:38, 9 July 2014 (UTC)
Regarding .jpe: yes, I do agree that if a filename wouldn't be accepted for uploading today, the file should be renamed (can you e.g. overwrite such files?). I don't think I said double extensions are a good thing that should be encouraged, but they aren't a bad thing either; not such a bad thing, at least, that they should be a reason for renaming. The same applies for dots before spaces: they are nothing but "new filename looks a bit better"; there isn't a technical reason to see these as problems. The procedure to copy the filename is the same no matter if the final dot is immediately preceded by " ", ".svg", or anything else, I can't really see anyone genuinely confused about that.
My comment on languages was due to seeing renames like this one; however such renames wouldn't be allowed under the new policy anyway (and rightly so), so it's mostly a moot point. This (just as my point about uploader requests) isn't really my main point of concern, but I still think double extensions shouldn't be a cause for action and certainly aren't what I'd take the phrase "non-controversial maintenance and bug fixes" to refer to. darkweasel94 19:59, 9 July 2014 (UTC)
Erm … just for the record, criterion #1 would still apply under the new policy, as I asked you for permission for renaming and you agreed. I did not rename only because the filename is not English and/or is not correctly capitalized. And still, if there is a file named Foto_4238_Kamera_Schatzi, choosing a language for the meaningful new title is up to me, under the old as well as the new policy.    FDMS  4    22:03, 9 July 2014 (UTC)
The new policy has this clarifying text: Note that the standard here is "completely meaningless", not "not specific enough". This criterion is aimed at random strings of letters and numbers, not at non-specific names like "File:Building in Riga 4.JPG" or especially short names like "File:RAS.jpg". You can always add additional detail in the file description page and through categorization. Which very clearly means that this rename wouldn't be covered anymore. It's true that you asked me if that was ok, and I didn't say anything against it, but we're not here to discuss certain individual renames, but the policy. darkweasel94 04:46, 10 July 2014 (UTC)
We've one case, at least regarding the misuse of uploader requests/wishes. See Orrling's comments at User_talk:MichaelMaggs/Archive/2014#Re_message_on_your_page_that_you_might_have_missed. This is a rare case, though. Jee 02:37, 10 July 2014 (UTC)
  • Pictogram voting comment.svg Comment. Adding "within reason" to criteria 1 is not needed. Obviously, an uploader request cannot be honoured if doing so would violate another criteria, and any admin that did so would be demonstrating a basic lack of competency if they accepted it. If there's any other reason for adding it, then please state it, otherwise it just looks like a pointless clause, which is only likely to confuse people, putting doubt in their mind as to whether they can rename their file or not, as they obviously won't know from this version what 'within reason' refers to. Ultra7 (talk) 18:05, 11 July 2014 (UTC)
    • I would argue that the case for including "within reason" has already been made above. I don't think people will be confused by this, and if they are, we can always revisit the wording. Sven Manguard Wha? 18:32, 11 July 2014 (UTC)
  • Symbol support vote.svg Support Looks good. It is missing one situation, though: if a file is incorrectly overwritten and then tagged with {{split}}, one of the revisions has to be moved somewhere else. This situation should maybe be described by the guideline.
It should maybe also be stated that there always must be a redirect from the old name, if the old name has been in use for some time (except when splitting incorrectly overwritten files, if the redirect target is ambiguous). I sometimes note that people nominate redirects for speedy deletion, and this breaks external usage and historic revisions of pages using the file. --Stefan4 (talk) 21:43, 11 July 2014 (UTC)
Splitting a file isn't renaming. The older file stays in the original name, and the newer file is given a new file name, as if it were a new upload. The page governing splitting is Commons:History merging and splitting. As for your comment about redirects, that would be covered in the "Redirects" section of the File renaming page. This RfC is only talking about the "Commons:File_renaming#Which files should be renamed?" section of that page. Sven Manguard Wha? 23:42, 11 July 2014 (UTC)
The newer file is renamed. Before the split, both files have the same name, which is inappropriate, and this is why the newer file is renamed. --Stefan4 (talk) 00:01, 12 July 2014 (UTC)
If you want to argue semantics, yes, the newer file is given a new name. The process that governs splits, however, is Commons:History merging and splitting, not Commons:File renaming. We don't need to mention it here because it is already covered there. If this really bothers you, use a {{See also}} to link the two pages together. Sven Manguard Wha? 01:50, 12 July 2014 (UTC)