Commons talk:File naming

Minimal guidelines needed

I think guidelines on file naming can be minimal. Basically define useless file names to be avoided (eg IMG00001.jpg, Unknown xyz.jpg), but little else really needs to be said. File names are usually only in a single language, the important thing is having a decent description on the image page, which can be translated. The only time I find the filename useful, at all, is if there is no description and no categorization. One other convention that I usually follow is not naming files with scientific/Latin names because the binomial names tend to change with alarming regularity as species are moved between genuses (genii?) - Better to have a stable common name. --Tony Wills (talk) 12:09, 22 October 2009 (UTC)

I agree it should be as minimal as possible. Titles should not be too general could be removed, but the other points are good to keep. This text is based on this revision. Description of files of course need to be good, but that's not in the scope of this policy. Multichill (talk) 12:26, 22 October 2009 (UTC)

Sounds good to me. We should alter Commons:File renaming after this policy is agreed on.

(re: Multichill's comment)

The part about sleeping cats is probably not so important (despite the examples).

But what about versionless software screenshots (they may be used in context where the version is important, and then somebody comes and uploads a new version)? I'm afraid, though, that those who need it don't read the page anyway. Maybe it should be rewritten and moved to Commons:Screenshots.

--AVRS (talk) 13:28, 22 October 2009 (UTC)

Yes, I am sure there are cases where a specific file naming convention helps. I think that example falls into the general category where people upload new images over-top of existing images without checking the usage of the existing images first. I have come across wikipedia articles where an illustration has been completely irrelevant because someone over-wrote the original picture, but no one noticed as it didn't show up in the article watchlist. I agree that with that example Commons:Screenshots would be a good place to mention it. --Tony Wills (talk)

I agree that filenames are quite unimportant, unless the description is missing or very bad (and in the replacing scenario). The problem is that the description often is missing or very bad. Sometimes of course people do not have much useful information to begin with (such as probably the uploaders of "Street in Turku.jpg" or "Sailing boat under rainbow in Helsinki.jpg") but if they do, they are more likely to put it in a useful filename than to write a free form description. This should be changed of course, making good descriptions the norm, but we aren't there yet, and the "not too general" and the sleeping cat example may make some contributors think about what they really are contributing (and perhaps to write the description too). --LPfi (talk) 14:43, 5 November 2009 (UTC)

Overwriting or a new name?

The policy should solve in what cases it is suitable to overwrite the original image under the original name and in what cases the new filename should be chosen for the new version. I propose:

• little technical correction (rotation, margin cropping, brightness correction etc.) may be made under the original name
• an other image of the same object should be uploaded under a new name on principle
• every updating of a diagram or a map should be uploaded under a new name: in articles should by a redirect-name. Instead of overwriting an image, an overwrite of the redirect should be made. --ŠJů (talk) 03:35, 5 November 2009 (UTC)

I would like to include the "conversion" of jpg images uploaded with CMYK color-coding (and thereby invisible in IE browser) to RGB color-coding. As the original CMYK version isn't deleted, somebody who likes to use it, can simply click on the thumb in the image version history. --Túrelio (talk) 07:20, 5 November 2009 (UTC)

?? I don't mean format conversion. I meant cases that somebody has taken some photo, next year taken some next photo of the same place and overwrite the old photo by the new photo instead of uploading it under some new name. Treatment of conversion is only other special case. --ŠJů (talk) 07:28, 5 November 2009 (UTC)

Ah, ok, then I've misunderstood you. In a situation as described directly above, the image should be uploaded under a new name and thereafter eventually a rfd should be filed for the older one, if the newer one is better. --Túrelio (talk) 07:45, 5 November 2009 (UTC)

SJu probably had in mind the image discussion on VP. There it's not a question of better or worse, but rather of different dates of reference for the map showing the ratification status of the Treaty of Lisbon. If you go through the 13 WP/Wikinews articles where it's used, you will notice how much Commons made a mess of these.

uses of File:Treaty of Lisbon ratification.svg (2009-11-05)

• Treaty of Lisbon
• WP
  1. fr:Traité de Lisbonne
  2. ru:Лиссабонский договор
  3. zh:里斯本条约
  4. no:Lisboa-traktaten
  5. cs:Lisabonská smlouva
  6. da:Lissabontraktaten
  7. id:Perjanjian Lisboa (2007)
  8. sk:Lisabonská zmluva
• Wikinews
  1. Wikinews:en:Ireland votes 'Yes' to Lisbon Treaty
  2. Wikinews:de:Iren stimmten dem_Vertrag_von_Lissabon_mit_großer Mehrheit zu
  3. Wikinews:cs:Ústavní soud rozhodl - Lisabonská smlouva je v pořádku
  4. Wikinews:ta:லிஸ்பன் உடன்படிக்கைக்கு அயர்லாந்து வாக்காளர்கள் ஆதரவு
  5. Wikinews:tr:İrlanda Lizbon Anlaşması'nı onayladı

I added a short note in the FAQ (How can I upload a new version of a file?). In addition, this should also be stated here. -- User:Docu at 08:14, 5 November 2009 (UTC)

I added a line here too. -- User:Docu at 08:43, 5 November 2009 (UTC)

Thanks to Docu.

See also User talk:ŠJů#Reupload and File:Beckenham Road tramstop look east2.JPG, or File:Albertov deska.jpg and User talk:Chmee2#Přehrání cizího souboru vlastním (discussion in Czech) and many others. Many users don't understand the basic distinction between exchange of images in articles and overwrite of the image. In this case was the photo overwrited by the photo of diferent author even and the date of taken was kept original = mistaken. I remember cases that there has been an image of some building (city tower). In front of it was some cars, streetlamps etc. Somebody categorized this image by type of car, into streetlamp category etc. However later the uploader overwrite the photo and the new "version" (image from different view) contained no streetlamp detail and quite different cars.

We should accent very strongly that the file name apertains to one concrete work on principle and that filename mustn't be overwrited one by the other under the same name alike as apostles at Prague Clock take turns. As well as I don't give my name to my successor when I change my occupation or my job position. I think, Commons:File naming is the right place to clear accentuation that filename pertains to one file only and finally.--ŠJů (talk) 09:28, 5 November 2009 (UTC)

Maybe we should generally prevent people from re-uploading images.

IMHO, it's less problematic if the original uploader replaces the image with a slightly different one (File:Beckenham Road tramstop look east2.JPG) even if personally I might have preferred the earlier one.
File:Treaty of Lisbon ratification.svg is messy, but an admin should be able to split the file/revision history into different file names. This isn't possible, e.g. for File:Predator.jpg, as we don't really know anything about the second image (no description was added).
Even technical corrections can be a problem, compare File:T-45A Goshawk 03.jpg to other re-uploads of the same user. -- User:Docu at 10:02, 5 November 2009 (UTC), 10:09, 5 November 2009 (UTC)

I'm not too sure about the addition on redirects. It tends to make things more complicated. -- User:Docu at 10:53, 5 November 2009 (UTC).

To expand on this: for the treaty of Lisbon, with some lag, it should be possible to get an accurate, up-to-date version, but for others, e.g. File:Languages of Europe.png, this isn't possible and one might just end up with debates where the redirect should point. Even if we can settle for one version or the other, we don't always know which version Wikipedia and Wikinews in every language intended to use. -- User:Docu at 11:53, 5 November 2009 (UTC)

Other places that should be updated may be:

• MediaWiki:UploadForm.js (see wpPreviewOverwriteError )
• Commons:First_steps/Upload_form (see #4. Set an appropriate file name and #5. File Summary )
• MediaWiki:Fileexists (compare with MediaWiki:Fileexists-forbidden)

-- User:Docu at 11:53, 5 November 2009 (UTC)

I mentioned a redirect as one of possibilities which should be offered. Btw, this solution have the advantage that if somebody don't like this redirect, he can create and maintain the second one paralelly. For example, we can have one redirect-page which redirect the stand of ratified (subscribed) countries and the second one can have the deposition of the document as its criterium.

This solution (redirecting) is suitable for repeated real changes of stand in time only. However, corrections of clear errors or clear improvements of the map or diagram should be made by overwriting. --ŠJů (talk) 13:14, 5 November 2009 (UTC)

I think the redirect approach is good as presented here. One more point: the policy of updates should be clearly stated. It is good to have the present situation in a map used in the article on the present situation, but if e.g. the ratification and deposition status is the same when the article editor writes the caption, it is important that he knows which changes the map will follow. Do descriptions work on redirect pages? --LPfi (talk) 14:59, 5 November 2009 (UTC)

Follow-up: I made update requests for the UploadForm and Fileexists. -- User:Docu at 12:56, 8 November 2009 (UTC)

Examples

This page needs illustration examples of diverse types of good names and of bad names. Many users don't understand complicated sentences in English, examples are more intelligible. Every requierement should be coupled with examples. --ŠJů (talk) 15:24, 5 November 2009 (UTC)

Agree. mahanga (talk) 04:24, 15 December 2009 (UTC)

Agree. --LegitimateAndEvenCompelling (talk) 07:40, 3 April 2010 (UTC)

I added a table from Commons:Sprache. Matt (talk) 18:42, 27 July 2010 (UTC)

Actually, the most recent revision of the policy removed some of the naming conventions you added.  Docu  at 19:02, 27 July 2010 (UTC)

Two things

• "The extension should match the file type." - I've been saying this elsewhere, but all videos with the file extension .ogg need to be renamed with the .ogv extension. This is the official extension for Theora videos.

• What's the policy on putting technical details, such as resolution and image/video quality, in the name? For example, should we be doing names like this.. "pacific ocean video 1028x720.ogv"? mahanga (talk) 04:24, 15 December 2009 (UTC)

  "Titles of media files should be meaningful, helpful and correct". IMHO, specification of technical details can be "meaningful, helpful and correct". It depends on the uploader's opinion what name is chosen. Just as problem of jpg/JPG or ogg/ogv etc. Commons should accept and support all commonly used extensions, not only "official" one. --ŠJů (talk) 22:43, 16 December 2009 (UTC)

I have seen many images where their dimensions were titled as "image 1970x1080". This is very helpful in using the image, but perhaps this should be put in automatically, like the extention.--RayquazaDialgaWeird2210 (talk) 21:55, 25 December 2010 (UTC)

Policy on the Files' Extensions

Wouldn't be technically better if the file names are not dependent on the extension. The file type can then be detected from the file header instead of the conventional way. This way it will be more convenient when adding a file in a RTL wiki, to avoid bad behavior when LTR characters (currently, extensions accepted by wikimedia are only LTR) are inserted and the confusion resulted by the BiDi algorithms in the browser or other text editors. --Banzoo (talk) 08:46, 15 June 2010 (UTC)

I vaguely remember a bugzilla request about this. -- User:Docu at 09:07, 15 June 2010 (UTC)

Dates

This is not something that should be in a general policy concerning file naming. At best, it is simply advice or proposed guidelines for a limited number of files. Can't we establish a basic policy first that applies to all files? I think Multichill's original proposal was good how it was. Everything already had vast acceptance. Rocket000 (talk) 15:04, 1 September 2010 (UTC)

When we were discussing and agreeing on it, I was wondering where would be the best place to put it, but I can't really think of another page where it should go. Thus I rather leave it here.  Docu  at 04:45, 10 September 2010 (UTC)

Including author names and personal cataloging info

I have a user on my talk page [1] wanting to add "1120461 nevit" to the name of a file I renamed, because he "use(s) those two parameters to find and organize my files on commons". I thought this was a bit odd, and probably not allowed (once you upload, they aren't your files), but oddly when looking here, there's nothing written about this. Opinions? Past precedents? Suggested clarifications? Other relevant pages? Free beer? Ultra7 (talk) 16:28, 22 September 2010 (UTC)

I have no problem with short identifying tags at the end of filenames. -84user (talk) 18:48, 22 September 2010 (UTC)

What's the significance of "1120461"? I'm not sure we should be encouraging editors to add arcane bits of code to image names that only they understand. However, I think it can be appropriate in some cases to indicate the name of the author of a file in a filename, for example, to show that the image is part of a series of images created by one photographer. — Cheers, JackLee ^–talk– 20:10, 22 September 2010 (UTC)

Users are free to add their image number to the filename.  Docu  at 21:32, 22 September 2010 (UTC)

This isn't mentioned anywhere here. Ultra7 (talk) 22:03, 22 September 2010 (UTC)

If you look at File renaming, you will notice that removing that isn't a valid reason for renaming.  Docu  at 03:22, 23 September 2010 (UTC)

I don't think people are going to be looking at Commons:File renaming to find out whether adding personal i.d. info to new filenames is allowable or not. If it is acceptable, it needs to be mentioned here, at Commons:File naming. Ultra7 (talk) 13:48, 23 September 2010 (UTC)

It's not acceptable to rename other users' uploads without a valid reason. Please refrain from doing so in the future.  Docu  at 20:31, 22 September 2010 (UTC)

Is "Edinburgh" considered "generally valid" for the purposes of Commons:File renaming? Geograph alone currently has over 8,000 images of Edinburgh. Ultra7 (talk) 21:59, 22 September 2010 (UTC)

If you rename files, you need to check if your rename meets File renaming. If it doesn't, you are not following that policy. Unless a file name is misleading (e.g. an image of a bird named "tomato"), renaming is generally not needed.  Docu  at 03:22, 23 September 2010 (UTC)

Good, because I believe a filename of just "Edinburgh" is sufficiently misleading to justify a rename. Ultra7 (talk) 13:48, 23 September 2010 (UTC)

If it's about Glasgow, that's for sure.  Docu  at 16:39, 23 September 2010 (UTC)

Poll

This text appears to be stable since 1 September 2010 (diff). It pretty much sums up the current practices. The poll is about this version. You can either support or oppose the proposal. Neutral votes are considered comments. Multichill (talk) 09:54, 18 December 2010 (UTC)

Votes

Try {{Support}}, {{Oppose}} or {{Neutral}}:

1.  Support, Multichill (talk) 09:54, 18 December 2010 (UTC)
2.  Support --  Docu  at 10:02, 18 December 2010 (UTC)
3.  Support I'd say that it is currently as specific as it can be withouth overreaching in the field of file description. --Ianezz (talk) 10:16, 18 December 2010 (UTC)
4.  Support Kameraad Pjotr 11:08, 18 December 2010 (UTC)
5.  Oppose Too early, the text needs copyediting. The sentiment is fine, but the grammar is poor, the use of bracketing non standard. What is a graphemic character- how does the use of a digraph relate? The advice about period is wrong- you cannot have a File:Object.new.jpeg. Except for minor technical corrections, files should be uploaded under new names. is wrong, it should have said Except for minor technical corrections, where over-writing is acceptable, files should not use an existing file name..The proposal has not been published in French, even though there is a link suggesting it has, and in no other major languages --ClemRutter (talk) 11:47, 18 December 2010 (UTC)
6.  Oppose per previous: too early, the policy of choosing new names for altered versions is not well formulated, and maybe is too indiscriminate, the reasons for the policy choices and/or recommendations aren't clear. Rursus (talk) 16:20, 18 December 2010 (UTC)
7.  Support, for the reasons shown. Expecially to avoid meaningless (xxx.jpg, d123.jpg...) or too much general (downtown.jpg, panorama.jpg...) names. A minimal guideline, IHMO, is needed. --Локомотив 17:02, 18 December 2010 (UTC)
8.  Support --The High Fin Sperm Whale 17:52, 18 December 2010 (UTC)
9.  Support On balance, it is an improvement on the statis quo. I encourage ClemRutter and others to correct problems (but after the conclusion of the poll to avoid confusion). Walter Siegmund (talk) 17:53, 18 December 2010 (UTC)
10.  Oppose Premature, still has issues. - Jmabel ! talk 19:18, 18 December 2010 (UTC)
11.  Support —innotata 20:00, 18 December 2010 (UTC)
12.  Support if the grammar etc. is bad it should be easy to fix. --MGA73 (talk) 21:17, 18 December 2010 (UTC)
13.  Support idea but not sure if wording is best right now or if this is necessary as a policy; guideline or "use common sense" should be enough? ←fetchcomms 22:43, 18 December 2010 (UTC)
14.  Support Well done. Nothing has been cast in stone, and people can continue to work on it. --Skeezix1000 (talk) 23:25, 18 December 2010 (UTC)
15.  Support However, it can still go some way. For example, on the topic of versions, if, lets say, the file is updated yearly, then there should be some way that the file is uploaded under the same name and yet, both files remain. Not exactly like file history, but perhaps a separate section for versions. Then, the projects can reference to that file and optionally use a specific version if specified in the command. Saiarcot895 (talk) 01:42, 19 December 2010 (UTC)
16.  Oppose Needs more work, the proposed policy is too vague and more work is needed. Bidgee (talk) 01:49, 19 December 2010 (UTC)
17.  Support Needs a little copyediting, but the arguments made for naming are sound. Seems pretty straightforward to me. Steven Walling 01:53, 19 December 2010 (UTC)
18.  Support This is a good move, more work need to done to achieve the full detail..--...Captain......Tälk tö me 04:30, 19 December 2010 (UTC)
19.  Support I agree with all of it and I like the tip. I had no idea it was possible to upload a file where the extension doesn't match the file type!! For this reason alone the policy should be adopted up asap. Jane023 (talk) 08:55, 19 December 2010 (UTC)
20.  Support Like it - GippsRail 11:46, 19 December 2010 (UTC)
21.  Support Great for people new to Wikimedia to have a clear idea what the policy is. Yhoitink (talk) 10:48, 19 December 2010 (UTC)
22.  Oppose policy status, however I would  Support guideline. In this form it is just too vague to be policy and leaves many ambiguities, but guidance is both necessary and helpful.--Nilfanion (talk) 11:58, 19 December 2010 (UTC)
23.  Support There is a large backlog of files with incoherent names resulting from digital camera default names or filenames of public domain content downloaded from the web, hopefully putting this policy into place with mean the backlog of files that ideally should be renamed won't get any bigger. --Jatkins (talk) 13:27, 19 December 2010 (UTC)
24.  Support Sound approach, concur with Jatkins. Hekerui (talk) 16:21, 19 December 2010 (UTC)
25.  Oppose I oppose the point that requires the file extension to be the same as the file format. I believe that extensions are useless since the format can be extracted easily from the file header. Adopting the header approach would fix problems when filenames use different language scripts (e.g. File:بيروت_القرن_١٩_أسود_أبيض.jpg). --Banzoo (talk) 18:51, 19 December 2010 (UTC)
26.  Oppose Over-writing should be acceptable. Denis Barthel (talk) 19:28, 19 December 2010 (UTC)
27.  Support Seems common-sensical. upstateNYer 19:47, 19 December 2010 (UTC)
28.  Oppose "No funny characters" and "names in any language in any script" don't go together well. "Minor technical" allows a major swing in interpretation. Too vague for a policy. Apart from these ambiguities, only a simple statement "No DSC12345.JPG filenames" deserves a policy-level pronouncement. NVO (talk) 20:22, 19 December 2010 (UTC)
29.  Support The text may not be completely optimal, but it's clear about some basic and valuable rules. --VR-Land (talk) 20:33, 19 December 2010 (UTC)
30.  Support to get something in place that can be tweaked. This probably should be a guideline at this point until some of the bugs and wording are worked out. Good points by NVO especially about having more guidance about descriptive filenames (like the DSC issue). Royalbroil 20:38, 19 December 2010 (UTC)
    1.  Oppose as policy and  Support as guideline. I struck my previous vote. I changed my thoughts after thinking about the poor wording which needs to be addressed first before this becomes policy. Royalbroil 02:09, 31 December 2010 (UTC)
31.  Oppose The wording is too vague, no clear examples of what would be acceptable or unacceptable. Needs some more work. User:Aaaccc (talk), 19 December 2010 (UTC)
32.  Support plus a naming guideline should be implemented alongwith this. --Vssun (talk) 06:08, 20 December 2010 (UTC)
33.  Oppose, "meaningful and helpful" is too vague and subjective a criterion for my liking. This would make a good guideline, and I might be inclined to support it as a policy if we could somehow make those terms a bit more discrete. Lankiveil (talk) 08:59, 20 December 2010 (UTC).
34.  Support — In computer programming, a well-chosen, meaningful, differentiable name for each variable, constant and called subroutine or function is vastly preferable to an arbitrary, random, cryptic or merely sequential one. Clear labelling and, if possible, self-documentation of each file is similarly very important for the Creative Commons user who is searching for the just-right image to illustrate a Wikipedia article. — Objectivesea (talk) 09:14, 20 December 2010 (UTC)
35.  Support--Kiran Gopi (talk) 09:15, 20 December 2010 (UTC)
36.  Support --Extra 999 (Contact ^me + _contribs) 12:48, 20 December 2010 (UTC)
37.  Support --Wilfredor (talk) 13:20, 20 December 2010 (UTC)
38.  Oppose in the present form. Agree with some others above that the wording needs improvement. Good start, nevertheless. Regards, SBC-YPR (talk) 14:42, 20 December 2010 (UTC)
39.  Support We need a logical guide. Rastrojo _(D•ES) 15:20, 20 December 2010 (UTC)
40.  Support Might start its life as guideline till wording and examples are improved. --Foroa (talk) 16:15, 20 December 2010 (UTC)
41.  Neutral These guidelines are useful but the wording needs improvement per above comments. Even if the wording is revised, I have reservations about more requirements for uploaders. The barriers to entry for Commons for new users are already high enough. I am concerned that more requirements without an easy-to-use FAQ specifically designed for beginners, listed in the left-hand column, will cause some people to give up and not upload their images. Yes, I know there is guidance available. But I am a native speaker of English and frequent user of Commons, and I have trouble finding it. It has to be simplified and put in one easily accessible place. Downtowngal (talk) 17:34, 20 December 2010 (UTC)
42.  Support You have to start somewhere. Populair (by the camera) names as DSC0001.jpg are absolutely meaningless and should be forbidden. Eddylandzaat (talk) 18:06, 20 December 2010 (UTC)
43.  Support Ks0stm ^(T•C•G) 20:20, 20 December 2010 (UTC)
44.  Support --Number55★ (after 54, before 56) 20:36, 20 December 2010 (UTC)
45.  Support Makes sense. -- OlEnglish (talk) 20:46, 20 December 2010 (UTC)
46.  Support --Davidpar (disc.) 21:47, 20 December 2010 (UTC)
47.  Support Sounds good to me Julroy67 (talk) 22:27, 20 December 2010 (UTC)
48.  Support Sounds good to me too. --Whiteguru (talk) 23:05, 20 December 2010 (UTC)
49.  Support maybe bad style, but intension is understandable to non native english speakers (simple english), good enough by now, improve later --W!B: (talk) 01:57, 21 December 2010 (UTC)
50.  Oppose policy status. This is just too confusing and strange to promote to that. People are supposed to "avoid unneeded punctuation", while using emdashes and Hanzi? And spaces, so far as I know, are translated by the software anyway, so a policy isn't needed for them. How about saying what characters are supposed to be banned, and why? I mean, if you're planning to ban asterisks because someone might use them in a wildcard search someday, why not just arrange a way to specify a literal asterisk in those searches when the time comes? Now as for the uploading of different versions under different names, it is a good idea, yes, and it should be proselytized, but even so, often this happens rather unintentionally as people start "updating" files about a current event, and as new stories come out, more "updates" keep coming in a chronological order. We shouldn't delete or mandate changes to files like that, even if they're muddled. So it isn't really a policy you're looking for, and a different file that is more widely read might make a better bully pulpit for getting the idea across. Wnt (talk) 04:18, 21 December 2010 (UTC)
51.  Support - No issues with the proposal here. I think policies are a good thing. Nephron  T|C 04:28, 21 December 2010 (UTC)
52.  Support - Fitoschido (talk) 05:46, 21 December 2010 (UTC)
53.  Oppose as a policy, per Wnt above.  Support as a general guideline that files should but don't have to follow. Files can be renamed if the name is unclear, so there is no reason to have a policy disallowing files based on their name. Regards SoWhy 11:14, 21 December 2010 (UTC)
54.  Support--Etrusko25 (talk) 11:32, 21 December 2010 (UTC)
55.  Oppose as policy, has to be more clear and less controversal, possibly with samples (about сyrillic, сhinese, symbolic unicode characters). A good guideline though.--PereslavlFoto (talk) 15:38, 21 December 2010 (UTC)
56.  Oppose policy, guideline ok, but policy no, thanks, --birdy geimfyglið _(:> )=| 15:54, 21 December 2010 (UTC)
57.  Support --EugeneZelenko (talk) 16:08, 21 December 2010 (UTC)
58.  Support --Jarekt (talk) 16:14, 21 December 2010 (UTC)
59.  Support -- MartinD (talk) 08:20, 22 December 2010 (UTC)
60.  Oppose I don't think "names in any language in any script" are a good idea. --Prolineserver (talk) 09:21, 22 December 2010 (UTC)
61.  Oppose As birdy, I would support as a guideline, not as a policy. --Moros y Christianos 10:05, 22 December 2010 (UTC)
62.  Oppose Guideline yes, policy no. This is still too general and unclear. Joeyfjj (talk) 10:55, 22 December 2010 (UTC)
63.  Support As Foroa, with just one remark: KIS (keep it simple) Lotje ʘ‿ʘ (talk) 12:49, 22 December 2010 (UTC)
64.  Oppose Cmon, do you really need a policy for this? Smells like Wikipedia-esque instruction creep. Lewis Collard! (lol, internet) 15:26, 22 December 2010 (UTC)
65.  Oppose policy status, however I would  Support guideline. In this form it is just too vague to be policy and leaves many ambiguities, but guidance is both necessary and helpful. -- Justus Nussbaum (talk) 17:26, 22 December 2010 (UTC)
66.  Support, User:ElchNiki 18:12, 22 December 2010 (GMT +1)
67.  Support Lymantria (talk) 18:13, 22 December 2010 (UTC)
68.  Oppose The word "minor" in "Except for minor technical corrections, files should be uploaded under new names." should be deleted. There are far too many unnecessary variations of images in Commons. Any attempt to just improve technical quality of an image should simply overwrite the existing file. If it's questioned whether that is a plain improvement, the old image always can be restored and the new version uploaded under a different name. -- H005 18:19, 22 December 2010 (UTC)
69.  Oppose I agree with H005 and I believe that overwriting should be allowed for various cases. --Geraki ^T_L^G 20:47, 22 December 2010 (UTC)
70.  Support FASTILY ^(TALK) 00:45, 23 December 2010 (UTC)
71.  Oppose as per ambiguities --Booksworm (talk) 09:36, 23 December 2010 (UTC)
72. Full  Support for uploading in any language and/or script.--_`23prootie (talk) 10:20, 23 December 2010 (UTC)
73.  Support It sounds good. Brejnev (talk) 10:36, 23 December 2010 (UTC)
74.  Oppose as policy, weak support as guideline. It needs further clarification, especially regarding updates/extensions/corrections. --Avenue (talk) 10:40, 23 December 2010 (UTC)
75.  Oppose
    1. Over-writing should be allowed also when more clearer or higher resolution images of the subject are found. For eg. File:Ravi Varma-Descent of Ganga.jpg is of considerable lower resolution and quality, than the current one IMO.
    2. The current policy needs elaboration with examples. In the current form, it is too unrefined. ## How do you describe "funny" symbols? The ", etc" is too vague and open to interpretation. --Redtigerxyz (talk) 17:53, 23 December 2010 (UTC)
76.  Oppose - per the numerous discussions below, this is not stable enough to be policy yet. -mattbuck (Talk) 18:07, 23 December 2010 (UTC)
77.  Support --Phrontis (talk) 21:18, 23 December 2010 (UTC)
78.  Support - To get a baseline policy in place.Jarhed (talk) 23:32, 23 December 2010 (UTC)
79.  Support, Without naming conventions there is anarchy. Marcus Qwertyus (talk) 00:26, 24 December 2010 (UTC)
80.  Support- This is a reasonable policy, but may need some copyediting. --Shankarnikhil88 (talk) 01:18, 24 December 2010 (UTC)
81.  Support --Astrochicken (talk) 06:40, 24 December 2010 (UTC)
82.  Oppose Not yet. It needs more copyediting and clarifying. – Kwj2772 (msg) 10:03, 24 December 2010 (UTC)
83.  Oppose It looks like this needs to be merged with COM:OVERWRITE (or they should at least mention one another). In particular that page draws an even stricter line on not modifying historical source images. --99of9 (talk) 11:04, 24 December 2010 (UTC)
84.  Support I strongly agree with the "meaningful and helpful" part. I try to do my bit on Comons:Backlog, but too often I find that the filename doesn't give me any clue as to what the image depicts. As to whether the current text is perfect"': this is a guideline. MartinD (talk) 19:01, 24 December 2010 (UTC)
85.  Oppose Support any language/script. However, I only see English on this page and no links to alternative languages. I don't see this poll as representative of the Commons community as a whole (unless I'm missing something). As others have pointed out, there's a lot of ambiguous wording that needs tightening up before this becomes a policy. Simon Burchell (talk) 22:23, 25 December 2010 (UTC)
86.  Oppose in the present form. In my opinion this is a good start, but the wording needs quite a bit of improvement, and should be a lot more factual and precise. –Tommy Kronkvist (talk) 22:52, 24 December 2010 (UTC)
87.  Oppose So many valid reasons already mentioned. The extension should match the file type? Why? If there's a good reason, then why use "should", not "must"? And we certainly don't want deletionists to be able to point to this and delete stuff just cuz the extension is missing or wrong... Why do we need this policy? Are uploaders belligerently refusing to use appropriate names, arguing that there's no policy that requires it? IIRC, No.--W☯W ^t/c 03:58, 25 December 2010 (UTC)
88.  Support I also agree with this, totally great plan. Nima1024 (talk) 20:57, 25 December 2010 (UTC)
89.  Oppose "In any script", no, thanks --Kyknos (talk) 02:05, 26 December 2010 (UTC)
90.  Support. A policy is the principle, and having too much detail and specifics is an anathema. Further detail would be written into a guideline that supports the policy and addresses the principle. The principle is sensible and informative naming. The guidance would address things like renaming incorrect extensions, etc.  — billinghurst sDrewth 16:36, 26 December 2010 (UTC)
91.  Oppose As per Kyknos! Joyson Noel ^{Holla at me} 17:44, 26 December 2010 (UTC)
92.  Support, User:Shashank Reddy.P 17:49, 26 December 2010 (UTC)
93.  Support A simple, sensible policy. --Ranveig (talk) 17:54, 26 December 2010 (UTC)
94.  Oppose Because of not updating graphs (not all older graphs are important, a historical timeline of statistics shows older data, too) and because of not understanding what the graphemic characters means, and I don't wanna miss my brackets for authorship-naming. --Quedel (talk) 19:50, 26 December 2010 (UTC)
95.  Support. Some good ideas in this policy. Kertraon (talk) 01:38, 27 December 2010 (UTC)
96.  Support. Seems good to me. Ingolfson (talk) 01:50, 27 December 2010 (UTC)
97.  Oppose until the wording is formalized. Barrylb (talk) 05:04, 27 December 2010 (UTC)
98.  Oppose per Clem, above. There are quite a few issues with this proposed policy that make it un-policy-worthy and which have been brought up either in "oppose"s here or in comments below. Once these have been consciously addressed, we can try this again. --Philosopher ^{Let us reason together.} 06:16, 27 December 2010 (UTC)
99.  Oppose wohin soll das führen? --Ralf Roletschek (talk) 09:57, 27 December 2010 (UTC)
100.  Oppose, best to list all characters to never use, and list others to be avoided if possible. Give examples of good and bad filenames. Abductive (talk) 12:11, 27 December 2010 (UTC)
101.  Neutral. Seems fairly infantile at this point. Would be more sensible as a guideline than a policy.   — C M B J   03:11, 28 December 2010 (UTC)
102.  SupportWithout naming conventions there is anarchy.--Bagratun (talk) 04:16, 28 December 2010 (UTC)
103.  Oppose Premature. Document needs a lot of work, as others have pointed out. There should be some mention of avoiding automatic image numbers (e.g. DCSF1234), and more examples of clear and unclear titles. Are non Roman character sets ok? Are some languages preferred? Give people time to work on the document. Then make it a Guideline for a year or so and see what problems arise in its application. There is no need to rush this into a policy.--agr (talk) 04:35, 28 December 2010 (UTC)
104.  Oppose I think that a single character set, or language, should be the standard. Evrik (talk) 06:03, 28 December 2010 (UTC)
105.  Oppose There's no structure to this policy (may be a general guideline), and far too long. Preferable to have something simpler for file names so that people can understand faster. File names extensions should stay standard.--Themenon (talk) 09:02, 29 December 2010 (UTC)
106.  Oppose Over-writing should be acceptable. Wikimedia has too many poor quality images.Wmpearl (talk) 09:14, 29 December 2010 (UTC)
107.  Oppose I disagree with allowing "funny symbols" in the name of the files. I also believe that over-writing should be permitted. Banfield - Amenazas aquí 13:55, 29 December 2010 (UTC)
108.  Oppose per Clem et al. - MPF (talk) 14:38, 29 December 2010 (UTC)
109.  Oppose Although well-intentioned the attempt to make it simple has resulted in it being vague. Needs working on - some examples would assist. Saga City (talk) 18:09, 29 December 2010 (UTC)
110.  Oppose We don't need a law for everything. --TheK (talk) 01:48, 30 December 2010 (UTC)
111.  Oppose vague standard. --虞海 (talk) 07:18, 30 December 2010 (UTC)
112.  Oppose since this does not help with main problems of searching, indexing, classification and nomenclature in Commons. A file name just needs to be a pointer to the object and the data about that object Gordo (talk) 10:08, 30 December 2010 (UTC)
113.  Oppose Opposed as a policy and needs more work as a guideline. I believe it should be made easy for new users to add content not discourage them. Additionally being able to change the file name after the fact shouldn't be too difficult, possibly time consuming though.--Iamany (talk) 10:23, 30 December 2010 (UTC)
114.  Oppose. I think all names should be in English. Elmor (talk) 17:35, 30 December 2010 (UTC)
115.  Oppose Names should continue in english, search tools should be promted to search in different langauges of the descreption. Thabet (talk) 20:20, 30 December 2010 (UTC)
116.  Oppose I very much like the suggestions here. But why a policy rather than a guideline? I don't understand this. --Toby Bartels (talk) 23:36, 30 December 2010 (UTC)
117.  Oppose but I might consider supporting it as a guideline if reworded. --Angelo (talk) 12:01, 31 December 2010 (UTC)
118.  Oppose השמות צריכים להיכתב באנגלית. A different solution should be found to allow english file names to be written in other languages (alias). Yonidebest Ω Talk 13:45, 31 December 2010 (UTC)
119.  Support -- Karl Brodowsky (talk) 14:06, 31 December 2010 (UTC)
120.  Oppose As per Lankiveil Patrol110 (talk) 19:32, 31 December 2010 (UTC)

Comments

• Graphemic characters? Policies should be written in simple, precise language that everyone can understand. LobStoR (talk) 01:44, 19 December 2010 (UTC)
• To ClemRutter : « The proposal has not been published in French, even though there is a link suggesting it has, and in no other major languages » → I don’t know if you translate a lot of Commons pages, but I do. And I usually translate only stuff that is already adopted and not likely to change the next week as I do not really like wasting my time (that's why I have not translated Commons:Sexual content for example).
  Anyway, the proposal is now translated in French. Jean-Fred (talk) 02:42, 19 December 2010 (UTC)

Merci, mais malheureusement ma langue maternelle est anglais et mes allemande, hollandais at francais écrits ne sont pas assis forts. In this case the English was so abysmal that I needed the French to help me understand what the proposal was. Your translation is certainly better than the original! I object when commons policy discussions are regarded as playground games for anglophones--ClemRutter (talk) 11:09, 19 December 2010 (UTC)

• Re:Extension: IMHO, "The extension should match the file type." should be put in stronger words, such as "The extension has to match the file type.", if native english speakers agree. --Túrelio (talk) 09:37, 19 December 2010 (UTC)

Fine. Or "The extension must match the file type." The problem with this sentence is the word match- which means- the same as, and here we are talking about three letters being the same as an abstract concept. ie The address must match the house."The extension must indicate the file type." would be better English- though has lost strength.--ClemRutter (talk) 11:10, 19 December 2010 (UTC)

• I did’t understand the « Avoid "funny" symbols … » part ; can someone give me an example ? Is ☳ (eg in File:Trigramme2633 ☳.svg) “funny” ? Moreover, translate this propositions before the vote would be a good idea. Cdlt, VIGNERON * ^discut. 12:05, 20 December 2010 (UTC)
• I think that it is always a good idea for pictures relating to a certain location to have the name of the location in the file name. For example: When the location may be of importance, it is good to include it in the file name. --Foroa (talk) 16:12, 20 December 2010 (UTC)
• 2 corrections that I think should be implemented:
  • "Avoid "funny" symbols (control characters, unneeded punctuation, etc.)": reword to avoid ambiguity as "Avoid non language-related characters, such as control characters, graphical symbols, or unneeded punctuation"
  • "Graphemic" should be eliminated: I should not need to read a dictionary entry to understand a policy. Train2104 (talk) 03:59, 24 December 2010 (UTC)
• I agree with Foroa that if known and relevant to the file, the location should be added to the filename. I also feel that the original artist name should be included for copies of 2-dimensional art -- there are lots and lots of old paintings used on commons for article illustration that have an uploader name, but no artist name. Though many artist names are unkown even by large museum institutions, mentioning this as a commons policy may help reduce the backlog in re-attributing files. Same thing for photographs of 3-dimensional sculptures, etc. Though I agree with the avoidance of "unneeded punctuation", I think it is necessary to show WHY this causes problems with multi-language use of files - does anyone have a concrete example? Without a reason, people usually won't bother to conform. Jane023 (talk) 08:52, 24 December 2010 (UTC)
• why is someone advertising a poll which is already running a long time with a very colorful votelist (red and green). That's a waste of Commons user's time showing this site notice. How should this ever be a consensus then.. Close it with no consensus, rework and start again at some day. Cheers --Saibo (Δ) 17:20, 28 December 2010 (UTC)
  • Because we are polling users and actually want to know what they think? It's not necessarily a good idea to close this prematurely just because the initial users agreed or disagreed with the proposal. --  Docu  at 18:10, 28 December 2010 (UTC)

"If a diagram or map shows the status on a given date, it should not be overwritten with the status on another date."

Shouldn't this just apply to files with dates in them? Some files are regularly updated as time passes, it's more efficient than changing the links on 50 projects. -mattbuck (Talk) 10:36, 18 December 2010 (UTC)

That's the reason of the tip below the text you quoted (the one about using redirects). While uploading a new version is, well, straight, I believe one should consider that if an old version of a file is useful, one should be able to wikilink to it. This is possible with different filenames, but I doubt it's possible with older versions under the same filename. --Ianezz (talk) 11:11, 18 December 2010 (UTC)

I agree this should not apply to all files. I'm not sure that restricting it to "files with dates in them" fully addresses the underlying concern here, though. --Avenue (talk) 11:08, 18 December 2010 (UTC)

Maybe something like "If a diagram or map shows the status on a given date, consider whether or not it is appropriate to overwrite it with information from another date." -mattbuck (Talk) 11:43, 18 December 2010 (UTC)

The other way round. If the former file is useful, e.g. for showing the historical situation, it should not be overwritten. For some files, e.g. files updated very often, the old versions may be of little use, but mostly historic borders are interesting. --LPfi (talk) 19:15, 18 December 2010 (UTC)

However, I don't see this as a file naming issue. I don't think naming should be concerned with uploads/overwriting - just ensuring that stuff is named correctly. -mattbuck (Talk) 20:22, 18 December 2010 (UTC)

I believe it is a file naming issue after all, since file names identify content. If you look at it from another perspective, it's just a way of saying that reusing existing file names is not OK in some (I'd say most) cases. --Ianezz (talk) 21:02, 18 December 2010 (UTC)

If a diagram or map shows the status on a given date, it should not be overwritten with the status on another date. This cannot even be debated, until the the above sentence is edited to make sense. Status is just the wrong word. It could mean the copyright status of the file, the file permissions of the file- what it can never refer to is anything on the map- or anything represented by the map. You have several choices to express in English the meaning expressed in the French version of this guide-line.

If a diagram or map represents a date or time dependent situation, it should not be overwritten with one that represents a situation at a different time. would be one.

A diagrams or map specifically showing an event or situation at a given time, should not be overwritten with one representing another time. Is not as good but possible.--ClemRutter (talk) 11:34, 19 December 2010 (UTC)

Some things should always show the current state. Old states can be useful, but not always. -mattbuck (Talk) 14:17, 19 December 2010 (UTC)

"Except for minor technical corrections, files should be uploaded under new names. The file name applies to one concrete work: do not overwrite it even with a similar image of the same subject."

Looks like it will ban the up-to-date maps like this one: File:Eurozone.svg ?! --WikedKentaur (talk) 16:32, 19 December 2010 (UTC)

This map is very good example that a different situation requires a different map under different name. If the image of a particular situtation on certain date is used and described e. g. in WikiNews (see wikinews:cs:Ústavní soud rozhodl - Lisabonská smlouva je v pořádku), a subsequent change of the image causes chaos and nonsense. --ŠJů (talk) 17:23, 19 December 2010 (UTC)

---

Don't understand whether having one redirect image like File:Eurozone current.svg would work. At first redirected File:Eurozone current.svg to File:Eurozone.svg and then redirected it to File:Eurozone 2009.svg, but the page where File:Eurozone current.svg is used shows still the old image at File:Eurozone.svg ?? (even after Cnrtl-Shift-R) Why won't the redirect image update itself? --WikedKentaur (talk) 18:10, 20 December 2010 (UTC)

There is a problem that cache delay of this type of changes is about many days or even several weeks. --ŠJů (talk) 19:52, 20 December 2010 (UTC)

---

Yes this could be a mess. However I think that files with a name like "Eurozone" should be reserved for maps that is updated all the time so if Wikinews (or any one else) want to use a file showing the status on a specific date they should make a copy and name it "Eurozone 2008". --MGA73 (talk) 19:40, 19 December 2010 (UTC)

I hold the opinion that every different image should have a different name. Filename shouldn't be like a window of Prague Orloj where figures of apostles promenade about. If somebody wishes use a filename as a periodically periodically "slideshow", a better way is to change the link or to use a switch-redirect. There is no reason to remove or hide into history or move under a new name the situtation of Eurozone in 2007 or 2008. Articles and news can use them. The basic principle is that when you want change an image for a better or newer in the article, you must change the link, not rewrite the image. --ŠJů (talk) 22:15, 19 December 2010 (UTC)

I strongly agree with that opinion, having just looked at the nonsense caused by the changes to the Lisbon treaty map. Making individual projects upload local copies is not an answer: all that does is further encourage them not to use Commons (see Wikinews:Talk:Ireland votes 'Yes' to Lisbon Treaty#Upload image locally?). The exact opposite of what Commons should be for. -84user (talk) 01:24, 20 December 2010 (UTC)

Let me offer another example: File:NZ opinion polls 2009-2011 -parties.png. This snapshot of polling trends has been updated at random times, typically once several new polls have been released, but also sometimes adding previous polls that were inadvertently omitted from earlier versions. No previous versions have any real illustrative value IMO, and only the current version has any real use. I see no point in requiring a new filename for each successive version. --Avenue (talk) 00:24, 20 December 2010 (UTC)

Actually, this is a good example of why we should not upload updated versions over old ones. Commons purpose is to host media for all Wikimedia projects, don't forget Wikinews. Election coverage is important to mainstream media and these polls themselves are newsworthy. If Wikinews had an equivalent of this article it might have used a version of the polling graph you linked to. However, it would need a snapshot - if the image changed in 2 months, the archived news article would be damaged.--Nilfanion (talk) 00:53, 20 December 2010 (UTC)

If a version of this graph was used in a Wikinews article, I would agree with you. But it's not. I'm familiar with both uses of the graph in Wikimedia projects, and I'm not convinced that it makes more sense to create a separate file each time (with associated overhead from changing links or redirects) than to simply overwrite it. Creating separate files is certainly more work; where is the corresponding benefit? Nonexistent Wikinews articles are not a convincing reason IMO. --Avenue (talk) 13:28, 20 December 2010 (UTC)

If the diagram is not replacing but only extending the previous version (File:Graf poctu clanku.png#Original upload log), the overwriting is more acceptable, but also not desirable. But if the situation was changed, diagram of the new situation should not overwrite the previous situation. Polling trends in certain moment exert influence up the real behaviour at the same moment, even if a subsequent calculation will the curve retroactively utterly change. --ŠJů (talk) 01:19, 20 December 2010 (UTC)

Blacklist

I dislike the current blacklist, and would like to see it used in a more sophisticated fashion. The current blacklist prohibits any name starting with fore example DCF. This forces me to put the real names at the front of a file name, instead of at its end, as I would prefer it. Putting it at the start of the file name disrupts the sorting in time sequence in my folders, especially as windows vista (yes, i know) gives the file a new timestamp. Of course I recognize the necessity to avoid standard generated file names, but I'm sure there must be some way to check if there has been added something after the DCFnnnnn part. Teun Spaans 16:07, 18 December 2010 (UTC)

This particular problem is a problem also the other way round. Only the first part of the file name is shown in category listings and important parts are often hidden, even without nine meaningless characters in the front eating half of the available space. I hope there is some working solution also on Vista (can shortcuts in another directory be automatically generated from exif information or from original file name?). --LPfi (talk) 19:10, 18 December 2010 (UTC)

That's probably caused by the prefix blacklist. The main title blacklist actually has a very similar but more precise set of rules, so we could probably blank the prefix blacklist completely if we wanted. All we'd lose is the fancy AJAX warning on the upload form. (The reason for the redundancy is that the prefix blacklist is a core MediaWiki feature, while the more flexible title blacklist is implemented by an extension.) —Ilmari Karonen (talk) 10:32, 19 December 2010 (UTC)

The existence of the blacklist - and fact it disallows things like DCFnnnn should be included here. The blacklist takes its lead from this page not the reverse. This page should explain why DCFnnnn.jpg is an inappropriate filename, it should also explain why DCFnnnn <description>.jpg is discouraged (as it makes the names in category galleries useless), better to put most significant info first.--Nilfanion (talk) 12:18, 19 December 2010 (UTC)

I do not understand the problem of vista or not vista Teun Spaans has. You do not need to change the file names on your harddisk. You only need to change them in the upload window after selecting the file to be uploaded. Cheers --Saibo (Δ) 03:31, 3 January 2011 (UTC)

A few issues

1. "Except for minor technical corrections" is too vague.
2. Why are commas and ampersands a problem in filenames?
3. Should be clearer on whether it is appropriate to ask for renames for minor typos, etc.

- Jmabel ! talk 19:23, 18 December 2010 (UTC)

1. Maybe. And I would not call a better scan of the same image or the same image with better resolution a minor technical correction. But uploading those under the same name seems to be uncontroversial.
   • Most of the people who edit war over maps think they are making "minor technical corrections." People make radical crops and think they should keep the same filename. We need to clarify that when you do this to someone else's file, it requires a separate filename. - Jmabel ! talk 02:27, 19 December 2010 (UTC)

People working on cropping watermarks from images are usually expected to keep the same filename. --Jarekt (talk) 14:07, 20 December 2010 (UTC)

1. Ampersands are problematic on Unix systems and in URL:s. They can be handled properly, but I think the risk of mistakes is bigger than the advantage of having them available.
2. Commons:File renaming is a guideline. As it is highly dependant on the resources needed for renaming, and thus is going to change, I think it is best left independent of original file naming.

--LPfi (talk) 21:03, 18 December 2010 (UTC)

Just make it easy on me

Just make it easy on me. I upload files many times (20 to 30) while getting them just right. If I have to come up with new names I'll probably just put a rev number on the end. It would look something like "firetruck_031.jpg". That would leave 30 previous versions that are never looked at by anybody.

I don't want to have to create and update a redirect page. I don't even want to have to remember that there is redirect page. If that is the way we go, then please create the redirect page automatically when I create the file and automatically update it when I upload a revised version of a file.

Perhaps append a revision number to the file name that gets automatically incremented when the file is modified or over written. Something like "firetruck.jpg.031". Any link to firetruck.jpg without the revision number will get the latest version. I update "firetruck.jpg" without reference to the rev number. The update creates a new file with an incremented revision number. The old file remains unchanged.

On the file's description page on Wikimedia Commons add three buttons. All create a link and put it on the clipboard. The first button returns a link that always retrieves the most recent revision. The second button returns a link to the current rev and will always return that revision even when there are newer revisions. The third button opens a dialog that allows any particular revision to be selected. Constant314 (talk) 17:29, 22 December 2010 (UTC)

I'm not sure if the suggested policy affects the type of upload you are doing. Obviously, you can still do gradual improvements of your uploads. --  Docu  at 05:19, 23 December 2010 (UTC)

It might. If the image is significantly cropped, then it may indeed become unsuitable for some use (at least caption may have to be rewritten). If the image is used in a project the language of which the uploader does not understand, then checking such things is hard (and the use may be on a former revision of an article, which is going to be restored after the checking).

On the other hand, colour adjustments and such seldom have this effect and can be done on the old name. Copying one's favourite version to a new name, if one doesn't like the uploaders "improvements", is easily done. I do not really get why tens of versions are needed for a single image, but that may be because of my not having experience with some particular way of working.

--LPfi (talk) 10:03, 23 December 2010 (UTC)

I make illustrations of such things as schematics and EM fields to go with a technical articles. As the articles evolve I find the illustrations need to evolve. Of course it is unlikely that an illustration fine tuned for a specific article will be used in some other article, but it has happened.Constant314 (talk) 17:47, 23 December 2010 (UTC)

A few suggestions

One major problem I have been rooting out of the Commons is duplicates and duplicated 'updates'. This policy, if adopted, should state that while different versions of an image should be uploaded under different file names updates should be uploaded onto the accossiated image that it fits regarding the subject. For example: If there is an image of the members of the United Nations on the Commons and a person wishes to upload a map which shows this but includes dependencies of members and non-members which do not have their own membership it should be uploaded under a different file name, but if an individual wishes to upload an update which identifies that a member has chosen to leave the UN then it should be uploaded over that image. Also, if an individual has aquired and/or created an image of any kind which is of higher resolution or quality but is otherwise the same as a file on the Commons it should overright the file already here instead of being put under a different file name.

Another point I would like to bring up id that the policy should state that a file name must be short, direct and specific. We don't want images which are misleading in their title or sloppily uploaded such as the very first image I ever nominated for deletion which was an image that identified itself as a map of the Spanish Empire but was in fact a simple cartoon of a hamburger. Maps & Lucy (talk) 01:06, 23 December 2010 (UTC)

Re: your sample about "members of the United Nations". If someone already used the existing map and even commented on it, it would be highly problematic if you'd just replace it with another one. --  Docu  at 05:23, 23 December 2010 (UTC)

What do you mean by this? What I am getting at here is: lets say we have a map which is called 'Member States of the UN', States in the United Nations' or something likie that with a file description that goes something like: A map of the world which includes all the countries in the world which are members of the United Nations. That map is then put on the United Nations page and Members of the United Nations page on several wikis with that description under the image on those pages. If North Korea, lets say, feels that being a member is more of a burdon than a benifit and decides to leave the organization that this map should be updated instead of have it be uploaded under a different file name. The reason would be because then the image being seen on all those pages accross the Wikimemdia Foundation which says it shows all the member states of the UN would now identify that North Korea had left the organization. If this update was loaded onto the Commons by a different name instead of overwriting the previous image it would cause a lot of problems. (I hope this clears up any confusions). Maps & Lucy (talk) 23:11, 23 December 2010 (UTC)

in the cases of mis-named files; standard practice should be to rename correctly NOT just to delete. (i.e.: what happened to that hamburger file?) ::Lx 121 (talk) 08:00, 23 December 2010 (UTC)::Lx 121 (talk) 08:00, 23 December 2010 (UTC)

When you rename a file it is either reuploaded as the correct name with the old (incorrect name) file deleted or an admin will move the file and delete the redirect. That's the common practice as far as I can see. As to that hamburger image being labelled as a map of the Spanish Empire, the reason why it was deleted instead of just renamed and moved was because it was likely a tool for vandalism and had utterly no educational purposes. it may have even been a joke the uploader found funny to use as a practicle joke. Anyway, it remained on the Commons for 3 years before I had it deleted and I gained lots of support for the deletion, (my first deletion ever on Commons) it is now long gone! Maps & Lucy (talk) 23:11, 23 December 2010 (UTC)

to be clear, i understand the user's concern about exact duplicates; but we do have semi-decent tools now, that are reasonably effective in tracking this problem. hopefully, they will continue to be improved, & reduce the workload associated with it.

if we are going to "update" certain specific individual files on an ongoing basis (such as the example given, re: UN membership), as differentiated from continuously adding new files (presumably correctly named & dated; haha), then maybe we should create a reserved space for them? i.e.: a specific naming format, special (hidden?) category, tools, templates, etc. to go with it?

& keep it distinct from the "general" namespace, where the files are preserved following more standard archival practices (probably including dated versions of the "ongoing-updated" files). Lx 121 (talk) 08:30, 23 December 2010 (UTC)

I think this is handled in many cases. The UN is a good example where this should be done: every update should have standard file name with a date (or similar) and a redirect to the current version should be created. All version should share a (non-hidden) category and the naming practice should be explained.

The policy (or a guideline) is needed in similar cases, where the maps are in less watched articles and the users creating the original map and updating it might not understand these concerns.

--LPfi (talk) 10:44, 23 December 2010 (UTC)

Yes, I agree, for things like political maps, the date it was valid for should be part of the filename. --Tony Wills (talk) 23:26, 25 December 2010 (UTC)

"Avoid "funny" symbols (control characters, unneeded punctuation, etc.)"

The term "funny" symbols is too funny. For an English speaker, a Devanagari or Chinese alphabet may be "funny". The terms "funny" and "etc." are too vague and open to interpretation. A list of finite items needs to be complied. --Redtigerxyz (talk) 17:56, 23 December 2010 (UTC)

There are too many characters, both funny and non-funny, for a list. I think a recommendation is enough and the specification best left to some common sense. But not only characters possibly used in future wikisyntax are to be avoided. I think characters commonly not found on the keyboard or in the fonts on computers set up for the language used in the filename should be used only for good reason. I hope people will not start using emoticons, rising suns, arrows and the like when they become widely available. --LPfi (talk) 23:56, 23 December 2010 (UTC)

Perhaps the wording could specify that it accepts letters of the Latin, Greek or Cyrillic alphabets (including letters of those alphabets which are not used in all languages and letters bearing diacritics) and archaic Greek letters. I have no opinion on the use of Devanagari, Hebrew or Arabic letters in file names, but presumably this is more in the nature of guidance and one would not jump on the use of a Sanskrit inscription in a file name if it does not cause computers to go haywire. That done, we might be able to list accepted punctuation. Hogweard (talk) 12:59, 24 December 2010 (UTC)

Control characters are (mostly) already banned in file names (at the mediawiki level), so it doesn't really make sense to make a policy banning them. I think it is highly unlikely that a general punctuation character that is currently allowed in titles will later be used by wikimarkup and not be allowed it titles. Not to mention that it should be impossible to upload a file with the wrong extension. (If you manage to upload a file with the incorrect extension, thats a bug, and should be reported) Bawolff (talk) 07:47, 26 December 2010 (UTC)

We are all against "♫", "♂" etc. Is there a list somewhere of characters which do not work in file names or which might foul them up (like "/"), to which the eventual policy can make reference?

After that, it is a would be useful to know that one can name a photo file in another alphabet: "Αθηνα" or "חֶבְרוֹן" or whatever. "Avoid funny characters" does not mean to exclude e-acute but even that is "funny" to some people. It is a matter of interpretation of a proposal with which most of us agree if we can work out what it means! Hogweard (talk) 22:56, 28 December 2010 (UTC)

You might want to ask volunteers with the Romanian Wikipedia for their views. It seems that due to software limitations they are having problems with filenames with certain types of diacritics. I recently handled some renaming requests for diacritics to be removed for this reason. However, in general I am for the accurate use of diacritics in filenames. — Cheers, JackLee ^–talk– 08:16, 29 December 2010 (UTC)

I think one should be able to name files correctly in whatever language is relevant, be it Sanskrit or Romanian. We in Finland had our share of those problems when ASCII was used, and I want to spare the new generations in other countries. If the software cannot handle diacritics, then the bugs should be fixed, not the policies. But I think uploaders should be restrictive about using punctuation, and we are probably better off not using characters unrelated to the script of the language(s) used. --LPfi (talk) 18:51, 29 December 2010 (UTC)

Just pointing out that in biological illustrations "♂" can be useful too-- File Bearded Newt ♂.jpeg for example.--ClemRutter (talk) 10:40, 29 December 2010 (UTC)

We-e-ell, I don't know about that. Seems to me that "Bearded Newt (male).jpg" or "Male Bearded Newt.jpg" would do fine. — Cheers, JackLee ^–talk– 10:59, 29 December 2010 (UTC)

Did the Romanian problem come from the difference between ȚțȘș vs. / ŢţŞş? The former ("T-comma" and "S-comma") are considered more correct, but are missing from many fonts, so the latter ("T-cedilla" and "S-cedilla") are very commonly substituted. Or was it something else? - Jmabel ! talk 01:10, 30 December 2010 (UTC)

That sounds likely; I would be interested to know that too. This article has image files with names in Latin, Greek and Cyrillic (and a title with a macron). If that one works with every browser then we know at least three alphabets and their main diacritics are accepted as "not funny". Who would know the technicalities?

In the meantime, we have to find out what this Romanian problem was. Hogweard (talk) 13:41, 7 January 2011 (UTC)

Yes, if I recall correctly, it was something about the "T-comma" and "S-comma" characters causing problems. The nominator suggested replacing them either with "T-cedilla" and "S-cedilla" or omitting them altogether. He expressed a preference for the latter, so I obliged by replacing all the diacritics in the filename with ordinary letters. — Cheers, JackLee ^–talk– 18:27, 7 January 2011 (UTC)

"Except for minor technical corrections, files should be uploaded under new names. "

Over-writing should be allowed also when more clearer or higher resolution images of the subject are found. For eg. File:Ravi Varma-Descent of Ganga.jpg is of considerable lower resolution and quality, than the current one IMO. The current guideline does not handle this. --Redtigerxyz (talk) 17:58, 23 December 2010 (UTC)

For "faithful reproductions" of 2 dimensional works this is probably ok, for practically anything else it should be a new filename. Normally photos have more than just a resolution or clarity difference, there is usually different lighting, different colour balance, different angle and specific details of licensing can also be different. People often disagree on which is the "better version" of a subject. Even for the first case (2 dimensional works) there can be a lot of variation and for instance a higher resolution version may not be seen as an improvement in other respects (eg colours). In general I think we should simply upload all different versions, from different sources as seperate files. Only overwrite a file with a better version of the original photo (eg higher resolution, better crop, less compressed). --Tony Wills (talk) 23:20, 25 December 2010 (UTC)

Countless photographs appear on Commons which are tilted (2° on average); leaning buildings and lakes on slopes are giveaways. I have straightened several images, but I always upload the straightened one with a different name, not least because straightening an image requires one to cut the edges off, which is more than a "minor technical correction". My practice is consistent with the proposed policy. Perhaps there would be value in having a template tag to add to the original leaning picture with a link to the new one and which a bot could pick up? I am no technical expert there. Hogweard (talk) 16:48, 4 January 2011 (UTC)

There is a tool which does exactly that (if I understood you correctly): http://toolserver.org/~luxo/derivativeFX It adds to the original image Template:Derivative_versions and helps in contruction the new description for the reworked image. However possibly due to a bug the Template:Derivative_versions was not added for the last months but still in the log . I already asked Luxo to fix it but according to the top of the talk page he sadly is not active anymore/currently. I wrote an email now. Cheers --Saibo (Δ) 23:44, 4 January 2011 (UTC)

It's running again. --Saibo (Δ) 04:16, 8 January 2011 (UTC)

Including author names and personal cataloging info (cont)

As Ultra7 points out in the discussion above, once you upload files they are no longer "your" files. I believe this is an exceptional point and I think that it should be made a part of the file naming policy. There are some file creators that put their names in every single file they upload. In my opinion this detracts from the usability of the files, since it says nothing about the content and it implies ownership. If a user will only license his images so that his name must remain an integral part of the structure of the encyclopedia, I believe that this creates an unreasonable restriction on the use of the image. In my opinion, if a file creator insists on such a restriction, I would rather the file be excluded from the database. Please see a good example of what I am talking about here: WM image search for David Shankbone.--Jarhed (talk) 23:28, 23 December 2010 (UTC)

• Non-point; incorrect reasoning. Author's (not mere uploader's) rights are non-revocable and perpetual. My files are mine, yours are yours. No form of free license can strip the identity of the author (and/or the uploader) from the image. And no file name can invalidate the license declared by uploader. It's either free license or it's not. If anyone feels "unreasonable restriction" imposed by D.S., it's their problem - they can change the file name or they can shop at Getty's. NVO (talk) 18:56, 24 December 2010 (UTC)

I think that renaming should be acceptable for file names that include photographers names. This will make is easier to remove the photographers name form the file name. Snowmanradio (talk) 00:08, 25 December 2010 (UTC)

I agree with that and I also think that the policy should be that filenames should be descriptive of the content, which automatically means that file names should not contain the names of authors or uploaders.Jarhed (talk) 03:36, 25 December 2010 (UTC)

Why does commons need to "remove the photographers name"? It must be provided anyway, and it must be credited on each re-use. NVO (talk) 19:07, 25 December 2010 (UTC)

I agree that it is helpful to give detail, but I don't see why a name (initials in my case) should be removed from the image name. It's a simple way to differentiate photos by one contributor from another's, and if nothing else allows my photos a coherent naming system. -mattbuck (Talk) 19:36, 25 December 2010 (UTC)

May I remind Jarhed and Snowmanradio that one of the conditions of Creative Commons Attribution-Share Alike 3.0, the main license we use, is that "You must attribute the work in the manner specified by the author or licensor"? A different example of this is that we occasionally get images (usually artwork) that have the condition that the author must be attributed on the same page where the image is used. There is no reason we shouldn't host these. If someone doesn't want to conform to the conditions, don't use the image. It is not one of the avowed goals of Commons to oppose the intellectual property rights of authors. Quite the contrary: that's part of why we are so scrupulous about not hosting even potential copyright violations. - Jmabel ! talk 07:49, 25 December 2010 (UTC)

When I started working on Commons I too thought peoples names on files were not appropriate, and tried to rename them, but I slowly realised that there is no problem with those names. To the contrary a lot of people take a great deal of pride in their photography and genorously make it available to the world, not something that we should discourage :-). And one of the common reasons people put their name or initials in the filename is to generate unique filenames that aren't going to be accidentally overwritten by someone elses photo.

--- Tony Wills (talk) 23:48, 25 December 2010 (UTC)

Remove the details about overwriting?

Perhaps we should simply remove the details about overwriting since many users find this part problematic. We have Commons:Avoid overwriting existing files and that should tell when we can overwrite and when we can not. Instead we can add a "See also COM:OVERWRITE." or a "Except for minor technical corrections, files should normally be uploaded under new names. See COM:OVERWRITE for further detalils.". --MGA73 (talk) 17:21, 25 December 2010 (UTC)

Why filenames are not important :-)

I think it is good to have a guideline on filenaming, I think there are good reasons to have descriptive information about the image conveyed in the filename, but I think it is actually a very unimportant part of this project!

1. Filenames can be in any language, if all filenames were in Russian, but very descriptive, I would be no better off than if they were just numbers (perhaps even worse off as I can remember numbers, but have a hard time remembering or transcribing strings of characters in a different alphabet). I am just lucky that at the moment a large number of filenames are in English.
2. Long filenames in any language are not useful, information about the image must be in the description.
3. Our cataloging system is not determined by filename, finding files is not dependant upon their filename. All images need to have multilingual descriptions so that our search facilities can find them and so that our volunteers can sort and catagorize them.

I see descriptive filenames as only useful in the case where an image lacks a description. If the subject is not obvious and there is no description then the filename is the only clue. But a filename policy in that case is no more useful than a description policy both can be equally ignored by the uploader. If someone uploads a file with a meaningless name and no description, then complain about the lack of description, not the filename!

I also think that some people think that a filenaming guideline/policy is also directly related to when they should rename a file. But the renaming criteria Commons:File_renaming are well thought out and quite specific. I think one should read the renaming criteria as policy and this filenaming 'policy' as a guide to how to name a file when it actually **Needs** renaming.

In summary: It is nice to have files with descriptive names in one's own language, but totally irrelevant to this project :-) :-) --Tony Wills (talk) 00:20, 26 December 2010 (UTC) (having carefully zipped up his flameproof protection before mounting his soapbox)

Mostly agree. A file name is in the first place a key in the database, but it is indeed better to have a meaningful key than an random one. --Foroa (talk) 07:44, 26 December 2010 (UTC)

Well, as long Commons "acts as a common repository for the various projects of the Wikimedia Foundation" (at the very start of COM:SCOPE), and as long as the only pratical way to include a file in another WMF project is to use filename-based wikilinks, I'd say that file names are not completely irrilevant (in that considering them irrilevant causes inconvenience). Of course, giving a file a name which is meaningful in, let's say, Elbonian, won't help a bit non-elbonian-speaking people (which probably would find a checksum-based name equally meaningful), but it would be of some help to Elbonian speakers. If I'd have to choose between "equally meaningless for everybody" and "meaningless for most, but meaningful for some", I'd choose the second. --Ianezz (talk) 11:20, 29 December 2010 (UTC)

This poll is about a policy- not a guideline

At the top of the page we are told:

There is a poll open to adopt Commons- File naming as a Wikimedia Commons policy.

The word is policy. Experienced editors and admins are penning comments of support for this guideline, and they wouldn't make that mistake unless somewhere it had been referred to as a guideline. I put in a formal oppose to this as a policy, way back at #7. My reasons stand. I still say that the French translation, is better than the original.

Now we are approaching end of poll and will soon have one definitive result to several wobbly questions. Can we examine the process and what we do next.

The process

1. It is too easy to launch a poll
2. The text of the question should go through some form of scrutiny before it is launched
3. A small group of native speaker admins should check the text for correct grammar and unambiguous meaning
4. The text should be translated, it is another form of scrutiny. Questions should only be launched if they can be read at least 3 major languages

Way forward with these proposals

1. Analyse the text, and if there is a consensus, adopt the sentiment as a guideline only
2. Re cast the text into correct English, and French and provide a manual translation into 3 other languages and lock it.
3. Start discussing the additional safeguards needed so that it could be launched as policy
4. Reiterate that this is a Guideline on File naming- and File renaming is already well defined. That once a file has been uploaded the process is finished and File renaming rules apply.

The outstanding issues seem to be ways to describe the character set, and a bomb proof way of overwriting files that need to be overwritten while not overwriting files that represent different interpretations of an image.

The list above is not exclusive--ClemRutter (talk) 21:21, 26 December 2010 (UTC)

• Very good points - as it stands, it looks like only English speakers get to vote, hardly representative. Simon Burchell (talk) 22:04, 26 December 2010 (UTC)

Hardly representative, but that is how Commons works at the moment.

If translations are to be compulsory, I suggest English, Chinese and Arabic as compulsory languages. If we want to add Spanish, French, Russian and German, that is OK, but translation into Western languages only does not make a poll representative. We should also have a mechanism against further changes to the policy making the policy different in different languages.

This means a lot of work; probably policies should be very short and clear to make accurate translations possible and everything with more text should be guidelines.

--LPfi (talk) 10:32, 27 December 2010 (UTC)

ClemRutter's proposal doesn't seem consistent with current Commons language policy. --  Docu  at 18:15, 28 December 2010 (UTC)

Simplify or "how to save thousands of hours of wiki work"

I expect this suggestion will meet a bit of resistance, but something to consider. A very simple way to eliminate the need for a lot of administrative work, a lot of needless arguments, all filename conflicts and save on link-rot for external websites:

Get rid of descriptive file names.

Just give each upload a unique, unchangeable file identifier.

Reasoning:

1. This is a multilingual project, the filename can currently be in any language (and/or character set), there is no reason to expect to be able to understand the file contents from the name.
2. The filename is usually in only in one language. This is a multilingual project, the important thing is to have descriptions in multiple languages.
3. A descriptive filename is not necessary nor particularly useful for locating a file. Unless you are guessing at a URL (eg maybe there is a file called File:White elephant.jpg that will serve my purpose, no? then maybe I try File:White elephant 01.jpg ... ). Searching should put an emphasis on the file description or categories.
4. A lot of churn is involved in people naming and renaming files, this includes arguments of whether a filename is a POV problem or offensive, and people "squatting" on what they see as prime namespace for their favourite topic ;-). There are plenty of other activities that need doing (describing, translating, categorizing).

Further commentary

Currently a lot of files have so little description that the filename is the only clue to the file contents. But I don't think that should be an argument for keeping descriptive filenames, just an argument for better file descriptions. The names of existing files could be added as a field in the descriptions. Likewise new uploads could still prompt for a filename and add this minimalistic information as a description field.

I think the naming emphasis comes from various other 'pedias, where the name of articles etc is significant and you don't want to have links of the form [[Article1234]] instead of [[The price of fish in Mongolia]], but references to files are usually to include (transclude) their contents and the name is never seen.

I expect some people will want to string me up as a heretic, and it is unlikely to see any change as it seems counter-intuiative, but maybe this soapbox will make people reconsider why they spend so much time in this field :-) --Tony Wills (talk) 22:42, 27 February 2011 (UTC)

Copy'n'pasted filenames to an article to make a gallery. Now: add the descriptions. Sure - now we could change the simple copy'n'paste by using the always broken "use this file" script to directly output the filename and a description. Simplicity where did you go?

File:00d01b3c757c2491032a57f734fda6d5.jpg
File:4cc8c3857c302a9c037c0f5a5dc1578b.jpg
File:56d10cfb727c4c16545f1fa49e6209d4.jpg
File:c69efe1ae431ace233baf5e087b77f08.jpg
File:b0a14ce5a5c91fa8185258ecf24a435d.jpg  
File:d1210690ddbbaaa926c5abea3a2ea99b.jpg
File:cdbf8cd918f3547892a1ee5298a30727.jpg

Next scenario: You have downloaded all those files to rework them. Now you want to start with the elephant.... Fine - of course you could switch to thumbnails view on your pc. Simplicity?

File:00d01b3c757c2491032a57f734fda6d5.jpg
File:4cc8c3857c302a9c037c0f5a5dc1578b.jpg

Two files. One is the reworked version of the other: Which one is the reworked version? Which one the original?

Your idea and reasons sound good - but I see many drawbacks. Cheers --Saibo (Δ) 23:10, 27 February 2011 (UTC)

Just copying the filename to use as a description for a gallery isn't something I would do often, but the filename as a trigger to my memory of which photo it is, and what caption to give it, would be lost.

Second point: I would seldom download a whole bunch of files to rework. Normally when I rework a file I then save it with a new suffix

File:00d01b3c757c2491032a57f734fda6d5-edit.jpg

then re-upload it over the original, or to a new file, the name of the file on my computer doesn't really matter.

On my personal computer almost all my files from my camera are stored with their camera filenames, even with only tens of thousands of photos, giving them individual names is a bit beyond me. Of course I have a database with tags and descriptions etc that allows me to find any photo that I am looking for.

• "String"? Give Tony a cigar. Actually I like the proposal as long as it's about numbers and not Hebrew or Devangari characters (if that's the case, replace cigar with slow impalement). But only when it comes with a transparent database interface that will link the files on my computer (starting with RAWs stored on external drives) with the codenames on commons. If not, how would the users track numeric codes - with pencils and scratchpads? NVO (talk) 23:16, 27 February 2011 (UTC)

Yes the mnemonic characteristic of filenames is important, but then I have no way of remembering a filename written in arabic, hebrew, chinese etc character sets, I don't even know how to 'type' those characters with my keyboard even if I could remember them. So it this idea just makes an even playing field - all files are equally difficult to remember, I'm no longer biased towards using files with names in english :-). Of course the automatic filenames could have some structure, eg date plus serial number. --Tony Wills (talk) 00:43, 28 February 2011 (UTC)

I dislike this idea. (1) From an SEO optimization point of view, this seems like a bad idea. (2) If I am uploading the same file to multiple sites, I find it very helpful for myself to give it the same filename on the various sites where I upload it. (3) This would make (for example) a watchlist much harder to use. Right now, I can often tell from the name of a photo and the comment on a recent change that I don't need to go look at that change. This would be much harder without a mnemonic name. I would not recognize what the file was & have an easy way to guess whether I needed to look. - Jmabel ! talk 17:05, 28 February 2011 (UTC)

 Support Might save indeed thousands of hours of unnecessary work and problems with the delinker. --Foroa (talk) 18:35, 1 May 2011 (UTC)

 Oppose It might save admin time and reduce conflicts, but don't forget all the wikipedia effort is intended for humans to read and find. I fully agree with Jmabel. It won't work or will be impractical on watchlists, editing articles, article histories, searches/search engines and so on. Too many disadvantages. I would rather have well written file names, preferably in English and with multilingual descriptions. A bot which will rename the files (on demand, by admins) based on the first phrase of the English description (if well written), would solve many problems I think. Tools like What is that? and sum-it-up] already extracts descriptions. It won't be that hard to feed them to a rename bot. Complementary, would be nice to have a bot which compares current file name with the description (multilingual if you wish), and if the name is too short or too different, tag the image. Then the rename bot or the admin can review/rename. --Codrin.B (talk) 16:47, 19 December 2011 (UTC)

Does this really need to be policy/guideline?

Does this really need to be a policy or a guideline? It is really mostly a help page, with tips and guidance. Policy points are covered by the language policy, and by Commons:Avoid overwriting existing files (also a proposal, but with much more detail on that point). Rd232 (talk) 09:17, 28 March 2012 (UTC)

A merge with Commons:File renaming would also be a fairly obvious solution. Rd232 (talk) 09:53, 17 August 2012 (UTC)

Suggesting a suggestion for file names

Weekend idea for geography-related naming: Inspired by File:D-BW-Konstanz - Dominikanerinsel - Hotelgebäude.JPG, uploaders who want to give their files both a distinctive and most descriptive name could be given an advise on this page like this:

Geography-related file names may be standarized as "<country> — <entity 1> — <entity 2> — <entity 3> — <county> — <smalles entity> — <object> — <orientation> — <other information 1> — <other information 2>" (option for countries: use the ISO 3166-1 abbreviations). Example: File:D-BW-Konstanz - Dominikanerinsel - Hotelgebäude.JPG

Awaiting your comments, --Mattes (talk) 00:59, 29 December 2012 (UTC) P.S. This scheme may also be used in the description field (no help page for that?), example: Switzerland \ Canton Basel-Stadt \ Basel \ Grossbasel \ Petersgasse 26 following a multi-language description...

In the category pages you see only the 20 or so first letters of the file name. To use them efficiently requires handling each file individually. --LPfi (talk) 01:14, 30 December 2012 (UTC)

Criteria # 4

Greetings! Is the harmonization of the the file names of a set of images still the legitimate reason for the file to be renamed? Sincerely, --Kwasura (talk) 08:55, 22 January 2016 (UTC)

@Kwasura: Just a note: Could you please move your question to Commons talk:File renaming since this page doesn't list any criteria for renaming and that's the topic of the other page? This page is about file naming, but not file renaming. Kind regards --Bjarlin (talk) 10:50, 22 January 2016 (UTC)

@Bjarlin: Yes, sure. I just don't know whether I should delete it from here or not? Sincerely, --Kwasura (talk) 04:26, 23 January 2016 (UTC)

I think that's not so important. Just a link here to the discussion and people perhaps will find it also from this page. :-) Here it is:

Commons talk:File renaming#Criteria # 4. --Bjarlin (talk) 17:38, 23 January 2016 (UTC)

Thanks, mate! :) --Kwasura (talk) 18:24, 23 January 2016 (UTC)

File names, languages and character set - a proposition

Hello!

A question that may seem "heretical" crossed my mind. As per #Language, character set and extension, a filename is allowed in any language. I'm happy with that. But as a user of the internet and filemover, I'm not so happy with the part that allows any character set - langage and character set are two different animals (eg. Japanese could easily be written in romaji, and on Wiki, we do have several different romanizations for Korean and Chinese ideographs). I'd suggest a change that would encourage the usage of latin characters, as those are, I guess, the lowest common denominator of every human usable computer system of the world. On the other side, support for asian writing systems most often needs to be separately installed, likely reducing the usability of filenames made of such character sets. In short, I'm pleading for a "could move" rule allowing but not to change filenames in non-latin characters to romanized ones at the discretion of the filemover. Regards, Grand-Duc (talk) 02:06, 28 January 2016 (UTC)

Hi, With current technology and browser support of UTF8, I don't think we need to change non-Latin character titles. If the title is broken, it should be fixed, but preferably in the original langage and character set. Of course, an additional description in English is a must. In short, no. Regards, Yann (talk) 09:45, 28 January 2016 (UTC)

Technology and browsers do support UTF-8, but not the humans who are, in my eyes, the target of Commons' media. I guess that more than 4 billion people worldwide are educated to read latin characters, but less than 1 billion for chinese writing, and those should be the next largest group of readers. It's IMHO a question of usability and ease of maintenance of the repository, because every contributor is likely able to use latin letters, but a large group will be unable to read and understand non-latin writing, even when considering tools like Google translate.

On the other side, do you see a way to enforce the said prerequisite for a description in English (or maybe Spanish, French or German)? Going as far as a DR (for "not complying with standards") is too much, I guess... Regards, Grand-Duc (talk) 11:16, 28 January 2016 (UTC)

I think you forget the 1.2 billion who speaks some Indian langages (all in non Latin), the ~300 M who speak Arabic, not to mention Thai, Farsi, Hebrew, Urdu, etc. Yann (talk) 11:22, 28 January 2016 (UTC)

Photographer's name in file names

After an issue that was brought up on the English Wikipedia's Wikipedia:Administrators' noticeboard recently, a few discussion within that thread mentions commons policy in regards to this so I think its about time we decided to update our own policy in regards to this..another discussion was started at Wikipedia talk:Conflict of interest to consider defining what exactly is "self promotion" because apparently our "loose" policy at commons allows photographers to abuse our own set policies by claiming that there is no such policies in regards to this on commons..is that true? reading the Commons:File_naming#Naming you do realise that its not very clear and to avoid future incidence like this, maybe we should look at 'updating' our policies here cause a change here would apply to all wikis across wikimedia...I'm not saying we forcefully start renaming images because image from commons are not only used in smaller wikis but on multiple websites around the world so that would break a lot of links, what i'm saying is that we come up with a policy which prevents this from happening in the future..anyone agrees?--Stemoc 02:40, 14 September 2016 (UTC)

• Meh. If he's edit-warring, or promoting his own photos over other better photos, then that is a problem; there didn't seem to be consensus in the linked discussion that he was doing any such thing, just a couple of people accusing him of that. Providing a ton of good photos that are either better than what we previously had or filling in gaps where we had nothing is unambiguously good. I don't put my name in my own filenames, but I have no problem at all with it if someone else does. If an excellent photographer promotes himself by doing good work here while possibly keeping a higher profile than usual, what exactly is the problem with that? - Jmabel ! talk 04:47, 14 September 2016 (UTC)

  Lol, you probably need to investigate it a bit further then because he was most definitely edit warring to promote his own images which actually got another editor blocked while trying to prevent it..One of the Cons of allowing users to add their name to the byline of any image is that it can and will be abused, maybe we should come up with a solution which forbids them completely, they are already attributed within the image, and sometimes with given categories as well so having their name on the image byline is basically overkill and in the long run, a problem..if we stop one from happening, we can stop another problem from developing as well suck as edit warring to enforce your images onto articles by deliberately replacing a previous image with one carrying your byline..its actually a big issue on enwiki..in this certain case, the photographer is using wikipedia to intentionally promote his own business...so yeah this is pretty much something which i deem worse than paid editing and we need to strengthen our own policies here before we can try to make a change there..--Stemoc 05:49, 14 September 2016 (UTC)

  I would be against any change to forbid author identification in titles. It's a quick and simple way to monitor your own uploads - anything I take has "MMB" in it, so if I see one come up on my watchlist I know it's one of my own photos that's being modified. Given authors are not identified in the captions on Wikipedia, and filenames are not immediately visible, having such things in the filename confers no advantage or disadvantage to the photographer than if the file hadn't had their name in. -mattbuck (Talk) 06:29, 14 September 2016 (UTC)

  I don't put my name in the filenames, but I am certainly not against it, as mentioned above, having good quality photos of subjects not otherwise covered is more important than worrying about whether a filename (which most people will never see) contains the name of the photographer. Simon Burchell (talk) 08:16, 14 September 2016 (UTC)

  I've seen File:Ravangla, Sikkim by Masum Ibn Musa (467).jpg almost 500 files, what will say about it promotion or just to identify? Regards, ZI Jony ^(Talk) 15:42, 8 October 2019 (UTC)

• I agree to update commons policy on this. Regards, ZI Jony ^(Talk) 16:33, 10 October 2019 (UTC)

English Wikipedia

Recently added: "For detailed file and category naming conventions see the English Wikipedia's Category: Wikipedia naming conventions," (spelling correction "detailled" => "detailed" is mine).

Yes, the conventions there are more detailed, but to what extent are they pertinent? - Jmabel ! talk 22:57, 12 May 2020 (UTC)

Thank you for your comment, although I am in no position to answer the question.

What I came from was a feeling of annoyance when I was trying to find out whether it should be "xx of Ukraine" or "xx of the Ukraine" when naming a category ..

.. and a feeling of relief when I found the answer in the respective en:Wikipedia:Naming_conventions_(geographic_names) - after spending half an hour and not coming across even a mention of any kind of naming conventions on Commons.

Also I seem to remember being pointed to the English Wikipedia help pages at several instances when the Commons meta pages were incomplete.

best regards

KaiKemmann (talk) 23:31, 12 May 2020 (UTC)

That particular one is simple: since the present-day country of Ukraine objects to the use of the definite article before the name of their country, we shouldn't use it, unless in a direct quotation. - Jmabel ! talk 01:51, 13 May 2020 (UTC)

The Wikipedia naming conventions may be detailed, but they don't apply here, other than through the sound reasoning they might provide. The reference is very confusing, as it gives the impression that they are used as such also here. –LPfi (talk) 22:12, 22 May 2023 (UTC)

New draft

There was a discussion recently on the English Wikipedia about whether including the photographer's work in the filename was relevant, specifically with images such as File:Murten Bern Tor photographed by Robbie Conceptuel.png. It was pointed out that Commons's file naming policy is very terse and kind of a mess. I found a note in Commons:Requests for comment/File renaming criterion 2 that "re-naming a file to remove the author's name is inappropriate", but this is not in any of the policy pages. I took it upon myself to create a new draft, User:Mathnerd314159/File naming. I am not quite sure about how updating proposed policies works but does anyone have any comments? Mathnerd314159 (talk) 19:43, 16 March 2024 (UTC)

@Mathnerd314159: Hi, Change of policies happens on Commons:Village pump/Proposals. Yann (talk) 18:56, 18 March 2024 (UTC)

OK, so should I update this page with my draft, or just link my draft from the village pump page, or what? Mathnerd314159 (talk) 19:00, 18 March 2024 (UTC)

Forcing users to "more informative" titles

Hello, I just had a very negative user experience when I tried to upload 44 images of the same GLAM location. My preferred title for them was "2024-06-26 DRU Ulft ZvD 01" (with copy of the name to the rest of the files, with number telling automatically). But the system refused the upload - I had to use a "more informative" title. This was extremely annoying. I like to add the date in the title should it ever get lost in the meta data, DRU is the name of the GLAM, ZvD are my initials.

The browser nearly crashed when I several times tried to add a "more informative title" (including "Industriepark"), and finally it did seem to work. But now I see that most files were not uploaded properly. "Key "1b10lj8fb2tc.rmiaj.133575.jpg" not found in stash."

Does anyone else have such an experience with the upload wizard? Kind regards, Ziko van Dijk (talk) 19:01, 26 June 2024 (UTC)

The Upload Wizard is currently getting overhauled so I suggest you report this at Commons talk:WMF support for Commons/Upload Wizard Improvements. (I think it is good that the Upload Wizard asked for a more descriptive title but certainly it shouldn't cause browser performance issues or fail at uploading.) Prototyperspective (talk) 22:49, 26 June 2024 (UTC)

Good thing the system refused it. Where did you get the idea that this type of filename was a good idea? Enhancing999 (talk) 21:55, 5 August 2024 (UTC)

We lost the prohibition against "funny symbols"

Related to a remark elsewhere from Enhancing999: we lot the prohibition against "funny symbols". Could we possibly add something like:

• Avoid "funny" symbols (control characters, unneeded punctuation, etc.) that might be significant in future wiki markup. It is a good idea to stick to graphemic characters (any of the many well-known alphabets originating in Asia or Europe; any of the East Asian ideographic and syllabic systems; etc.), numbers, underscore (space), ASCII hyphen/minus/dash, plus, and period (dot).
  • It is generally best to stick to a single writing system within a filename (e.g. it can be very confusing to mix Latin and Cyrillic letters in a single filename, especially because they often use very similar glyphs).
  • Please do not use emojis, unless the emoji in question is the actual subject of the file (example of where this might be acceptable: the file shows how some font will render this emoji).
  • Avoid using strictly ancient characters such as Sumerian cuneiform or Egyptian hieroglyphs unless they very directly relate to the subject matter (example of where this might be acceptable: the filename transcribes a text visible in the image, written in that system).

- Jmabel ! talk 21:30, 5 August 2024 (UTC)

 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:46, 5 August 2024 (UTC)

Wouldn't we be better of we a three part thing: A short intro for those seeking help, a section with the 3 things to avoid, plus the current version for those seeking an academic ideal. Enhancing999 (talk) 21:50, 5 August 2024 (UTC)

I would argue nothing has been "lost", all of the original intent is there in the "Avoid abusing Unicode" bullet of the "Language-specific guidelines" section that Enhancing999 quoted. I don't remember at this point how I wrote that section but I think I changed away from the "funny" phrasing due to the section above complaining about that word, and similarly went through and added the other examples based on that. I'm not saying I'm the best writer, but I think the original phrasing is worse.

Part of why I made it language-specific is that if the name is e.g. Chinese, then English guidelines on punctuation and so on make little sense. It seemed more natural to me to provide relatively specific English guidelines and to let future Chinese contributors determine Chinese-specific guidelines, likely ending up with different conventions regarding what constitutes "funny" Unicode symbols for that language.

On the other hand, I would support adding the sub-bullet points such as sticking to a single writing system and so on as part of the language-specific guidelines - there wasn't much source material to work with from the other wikis, so that section is almost certainly much shorter than it should be. I certainly didn't do a systematic review of all the file-renaming discussions here. Mathnerd314159 (talk) 21:34, 24 September 2024 (UTC)

Not sure I agree with sticking to a single writing system. Besides cases like Japanese (where you might legitimate mix kanji, katakan, hiragana, and romaji), I could also imagine something like "Kremlin (Московский Кремль)" being part of a good file name. - Jmabel ! talk 08:13, 5 October 2024 (UTC)

Catalogue number prefixes versus suffixes

A recent discussion took place about file naming rules and the proper place for including a catalogue number. Most museums use the convention to append the catalogue number as a suffix to the media file name. In a recent Wiki Loves photo competion one of the participants complained about another participant having put ones images at the top of the Category list using a sequence number as a prefix (consider it as a "private" catalogue number). I would like to propose in the File naming standard a constraint for the upload script to refuse file names starting with a sequence of digits... Any feedback? --Geert Van Pamel 08:09, 2 October 2024 (UTC)

Unacceptable file names like Aaaaax

Recently, during a Wiki Loves campaign, several files were uploaded with illogical names like Aaaaaa, Aaaaab, etc. We suspect the uploader wanted the images to appear at the top of the Category. This should be refused as per the naming convention. We believe at least one space character should be contained in the file name to have a proper descriptive name. --Geert Van Pamel 11:55, 2 October 2024 (UTC)