Wikimedia Commons

Commons:Requests for comment/File renaming criterion 2

< Commons:Requests for comment
General notes
  • Originally, the RfC focused primarily on visual works, and there particularly photos and videos. Audio files, books and graphics are only touched tangentially.
    • It was pointed out that files should be generally renamed with the most possible care, especially when in use.
    • When a file is used on WikiSource, that project should be notified beforehand, if possible and not a matter of urgency (e.g. an offensive file name).
    • In case moving a file would justify a second consecutive move, it is better to take no action.
  • Whether a file name is perceived suitable often depends on the familiarity of the individual with the subject, which is often the place depicted. It also occurs that items are know under different terms to different users or they believe entities are more well-known under the specifier they are used with to describe this entity, neglecting cultural differences (even within countries). Not of less importance is the purpose the file name is believed to have; user frequently categorizing files have different demands than those who take, process, manage and upload them.
  • Uploaders often have schemas naming their files; moving files might break them. If possible, language and schema should be preserved. If possible preserve the camera or catalogue number.

Note by the closing administrator: Please also consider using file redirects where possible. They are cheap, usually do not break anything and are easily edited or deleted, if required.

Support to specific criteria
  • "Absolutely no information at all" lists files whose names consist entirely of camera numbers and image repositories as examples.
    • Support: 100% (13)
    • Support points: "Obvious", "random letters and numbers are simply unhelpful"
    • Oppose: 0% (0)
    • Concerns: The codes should be preserved while moving the files because they could be helpful information for the uploader.
  • "Only information is the photographer or rights holder" lists files consisting of image repositories, user names and codes (number/character combinations that are only useful to a very limeted set of users) as examples.
    • Support: 93% (14/15)
    • Support points: "filnames should be the first indicator of what the image shows", "a helpful title should be added", "Name belongs in author field in summary"
    • Oppose: 7% (1/15)*
    • Concerns: "appearance of an author's name is quite relevant", author's name in the title can be helpful, and re-naming a file to remove the author's name is inappropriate
  • "Only information is the date" list file names consisting entirely of dates and codes
    • Support: 100% (16)
    • Support points: "Every file one Commons needs to have at minimum what is in the picture", "The date should be in the description instead", "having this as the only useful information is inappropriate"
    • Oppose: 0% (0)*
    • Concerns: "having the date in the file name can be useful", exception required for "artistic works whose name is a date (there's a few)"
  • "Only information is the location (broad)" lists files whose names consist of names of capital cities (>=700 000 inhabitants), a general depicted-object type and codes.
    • Support: 83% (15/18)
    • Support points: "thousands of files related to London or Paris differentiated only by numbers after the city name", "broad location, such as a city, province, or country seems clear to me", "Filenames that include the country only are pretty useless to begin with, except for election charts and such", "problem I encounter when categorizing Category:Berlin and its sub-cats", "filenames should include what (and not merely where) as the bare minimum"
    • Oppose: 17% (3/18)
    • Concerns: "There isn't any obvious limit between a "broad" and a "narrow" location.", "What is broad?", "province and city (too difficult to define)", "wide-ranging photo, and there is no specific subject beyond the city itself"
  • "Only information is the location (narrow)" lists files whose names consist of Country+City+Park name, Name of Events + Ordinal number of that event codes.
    • Support: 0% (0/11)
    • Support points: "huge number of uploads with the name of one specific place as a filename", "depends on a case-by-case basis", "should explicitly be allowed to be a judgment call by filemovers"
    • Oppose: 100% (11/11)
    • Concerns: "Filenames don't need to be copies of the entire description page", "this level of specificity is more than enough for filenames", "have to draw a line in the sand", "cause a needlessly long filename"
    • Case-by-case basis (file mover's decision): 29% (4/14) [including comments]
  • "Generic category rather than specific item" lists files whose names consist of generic terms describing physical and virtual items as examples.
    • Support: 85% (11/13)
    • Support points: "the names are not specific enough", "would be fine if they are the only images we will ever have of the subjects", "all three examples given here are too vague", "smartfon.jpg/myfone.jpg/car.jpg isn't helping anyone", ""Smartphone" is ambiguous, and I would be looking to rename", "Very generic titles just aren't helpful"
    • Oppose: 5% (2/13)
    • Concerns: "if they're used as generic icons", "not all information needs to be on filename", ""Wiki.jpg" for a MediaWiki screenshot would be a filename that shouldn't be moved"
  • "Acronyms and initials"
    • Support: 69% (11/16)
    • Support points: "because acronyms are not always better known than the full name and even when they are it isn't always a helpful name", "often gibberish or lingo acronyms", "some are better known than the full form (NATO, ÖBB)", "should include the relevant keywords (image subject, location)" for Google ranking, "Generally I would say acronyms alone are far too vague in most situations"
    • Oppose: 31% (5/16)
    • Concerns: "No reason to treat acronyms any differently from their full forms, especially as in some cases the acronym is better known than the full form", "some abbreviations are meaningless"
    • There appears to be consensus that acronyms and initials well-known through international media don't deserved to be renamed.
  • "Very short names" (File name without namespace and file ending <= 6 characters)
    • Support: 47% (7/15)
    • Support points: avoids "unnecessary and excessive ambiguity"
    • Oppose: 53% (8/15)
    • Concerns: "arbitrary limit", but I and most of the people in my country are pretty comfortable with that file name, ""A.svg" is a meaningful name for an image of the letter A", "absurd because it isn't limited to filenames written in alphabets", "Chinese is comparatively information dense", "Short names may be meaningful", "If the short filename is confusing, it qualifies under the meaningless criteria."
  • "Names that are not meaningless, but do not describe the file" lists files whose names consist of interjections, comments or personal feelings about the file's subject (which are not sufficient to identify said subject), a source repository, and codes.
    • Support: 86% (12/14)*
    • Support points: "are as bad as random letters and numbers", "problematic in file titles as it makes files hard to identify, find etc, so should not be permissible", "Names should be descriptive of what is being pictured"
    • Oppose: 14% (2/14)*
    • Concerns: " should be discussed on the item's talk page", "weasel wording that would lead to arbitrary decisions", "do they represent "the title given to a work of art by the artist that created it" or not?", "what other name could have been chosen for them", "moral right [...] to substitute it with something of our own invention", "where to draw the line?"
  • "Images where the information in the filename, while normally acceptable, is inappropriate for the specific content" lists a file name consisting of a location (a museum and building) together with an ordinal number
    • Support: 67% (4/6)
    • Support points: "Titles should be descriptive and not misleading"
    • Oppose: 33% (2/6)
    • Concerns: "What is the "specific context"?", "Images don't have a context by themselves, only within categories, local project pages, search results"


* One individual is supporting/opposing nothing related to the topic of this criterion but suggests separate criteria for batch uploads from other repositories and those uploaded or transferred in a way that the uploader had to enter a file name.

Result
The scope of file renaming criterion 2 will be extended, producing the following:

Whether a file name is perceived suitable often depends on the familiarity of the individual with the subject, which is often the place depicted. It also occurs that items are known under different terms to different contributors or they believe entities are primarily well-known under the term they are used with to describe this entity, neglecting cultural differences, even within countries. Not of less importance is the purpose the file name is believed to have; contributors frequently categorizing files have different demands than those who create, process, manage and upload them. Uploaders often have schemas naming their files; moving files might break them. If possible, language and schema should be preserved, as well as the camera or catalogue number.

# Aim Examples (old name) Examples (new name)
1. At the original uploader's request.[1]
2. To change from a meaningless or ambiguous name to a name that describes what the image displays.[2] File:DSC 1342.jpg** File:Pretoria Venningpark DSC 1342.jpg
File:20110428 OH K1023900 0014.JPG - Flickr - NZ Defence Force.jpg** File:Helicopter A109LUH(NZ) by NZ Defence Force.jpg
File:20120519 3349.CR2.png** File:Sebkha-Chott 3349.png
File:Paris 319.jpg** File:Paris 75018 Rue Norvins no 018 Le Consulat z.jpg
File:Smartphone.jpg** File:Samsung Galaxy Note series (Original, II, and 3).jpg
File:RAS.jpg** File:Rodrigo Arias Sánchez.jpg
File:Flickr - law keven - Anybody know a Good Dentist^......Happy Furry Friday Everybody...-O))).jpg** File:Lion-tailed Macaque, Colchester Zoo, England.jpg
File:Louvre 12.jpg** File:Mona Lisa by Leonardo da Vinci.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
  1. ↑ Unless there is a compelling reason not to, uploader requests should be honored. This is a courtesy, not an absolute, however. If a file mover feels that a proposed new name is disruptive or inappropriate, they can suggest a different name or decline the request.
  2. ↑ Including:
    1. Absolutely no information at all
      Composed entirely of random letters, numbers, and words like “Flickr”, “original”, and “crop”, which do not describe the subject of the image, but may indicate its upload history
    2. Only information is the photographer or rights holder
      The only piece of meaningful information is the name of the photographer or the holder of the copyright
    3. Only information is the date
      Only piece of meaningful information is the date that the photograph was taken on
    4. Only information is the location (broad)
      The only piece of meaningful information is a broad location, such as a city, province, or country. In this case, the location is so large that an average person would not be able to figure out where the image was taken or what the image depicted, without assistance from someone that knows the area.
    5. Generic category rather than specific item
      The only piece of meaningful information is a word, such as “smartphone” or “screenshot”, which broadly describes the subject of the file, but does not impart any information that would help someone identify the specific object depicted. This is not just restricted to inanimate objects, it also applies to broad titles or groupings, such as “queen” or “bird”.
    6. Acronyms and initials
      The only piece of meaningful information is an acronym or a person's initials. This differs from “Absolutely no information at all” in that the acronym or initials are related to the subject of the file, even if it takes a second to figure out how.
    7. Names that are not meaningless, but do not describe the file
      Contains a coherent description or message that do not describe the subject of the file. Does not apply in cases where the name of the file is the title given to a work of art by the artist that created it, even if the name has nothing to do with what is depicted (for example, many works of Dadaism)
    8. Images where the information in the filename, while normally acceptable, is inappropriate for the specific content
    Not including: Specific locations, such as a park, an individual building, or an event.
  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.


The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.


RfC on the scope of file renaming criterion 2

Several people at the proposed overhaul of the "Which files should be renamed?" section of Commons:File renaming expressed issues with the scope of criterion 2.

It currently reads:

# Aim Examples (old name) Examples (new name)
2. To change from a completely meaningless name to a name that describes what the image displays.[1] File:DSC 1342.jpg File:Pretoria Venningpark.jpg
  1. ↑ 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.

The errata (footnote) is new, but it's only putting down on the page what is already the existing interpretation of that rule. During the prior RfC, the addition of the errata drew both support by people that felt that criterion 2 had been abused in the past and opposition by people who felt that criterion 2 is too narrow.

The purpose of this RfC is to solicit feedback from the community on how broad criterion 2 should be. At the conclusion of the RfC, I will build a case list (similar to the one at Commons:De_minimis#Guidelines) based off of the results of the RfC, and modify the errata to defer to that case list. Each of the possible criteria below should be considered independently from one another. If some of them but not others achieve support, the errata and case list will be built to reflect that.

Thank you for your participation.
Sven Manguard Wha? 17:21, 24 July 2014 (UTC)[reply]

Note that below:
 Support indicates that you would allow files to be moved under the given rationale
 Oppose indicates that you would not allow files to be moved under the given rationale

Absolutely no information at all

This is for file names that cannot possibly be interpreted as describing the subject of the file in any way. This is the interpretation of the phrase "completely meaningless" that is reflected in the errata in the current version.

  • File names that are composed entirely of random letters and numbers
  • File names that are composed entirely of random letters and numbers, and camera prefixes such as "DSC", "IMG", or "PIC"
  • File names that are composed entirely of random letters, numbers, and words like "Flickr", "original", and "crop", which do not describe the subject of the image, but may indicate its upload history

Examples: File:1214966884.jpg, File:DSC 2393 (8736477602).jpg, File:Flickr 1IMG 6771 (4996551392).jpg, File:Flickr-144577104-original.jpg

Comments

Only information is the photographer or rights holder

This is for file names where the only piece of meaningful information is the name of the photographer or the holder of the copyright. Many such files bear the halmarks of large batch uploads from a single source (see examples below). This would not apply in the case of self-portraits (where the photographer is the subject of the file), but would apply if the rights holder is an organization, and the photograph is of one small part of that organization (see second example).

Examples: File:- Flickr - andrewbasterfield (12).jpg, File:20110428 OH K1023900 0014.JPG - Flickr - NZ Defence Force.jpg

Comments

Only information is the date

This is for file names where the only piece of meaningful information is the date that the photograph was taken on.

Examples: File:2007-10-07 001 002.JPG, File:20120519 3349.CR2.png

Comments

Only information is the location (broad)

This is for file names where the only piece of meaningful information is a broad location, such as a city, province, or country. In this case, the location is so large that an average person would not be able to figure out where the image was taken or what the image depicted, without assistance from someone that knows the area.

Examples: File:Paris 319.jpg, File:20110531 London 158.JPG, File:Building in Riga 4.JPG

Comments

  •  Oppose There isn't any obvious limit between a "broad" and a "narrow" location. Take the images I uploaded into Category:Aderklaa. Aderklaa is a municipality, albeit a small one: is that a broad or a narrow location? If it's a narrow location, but Vienna a broad location, then where exactly is the limit? Aderklaa is just slightly bigger in area than Vienna's biggest park, and parks are defined below as narrow locations. There isn't any way to tell except by drawing some entirely arbitrary limit. darkweasel94 21:10, 24 July 2014 (UTC)[reply]
  •  Support, just because some places are really small it doesn't mean we should treat larger places with the same standard. I agree that somewhere like Aderklaa can get away with such filenames, but does that mean we should have thousands of files related to London or Paris differentiated only by numbers after the city name? I don't think we could set a limit but admins and filemovers should be allowed some discretion in deciding if a place is small enough to warrant some filenames like this. Green Giant (talk) 01:04, 25 July 2014 (UTC)[reply]
  •  Comment While editors may agree on extreme cases, I think that Darkweasel is right. Unless some objective standard can be set, this criterion will invite endless arguments and acrimony. It may be better to assume good faith on the part of our contributors and to try to educate and persuade when filenames fall short. It suffices that a filename be a unique, not deceptive and human-readable identifier. --Walter Siegmund (talk) 02:00, 25 July 2014 (UTC)[reply]
  •  Support; the line isn't easy to draw, but I still think this is a good idea. - Jmabel ! talk 04:40, 25 July 2014 (UTC)[reply]
  •  Support in the case of Paris and London above. The criteria is a broad location, such as a city, province, or country seems clear to me. Yann (talk) 06:35, 25 July 2014 (UTC)[reply]
  •  Support per above, including opposition. We should be able to rename filesnames with broad locations. Esp. for big cities like London, Paris, Tokyo(!!!). Filenames that include the country only are pretty useless to begin with, except for election charts and such. --Hedwig in Washington (mail?) 23:27, 26 July 2014 (UTC)[reply]
  •  Support If these are meant to be a restrictive set of criteria, there has to be some subjective judgement allowed in cases like this, because there clearly are bad filenames that fit under this category. We have to presume some common sense, otherwise, there's no point having criteria in the first place. Adam Cuerden (talk) 01:00, 27 July 2014 (UTC)[reply]
  •  Support Encyclopedic or PPOV are not cutting edge criteria but in WP people live for them often with arguments and acrimony. Here we must do the same hard job for titles. "Only place" titles must be compared with level of detail of pictures otherwise theoretically we could launch a bot and rename all nonsensical titles in "Cosmos 1.ext", "Cosmos 2.ext"...--Pierpao.lo (listening) 10:53, 27 July 2014 (UTC)[reply]
  •  Oppose What is broad? If we need to be more precise, we can use description.--Pere prlpz (talk) 13:05, 27 July 2014 (UTC)[reply]
  •  Support, dependant upon context - While I think this is generally a worthwhile goal, it has its limitations. For instance, my own upload File:London MMB «03.jpg is so named because it is a pretty wide-ranging photo, and there is no specific subject beyond the city itself. If the photo is of a specific street or building or place within the city, sure, it should be renamed (but preserving the author's naming convention). -mattbuck (Talk) 18:26, 27 July 2014 (UTC)[reply]
  •  Comment I would think that the words we are looking for are "generalised" or "ambiguous". There is more than one London, Paris, etc. or One Tree Hill. I would think that this is guidance to take into account.  — billinghurst sDrewth 12:55, 28 July 2014 (UTC)[reply]
  •  Support Beyond My Ken (talk) 20:41, 28 July 2014 (UTC)[reply]
  •  Support This is an occasional problem I encouter when categorizing Category:Berlin and its sub-cats. Filenames like "Berlin 25.jpg" are not useful at all. --Sebari (talk) 21:06, 28 July 2014 (UTC)[reply]
  •  Support Magog the Ogre (talk) (contribs) 04:52, 29 July 2014 (UTC)[reply]
  •  Support support continent and country (when it is significantly larger than the capital),  oppose province and city (too difficult to define).    FDMS  4    09:39, 29 July 2014 (UTC)[reply]
  •  Support Commons filenames should include what (and not merely where) as the bare minimum. Take a look at how John Phelan names his images; every single one of them specifies what the image is of and where it was taken. He rarely needs more than five words, yet none of his images will ever need to be renamed. That should that be standard across all of Commons as a bare minimum. Pi.1415926535 (talk) 13:19, 30 July 2014 (UTC)[reply]
  •  Support INeverCry 03:45, 2 August 2014 (UTC)[reply]
  •  Support What not where. Ellin Beltz (talk) 01:27, 3 August 2014 (UTC)[reply]
  •  Support – Open to interpretation; for example, I would consider a file name just giving the name of an African national park the size of Wales to be overly broad. However, policy cannot prescribe for every possible situation. Overall, expecting a file name to be more specific than a city, province, or country seems very reasonable to me. CT Cooper · talk 08:51, 3 August 2014 (UTC)[reply]

Only information is the location (narrow)

This is for file names where the only piece of meaningful information is a specific location, such as a park, individual building, or event. In this case, there is no ambiguity as to the location where the image was taken, but reusers may still need to click on the image to see what specific facet of that location is being photographed.

Examples: File:USA-Boston Common.jpg, File:Fancy Frontier 16 (4824108744).jpg

Comments

  •  Oppose If an individual building isn't specific enough, I really don't know what is. Filenames don't need to be copies of the entire description page. darkweasel94 21:10, 24 July 2014 (UTC)[reply]
  •  Oppose because this level of specificity is more than enough for filenames. Green Giant (talk) 01:04, 25 July 2014 (UTC)[reply]
  •  Oppose, per darkweasel & Green Giant - Jmabel ! talk 04:40, 25 July 2014 (UTC)[reply]
  • ((o)) per above. I can think of rare cases where one could add a little bit of more (helpful) information. We still have to draw a line in the sand, otherwise we are moving files for the next few years. :) --Hedwig in Washington (mail?) 23:31, 26 July 2014 (UTC)[reply]
  •  Comment "Fancy Frontier 16" is a place? I'd strongly suggest dropping that example when this becomes a part of the criteria, it's more confusing than not, particularly as a Google search turns up almost nothing on it. I think it's a convention of some sort? Maybe? Better to use a clearer example. Adam Cuerden (talk) 01:04, 27 July 2014 (UTC)[reply]
    • The inclusion of Fancy Frontier 16 was deliberate, although the section header ("location (narrow)") is perhaps not ideal for describing it. In the parameter description, I said "a specific location, such as a park, individual building, or event", and Fancy Frontier 16 is, best I can tell, an anime convention. Take a look at this search result for the reason why I included "event". I suppose that using one of the Comic-Con file names instead of Fancy Frontier would be a good idea, but Fancy Frontier came to mind when I was writing this RfC because I had just cleaned out a bunch of COM:DW violations from that series of images. Sven Manguard Wha? 02:11, 27 July 2014 (UTC)[reply]
  •  Oppose For above and below (general discussion).--Pere prlpz (talk) 13:06, 27 July 2014 (UTC)[reply]
  •  Oppose - I see no particular need for disambiguation when it would cause a needlessly long filename. In fact I'd say those names possibly need some less specific information. -mattbuck (Talk) 18:28, 27 July 2014 (UTC)[reply]
  •  Comment it is going to depend. If someone says "Big Ben", then shows a picture of the top step as it looks out from the internals to the clock tower, then I would think that it is not sufficiently descriptive. If it says "Mona Lisa painting" and is only a picture of the kisser, then that is insufficient. So if it is of an element, then it should say so. This again should be guidance for cases where a rename usually would be declined, though other factors may be necessary.  — billinghurst sDrewth 13:00, 28 July 2014 (UTC)[reply]
  •  Oppose Beyond My Ken (talk) 20:42, 28 July 2014 (UTC)[reply]
  •  Oppose --Sebari (talk) 21:16, 28 July 2014 (UTC)[reply]
  •  Comment Agree with billinghurst: it depends on a case-by-case basis. If it is of an element, then it should say so. --Eleassar (t/p) 08:24, 29 July 2014 (UTC)[reply]
  •  Oppose per above.    FDMS  4    09:41, 29 July 2014 (UTC)[reply]
  •  Comment this should explicitly be allowed to be a judgement call by filemovers (who are considered trusted users) for smaller divisions. As noted by others, there is a huge amount of variation here, and it's ultimately going to be a judgement call. There are current 407 images of Boston Common (a mid-sized but extremely popular public park) and 217 more in subcategories; it is utterly necessary that file names are disambiguated. File:USA-Boston Common.jpg fails to tell me what is in the picture; File:Learning statue on Boston Common with State House behind.jpg tells me what the image is actually of. If Commons wants to be a useful image source (especially for more than just Wikimedia projects) then we have to be careful about naming images so that file names express a generally useful description, and not merely the minimum description possible. If a building has one image then it doesn't need renaming; if it has twenty then there has to be useful organization. Pi.1415926535 (talk) 13:01, 30 July 2014 (UTC)[reply]
Having 407 files in a category sounds like insufficient categorization to me. Just glancing at Category:Boston Common I see many possible sub-categories. Good file names are very useful, but not an excuse for insufficient categorization. --Sebari (talk) 20:00, 30 July 2014 (UTC)[reply]
But conversely, great categorization can't make up for a large number of ambiguous filenames. Both are needed for a good system of sorting images. Pi.1415926535 (talk) 21:06, 30 July 2014 (UTC)[reply]
  •  Oppose This would seem specific enough. Ellin Beltz (talk) 01:27, 3 August 2014 (UTC)[reply]
  •  Oppose for most situations – Personally I think file name should contain more information than just the specific place, but for those that don't follow this view, I don't think re-naming would normally be appropriate, since the most critical piece of information is still provided. However, if there's a huge number of uploads with the name of one specific place as a filename, a case for re-naming them can be made. Again, judgement by file movers on the specific situation is required here, and I think that's what the guideline should say on this issue. CT Cooper · talk 08:48, 3 August 2014 (UTC)[reply]

Generic category rather than specific item

This is for file names where the only piece of meaningful information is a word, such as "smartphone" or "screenshot", which broadly describes the subject of the file, but does not impart any information that would help someone identify the specific object depicted. This is not just restricted to inanimate objects, it also applies to broad titles or groupings, such as "queen" or "bird".

Examples: File:Smartphone.jpg, File:Screenshot3.jpg, File:Queen ver. 2.JPG

Comments

  • These three examples appear very different to me. I would  Oppose renames of "Smartphone.jpg" and "Queen ver. 2.JPG", but "Screenshot3.jpg" conveys absolutely no useful information about the file (while e.g. "Wiki.jpg" for a MediaWiki screenshot would be a filename that shouldn't be moved). darkweasel94 20:40, 24 July 2014 (UTC)[reply]
  •  Support because although these three examples look different, the names are not specific enough. Each of these would be fine if they are the only images we will ever have of the subjects. Is that smartphone the only smartphone that has ever existed or are there a lot more? It is the same as File:Cat.jpg or File:Dog.jpg, which are clearly too vague so they have been upload-blocked. Green Giant (talk) 01:04, 25 July 2014 (UTC)[reply]
  •  Support; again, hard to draw the line, but all three examples given here are too vague. - Jmabel ! talk 04:40, 25 July 2014 (UTC)[reply]
  •  Comment Just so that it's clear what we're talking about – we're talking about legitimizing renames like those of Tram exterior.jpg, right? (Ping User:DragonflySixtyseven so we don't talk about their actions without their knowledge.) Or perhaps the new filename there is also too unspecific, because it doesn't say which tram type that is? This criterion smells strongly of "filemovers thinking they would have chosen another name, and moving on that basis". Will this criterion really allow filemovers to rename File:Touche CTRL.jpg to include the keyboard model? If not, then where is the difference to "Smartphone.jpg"? darkweasel94 05:17, 25 July 2014 (UTC)[reply]
    •  Comment (not a vote, I'm not voting in this) When I wrote this, I was sort of thinking of this in layers of depth, as you would have with categories. For example, the bottom end of the category tree leading to images of a BlackBerry Q10 is category:Mobile phones → category:Smartphones → category:BlackBerry smartphones‎ → category:BlackBerry Q10. Obviously, different people are going to look at different points in that tree and say "that's specific enough for a file name". "Smartphone" could be one of 250 different distinct objects (going by the number of subcategories). "BlackBerry smartphones" takes that down to 15 possibilities (again, going by the number of subcategories). "BlackBerry Q10" takes it down to one. I'd love it if every file has a name that is specific enough that there is no, or almost no, ambiguity as to what is being described. That's never going to happen, however. I would be willing to live with "File:BlackBerry smartphone.jpg" because, since there are only 15 options as what it would be, it would take me maybe five minutes to figure out the exact model. It would take perhaps an hour to figure it out if the name was "File:Smartphone.jpg", because there are so many more possibilities to get through, and that's too much time (too many options), in my view. So yes, although I disagree with the way DS's edit summary made the case, in my mind this would legitimize the Tram exterior.jpg move, because there are hundreds of tram lines, so going off the name only it would take hours to figure out which one was shown. It would not legitimize File:Touche CTRL.jpg, however, because Category:Control key is at the very bottom of the chain. Sven Manguard Wha? 21:35, 25 July 2014 (UTC)[reply]
      • If it's supposed to be a function of which categories we happen to have at the date of renaming, then that's even more arbitrary. To take an example from my topic area, files in Category:Trams in Vienna would (for the most part) be eligible for renaming to include the tram type, but files in Category:Trams in Graz wouldn't (for the most part), and files in Category:Trams in Brno would even be eligible for renaming to include the exact tram fleet number. (All assuming that we're starting with a filename like "Tram in Vienna.jpg", "Tram in Graz.jpg", etc.) darkweasel94 21:58, 25 July 2014 (UTC)[reply]
        • No, I said nothing about it being "which categories we happen to have at the date of renaming", I said that I viewed it in terms of "layers of depth, as you would have with categories". Calling something "BlackBerry.png" is more specific than calling something "Cell-phone.png", because while there are 1000 different objects that could fit the bill of "Cell-phone", there are just over a dozen that could fit the bill of "BlackBerry". Sven Manguard Wha? 00:17, 26 July 2014 (UTC)[reply]
          • OK. I still think this is open to a far too wide degree of interpretation of what is specific and what is general. Filenames are there primarily to uniquely identify a file, and only secondarily to describe it, and filemoves should be done when it's necessary, not when it's merely possible to pick a better name. (Technical question: do hotlinks on other sites still work after a file is renamed?) darkweasel94 07:41, 26 July 2014 (UTC)[reply]
          • I don't see why we wouldn't rename files 1. when it brings substancial more information; 2. when it is non controversial (smartphone.jpg is obviously a bad name, Samsung phone.jpg or Nokia phone.jpg are much too vague, seeing the number of models). Regards, Yann (talk) 08:48, 26 July 2014 (UTC)[reply]
  •  Support as per Jmabel above. Yann (talk) 06:30, 25 July 2014 (UTC)[reply]
  •  Weak support darkweasel made good points. Maybe a few words could be added on the page to clarify the intention a little bit? Certainly smartfon.jpg/myfone.jpg/car.jpg isn't helping anyone. That doesn't mean we need to have the serial number of the keyboard mentioned above in the file name. :) Regarding Trams: There's always room for improvement, e.g. route, vehicle manufacturer, etc pp. Some(!) more info doesn't hurt anyone but makes finding things easier. For example: a few days ago (or a week?) I was trying to find a picture of a tram where I could look up the manufacturer. Something like that would have been helpful, I had to switch from Commons to wiki and back and forth. OK, I stop complaining! :) Hope you get the idea. ;) --Hedwig in Washington (mail?) 23:43, 26 July 2014 (UTC)[reply]
    • Which is a great reason to add such information to the description page. But file renames should really be kept to a minimum, in the interest of computing resources, prevention of watchlist flooding, and (if I'm not mistaken) hotlinking. Not all information needs to be in the filename. darkweasel94 07:48, 27 July 2014 (UTC)[reply]
  •  Oppose For above and below (general discussion), and per Darkweasel: not all information needs to be on filename.--Pere prlpz (talk) 13:08, 27 July 2014 (UTC)[reply]
  •  Support -mattbuck (Talk) 18:29, 27 July 2014 (UTC)[reply]
  • generally  Support though I again think that we can put this as guidance, rather than mandated. "Smartphone" is ambiguous, and I would be looking to rename. "Chromatogram" is ambiguous but I wouldn't rename. "Chromatograph" is ambiguous, and I would rename with make and model.  — billinghurst sDrewth 13:06, 28 July 2014 (UTC)[reply]
  •  Support
  •  Support --Sebari (talk) 21:07, 28 July 2014 (UTC)[reply]
  •  Support: Generic files should include scheme, example or anything similar in their filenames.    FDMS  4    09:44, 29 July 2014 (UTC)[reply]
  •  Support Filenames should be as specific as generally needed, not merely unique. "Smartphone" and "screenshot" and "queen" as generic terms should not be allowable filenames because they fail to specify what is actually in the image (except possibly if they're used as generic icons or something similar). Pi.1415926535 (talk) 13:17, 30 July 2014 (UTC)[reply]
  •  Support a helpful title should be added, and if the generic name given is not helpful, it should be removed. "Car" can be renamed as in "Ford Cortina 1600E", and "smartphone" as in "BlackBerry Q10", but in both cases only if the photo depicts the specific item as such. If not, the photo should be given a helpful name that best describes the topic as a whole (as specific as generally needed). "Queen" should become at least Queen X or Queen of X. I consider "chromatogram", or "stereogram", etc, relevant enough to be in the title, but the topic should also be present there. Hoverfish (talk) 22:34, 1 August 2014 (UTC)[reply]
  •  Support – Very generic titles just aren't helpful, though as always judgement will have to be made on a case-by-case basis – particularly with flora and fauna, where being as specific as possible is great, but having uploaders find out/know the exact (sub-)species isn't always practical. CT Cooper · talk 08:58, 3 August 2014 (UTC)[reply]

Acronyms and initials

This is for file names where the only piece of meaningful information is an acronym or a person's initials. This differs from "Absolutely no information at all" in that the acronym or initials are related to the subject of the file, even if it takes a second to figure out how.

Examples: File:24012012-lpicm.jpg, File:RAS.jpg

Comments

  •  Oppose No reason to treat acronyms any differently from their full forms, especially as in some cases the acronym is better known than the full form. For example, "ÖBB.svg" would seem like a better filename for the logo of Österreichische Bundesbahnen than the full name. darkweasel94 21:10, 24 July 2014 (UTC)[reply]
  •  Support because acronyms are not always better known than the full name and even when they are it isn't always a helpful name. Does anybody want to upload File:NATO.jpg or perhaps replace the redirect at File:USA.jpg? Green Giant (talk) 01:04, 25 July 2014 (UTC)[reply]
  •  Oppose No problem with acronyms or initials as such -- e.g. "NATO" is better known than "North Atlantic Treaty Organization" -- but if they make for an effectively incomprehensible name, then we get back to where they might as well be DSC5388. - Jmabel ! talk 04:40, 25 July 2014 (UTC)[reply]
  •  Comment This has to decided on case by case basis, but I think that usually just an acronym is not clear enough (Flag of USA.jpg is better than USA.jpg). Yann (talk) 06:36, 25 July 2014 (UTC)[reply]
  • Partial support Pretty much per all the other comments. We shouldn't have a rule that all acronymns should be expanded, but as a general rule, a short acronymn like RAS.jpg contains insufficient information to figure out what the topic is. But we shouldn't, say, expand "NATO logo.jpg" or "JSTOR logo.jpg", though I'd say it's far less than best practice to have NATO.jpg without a disambiguation. Adam Cuerden (talk) 20:30, 26 July 2014 (UTC)[reply]
  •  Support How often do we have useful acronyms vs. gibbersih or lingo acronyms? Most of the time the acronym says nothing about the image. We should be allowed to rename toward Logo XYZ.xxx Btw: File:Logo ÖBB.svg makes more sense then ÖBB.svg. It might be clear for experts what it is, but does it really hurt to add Logo (in most cases) to the name? --Hedwig in Washington (mail?) 23:49, 26 July 2014 (UTC)[reply]
    • I don't think the question is if it hurts to add something more to the filename, but if it's necessary to do so. Filemoves cause edits to all pages where the file is in use, leading to waste of resources and watchlist noise. AFAIK they also break hotlinks from outside. That's why I think they should be kept to a minimum, and files shouldn't be renamed just because the filemover thinks there could be a better filename. This entire discussion makes me sad, because I see that trigger-happy bored filemovers will now get their actions legitimized. It's sad that the community apparently supports going the way of having Wikipedia-like naming conventions for filenames. The times when uploaders were allowed to choose the specificity and amount of context they put into their filenames, including choosing simple rather than complex filenames, appear to be over. I guess I'll need to move with the times. darkweasel94 08:00, 27 July 2014 (UTC)[reply]
      • @Darkweasel94: I think "waste of resources" and "watchlist noise" are poor arguments against renaming. Seeing the amount of data processed in all Wikimedia projects, even renaming a few thousand files wouldn't change anything in the load of the system. I suppose that "watchlist noise" is a problem for you because you watch your files. But if you put a meaningless name in the first place, it is the duty of the community to improve the names, regardless of your inconvenience. If you want less "watchlist noise", use better names. Regards, Yann (talk) 13:21, 27 July 2014 (UTC)[reply]
        • Yann (talk · contribs), this is not really about my own files: if I watch a page (on any Wikimedia project) where a renamed file uploaded by anyone is in use, then I also get notified of the very important information that a file was renamed. I watch four OgreBot galleries of new files in my userspace, and this is what I mean by watchlist noise. darkweasel94 14:27, 27 July 2014 (UTC)[reply]
          • Well, sorry for you. But since I have a big watch list on some active projects (Commons, English Wikipedia, etc.), should I ask people to stop improving the articles because it floods my watch list? Yann (talk) 15:58, 27 July 2014 (UTC)[reply]
            • No, but that's comparing two totally different things. Filenames aren't the central part of what Commons is about. They exist to uniquely identify a file, and that's it. If I watch a page, then that means that I do want to be notified about changes to that page, but filemoves aren't really changes to the pages the files are on. I don't object to seeing them, I object to filemovers moving files totally gratuitously "just because they can". The filename is the absolutely least important piece of metadata of an image. And BTW, I've just tested: yes, moving files does break off-wiki hotlinks to the full-resolution versions – and under that circumstance, there really exist people who want more filemoves than are already done (far too many already)? I really can't believe it. It's destructive and makes people lose faith in Commons as a persistent hoster. darkweasel94 17:18, 27 July 2014 (UTC)[reply]
              • No, that's not different things. I am sorry that your watchlist is flooded, but this is a very little inconvenience for an improvement. I completely disagree with "the filename is the absolutely least important piece of metadata of an image". On the contrary, one of the major information about a file is its name. That's the first and most important criteria used by the search engine. Then filemovers do not move files because it is fun, but because the name is broken, and does not represent what the file is about. I agree that we should be cautious for files hosted for a long time, but for newly uploaded files, there is no valid reason not to rename them, if the name is misrepresenting a file. And there are certainly not "far too many" filemoves. A lot of files have a bad name and should be renamed. Finally, you could wish to have more options on how a watch list works. I could imagine to have an option when renaming a file doesn't trigger the watchlist. If it really that important for you, make a request to the developpers. But I don't see any valid reason in your arguments against the improvement which constitute renaming files. Regards, Yann (talk) 17:53, 27 July 2014 (UTC)[reply]
              • "They exist to uniquely identify a file, and that's it." That's completely untrue. Filenames exist to identify what the image is of in all cases, and where, when, and who created it when (at a minimum) they are relevant to identifying the image. By your argument, we could assign ten-digit numbers to every file (or use five or less Unicode characters!) and that'd be sufficient. That's bollocks. Commons filenames have relevance outside what name the uploader happens to like; they provide basic ID and description when working with them on other Wikimedia projects, and when hotlinking from outside the filename provides useful search terms as well. Broken hotlinks are a technological problem and Wikimedia projects are very good at solving those (old hardlinked images work after moves unless the filename is overwritten? That's possibly doable); bad filenames are a systemic problem with serious implications about the long-term significance of Commons as a legitimate gathering point for hundreds of archive collections. I frequently use images taken a century ago by those hoping they would be useful historical documentation someday; I upload my images under similar hopes, and that means establishing architecture - category structures, and filename structures - that will last. A few broken external links will suck, but they'll suck a lot less at 22 million files than at 220 million files. Pi.1415926535 (talk) 13:51, 30 July 2014 (UTC)[reply]
                • If your search engine just looks filename and doesn't look description pages, you should improve your search engine or change it, not mess with other people's files names.--Pere prlpz (talk) 21:30, 27 July 2014 (UTC)[reply]
                  • @Pere prlpz: FYI, it is not my search engine. All search engine, including Google, use the file name as primary criteria. If you are not happy with Commons search engine, please fill a bug report here. If you are not happy with Google search engine, please make a request to Google. If there is a mess, it is because people use meaningless names in the first place. Frankly, more it goes, more the objections against renaming are ridiculous... Regards, Yann (talk) 13:23, 28 July 2014 (UTC)[reply]
  •  Support as Hedwig. Yann (talk) 04:51, 27 July 2014 (UTC)[reply]
  •  Oppose As Darkweasel.--Pere prlpz (talk) 13:36, 27 July 2014 (UTC)[reply]
  • It depends on the context really - some acronyms are very well known (CIA, EU, etc), others less so (JC for Jubilee Campus). -mattbuck (Talk) 18:30, 27 July 2014 (UTC)[reply]
  • generally  Oppose as the acronym will often be expanded in the description, and something like NARA, PRO, POTUS, BA MA, are all well-known and accepted. Prefer that this is given as guidance, not mandated.
  •  Support On the understanding that the renaming criteria doesn't make it mandatory to rename a file, but leaves it to the discretion of individual editors, who, I would hope, would evaluate the acronym to determine if it carries sufficient information to avoid renaming. Also, strong consideration should be given to whether the acronym is adequately expanded or explained in the image's information. If so, then there is no need to rename.

    Given these caveats, I would recommend that an explanation be part of the criteria. Beyond My Ken (talk) 20:44, 28 July 2014 (UTC)[reply]

    •  Clarification Beyond My Ken: Although I certainly hope that anyone that saw a file name in violation of new criterion 5 would change it on the spot, file renaming is not mandatory. For any file to be renamed, at least one person (two if the first is not a file mover or admin) needs to look at a file name and think that there is a compelling reason for it to be renamed. Some people have better judgement than others, and some people interpret the rules differently than others, but file renaming always involves a human making a judgement call. Sven Manguard Wha? 21:27, 28 July 2014 (UTC)[reply]
  •  Weak support as per Adam Cuerden, some abbreviations are meaningless, some are better known than the full form (NATO, ÖBB), and sometimes it depends on the context (BER in itself is meaningless, but BER airport diagram is a good name) --Sebari (talk) 21:14, 28 July 2014 (UTC)[reply]
  •  Support per Cuerden, Hedwig and Yann (i.e. an acronym is in many cases well-known, but e.g. the word 'logo' describes an essential aspect of the file). Filenames are certainly not "the absolutely least important piece of metadata of an image". As stated above, they're used by the Google ranking etc. and also allow reusers to find what they're looking for through categories at the first sight, by scanning the thumbnails without enlarging the view - so they should include the relevant keywords (image subject, location). The filenames should clearly and concisely tell what the image represents. --Eleassar (t/p) 08:38, 29 July 2014 (UTC)[reply]
  •  Weak oppose per above.    FDMS  4    09:47, 29 July 2014 (UTC)[reply]
  •  Support with judgement calls allowed by the filemover. If the acronym is not sufficient to fully disambiguate the subject, then it should not be the filename. Enwiki alone has 49 listings on the RAS disambiguation page; RAS.jpg could be any of those. Logos of organizations where the acronym is sufficient to specify - like File:MBTA.svg as I mentioned elsewhere - could plausibly be left as is. But even then, File:MBTA logo.svg is still a superior filename. Redirects are cheap. Pi.1415926535 (talk) 13:34, 30 July 2014 (UTC)[reply]
  •  Support per Hedwig & others. INeverCry 03:47, 2 August 2014 (UTC)[reply]
  •  Support as Hedwig. Ellin Beltz (talk) 01:27, 3 August 2014 (UTC)[reply]
  •  Support per Pi.1415926535. As per the emerging theme of this RfC, a judgement call has to be made. Generally I would say acronyms alone are far too vague in most situations, but there may be a small number of cases where a file can be left alone. CT Cooper · talk 09:05, 3 August 2014 (UTC)[reply]

Very short names

This is for any file name where the file name proper (i.e. not counting "File:" or the extension at the end) is six characters or less. This does not distinguish between names that may be meaningful and names that aren't. Many of these also fall under one or more of the other criteria proposed above, especially "Absolutely no information at all", "Generic category rather than specific item", and "Acronyms and initials", so if all of them are approved, there will be overlap.

Examples: See User:DragonflySixtyseven/Short filenames 15 (or any other page number, they go up to at least 50)

Comments

Names that are not meaningless, but do not describe the file

This is for file names that contain a coherent description or message that do not describe the subject of the file, and do not already qualify for renaming under criteria 3 (obvious errors) or 5 (violation of Commons' policies and guidelines). This does not apply in cases where the name of the file is the title given to a work of art by the artist that created it, even if the name has nothing to do with what is depicted (for example, many works of Dadaism). This can sometimes be difficult to tell, especially with artistic photographs. This is not a catch-all criterion, it is for a specific type of name, illustrated by the examples below.

Examples: File:How cute is he^ - geograph.org.uk - 1426163.jpg, File:Flickr - law keven - Anybody know a Good Dentist^......Happy Furry Friday Everybody...-O))).jpg

Comments

Images where the information in the filename, while normally acceptable, is inappropriate for the specific content

For example, File:Louvre 12.jpg would normally be an acceptable filename, and if it was of the outside of the building, or a general shot of galleries, it would be fine. However, if it was of a specific painting in the Louvre, say, the Mona Lisa, then it should probably be renamed. Adam Cuerden (talk) 01:13, 27 July 2014 (UTC)[reply]

Comments

Our current criterion #6 gets used in a huge lot of invalid rename requests (like this one), as a catch-all.    FDMS  4    19:33, 3 August 2014 (UTC)[reply]
  • On criterion three, this has been re-worded as per the first RfC. I'm not sure why the guideline page hasn't yet been updated? Criterion three now covers obvious errors, such as misspellings, incorrect dates, and the misidentification of the subject. While is not unarguable that it could cover misleading file names, this is far from clear, and I see no reason why criterion two can't address this issue instead. CT Cooper · talk 19:08, 3 August 2014 (UTC)[reply]
  •  Comment To my mind "misleading file name" examples would be "ThisBitchIsAPieceOfShit" or "RulerOfTheGodUniverse", or "MyLittleHouse" instead of "Mary Jane Smith," "Bob Jones" and "123 Main Street, Everytown". Ellin Beltz (talk) 15:21, 6 August 2014 (UTC)[reply]
    • Your first example is covered under the criterion allowing renames of filenames that would otherwise be violations of Commons policies/guidelines. The other ones will probably variously be defined as "generic category rather than specific item" (more likely for "MyLittleHouse", although if it actually is a little house, then I don't see a problem with that filename, there isn't anything misleading here) and "names that are not meaningless but do not describe the file" (more likely for "RulerOfTheGodUniverse"). None of them needs this kind of vague catch-all criterion to be renamed. darkweasel94 15:29, 6 August 2014 (UTC)[reply]

Other suggested criteria

I covered all of the cases I could think of, but there might be something I've missed. If so, please mention it here. If your suggestion gets endorsed (that is to say, you and one other person support it), I will create a section for it above, moving any pertinent comments into that section when I do.

  • Excessive ambiguity - names that, while they technically describe the file, do so in a way that makes it unnecessarily difficult to identify the topic. For example, a two-letter or three-letter acronymn is likely to have dozens, if not hundreds, of possible meanings, making it very, very hard to identify the topic. As another example, File:Cage.jpg could be anything from a cage used to restrain people to John Cage or Nicholas Cage. Obviously, this is a subjective criterion, but if the naming policy is meant to be an exclusive list of reasons, not simply ones accepted automatically, it's good to include a little ability to use judgement. And if it's not meant to be exclusive, we should probably say that explicitly. Adam Cuerden (talk) 20:41, 26 July 2014 (UTC)[reply]
  • To help disambiguate a set of files with similar names For example, if File:Andrew Person.jpg, File:AndrewPerson.jpg, File:A. Person.jpg, File:APerson.jpg, and so on all exist, adding a little more information to every file name might help people quickly evaluate the files, especially if, for example, A. Person.jpg is actually Adam Person, but APerson.jpg is Andrew Person. This is, however, arguably a variation on Criterion 6, not 2, but the concept is similar to the things we're discussing here. Adam Cuerden (talk) 20:46, 26 July 2014 (UTC)[reply]
That sounds like a good idea, I think we should add something similar to the rules. --Hedwig in Washington (mail?) 00:01, 27 July 2014 (UTC)[reply]
  • DjVu/PDF files used at the Wikisources can have any of the above faults,, however, these files should not be renamed unless there is evidence that they are not used, or only after the WS approves the move. Renaming these files is problematic and should only be done in consultation with the WS that has the file. When they are pulled over from archive.org they can have names that match the details string of the url, and while rubbish, the use of {{Book}} is more relevant. Again this is guidance material, but needs to be stressed to admins.  — billinghurst sDrewth 13:22, 28 July 2014 (UTC)[reply]

General discussion on file renaming criterion 2

Any discussion that is not on a specific option should take place here, so that those sections remain easy to follow.

  • Here's a post I made to user:LX's talk page last year. I concede that the tone is more hostile than is optimal, but I was in a somewhat hostile discussion (having been harshly criticized for the very first rename mentioned in that diff) at the time. Also consider this diff: if the file had been given a proper name earlier, splitting would not be necessary. DS (talk) 16:26, 25 July 2014 (UTC)[reply]
    • Umm. My problem with that post isn't so much with the tone, but with the fact that it contains plenty of non-sequiturs:
      • Having a photo called "advocaat.jpg" is stupid and wrong, because if an idiot wants to upload a photo of a glass of rich eggy liqueur, that idiot will call it "advocaat.jpg", and all the articles about the football coach will be altered, and many people will be upset. – and if "advocaat.jpg" is already taken by another photo of rich eggy liqueur, then it is not exactly much better if that same idiot uploads over that file. All upload interfaces (except maybe direct API use or bot interfaces, which aren't normally used by idiots – except for me, of course) that I know warn or prevent people from doing that.
Warn, yes. Prevent, no. And there are people who will click through and upload the new version anyway, without noticing. DS (talk) 19:23, 25 July 2014 (UTC)[reply]
      • What is the difference between "After.jpg" and "AFTER.jpg"? Don't look at them, just tell me. What about "Abies koreana 02.JPG" and "Abies Koreana 02.jpg"? Or "90 mile Beach.JPG" and "90 mile beach.jpg"? Now explain that to your grandmother over the phone while she's trying to edit a page and getting all flustered because it's the wrong picture. – If my grandmother (or anyone else) doesn't pay attention to capitalization, then she won't succeed to insert a file even if one of the capitalization variants doesn't exist. Is it really better if my grandmother gets a redlinked file than if she gets the wrong file? I'd say these are equally bad, and I'm fairly certain my effort in explaining it to her on the phone would be the same in both cases.
    • darkweasel94 17:48, 25 July 2014 (UTC)[reply]
Email me the phone no., I'll try to explain it. Caps are certainly a problem. We could rename all files to caps. Or lowercase. Oh boy, I can see the discussion getting out of hand with tons of blocks.
We(the ones actually doing the maintenance work) need to be able to rename files like after.jpg or advocaat.jpg for two reasons: First, it makes sense to add a little bit of information to the filename. Second, it prevents other, not experienced, users from overwriting. No, it is not bulletproof! But it is helping to avoid a little unnecessary work. --Hedwig in Washington (mail?) 00:11, 27 July 2014 (UTC)[reply]
  •  Oppose In previous wording of the rule and its example, this criterion was to rename files with no information at all - automatic file names created by cameras. It's up to the author and uploader to choose what information wants in file name. We can put as much information as we want, but such information should go to file description, not filename.
A possible exception can be files uploaded from somewhere else. We know author's choice of file names for files uploaded to Commons by author, but we don't know which name he would have chosen for Commons if he only uploaded the file to Flickr - then, we can chose a better name for Commons.--Pere prlpz (talk) 12:59, 27 July 2014 (UTC)[reply]
After reading again each proposal, I see all them just a set of wild cards to rename other people's files at will. All the work of rewriting the rules is only useful to prevent current abuses, but this second request for comments is just destroying what the first one did and encourage such abuses.--Pere prlpz (talk) 13:44, 27 July 2014 (UTC)[reply]
  • In any renaming, the author's naming scheme should be followed where possible. -mattbuck (Talk) 18:32, 27 July 2014 (UTC)[reply]
    •  Agree and especially it should stay in the same language. Apparently we are (however unfortunately) going to allow renames from "Austria DSC 3452.jpg" to "Church in Groß-Enzersdorf DSC 3452.jpg", but it shouldn't become "Kirche in Groß-Enzersdorf DSC 3452.jpg" (although it should become that if the original was "Österreich DSC 3452.jpg"). darkweasel94 20:28, 27 July 2014 (UTC)[reply]
Well, I  disagree (even using a template). It should not become a requirement to learn all thousands of languages in order to be able to rename any file in accordance with filemoving policies.    FDMS  4    09:30, 29 July 2014 (UTC)[reply]
 Support How do you expect to "improve" a filename written in a language you don't know? If you don't know the language you should let it to someone else.
Furthermore, most of the supposed advantadges of changing names are overriden by the multilanguage nature of file names, but it can be solved by improving descriptions instead of filenames.--Pere prlpz (talk) 15:45, 4 August 2014 (UTC)[reply]
Well, there are several indications that a filename is bad, for example when it is very short or contains many numbers or exclamation marks, for non-obvious cases there are online translators available. Also, if a bad name is in German (which I'm a native speaker of), the better name I would come up with would be in English for several reasons. While Commons is a multilingual project, no one can force me not to use English (unfortunately, no one could force me not to use Japanese in filenames either).    FDMS  4    16:22, 4 August 2014 (UTC)[reply]
  • Just a note: I'd be careful how you define author. I'd be upset if my careful sets of restoration (JPEG and PNG) and original scan (often TIFF) were broken, particularly as I've fallen into a (fairly) consistent naming scheme for my restorations. Adam Cuerden (talk) 06:42, 28 July 2014 (UTC)[reply]
File:2 Hurbanovo námestie.jpg – no one seems to think it should be renamed, and neither do I, but tell me without further context what it shows?
  •  Comment I think many of the views in this discussion are based on the fallacy that usefulness of filenames is absolute and equal for everyone. It isn't; it depends on the context you found the photo in, and your knowledge. Take, for example, my own file File:2 Hurbanovo námestie.jpg. Its file naming scheme is one I've often used for tram photos (mainly because it is language-neutral): "$linenumber $location" (the location usually being a street, square or tram stop, in this case a square). This is a naming scheme that no one here appears to be criticizing, as it's quite specific and contains more than one piece of information.
    • If you found it in the context of Category:Tatra T3AS in Bratislava, then the filename is very useful; it distinguishes the photo from other files in that category well.
    • If you found it through Category:Hurbanovo námestie, Bratislava, then it's less useful, but if you've already noticed on the thumbnail that it's a photo of a tram, you might correctly guess that "2" is the line number.
    • If you found it through Category:2013 in tram transport in Slovakia, then the filename's usefulness depends on whether you know there is a Hurbanovo námestie in Bratislava, but none (as far as my quick research has found) in Košice, the other Slovak city with a tram network. If you know that, it's very useful; if you don't, less so, and in that case, you might have appreciated "Bratislava" in the filename.
    • If you found it through Category:Advertising columns or perhaps Category:Photographs taken on 2013-07-22, then it's most likely totally useless (almost as much as "IMG 2534.JPG"), because in that case you probably don't already know anything about Bratislava or Slovakia or trams, or even if you do, you're not expecting a file described like that. If you found it that way, then "Bratislava IMG 2534.JPG" would probably have helped you a lot more than what I chose.
Now this is just a random example I quickly found. There are probably better examples. My point is that if you're in a category like Category:Black objects, other filenames will be useful to you than if you're in Category:Fujitsu mobile phones. In the first case, "Smartphone.jpg" is a quite useful filename, in the second one it's less useful. The latter category now contains File:ISW11F BACK.JPG, a useless filename in the context of "black objects", but a useful one in the context of "Fujitsu mobile phones". It seems pointless to me to presuppose the context (which may not be just categories, but also searches, which are far less predictable) a user will find a file in. It isn't the same for everyone, and if we tried to make a filename useful for every possible context (and, importantly, allow renaming to do so), it would end up as a copy of the description. "Vienna DSC 2341.JPG" can be a very useful filename if you aren't already in the category structure of Vienna.
This fits both with the "broad location" and the "generic category" criterion, which IMHO raise the same considerations, so I'm putting it here. darkweasel94 19:06, 29 July 2014 (UTC)[reply]
  •  Comment Long time ago, Commons decided to use categories instead of tags as the primary mean to classify and find files, and a lot of good work has been done in categories - Flickr decided the other way and they use tags. Now, you are trying to replace categories by tags by putting all tags (or some randomly chosen tags) in the place of filename.--Pere prlpz (talk) 15:32, 31 July 2014 (UTC)[reply]
  • And so what? Descriptive filenames are not remotely the same as flickr tags; they act equivalently to the title of an article on the various wikipedias. Within a category, they serve to identify what differentiates that image from other images in the category. Any sorting system - category or tag - is still kneecapped unless files within those sorting bins are also well-named. Flickr has image titles too; they're not always used in a descriptive manner, and that's part of the reason that it will never been anything but a personal image hosting and social site. Commons is not a personal image hosting site; releasing files under PD or CC licenses means that the author permanently gives up an absolute claim to what is done with it. Commons is for images used in an educational and archival manner; if we want to be taken seriously as such, then we need a strong system of both categorization and image naming.
Commons, if it can be compared to anything else, is organized rather like a research library. Imagine a bookshelf (category) with fifty books labeled "Calculus" on it. Yes, you could go back to the card catalog to figure out which of them are the one you want (category intersections) or start looking at the table of contents (search function). But if you want to find the single book you're looking for quickly, you want the spines to read "Elementary calculus" and "Partial differential equations" and "Solutions to difficult integrals" so that you can visually find the one you want. (Remember that the search function only displays the first few words of an image description, but the whole filename, so a descriptive title becomes essential literally any time the search function is used.)
I am sympathetic that you are worried about the files you have uploaded; I took am protective of "my" files even though they do not belong to me. But it looks like you are extrapolating that to the everyone's files, and in doing so you are advancing a philosophy that is incredibly damaging to the mission of Commons. Pi.1415926535 (talk) 17:56, 31 July 2014 (UTC)[reply]
Wow. So much I strongly disagree with in one comment. File moves are technologically and socially expensive, break hotlinks (!!!!!!!!), and make files harder to find again if you've already found (or uploaded) them once under their old filename, with very few benefits. For example, I'd instantly recognize File:2012 Wien 0228 (8102865895).jpg as a file I've uploaded and I'd know which Flickr stream it came from, but I don't know what File:Yellow Trabant 601 at a street in Vienna, Austria.jpg is if I find it in a category, that must be some random file someone else uploaded – why is it on my watchlist again? Ohhh yeah right, because someone decided to gratuitously rename a file I uploaded, in the process randomly changing the language from German to English, removing useful information like the Flickr ID and the year the photo was taken in, and making it non-obvious to everyone that this was taken by the same person just before File:2012 Wien 0229 (8102878512).jpg, which might help in identification of the location. Oh, and if anyone ever somehow (advertently or inadvertently) breaks the link to the Flickr source, Flickr2Commons won't scream "a file of this name already exists on Commons", and people might waste time trying to upload it. The benefit being what, exactly? If I'm in Category:Trabant 601, then I already know that what I'll find there is cars of that type. I can instantly recognize on the thumbnail that it's yellow, without needing to read the filename (and possibly not understand it, because not everyone speaks the same language). The information that it's in Vienna was already there before the rename. And the potentially useful information of the year was removed. Also removed: the fact it comes from Flickr, and the filenaming scheme that might lead people to know (e.g.) the license (or expected quality) beforehand by analogy of other works by the same photographer. (Pinging Mippzon (talk · contribs), LezFraniak (talk · contribs) as it is their rename I'm using here as an example of an unnecessary filemove that seems to be gaining consensus now and I don't want to talk about people behind their backs.) darkweasel94 20:22, 31 July 2014 (UTC)[reply]
That's a poor choice of filemove to show. Removing useful information like the date and flickr id, and changing the language, are changes that are not being advocated by anyone here. That rename would not be encouraged by anything being proposed here. File moves should increase (not decrease) the amount of information in the file name; I don't believe there's anyone who is arguing otherwise. The vast majority of flickr filenames are terrible for any sort of encyclopediac use and would not be accepted for uploads by users here; why should they be accepted for transfers from flickr? And you're ignoring that you don't own pictures you upload - filenames should serve all users of Commons, not merely the person who uploaded it. Personalizing your filenames for your benefit only is for social sites... like flickr. You wouldn't have any problem remembering which images you transferred, and this whole discussion would be moot, if you'd transferred them to a good filename in the first place.
You can still have all the information from flickr - the id and even the photostream - but why are you not tacking on a description in the filename after the flickr information that when you transfer them? What's so wrong with 'File:[flickr information]-[what the image is actually of].JPG' that makes you refuse to name files that way? That's frankly irresponsible. There seems to be an attitude that when mass-transferring files from flickr, three of the essential elements of a file - descriptive filenames, properly specific categorization, and good descriptions - are optional. That's simply not true; if anything, they're more essential because with files self-published on Commons, the creator is at least around to answer questions. Those trusted with mass-uploading files from flickr should be highly capable users whose transfers never even come under consideration for renaming because they were properly named during transfer. Unfortunately, that's not the case, as your and other editors' transfers show. You should be trying to always create hundred-year filenames - names that would make sense to a researcher in 2114 when there's no guarantee that flickr - much less any of the editors now - will be around. You're saying that file moves ruin your ability to keep track of your filenames; do you as a single person matter in the grand scale of millions of editors and billions of potential users who would be benefited by a descriptive filename? Pi.1415926535 (talk) 20:41, 31 July 2014 (UTC)[reply]
Darkweasel94, you mentioned "useful information like the Flickr ID and the year the photo was taken in" but that information can go into the file summary using {{Flickr}} which is designed specifically for Flickr images in place of {{Information}}. There is also a parameter which let's you preserve the original filename from Flickr so that information doesn't have to be lost if the file is given a different Commons name. Such information doesn't really have to be in the filename. Needless to say, summary templates have a parameter for the date of creation so it shouldn't really be lost either. Green Giant (talk) 00:13, 2 August 2014 (UTC)[reply]

My little contribute to this discussion

Please, excuse me this manner to participate at this discussion. My elementary level of english is a very handicap for me to participate at this discussion. I cannot read all the intervention above and to understand it correctly. It needs for me hours and hours... is an immense effort for me... it's not possible. Sorry. Just wanted to say that not all file names that seems meaningless are meaningless. I found myself in this situation that the Brooklyn Museum uploaded thousands of files, very interesting black and white photographs of 1890's. I am interesting in art and architecture of Italy. The users that uploaded all these files were not coordinated between them, so they uploaded all the files without coherence, some in the main cat Category:Media contributed by the Brooklyn Museum, some others in Category:Photography in the Brooklyn Museum, some others in Category:William Henry Goodyear and in Category:Photographs from the Goodyear Archival Collection. Between all these photographs there are the pictures of William Henry Goodyear taken in Italy, France, Egypt... The photographs was uploaded with theyr catalogue number (like here). These numbers seems meaningless, but are not. The uploaders have scattered the photographs of Goodyear between several categories (Brooklyn Museum, Godyear, the different monuments in Italy, etc.). I was obliged to search and to find them again everywhere, it was a big work for me; I put all that I found in the new Category:Historical images of Italy by William Henry Goodyear, and finally I made all the subcats by cities. Now, to find them, it was VERY IMPORTANT the catalogue number of these pictures. So I could see if the photograph was there or not, if it was a duplicate, where the photographs were missing, and where there was mistakes in the catalogue numbers or in the file name. Where users had changed this "meaningless number" with a file name of the monument or of the city (like severals here), there was a new problem for me, because I was obliged to open each pictures to see if it is by Goodyear or not, and then to find the catalogue number and finally to put it as a sort key. A big work more that I would rather not have to do!
As for the new photos, when I upload photos taken by me, it is equally important the number and the camera prefixes (such as "DSC", "IMG", or "HPIM"), because they allow me immediately to identify the photo, the period in which I have taken it, and with what camera. So these are perhaps "meaningless" file names for WP or Commons, but not for me the author of the picture. This is wath I wanted to communicate. I do not know if it is useful to the discussion. Thank you at all. Best regards, --DenghiùComm (talk) 10:47, 5 August 2014 (UTC)[reply]

Thanks for that contribution. S a g a C i t y (talk) 14:15, 5 August 2014 (UTC)[reply]
I keep in my uploads the number and camera prefixes, too. It's very useful to find my pictures. I didn't follow this practice in my first hundreds of uploads, and since them I've uploaded some tens of duplicates of them without noticing. Therefore, such "meaningless" part of the name is actually useful. Furthermore, it's often useful to relate correlative images, like an sculpture and a plaque identifying it.--Pere prlpz (talk) 10:50, 9 August 2014 (UTC)[reply]

Current filemovers and new requests for filemover rights

 Question New requests for filemovers are coming in several times a week. Should we postpone to grant the right until the new caselist is done?

 Question We should inform all users with file mover bit about the new caselist as soon as it is updated. Probably a bot should add a message on the talk pages and/or watchlist notice. Any takers? --Hedwig in Washington (mail?) 16:48, 1 August 2014 (UTC)[reply]

I think that now it's more important to inform all uploaders that file name can be changed at will by anybody.--Pere prlpz (talk) 18:04, 7 August 2014 (UTC)[reply]

Ridiculously long file names

Not sure if this is the right place to mention this, but are there, or can / should there be, any criteria for renaming inordinately long filenames? For example, this series in Category:Aquila verreauxii:

Each contains two vernacular names (one archaic) as well as the scientific name, a load of nonsense about "baby eagle nappies" (nest material, actually), plus location and the Flickr code number. An absolute pain if you need to type the filename out, if one is without access to a copy-n-paste facility. My preference would be to rename them File:Aquila verreauxii at Walter Sisulu NBG, Johannesburg 1.jpg et seq. to File:Aquila verreauxii at Walter Sisulu NBG, Johannesburg 9.jpg - anyone any thoughts for a formal guideline? Perhaps permit file renaming if the name exceeds X characters, where X could be 20, 30, or whatever? - MPF (talk) 17:40, 7 August 2014 (UTC)[reply]

I think these names are fine. Fully decriptive and useful. Regards, Yann (talk) 17:46, 7 August 2014 (UTC)[reply]
Actually, they're not "fully decriptive and useful"; that cr@p about "nappies" is manifest nonsense, birds don't use nappies. And having three names for the same thing, one of them misleading ("Black Eagle" correctly refers to Ictinaetus malayensis), isn't helpful either. - MPF (talk) 18:04, 7 August 2014 (UTC)[reply]
All this request for comments is about putting the whole description in file name, so resulting names will be longer than those ones.
Anyway, I think such names are fines if they are the names chosen by author.--Pere prlpz (talk) 17:51, 7 August 2014 (UTC)[reply]
That is not my reading of this RfC. CT Cooper · talk 02:13, 8 August 2014 (UTC)[reply]
I'm not inclined to support a criterion banning file names just because they are viewed as too long, for similar reasons as why I'm against re-naming files just because they are too short. As for the examples given, criterion three already cover factual errors and people always have the option of taking up grievances with the uploader. CT Cooper · talk 02:13, 8 August 2014 (UTC)[reply]

Too long file names... These of the black eagle are quite short... Usually all the recent pictures of the US Navy activity in the world have extremely long file names (e.g. look at here ). I don't understand why some people confuse the name of a file with his description. I think that these are two different things. Clearly two different things! Such long names unnecessarily encumbers the pages of files in categories, make it more difficult to find a particular file, and generally to work on images and categories. So I am strongly contrary to this kind of long file names. My opinion is that WP or Commons should put a limit on the length of file names, otherwise we will continue to have these absurd names and these abuses. Too long file names could become a new criterion for file renaming! --DenghiùComm (talk) 04:56, 8 August 2014 (UTC)[reply]

There is already a technical limit of 240 bytes for new uploads, and 255 for those that existed before it was lowered to that. I think this is getting ridiculous: let's change filenames that are too short, let's change filenames that are too long, let's change all filenames a filemover doesn't like and break as many hotlinks and naming schemes as possible. darkweasel94 05:31, 8 August 2014 (UTC)[reply]
I agree with darkweasel's statement.--Pere prlpz (talk) 11:33, 8 August 2014 (UTC)[reply]
This should be about finding a healthy balance. Some files clearly need to be re-named at some point, but the line has to be drawn somewhere. Being against moving files just because they are too long or short is one point where I believe that line should be drawn. The issue of file names being too long is a minor one at best, and I don't think there is any issue of confusion between a file title and description – file titles are already limited to 240 bytes, while descriptions can be paragraphs and paragraphs long. If there is a desire to lower the limit further, then that is for a separate discussion. CT Cooper · talk 23:18, 8 August 2014 (UTC)[reply]
I agree with Darkweasel94 (just above). The perfect should not be the enemy of the good enough. We have file descriptions, a good place for items that some would like to include in file names. If the file name is humanly readable, not deceptive or confusing, and unique, that is enough, I think.
The following provide little guidance to the file mover. The three overlap and make the file mover the arbiter of whether file name is specific enough. If adopted, I urge that guidance be provided that these criteria be used sparingly and only in obvious cases. I suggest that they be grouped with "Absolutely no information at all" into "obviously [clearly] too broad, general or uninformative".
 Comment This shows the problem of trying to codify common sense. These proposals, as a whole, are very good but suffer from trying to cover every conceivable angle. Perhaps on top of these, literally, we need over-arching principles such as "If in doubt do not rename" and "Only rename if it will improve the project" S a g a C i t y (talk) 08:25, 9 August 2014 (UTC)[reply]
We used to have a rule about not renaming if the new name is just a little better than old one. It is a wise rule and we should stick to it.--Pere prlpz (talk) 10:51, 9 August 2014 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Requests_for_comment/File_renaming_criterion_2&oldid=142477165"