Commons talk:File renaming/Archive/2014

criteria revision

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

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)

How to request renaming

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

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)

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

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)

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

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

---

There is an overall support by the 30 users commenting in this RfC to the new criteria. Compared to the total number of file movers and administrators of about 1000 together, it seems that not a big portion of the community commented here. However, other votes and ballots (administrator elections, recent votes at COM:VPP) have shown that participation in votes is generally low at Wikimedia Commons. This is perhaps address-worthy.

Announced to file movers and administrators for the duration of one week through Commons Notice that can be read in the Community portal and the Watchlist and open for more than 2 weeks, I believe there was enough time to comment and we reached most parties possibly interested in this proposal.

The concerns about uploader's requests being dishonoured have been addressed by a re-wording. The remaining point to discuss - whether file names should be improved from less specific names to very specific ones - will be clarified in a separate RfC. As the overhaul doesn't suggest any change to the current practise in this regard, I am going to deploy the new version in a while; several templates need to be amended and will require new translations. -- Rillke^(q?) 09:24, 24 July 2014 (UTC)

---

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.
2.	To change from a completely meaningless name to a name that describes what the image displays.	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.	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).	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.	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.	File:Map of Asia.svg.png File:Computer mouse.jpe	File:Map of Asia.png File:Computer mouse.jpg

Additional information

What is changed in this draft

• 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 the 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 was 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.

Comments

•  Support as proposer. Sven Manguard Wha? 19:16, 8 July 2014 (UTC)

 Support seems reasonable --Jarekt (talk) 19:37, 8 July 2014 (UTC)

 Support can't foresee any problems with this. Rodhullandemu (talk) 20:24, 8 July 2014 (UTC)

 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)

•  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)
  •  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)

 Support.    FDMS  4    22:03, 9 July 2014 (UTC)

 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)

 Support Jee 03:28, 9 July 2014 (UTC)

 Support - Jmabel ! talk 07:24, 9 July 2014 (UTC)

 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)

darkweasel94:

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)

•  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)
    • I'm not seeing where the case was made. All I see is you giving the example of someone wanting to make moves that no competent admin should accept anyway. I don't see any need to add wording that will obviously be confusing (how can it not be when there's no explanation at all about what constitutes "within reason") if you can't explain clearly what problem it's meant to be addressing. You even said yourself you're not aware of any case it's been abused, and the Orrling example given later doesn't appear to be relevant, as adding the clause "within reason" wouldn't have helped settle that dispute one bit, as far as I can tell. I see no other discussion except Darkweasel suggesting the criteria violates OWN, and Pere prlpz giving the counter case by explaining why it exists in the first place, without arguing the extra wording is needed, and indeed also asking the question, has there ever been any controversy over it, in its current form. Ultra7 (talk) 14:01, 12 July 2014 (UTC)
•  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)

•  Support Looks better than the old version, although I don't think there were too many renamed files IMO, as said above. Regards, Yann (talk) 20:37, 16 July 2014 (UTC)
•  Support One of the clearest and best-thought-out set of guidelines around. S a g a C i t y (talk) 07:00, 17 July 2014 (UTC)
•  Support Makes sense - -- Maxxl² - talk 08:15, 17 July 2014 (UTC)
•  Question@Sven Manguard: / Comment: Generally i think the proposal is OK and does not make a big difference to the current rules. But there is one point: I often see users uploading good images with personally "harmonized" names eg. like Objectname_Date_02.jpg, Objectname_Date_03.jpg etc. But sometimes it happens that one of the files, often the one uploaded at first, differs eg. like More_general_name_Camerastring.jpg (please note that in principal this is also a "valid" name). Then the users often request renaming to Objectname_Date_01.jpg after they have uploaded the full set. At the moment renaming is covered by old criterion 1 ("Uploader requested"). Is it correct, that this should not be possible with the new proposal (because of the added "Within reason" note)? – If yes, i don't really understand the reasoning for stricter handling, and i think it would be user-unfriendly to decline such rename requests. From my point of view especially new users who don't have much experience with Wikipedia/Commons are often driven away by certain "bureaucracy rules". And here, they often don't even know before that they can't change filenames by themself, and they maybe get disappointed or angry when they see that we do not follow such rename requests, of which they think they are only good and make sense. I think the addition to criterion 1 is unnecessary, and the proposal in this point has the potential to be counterproductive. Holger1959 (talk) 08:32, 17 July 2014 (UTC)
•  Support  Comment at User:Ultra7 and User:Holger1959. Didn't you receive not polite messages from uploaders when you declined stupid requests not conforming to criteria 2-7? I, often (see last message in my talk), especially when they are new users and often when they think to have full power of renaming. About Holger1959 question: it is correct but not regarding only uploaders. I think we must debate it for criterium 6 not 1--Pierpao.lo (listening) 09:49, 18 July 2014 (UTC)

no, i did not receive such messages, and my point clearly is about criterion 1, not about the "technical" criterion 6. Holger1959 (talk) 10:03, 18 July 2014 (UTC)

I've never had any such messages either, nobody's ever asked me to move a file at all actually :(. But if the purpose is to dissuade new users from requesting moves under #1 that violate the other criteria, then surely it makes sense to state that explicitly, rather than use a meaningless phrase like "within reason". Ultra7 (talk) 15:38, 18 July 2014 (UTC)

Ultra7: Okay, fine. I adapted your wording from above (edit) to tweak that bit of errata. Sven Manguard Wha? 16:32, 18 July 2014 (UTC)

•  Support Makes sense --Steinsplitter (talk) 16:38, 18 July 2014 (UTC)
•  Support Makes sense --Archaeodontosaurus (talk) 16:53, 18 July 2014 (UTC)
•  Support, looks ok to me. I don't get the use of leetspeak in note 5, though... "File:Biggest nose ever seen.jpg" might be a clearer example, considering that it's not the spelling that makes the file name inappropriate in the first place. Jafeluv (talk) 19:14, 18 July 2014 (UTC)
•  Oppose #1 criterium must be aligned with speedy deletion conditions. If a user can ask speedy deletion of a file s/he has uploaded, provided that it's done within the 7 days after the upload, the same criterium should apply here. It makes no sense that an uploader may not ask for the renaming of a just uploaded file but may ask for its deletion and upload it again with another name. -- Discasto 19:59, 18 July 2014 (UTC)

Therefore, it should read "Original author or uploader may request rename of recently created (<7 days) unused content. Author/uploader requests for rename of content that is older or in use should not be honored if the new name would go against one of the other rename criteria". It makes sense and complies with Commons:Criteria for speedy deletion (BTW, an official policy). Best regards -- Discasto 20:02, 18 July 2014 (UTC)

I don't understand your logic here at all. The uploader of a file can request that it be renamed at any time. They can request a rename 30 seconds after upload (and a lot of rename requests happen at about that time), or they can request a rename 30 months after upload, and it makes absolutely no difference to whether or not the rename request will be accepted. If they're requesting a rename because they misspelled something, it's always going to be accepted, whether the upload is younger than seven days or not. If they're requesting a rename because they're angry at someone and want to turn a file name into an insult, that's never going to be accepted, whether the upload is younger than seven days or not. Sven Manguard Wha? 20:30, 18 July 2014 (UTC)

To request a rename because they misspelled something, no one needs criterion #1. Criterion #3 covers this, both for one's own and for someone else's files. I'm also not really convinced that we should allow uploaders to switch their files from "FooTown 3.jpg" to "Protestant church in northern FooTown, eastern side, view from no. 4 BarStreet, on 24 May 2012.jpg" and back (or perhaps between different languages) every few weeks if they so desire. But it's just a comment, at least the new proposed guideline limits such renames to the uploader's request and doesn't allow every filemover that comes across the file to change the filename to something that's "specific enough" for that filemover's liking. darkweasel94 20:47, 18 July 2014 (UTC)

Darkweasel94: If someone requests that a single image be renamed multiple times, I'd be willing to tell them "please pick a name and stick with it, multiple renames makes it hard on [external] reusers", and see where it goes from there. If lots of people start doing it to lots of files, for some odd reason, it might be worthwhile to add a restriction into the errata, but I've never heard of this being a problem before, so I didn't include it. I personally don't see a great need for criteria 1, but I figured it wasn't doing any harm, and removing it might derail the rest of the improvements, so I left it in. Sven Manguard Wha? 20:59, 18 July 2014 (UTC)

•  Oppose note for criterion one (see below – 22:45, 18 July 2014 (UTC));  Support everything else – I broadly support the changes being proposed, as they make sense to me. My only minor concern is with criterion one – "an uploader's request should not be honored if the new name would go against one of the other rename criteria." That could be interpreted as meaning that a request should only be granted if it meets one of the other criteria, which rather defeats the purpose of having criterion one. I believe uploader's should be allowed to re-name their own files for their own reasons, even if it doesn't strictly meet one of the other criteria, though I also do understand the concept of stopping uploader's from re-naming their files very often or for highly trivial reasons. However, this doesn't seem to be a serious problem. So I can't see the current note achieving anything other than causing confusion. CT Cooper · talk 21:13, 18 July 2014 (UTC)
  • CT Cooper: I've changed the wording (edit). What do you think now? Sven Manguard Wha? 22:25, 18 July 2014 (UTC)
    • I think that's much clearer and I will give my support to that wording. Though I would be interested in seeing what others think about it. CT Cooper · talk 22:45, 18 July 2014 (UTC)
      • This still looks like a note in search of a problem to me. I just can't see any benefit to it at all - obviously no competent admin should be accepting move requests they think are "disruptive or inappropriate" - but that goes without saying, and of course it applies to everyone, not just original uploaders. Ultra7 (talk) 14:19, 19 July 2014 (UTC)
• Oppose Criterion 2 as too restrictive: We really, really don't need bad filenames here, whether they're merely unhelpful or complete nonsense. The note saying that very nearly meaningless is fine ruins the criteria. Adam Cuerden (talk) 22:54, 18 July 2014 (UTC)
  • Criterion 2 didn't actually get changed. The errata is new, but it's only putting down on the page what is already the existing interpretation of that rule. There's a huge grey area between criterion 1 in "What files should not be renamed" and criterion 2 in the current (i.e. not this) version of "Which files should be renamed?", and every time I've seen names in that grey area come up, it's always been "completely meaningless means completely meaningless". Sven Manguard Wha? 23:12, 18 July 2014 (UTC)
    • Many filemovers actually do interpret that criterion the way Adam Cuerden seems to support. Which is a bad thing. It's the best thing to ever happen to this guideline that in the future, files like those in the categories Category:Files of Paris with bad file names, Category:Files of Versailles with bad file names and Category:Files of London with bad file names won't be eligible for renaming (and these categories should then be deleted as misleading), because anything else is a slippery slope potentially leading to filemovers gradually improving the filename to put more and more description into it (like, one filemover says "DSC 1234.jpg" is too unspecific and moves it to "Vienna DSC 1234.jpg", which is right, but then someone else comes along and moves it to "Tram in Vienna DSC 1234.jpg", then someone else to "Tram on line 5 in Vienna DSC 1234.jpg", etc.; there's no logical point to stop unless we define one, which is that "Vienna DSC 1234.jpg" shouldn't be renamed further). darkweasel94 09:19, 19 July 2014 (UTC)
      • In my opinion, we should be as specific as it is necessary to correctly and unambiguously identify the subject of the image. If it takes the name 'Tram on line 5 in Vienna' to do so, it is an appropriate title, given that there are many files of trams in Vienna and the location is important in regard to trams. In most cases, it is possible to standardise such file names. However, there is probably no need to be overspecific and title the file 'Tram on line 5 in Vienna (with square windows)' (assuming that all trams in Vienna have square windows, it doesn't help in identification, it is therefore superfluous). --Eleassar ^(t/p) 08:14, 21 July 2014 (UTC)
        • You can't seriously tell me that Category:Files_of_Paris_with_bad_file_names is not fuill of filenames with so little meaning as to be useless. And if the filenames are useless, how is that any better than them being meaningless? Adam Cuerden (talk) 00:12, 22 July 2014 (UTC)
•  Support This is a well-constructed and helpful proposal. I thank those who brought it to this point --Walter Siegmund (talk) 03:38, 19 July 2014 (UTC)
•  Support Just a thought concerning sets of images, which seems to be a bit unclear. What do you think of something similar to an intended set of images? That would clarify that it's normally the uploader of at least part of the images who declares that those images form a set and not just somebody who decides that some images could/should form a set. --Anna reg (talk) 10:46, 20 July 2014 (UTC)
•  Support Like Pere prlpz – the old version is not bad, the the new is a little better. --Packa (talk) 13:25, 20 July 2014 (UTC)
•  Support, except for my restraint above in regard to Criterion No. 2. --Eleassar ^(t/p) 08:14, 21 July 2014 (UTC)
•  Support all except the defintion for Criterion 2 - it isn't just "random strings of letters and numbers" that is a problem. @Sven Manguard: We have many Flickr-origin files where the Commons-uploader has simply copied the Flickr-filename, however these are sometimes very vague. An example is Category:Images taken by Law Keven which has gems like File:Flickr - law keven - A Moments peace....jpg (a tiger having a nap), File:Flickr - law keven - A Stretch in time....jpg (a duck opening its wings) and File:Flickr - law keven - All the better to taste you with.....jpg (a wolf yawning). The definition of Criterion 2 should be expanded from "random string" to include this kind of bad name. Green Giant (talk) 18:09, 21 July 2014 (UTC)
  • Green Giant Those are pretty bad, but again, the note that I added for criteria 2 is not new, it is simply stating the existing expectations. After this RfC closes, I will open another RfC that focuses specifically on what is and is not movable under criterion 2, as it seems that there are divergent opinions on that, and it is something worth putting to the community. I don't want to make it part of this RfC, however, both because it will probably close tomorrow and because my philosophy on RfCs is that they should be narrowly focused, in order to avoid disintegrating into chaos. Sven Manguard Wha? 19:17, 21 July 2014 (UTC)

Thanks you for the reply. I will therefore support this change fully and look forward to a new RfC. Green Giant (talk) 23:41, 21 July 2014 (UTC)

•  Note Shortly after this is closed (or immediately after, if I get it finished before this is closed), I will be opening up another RfC specifically on criterion 2. It's going to be on the long and complicated side, so please be patient. Sven Manguard Wha? 00:48, 22 July 2014 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Rule 1 is very controversial

It can't be that the meaning of the uploader is higher than the other rules. This leads clear to ever paradoxical maintenance, like this:[1][2][3] So please update the rules. (Here concrete to COA is an international naming systematic LANG-CODE ... COA, also alone the "Wappen der Stadt " / "Wappen des Kreises" is very uncommon) → User: Perhelion (Commons: = crap?) 12:52, 30 August 2014 (UTC)

Ask the executing user to please apply common sense before running any file renaming action in future. If a request by an upload clashes with one of the other points (meaning that after renaming it as the uploader requested, another renaming would be required), such a request should be declined. Anyway, I am going to close above mentioned RfC now; please re-check whether it got better. -- Rillke^(q?) 15:09, 11 December 2014 (UTC)

RfC on the scope of file renaming criterion 2

Pursuant to the closing of the RFC "Proposed overhaul of the "Which files should be renamed?" section", a second RfC has been opened at Commons:Requests for comment/File renaming criterion 2 specifically to address the scope of criterion 2, which currently reads "To change from a completely meaningless name to a name that describes what the image displays."

Please note that I fully anticipate that the first few days will see a number of additional options proposed, so it may be a good idea to check back periodically on the RfC.

Thank you. Sven Manguard Wha? 18:18, 24 July 2014 (UTC)

Everybody: Please review whether I missed something while closing Commons:Requests for comment/File renaming criterion 2 and bring it up at its talk page. Thanks in advance. -- Rillke^(q?) 17:15, 12 December 2014 (UTC)

File renaming rights criteria and failure

Hello guys, I need a 2 question abount File renaming rights:

1. By what criteria is given the File renaming right: maybe, >500 edits, good requests to renaming, good status in Commons or file renaming/non-redirect renaming rights in local (native) Wikipedia??
2. What if file renaming user make a mistake in choosing the right of action; ie, do rename, when he cann't rename OR don't rename, when it was possible (for example, to request by WikiProject where this files is (only) used). ← Alex Great ^talk_rus? 13:39, 11 December 2014 (UTC)

Let me quote from Commons:Requests for rights#Filemover: As a rough guideline, administrators usually require editors to have made between 1,000 and 1,500 useful non-botlike edits or a large amount of justified renaming requests at the Commons before they will consider granting the filemover right.

If you rename despite you aren't allowed, the right would be probably removed. If you reject valid requests the requesting users will complain on your talk page and perhaps elsewhere. In the worst case you would engage in an edit war and could be blocked for that. That said, simply leave alone requests you are not sure how to deal with. -- Rillke^(q?) 15:05, 11 December 2014 (UTC)

 Thank you. for sufficiently detailed response. I learned everything that I need. ← Alex Great ^talk_rus? 13:09, 12 December 2014 (UTC)

Mass file renaming

There is a way to request required for renaming a large number of files on the same criteria (for example, files in one category)? ← Alex Great ^talk_rus? 13:14, 12 December 2014 (UTC)

You may use the powerful VisualFileChange (action "prepend any text") to insert the {{Rename}} template. I warmly suggest you make a single test edit with that script first and then confirm it is what you wanted to do. If you were a file mover, you could use User:Legoktm/massrename directly. -- Rillke^(q?) 13:24, 12 December 2014 (UTC)

Wow, thanks. Very usefull tool. ← Alex Great ^talk_rus? 16:54, 12 December 2014 (UTC)

Just make sure that ALL files meet the criteria to rename. And just because you can find a reason to rename does not mean that you have to rename. Personally I think that adding a good description and a good category is more important than spending time to change the name. --MGA73 (talk) 17:23, 19 December 2014 (UTC)

What's the next step?

If a {{Rename}} tag is declined by a filemover and the decliner refuses to respond to a talk-page question about how to handle the situation, what's the next step? I don't see anything on COM:MOVE about a noticeboard or other discussion forum, just the tag/move process itself. DMacks (talk) 21:52, 13 December 2014 (UTC)

I guess you write because of File:Е217.jpeg.

I think the rename was declined because the description of the file says that it IS an image of Е217. The description is more important than the filename so in the future please change the description.

If rename is refused you can 1) fix the description and just let the name be, 2) add a {{Disputed chem}} and if there is concensus that the filename is wrong then it should be easy to get a rename done or 3) nominate file for deletion as you did if file is not usable. --MGA73 (talk) 17:45, 19 December 2014 (UTC)