This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2024/08.
One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
This is a months-long discussion that has taken a long time to settle.
Based on raw numbers, there has been 12 support votes and 11 oppose votes. However, the effective number is 12 support votes and 7 oppose votes, since two oppose votes are based on the idea that all file names would be English, which was amended. 2 oppose votes did not provide a reason they opposed the proposal, and just rehashed "this is a bad idea". Furthermore, some of the arguments on the oppose side have been explicitly refuted.
The idea this guideline won't solve anything is patently false, by making a more accessible guideline we will reduce the number of disputes in the first place
The idea that there are no "good or bad file names" is also wrong, the file name shows in categories, on search results, and externally on search engines.
The prescriptivity of this guideline has come under debate, with opinions ranging from it should exist as a simple information page to the full force of policy with no exceptions. Of course, we should stay in the middle, where uploaders are not required to follow the file naming guideline religiously, but should take away the key points and avoid uncontroversially bad file names. Ideally, a warning template should also be created to help users find the guideline.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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' file naming guideline is very terse, kind of a mess, and is actually a failed proposal - the closest accepted guideline is the Commons:File renaming policy. The "blatant advertising" renaming criterion was mentioned but 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". I think that discussion has been resolved but it did bring to my attention that there is a gap in guidance - Commons has a detailed official guideline on renaming files, but no official guideline on what to name them initially.
Therefore, I took it upon myself to create a new draft, User:Mathnerd314159/File naming. I incorporated existing policies, guidelines, and advice from a variety of sources on Commons while trying not to create any novel policy. I was thinking that I would revise the draft to accommodate any comments and then once the draft is in a good state I would overwrite the main Commons:File naming page and there would be a vote on whether to adopt it. Mathnerd314159 (talk) 17:52, 22 March 2024 (UTC)[reply]
Comment — An important Commons constituency are third-party users. In the "Ideal" section I'd like to see a mention of the importance of choosing a name that is suitable for use/linking by third-party users. —RP88 (talk) 18:24, 23 March 2024 (UTC)[reply]
I looked a bit but couldn't find many considerations in naming that were specific to third-party users. There is the general policy of stable filenames, which is partially to ease third-party use/linking, but that does not affect new uploads, so it is only mentioned in the introduction. There is searching for relevant files, but all Commons users appreciate better filenames in this task, so specifically identifying third-party users would be strange. Is there a specific file naming criterion that you had in mind that is important for third-party users but not relevant to first-party users? Mathnerd314159 (talk) 21:13, 26 March 2024 (UTC)[reply]
Sorry, I wasn't as clear as I should have been. I'd like to see a mention of the use/linking by third-party users as an example/justification for the first point (the one that contains "...good idea to stick to graphemic characters, numbers, underscore..."). If I recall my Commons history correctly, linking by third parties was part of the original justification for suggestions of this sort when recommending preferred (as opposed to mandatory) name criteria. —RP88 (talk) 22:16, 26 March 2024 (UTC)[reply]
The line in my guideline is from the original 2009 File naming guideline, there was a discussion on the talk. I see no mention of third-parties, it seems like the justification was that some files were being uploaded with control characters. I think most OS's/CMS's fully support UTF-8 filenames these days so generally any valid Commons name will be usable by a third party. When I kept the advice, I was thinking of stuff like w:Zalgo text. Mathnerd314159 (talk) 04:29, 27 March 2024 (UTC)[reply]
Oppose there are several problems with that approach:
the guidance that "filenames should be in English" violates our core Commons:Language policy.
Also, given that your initiative seems to have come from wanting to curbe the inclusion of the name of photographers as advertising or self-promotion, there should be some guidance that including the name of the photographer or archive is acceptable.
Also it's unclear if there is actually any added value in another page on the topic (Will we end up renaming because of the "file renaming policy" or because of the "file naming policy"?).
Further, I don't think the following is helpful and might make uploads of archives utterly complicated:
"The following styles of names are not allowed: Names consisting primarily of a broad location, such as a city, province, or country." Uploaders might struggle to be more precise than including the a city or province, but other contributors can easily complete descriptions and categories.
On some of these, I think we need to distinguish between what is allowed and what is encouraged. Certainly that is the case for discouraging "broad location, such as a city, province, or country" and such files should probably be subject to renaming. I recently ran across a case where someone took 50 files of a single cemetery and gave titles that were each just the city name plus a number.
Even so, e.g. we have thousands of files from Ray Swi-hymn uploaded from Flickr with somewhat general, but useful filenames. Eventually some files end up fairly well described and categorized, but this is way beyond what can be done or expected from an uploader. Enhancing999 (talk) 10:32, 24 March 2024 (UTC)[reply]
@Enhancing999: I think you have separate the usefulness of a file name from the ability to categorize an image. Since they different ways of finding media that aren't mutually exclusive. If you want an example, check out how most stamps of the Soviet Union or Russia are currently named and categorized. Sure Russian stamps from 1996 are still categorized appropriately in Category:Stamps of Russia, 1996, but then the individual files are named after a catalog number from an obscure stamp catalog in Russian that no normal person has access to, cares about, or would use a way to search for the images. Especially on something like Google where descriptive file names are pretty important.
Someone said recently in another proposal that most people don't find files through categories, but mainly through file names. I think that's true. Categories are mainly a backend thing that are exclusively used by people who specifically spend their time sorting files, not re-users. They mainly, if not exclusively find images through the file name. So it's important not to have ambagious file names. Let alone ones that create a situation where someone has to browse through, and/or be an expert in, a specialty catalog's numbering system in order to find an image. --Adamant1 (talk) 17:11, 24 March 2024 (UTC)[reply]
@Enhancing999 Since you insist on the Ray Swi-hymn files. Which one of his files would you like to use in an article? I went through them and well, I didn't find one used in an article. Many, many of those files will wait for a long time for some local who can eventually describe what is shown, likely more than the 5 years that some are waiting already. The files of Ray Swi hymn are to me rather the reason for why we need an update of the file name guideline. Paradise Chronicle (talk) 18:24, 27 March 2024 (UTC)[reply]
A few are directly used, others are useful providing more context around articles.
Maybe you can outline how an upload for 30000 photos should work in the proposed "enwiki"-Guideline. You can also use Panoramino or a GLAM (ETHZ, CH-NB) as a sample. Enhancing999 (talk) 18:41, 27 March 2024 (UTC)[reply]
If you look at single person portraits, obviously so, but landscapes less so. They even published their images archives among others to enable the general public to determine what is visible. Enhancing999 (talk) 18:51, 27 March 2024 (UTC)[reply]
In that file at least the city and the UN are given. And LBS is a German abbreviation for aerial image/photograph from Switzerland, LuftBild Schweiz. Paradise Chronicle (talk) 05:41, 9 April 2024 (UTC)[reply]
Regarding the English, I wrote in the minimum filename standards that any language was acceptable. The question I was attempting to answer was instead, for a multilingual uploader, which language they should use for their upload name. The language policy calls out English in several places (e.g., category names, creator names) so it seemed a good suggestion. I have updated it to prefer the language most relevant to the subject (based on Commons:Galleries#Naming conventions). There could be further work on this guideline but at least the gallery convention encourages language diversity.
Author in the filename is listed in the minimum standards bullet list under "Names consisting solely of dates, the name of the photographer or rights holder, and/or words like "Flickr".
The "broad location" guidance is in the file renaming policy, there was a vote 15/18 that uploaders should do a "bare minimum" of work to include detailed locations in the filenames. For example File:20170712 ZurichRail 0932 (36101630414).jpg, arguably the filename is a "meaningless or ambiguous name". The only legible information is "Zurich Rail" but there is no Zurich Rail visible in the picture. The file could likely be renamed to a more informative name like "20170712-Lidl-Gretzenbach" without any opposition. Since it can be renamed, it is a bad filename.
There is some overlap between the naming and renaming policies, but the renaming policy actually specifically links to the naming policy page and says "Commons:File naming describes how files should be named." I would say the distinction is that the file naming policy describes how good a filename is (absolute scale), while the file renaming policy evaluates whether there is sufficient justification to rename a file (a certain arbitrary increment on the scale, from new to old). If this guideline does get accepted, likely some of the footnotes and explanations on the renaming page could be omitted as the file naming page goes into depth on those details. Mathnerd314159 (talk) 16:04, 26 March 2024 (UTC)[reply]
Support Per my comment above. We have a longstanding issue with people using file names for images that are to ambiguous or specialized to be useful. I think we should be able to separate the ability categorize something from the usefulness of the file name. Since they aren't mutually exclusive. Like with my example of how Russian stamps are currently named, sure they are "well categorized", but that doesn't mean that specific images are easy to find or that how they are currently named is at all useful to anyone. Anyway, we really need some kind of guideline to curb things like that. Although I do wonder how it would be enforced, but that's another discussion and I trust Mathnerd314159 will iron out the details before a final vote. --Adamant1 (talk) 17:23, 24 March 2024 (UTC)[reply]
Support for the minimum standards. The ideal standards might need more work (vote Neutral), but there have been improvements after Enhancing999 pointed out flaws. Mentioned is now: local languages are recommended for subjects; English would be standard for generic subjects. I don't know how this can be formulated better, but please imagine that we have the scan from a Polish book that features the 436th portrait of Columbus for Commons. Is "Ritratto Cristoforo Colombo" (it-Standard) better than "Portrait Christopher Columbus" (en-Standard) or shouldn't it be "Portret Krzysztofa Kolumba" (pl-Standard) because of the language of the book? On the other hand, which language can we reasonably expect when naming a photo of the Finnish folklore band that a Korean tourist took on their tour in Paris? en/fi/ko/fr could all apply. I would say all languages would qualify for "ideal" titles, as long as nothing is misspelled. But I'd also support that we focus on correcting file names that don't fulfill the minimum standards; rather than try to bring every name into "ideal" territory.
But we might want to (more clearly) discourage needless abbreviations: "pic org-com 4 wp glam-denco 02'10'2025" is a bad title, even if everyone involved knows that this is obviously a "picture of the organization committee for the Wikipedia-GLAM event in Denver, Colorado on October 02, 2025". Even if the description decodes that title and makes the picture searchable, it's too cryptic. The guideline covers "acronyms", but not abbreviations, so far. --Enyavar (talk) 09:20, 27 March 2024 (UTC)[reply]
I think the policy may be useful for English language descriptions, or possibly filenames in English language Wikipedia, but Commons is not the English language Wikipedia file storage only.
It's still not consistency with our language policy to tell, e.g. Spanish language uploaders that they should use "chair" and not "silla" in the filename.
Also, the proposer's feedback fails to address the issue with large batch uploads, e.g. the thousands of files of the "Ray Swi-hymn" uploads. The "minimum standards" make these practically impossible. Maybe the proposer can try to work out a batch upload that consists of more than a dozen of images and attempt to tackle the issue in practice. The proposed guideline just doesn't scale to Commons size.
We already have multiple ways to describe files, we don't need another one. Filenames are already unambiguous, we don't even need a guideline for that, it's a technical necessity. Enhancing999 (talk) 09:45, 27 March 2024 (UTC)[reply]
The argument for using English for general names is consistency of search results. If I search for "chair" I get pictures of chairs. If I search for "silla" I do not, the main results are an ancient Korean kingdom. There is one chair mixed in there, File:Silla de la Casa Calvet, Antonio Gaudí.jpg, but it is categorized as "furniture" rather than as a chair, so it does not show up when searching for chair. Just because an uploader "can" name their file "Silla de la Casa Calvet" does not mean that they should - there are actually 2 other files File:Gaudi's chair for Casa Calvet - Casa Milà - Barcelona 2014.JPG, File:Gaudi's chair for Casa Calvet - Casa Milà - Barcelona 2014 (2).JPG, so if the uploader knows English then naming it along the lines of "Casa Calvet Chair" would be more consistent. Similarly other terms like "armchair", "loveseat", "butaca", "confident" - they are all harder to search for than "chair". It is not really about language - if there was a really popular German term for something that had little usage in English, then likely using the German term would be appropriate - but I haven't encountered any such terms.
Regarding mass uploads, this seems to be a perennial conflict. For example in Commons:Batch uploading/US National Archives#File name maximum length and file name cutting format, Teofilo stated "It is not realistic to correct all these file name errors afterwards one by one [...] The upload software bug must be solved. [...] I think the bot should be blocked until the file-name issue is solved." I certainly have some agreement with that - if Commons was willing to accept files under any name and rename them afterwards, it would not have global filename blacklists. Similarly, if an uploader is not willing to do any work on improving filename quality, how can they be trusted to have checked more important details such as licensing and that the file is of sufficient quality to be uploaded? Tools such as Pattypan allow easily changing the target filename and other details. What Commons needs is high-quality files with accurate and comprehensive metadata, at least meeting some minimum standards, not terabytes of garbage thrown in at random. And yes, I would include the "Ray Swi-hymn" uploads in this category of "garbage"- many photos are blurry, have no clear subject, seem like they have no realistic educational use, or are duplicates or worse shots of similar photos. The bad filenames are the least of the problems but serve as an indicator that minimal effort was made to curate the photos. Commons is not a Flickr mirror and does not need to blindly copy every single freely-licensed photo.
Regarding multiple ways of describing, filenames are not new and were the first method of describing files. I was reading a discussion where many users still reported finding files by their filename, finding categories and description data difficult to use. I suppose we could adopt something like Wikidata where all files are identified by an ID like Q691283, but I think this would make it more likely to have insufficient metadata for files, not less. As long as filenames are in use, it makes sense to have guidelines for how to write them. Mathnerd314159 (talk) 18:50, 27 March 2024 (UTC)[reply]
No, I'm not trying to fix search, I'm trying to write a guideline. As I stated above there is a clear gap in policy, with Commons:File renaming referring to a non-accepted Commons:File naming page. I would be interested in hearing what you think the purpose of filenames is - my view is stated under "Purpose" - "Names are used to uniquely identify the item involved." But search visibility is certainly a consideration when choosing a filename, as are many other factors. Mathnerd314159 (talk) 20:04, 27 March 2024 (UTC)[reply]
Well, clearly the string must be unique, as that is enforced by the software, but I also think that the intelligible part of the filename should be sufficient to distinguish it from other files. Like if there are "File:Duck-1.jpg" and "File:Duck-2.jpg", maybe they should have been uploaded with more detail in the filename, like "File:Duck-Cambodian Farm.jpg" and "File:Duck-Virginia Tech Pond.jpg". Mathnerd314159 (talk) 20:50, 27 March 2024 (UTC)[reply]
Well, the rule is the language / name most closely associated with the subject. So for the Columbus example, if it is an original painting of Columbus, the name most closely associated would presumably be the name the painter used for Columbus. This could be the Italian, Spanish, Latin, or Old Portuguese spelling depending on the painter's preferred tongue. I think it is unlikely that Polish would be closely associated, as Columbus never went to Poland. Also English is unlikely, although I suppose it could be argued that Columbus is a "general subject" and the English spelling is therefore justified based on popularity. For the Finnish folklore band, I would say that the Finnish name is most appropriate if no text advertising the band is visible, otherwise French is most appropriate as it would match the name present in the photo. It is certainly a bit academic - few people are going to read the naming policy, and even fewer are going to put in the effort of finding the perfect name, but I think it is important to define what would be the perfect filename if renaming was zero-cost and we could endlessly debate and argue over filenames.
I think you misunderstand the problem. Many images are of general features that don't necessarily have a lanugage associated with it and we don't want English Wikipedia telling Spanish Wikipedia that English is ideal when uploading files in our Common repository. If you want to describe an ideal, don't make a guideline hindering uploads. Enhancing999 (talk) 18:44, 27 March 2024 (UTC)[reply]
How exactly would it hinder uploading? Are you seriously going to argue someone from isn't going to know the dudes name is Columbus or not be able to put it in the file name? Look at it this way, its a global project, English is the prefered language and is spoken by most people in the world. Say you have someone who speaks a niche language like Basque and they want to upload a bunch of photographs they took on trip to the United States. Sure you shouldn't name files purely to help search results, but how exactly does anyone benefit from that user uploading those images in the Basque language? The four hundred thousand other people who speak the language are the only ones who are ever to see or use the files. And yeah, there's categories, but there's also an extremely small chance anyone who speaks the language will come along and be able to properly categorize the imahes to begin with. But hey, screw litterly everyone else I guess. --Adamant1 (talk) 19:23, 27 March 2024 (UTC)[reply]
I'm a native English-speaker, but there is absolutely no reason why English should be favored over any other language for filenames, especially not to "make English-language search easier" and make searching in any other language harder. We want filenames that are decently descriptive in a language the person can actually write. It's bad enough that non-English-speakers have to cope with a mostly English-language category system (where uniformity actually is important) without making them use English where another language will do exactly as well or, in some cases, better. - Jmabel ! talk22:46, 27 March 2024 (UTC)[reply]
@Jmabel: I'd argue file names should be in the most common form for the subject and whatever allows the most people to find, categorize, or use the image. That doesn't mean I think English should be favored, but if it's a subject where the name is in English to begin with and that's what everyone knows it by then the file name should be in that language. Same goes for something having to do with Korea and being in Korean, China and being in Chinese, Etc. Etc.
I could really care less about "English" per say per se, what I care about is people not writing file names that confuse people and/or make it harder or impossible for them to find the image because no one speaks the language or can decipher the code. Otherwise we could rename every file having to do with Christopher Columbus to "Cristóbal Colón" and call it good. Of course we aren't going to do that, but at the same time there should at least be some uniformity and common sense in file names. Otherwise what's the point in even having them? --Adamant1 (talk) 23:32, 27 March 2024 (UTC)[reply]
OK, I have uploaded a new draft. It seemed to me that the minimum vs. ideal distinction was perhaps a bit duplicative of the file renaming policy. Also the navigation was a bit difficult as the bullet points were not labeled. So I have collapsed it into a long list of the form "Name - criterion". I expanded the list with criteria from other projects, e.g. Wikipedia's article title policy. It is pretty long now but I couldn't see any obvious duplication and the "mess" of criteria well characterizes the state of affairs. I also added a language-specific section as that structure was on wikidata:Help:Label and it seems clear that a criterion like avoiding articles is language-specific. I also tried to address the language issue, by taking the English-specific guidelines (e.g. wikivoyage:Wikivoyage:Naming conventions#Romanization) and negating them (c.f. "Language preserving" bullet point). Mathnerd314159 (talk) 02:05, 30 March 2024 (UTC)[reply]
I would look at the file, devise an appropriate name, and upload it? I guess if it was particularly tricky I might ask on the help desk - I would describe the contents and ask what a good filename would be. Or I would upload it under a bad filename and hope someone else renames it. Mathnerd314159 (talk) 16:04, 30 March 2024 (UTC)[reply]
I don't think the initial method scales. There are 800 files in that category and if you ask 800 questions on help desk you might not get any help or even get blocked over it. So that essentially leaves you with "I would upload it under a bad filename". Can you add this to your proposed file naming policy? Enhancing999 (talk) 16:13, 30 March 2024 (UTC)[reply]
It wouldn't be 800 questions for 800 files, it would be 800 instances of devising filenames and maybe 1-2 instances of asking for help. I myself am not particularly well-versed in cosplay but presumably a skilled contributor or three could go through all of those photos and identify the specific characters involved / media referenced. So if I made a help desk post it would likely be asking for such contributors to get involved.
My guideline already mentions that existing files with bad names will most likely stay. But I don't think it is a good idea to note that new files with bad filenames can be uploaded - it might be seen as encouragement of such behavior. Repeating myself, if someone cannot be bothered to devise a good filename, they likely will not add any metadata, and it is also questionable if they will select high-quality images in the first place. Like in this case, the cosplay photos have watermarks, are not particularly high resolution, and have no metadata relevant to their content. Apparently such images are not completely forbidden but are "strongly discouraged". I'm tempted to nominate them for deletion and see what happens - the uploader does not have a particularly good track record, and it is probably less work to delete them all and re-upload specific characters that do not otherwise have photos, than it is to systematically fix them. Given that Category:Files with bad file names by source lists 45.8k Flickr files, I would say it is definitely too easy to use the Flickr2Commons tool and use of the Commons:Batch uploading page should be required. Mathnerd314159 (talk) 18:36, 30 March 2024 (UTC)[reply]
So practically, you want to prevent mass uploads of files where the uploader isn't sufficiently knowledgeable to devise the full description beforehand? Does this apply to Cosplay only or also to GLAMs or Flickr? Enhancing999 (talk) 09:55, 1 April 2024 (UTC)[reply]
I think you are confusing filenames and metadata, as well as uploaders and hosts. Flickr isn't an uploader. So bad file names if uploaded by GLAMs are ok? Enhancing999 (talk) 08:32, 7 April 2024 (UTC)[reply]
It's more like the rate of bad filenames. Uploading a million files from a GLAM with 90% good filenames is pretty good - the junk doesn't matter, it is mostly invisible. And in the case of a GLAM there is often a metadata field suitable for use as a filename so such a 90% rate is achievable. Uploading 10 files, all with terrible filenames, probably deserves a warning - they are wasting their time uploading junk by hand when they should be writing better metadata, and also there is the w:broken windows theory suggesting that others will follow suite. In the case of Flickr, it seems a lot of files are uploaded by various people without changing the name (or adding a description, or anything really), and most names on Flickr are bad. A consistent effort to improve Flickr uploads could have significant effects. Mathnerd314159 (talk) 01:45, 8 April 2024 (UTC)[reply]
The cosplay filenames aren't actually bad (such as misleading or fully undescript). It's unclear why GLAMs should be favored. We do have thousands of NARA files that don't meet your ideal. Enhancing999 (talk) 10:48, 8 April 2024 (UTC)[reply]
It is simply about what is practical. For the cosplay, the user went through and added descriptions by hand to the ones they knew, like for example File:Cosplay of Denji, Power and Reze from Chainsaw Man at FanimeCon 2023 (53056133958).jpg. When they were uploading, they could simply have not uploaded the files they didn't recognize. With a GLAM / mass upload, simply examining each upload could be infeasible for a single contributor.
And you are seriously saying "the cosplay filenames aren't actually bad"? You are telling me you prefer the name "Fanime-2023-05-28-0362 (53055068002)" to "Cosplay of Denji, Power and Reze from Chainsaw Man at FanimeCon 2023"? In the bad filenames, the only relevant information is "Fanime", and it is unclear what it means. I could list off more criteria one-by-one but that is the point of the guideline, to establish a metric for evaluating filenames even in the absence of obvious comparisons. Mathnerd314159 (talk) 20:55, 8 April 2024 (UTC)[reply]
I wish commons policy would forbid mass uploads with bad file names. Most of them are anyway not in use, many of those files are also just random files of whatever and they'll need to wait for years until someone appears and renames them correctly.Paradise Chronicle (talk) 16:51, 30 March 2024 (UTC)[reply]
The problem are not the mass uploads of original content or GLAM content the only often problematic uploads are mass imports from Flickr or other image hosting pages. GPSLeo (talk) 19:59, 30 March 2024 (UTC)[reply]
We could solve a good portion of the Shovelware and problems that come along with it like the bad file names just by banning mass imports from Flickr. 99% of the images from there are technically OOS, not being used anyway, and I can guarantee a lot of them would be deleted as non-educational if uploaded by regular uses. But for some reason it's totally cool to upload low quality, badly named, OOS scrap in mass as long as it is being imported from another site for some reason. --Adamant1 (talk) 04:39, 1 April 2024 (UTC)[reply]
Usage on other Wikimedia websites doesn't necessarily indicate if a file has educational value or not. I often browse bookstores and check out random books and one thing I notice is that a lot of images I didn't even consider are used in educational ways. Random photographs of streets are often placed side-by-side to explain the evolution of a town if you read the Toen en nu ("Then and now") series of picture-books that are very popular among the elderly in the Kingdom of the Netherlands. Sometimes I think that some users see the term "educational" as something very narrow where if it's outside of the idea of educational materials they can think of they can't see the educational uses of a file.
The images from SmugMug's Flickr aren't too different from those of the national archives of many countries. To me, a random image of a random candle 🕯️ wouldn't be "educationally interesting", but to someone writing a book about different types of candles found around the world such an image would be very valuable. --Donald Trung 「徵國單」 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:13, 1 April 2024 (UTC)[reply]
That's a fair point. I'm just not a fan of how indiscriminate and uncurated (if that's the proper term) mass imports from Flickr are. Like people will just import thousands of photographs without meaningful descriptions or file names and not categorize them anywhere. Then expect us to do all the footwork to figure out what they are images of and how to organize them. It's just a very easy, selfish way of contributing to the project. On our end though we could at least have an approval process for mass imports from other websites like Flickr. I'm totally against them, but there should be some kind of oversight and the person doing them shouldn't just be able to dump a bunch of images on here and expect everyone else to do the work of sifting through them. --Adamant1 (talk) 05:29, 1 April 2024 (UTC)[reply]
There I agree with you. If Universities and Museums upload their content, it is great, but those files usually also have a good filename and if that is missing at least a good description. But mass Flickr uploads are usually just a problem.Paradise Chronicle (talk) 08:20, 4 April 2024 (UTC)[reply]
@Adamant1@Paradise Chronicle@Mathnerd314159 or better still, which may also solve COM:SCOPE debates and also reduces possible no-COM:FOP infringements: why don't we limit importation of Flickr files to just one file per import session? That will enforce discipline among all average users. Batch uploading may be allowed if the user conducting Flickr importation is a sysop/admin. JWilz12345(Talk|Contrib's.)23:11, 7 April 2024 (UTC)[reply]
That sounds like a great idea. I'd probably support extending it to autopatrollers. Although I agree it's probably best for another proposal. --Adamant1 (talk) 00:07, 8 April 2024 (UTC)[reply]
Since feedback on my v2 draft was limited to one "thank", and comments on the first draft were generally positive, I have updated the main proposal page with my draft. This gives it better visibility and I think the overwrite is also an improvement as the voting on the old proposal was much less positive. I would say the proposal is "provisionally" final - someone could bring up new concerns, but I think all mentioned concerns have been addressed, besides enforcement w.r.t. Flickr imports, but guidelines generally do not include the enforcement process. So the main question now is whether it can become an official guideline. Mathnerd314159 (talk) 05:07, 7 April 2024 (UTC)[reply]
Oppose Still has issues that will cause more problems than it solves. "Consequently, new uploads should aim for the highest-quality filenames." Big expectation and will differ depending on people's opinion of certain file names.
in the Content-based "Names consisting solely of dates, the name of the photographer or rights holder, and/or words like "Flickr", "original", and "crop" are forbidden.", overly vague (should have an example of what is and isn't acceptable) and makes it sound like those should never be used when in cases it might be. Bidgee (talk) 16:14, 7 April 2024 (UTC)[reply]
"will differ depending on people's opinion": the point is that by establishing objective criteria for filenames, it will not depend on opinion. I suppose "highest-quality" is maybe too optimistic and I could instead say to aim for mediocre-quality filenames that are at least not terrible, or else to recommend spending between 10 and 30 seconds deciding on a filename (or some other range) – would either of those be better?
Content-based: This is from criterion 2 for renaming, "meaningless or ambiguous name", a widely accepted guideline. I added some examples. Mathnerd314159 (talk) 19:53, 7 April 2024 (UTC)[reply]
@Bidgee: what is an example where (for example) just "Flickr" and the name of the photographer would be an acceptable file name? Or some other combination of the things in this list? - Jmabel ! talk20:41, 7 April 2024 (UTC)[reply]
Just in looking, when uploading a modified version of a file, it is typical to use the original's filename and modify it for the upload ("cropped", "2", "3" "altered", etc.) Sometimes multiple versions are uploaded for choosing on feature picture nominations. Calling that practice "forbidden" now is definitely not correct -- this is a guideline I assume, not policy, and I certainly would not want to use this as justification for mass renaming of existing files. Maybe say "discouraged", at most, but once a filename exists then modifications using that as a base seem fine. Carl Lindberg (talk) 22:57, 7 April 2024 (UTC)[reply]
The point is to forbid filenames that consist solely of such identifiers. It is fine if they are there, just not if there is nothing else. I already have a whole sentence "It is not forbidden to include such information" so I am not sure what else would make this clear. Mathnerd314159 (talk) 23:05, 7 April 2024 (UTC)[reply]
@Bidgee: I think you may simply be misreading (and I don't know what "example file name (noted above)" you are referring to, since there have been numerous filenames on this page). The sentence you quoted begins, ""Names consisting solely of..." (emphasis mine), but you seem to be flatly saying that it is an exclusion of using these things at all. If I say, "I won't eat a meal consisting solely of broccoli," it doesn't mean I won't eat broccoli. - Jmabel ! talk14:07, 8 April 2024 (UTC)[reply]
Really? This reads nothing like a guideline. "This page is designed to aid uploaders in selecting proper names for their files, promoting standards of excellence in filename conventions." We are not a university, the guideline should be about helping uploaders to select/pick filenames that are ideally appropriate/suitable. "It is important to note that while this page provides recommendations for creating high-quality filenames, the recommendations are not intended to serve as standalone justification for renaming files." Drop "high-quality" and replace with "suitable" and why do we need to repeat "recommendations" twice? "... balancing the principles outlined here with the costs of renaming files. In general, the costs of renaming are significant, so Commons aims to provide stable filenames and renames are limited." Why use "costs"? And how is it "significant"? Renames are not limited, just recommended not to be done too often. Keep the guideline simple (like Commons:Image annotations, Commons:Galleries), not complex, since it currently reads like a policy. Bidgee (talk) 05:16, 11 April 2024 (UTC)[reply]
OK, I guess the phrasing was a little over-the-top. I have addressed the issues you mention, besides complexity (w:WP:MOS is a lot more complex). In the future you can be bold and fix it yourself, I won't mind. Mathnerd314159 (talk) 05:35, 11 April 2024 (UTC)[reply]
Support I still have a few issues with the whole thing myself, but Perfect is the enemy of the good and overall this seems like a good proposal. Some guidance on how to name files is clearly better then none. The few objections just seem like nitpicking, or at least things that can be ironed out later. You can't really iron out a guideline that doesn't exist in the first place though. --Adamant1 (talk) 00:12, 8 April 2024 (UTC)[reply]
Oppose it's one thing to describe an ideal filename, but we shouldn't use this as a guideline to stop GLAMs and other users from uploading files that meet current standards while not being as detailed as a user with 10 uploads might expect. Glad the current version at least dropped the academic ideal of requiring English filenames. Wonder what academic current that guideline comes from. Enhancing999 (talk) 10:52, 8 April 2024 (UTC)[reply]
Strong oppose: One seldom sees in Commons so many bad ideas bundled toghther with so much support from otherwise serious users. -- Tuválkin✉✇23:35, 8 April 2024 (UTC)[reply]
I am a bit confused. I believed, it was quite an improvement. Then what would be your suggestion to prevent uploads like this or this, there are several more of those... They were uploaded in 2020, with ambiguous filename, received a Basel category in 2022, and I eventually moved it to Nature in Basel in 2024. I don't know where in Basel there is such a landscape, its a city and there is not much nature. Or this one with simply Zurich, panoramio and numbers in the filename, uploaded in 2017, received a Zurich category in 2017 and was eventually moved to Nature in Zürich by me in 2024. We still don't really know where it is, what it shows etc. There is a problem with identification and I'd be glad if we could find a solution together. Paradise Chronicle (talk) 23:52, 9 April 2024 (UTC)[reply]
No addressable / transparently-explanatory reasons have been given here so this is anything but a "strong" oppose. Agree with Paradise Chronicle but there are way worse filenames than PD's examples like "Jmse-10-01816-g001-550 hor.jpg". Prototyperspective (talk) 11:57, 14 April 2024 (UTC)[reply]
Comment This looks OK for best practice, but it should not be required (guideline, not policy). We basically have five redundant descriptions of the files - the filename, the categories, the caption, the description, and the structured data. Of those, I would argue that the least important is the filename, and the most important the categories, since that's how people currently find files (although that will hopefully transition to structured data in the long term). I reflect this in my uploads - since I upload a lot of files using batch uploading, giving them quite generic filenames (such as 'At Singapore 2023 001') is the most efficient way to get them uploaded to roughly the right place, and after that point my time goes into categorisation/use/QI. Requiring filenames to be more detailed would be a huge blocker to my workflow, although I never object to people renaming my uploads if they want. Thanks. Mike Peel (talk) 17:58, 9 April 2024 (UTC)[reply]
It does read the contrary on the page itself and it would still be a guideline GLAMs and users like @Mike Peel are expected to follow. An alternative could be to make an essai somewhere, e.g. MAthnerd's user namespace. Enhancing999 (talk) 21:18, 9 April 2024 (UTC)[reply]
Oppose This proposal does not solve a single problem that, to my knowledge, is not already regulated elsewhere or covered by the renaming rules. Instead, it creates additional hurdles and complicates things further, which will deter many potential uploaders. In addition, such a collection of rules will be used by some regulation and order fanatics as justification for enforcing their own ideas against the wishes of those contributors or creatives who are responsible for the actual content in the media sector, thus causing resentment, disputes and completely unnecessary extra work. --Smial (talk) 12:13, 10 April 2024 (UTC)[reply]
The point here is to avoid the need for renaming, by specifying how to make a good name in the first place. Nothing here changes the renaming rules. - Jmabel ! talk14:30, 10 April 2024 (UTC)[reply]
Sure, but disputes can be greatly reduced, if not totally mitigated, by having guidelines. Instead of people just endlessly bickering about something because we can't be bothered to give people guidance on the best way to do something or how to do it properly for some bizarre reason. --Adamant1 (talk) 06:57, 11 April 2024 (UTC)[reply]
You're right that this is generally duplicating the renaming rules. However I absolutely do not expect new users to be aware of our renaming rules, whereas there should be a guideline accessible to them on how to name filenames correctly in the first place. Today, as far as I know, the only guidance they get is Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg on Special:Upload. Consigned (talk) 11:17, 19 May 2024 (UTC)[reply]
Support Very much support proper filename guideline. Details could be discussed there but as far as I can see things are fine. I do object to "When it comes to organisms and biological subjects, the scientific (Latin) name is recommended." even though it's just a recommendation. I think the most widely and most reasonable name should be used (except if incorrect/inaccurate). For example the word kidney should be used over phrases with "renal". Prototyperspective (talk) 00:06, 12 April 2024 (UTC)[reply]
The Latin recommendation is from Commons:Galleries#Naming conventions, "An exception to this rule is the naming of galleries of organisms and subjects where Latin names are considered universal." And then I added "biological" as the grammar was a bit strange and I couldn't think of any other "subjects where Latin was universal". And then "scientific" came from w:WP:COMMONNAME, where there is a note "Common name in the context of article naming means a commonly or frequently used name, and not necessarily a common (vernacular) name, as opposed to scientific name, as used in some disciplines." It is certainly something worth discussing. Like there is the w:Terminologia Anatomica, using it as a systematic naming scheme for files would be good, but nobody uses it so it would be hard to adopt. For now I have changed "biological" to "botanical". As w:WP:FLORA says, in the vast majority of cases, the most common name will be the current scientific name. In the cases where it isn't, I expect the common name would not translate. Mathnerd314159 (talk) 03:53, 13 April 2024 (UTC)[reply]
You write "so I oppose" but you didn't give any reason and didn't address the one I gave. People understand and search for certain things like kidney cancer and a few people use some words of a dead language the vast majority doesn't know, search for, or understand. Prototyperspective (talk) 13:18, 13 April 2024 (UTC)[reply]
Google is pretty clear that binomial names apply to "animals and plants" and "organisms". Indeed Homo sapiens qualifies as an animal and an organism. You have not given any examples of binomial names that are not organisms or plants. Mathnerd314159 (talk) 15:44, 13 April 2024 (UTC)[reply]
And it doesn't mean people can't use the word renal or "cat" instead of "Felis catus". There needs to be some guidelines for descriptive useful filenames but at the same time it shouldn't be overprescriptive. Prototyperspective (talk) 13:36, 13 April 2024 (UTC)[reply]
I don't know if you are you replying to me. No, images like "A cat catching a mouse.png", "Three people operating a robot.png", or "Statue of a dog.png" etc should not be recommended to be called "Felis catus catching a Mus musculus.png", "Three Homo sapiens sapiens operating a robot.png" and "Statue of a Canis lupus familiaris.png".
Categories and file descriptions can be used for that and they can still be named like that without this being in the guideline. This is absurd and partly because Jeff has still not given any reasons for the objection, I won't continue debating this which would just produce a walls of empty text. Prototyperspective (talk) 15:03, 13 April 2024 (UTC)[reply]
@Prototyperspective: you are making a straw man argument. Presumably no one would prefer those file names, especially insofar as they refer to very common species (especially homo sapiens). Personally: I'm still normally going to say "gull" rather than larus, but if I know for sure I've got a Larus fuscus I might well use the species name rather than "Lesser Black-backed Gull." - Jmabel ! talk06:24, 14 April 2024 (UTC)[reply]
This whole thing about using species names or not seems rather tangential. Is there a reason it can't be ironed out or further clarified after the guideline is implemented (assuming it is. Otherwise, the conversation doesn't really matter anyway). --Adamant1 (talk) 06:48, 14 April 2024 (UTC)[reply]
Not a strawman but showing how ridiculously bad these specific proposed recommendations are. What's in your mind regarding common sense does not undo what's on paper/text. As Adamant1 said, those things can still be fleshed out later on and I support the guideline for adoption except for this part. Prototyperspective (talk) 12:01, 14 April 2024 (UTC)[reply]
To clarify: I still oppose this part. It doesn't diminish the overall support since details like that could also be changed later on and because a recommendation doesn't mean it has to be applied while Latin names may be useful in some cases. But this part really needs to be removed. You know humans are organisms right? Are file titles really recommended to use e.g. "Felis catus" instead of "cat"? I also oppose the part about "Language preserving" – I want to use file titles of the most widely understood and on WMC most widely-used language, English, for probably all media I upload. I think RZuo raised a few segments of the text where weakening them away from "should" may be a good idea. Prototyperspective (talk) 12:02, 19 May 2024 (UTC)[reply]
The following was removed from the draft: When it comes to organisms and botanical subjects, the scientific (Latin) name is recommended. Could this be reworded as When it comes to organisms and botanical subjects in a scientific context, the scientific (Latin) name is preferred, but local languages are acceptable.? I think it is useful to recommend using Latin names in scientific areas. Consigned (talk) 16:15, 19 May 2024 (UTC)[reply]
I'd have no active problem with that, but it is getting fairly long. I'm wondering if we'd do better to have somewhere that we lay out weird exception cases rather than the main flow of the document. But, yes, I think that should be said. - Jmabel ! talk16:55, 19 May 2024 (UTC)[reply]
Oppose There isn't a good policy reason why English must be preferred for file names. Status quo works, and is more fitting for a multilingual project. Abzeronow (talk) 20:46, 14 April 2024 (UTC)[reply]
@Abzeronow From where do you take that English must be preferred? The phrases on languages I see in the proposal are: These guidelines apply to names in English. Speakers of other languages may define guidelines for their language in the relevant translations. Paradise Chronicle (talk) 21:05, 14 April 2024 (UTC)[reply]
Support per nom. this would presumably be a nice starting guideline for someone who may not know how to name things well or otherwise want a nice "standard" to stick to. something that I also would like adding as a possible template is {source} - {name}, this I have seen mostly batch uploads, such as in fonts (see Noto) and I have used for magazine issues at lipu tenpo illustrations. Juwan (talk) 20:03, 9 May 2024 (UTC)[reply]
Support. Thanks for your work in codifying something that is referenced in many places but lacks a guideline. It seems to accurately summarize the various other references to this topic as well as best practices followed today. Consigned (talk) 18:53, 16 May 2024 (UTC)[reply]
Support Well, a lot of consideration and re-writing has gone into this, and as long as this is just a guideline (no new restrictions on uploading will directly follow from this, right?) for anyone read and consider when naming files, I will gladly Support this, also per MikePeel and Adamant: Better have a good-practice guideline rather than having none. I checked the oppose-voices and and didn't find compelling arguments against the new proposal. I have a feeling that English will remain the only additional "Language-specific guideline". --Enyavar (talk) 19:21, 18 May 2024 (UTC)[reply]
I don't think we already have such guidance on naming files, we only have a policy/guideline on renaming (Commons:File renaming). Special:Upload currently just says Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg. but ought to link to a more detailed policy/guideline page with more information. Consigned (talk) 01:11, 19 May 2024 (UTC)[reply]
As far as I have read the guideline, there is nothing in there to announce sanctions against people who don't comply with it.
But just to clarify: Would an uploader of material like File:Colorado -Adams County - Las Animas County (part)- - NARA - 17443770 (page 700).jpg get blocked, if they persist to upload material like the linked one, after this guideline goes into effect? Note how the name only indicates that this is a NARA document of any place in Colorado located in a county with a name alphabetically between "Ada" and "Las". That example file is following a naming scheme, but a very very bad one with respect to our guideline. Now, if such an uploader cannot be convinced to use a better naming scheme: would we use THIS guideline as a cudgel to block them? As it is currently outlined, I don't think so. The only consequences that the guideline announces, is that files which don't comply with the guideline, may get moved. --Enyavar (talk) 08:52, 19 May 2024 (UTC)[reply]
I don't think that that filename is horrible, and I would hope that a person who consistently uploads filenames like that wouldn't get blocked, as there is likely a good reason why the filename is so (e.g. bulk uploads). Enhancing999 does raise a good point - should the guideline clarify what the consequences are? Is there a policy somewhere that explains when guidelines become blockable? Personally I don't think that this guideline should be creating new blocking criteria - the same norms today regarding blocking for disruption and wasting community time (which could feasibly happen due to file name issues) ought to continue to apply. Consigned (talk) 11:09, 19 May 2024 (UTC)[reply]
Users are expected to follow guidelines. Or is it just users except NARA?
Supposedly they are likely also to get in trouble with getting their filenames into neutral POV. Historic materials tends to not necessarily reflect current enwiki views on the topic. Enhancing999 (talk) 15:37, 19 May 2024 (UTC)[reply]
If an uploader wastes community time today by uploading useless filenames, e.g. IMG12345.jpg, and the community reaches out and they continue to waste community time, I expect they could be blocked today. This guideline just helps to clarify the reasons why. That said the level of disruption would have to be quite high, and I don't expect "bad but not useless" filenames would rise to the level of blockable disruption, today or in the future with this guideline. Consigned (talk) 16:08, 19 May 2024 (UTC)[reply]
If this is your only point, we don't need the new guideline.
Such filenames are already not possible today and were by the previous version. The explanation in the upload wizard is fairly explicit.
If you think the guideline shouldn't be applied in some cases, but should be applied in others, the guideline should say that. Otherwise contributors might not appreciated to be blocked while some archive continues with the same. Enhancing999 (talk) 16:20, 19 May 2024 (UTC)[reply]
I agree that the guideline should make it clear what the consequences are of violating it. But it is a problem today that we might block on something that does not a clear guideline; users should not have to understand our file renaming procedure or vague community norms in order to learn how to best name files. Consigned (talk) 16:24, 19 May 2024 (UTC)[reply]
As I've pointed out in other comments, to my knowledge the only guidance users get at Special:Upload is Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg. Is there other guidance that I'm missing? Consigned (talk) 16:37, 19 May 2024 (UTC)[reply]
@Enhancing999: I have never uploaded a file with the Upload Wizard (or maybe one or two just to try it, years ago). Does that disqualify me from discussing file naming? I think not. - Jmabel ! talk16:58, 19 May 2024 (UTC)[reply]
Well, you don't seem to have problems picking good filenames and you don't lecture Commons about using English or Cyrillic.
I do think you need to have some experience with Commons to contribute anything of substance to this discussion. Merely attempting to reason based on English Wikipedia article titles is obviously not working.
From you personally, I'd expect you'd explain how archives should change their filenames to comply with the guideline so they can continue to upload. I would deem an explanation like "no it's doesn't apply to NARA; but only Flickr" as not acceptable. Enhancing999 (talk) 17:05, 19 May 2024 (UTC)[reply]
I believe there should be more guidance than that on how to choose a good filename. I think it would be helpful for that note on Special:Upload to link to a broader guideline on how to name a file. Consigned (talk) 16:53, 19 May 2024 (UTC)[reply]
Please note: If there are dire consequences for not following the guideline, I will change my vote against it. The worst that should happen for "offenders" (unless it's disruptive material) should be consistent nagging to pretty-please choose better naming schemes, and maybe getting placed on a watchlist. Disruptive material (like obscene/insulting filenames, or notably on-purpose bad names to create a mess, like uploading penises as "cute teddy bear") gets people banned for other reasons anyway. --Enyavar (talk) 21:08, 20 May 2024 (UTC)[reply]
While I support the proposed text as-is and if we get to consensus it ought to be published, I agree that its length is a weakness. I wonder if the introduction could be rewritten into an effective summary so that a new user can understand the file naming recommendations at a glance? Consigned (talk) 11:13, 19 May 2024 (UTC)[reply]
"The name should not consist primarily of a broad location, such as File:Paris 319.jpg, Ontario hill, or Japan train station, where the location is so large that only someone who knows the area very well can identify the image."
"For place names, the basic name of the place, without a whole bunch of localizing addenda, is the best, e.g. "Denver" instead of "Denver, Colorado" or "City of Denver"."
Strong oppose "Refer to the Neutral point of view and No original research guidelines of Wikipedia."
"Language preserving – Follow the conventions of the source(s) appropriate to the subject and avoid translation or romanization unless these are present in the source(s). If a subject has strong ties to a particular language, the name should use that language."
whoever came up with these ideas probably have never dealt with multiple writing scripts.
say i find a photo of Zelenskyy on the ukrainian govt website to upload. i have zero knowledge of cyrillic alphabet. how am i supposed to use ukrainian written in cyrillic? or a photo of a mountain in tibet on a tibetan blog. how many commons users can write tibetan?
how many users know the tibetan mountain well enough so that "The name should not consist primarily of a broad location"?
this discussion has no merit at all because what led to this discussion is still not revealed for 2 months now. jokers want to exclude photographers' names from filenames? such absurd proposal if started on commons gets discarded straight. yet yall choose to be happily carried away by this absurdity that's hidden from users here. RZuo (talk) 12:48, 19 May 2024 (UTC)[reply]
I think the important thing is that this guideline uses the word "should" rather than "must". How would new users know what to do in the scenarios you bring up today? We have no guidance for them, and some type of guide is better than a free-for-all. Consigned (talk) 12:54, 19 May 2024 (UTC)[reply]
@RZuo Nowhere in the guideline it says you have to use Cyrillic for a Ukrainian file nor that you have to use a specific language for any file. Write in the language you are proficient in. Paradise Chronicle (talk) 13:11, 19 May 2024 (UTC)[reply]
Please note that the example with the broad location is an example from Commons:File renaming, which is a guideline already. This kind of nonspecific file names is even common in quality images that are supposed to have meaningful file names according to the rules. E.g., this is a major nuisance during quality image categorization, even more so if the description is exactly as meaningless and contains half a Wikipedia article of text about the city or the country, but nothing at all about what is actually shown on the photo. The rather common preference for this kind of essentially meaningless file names is one of the major reasons why I support even this very lengthy guideline. Renaming this kind of material would very likely enrage the authors because the new names would not match their naming conventions. Therefore, avoiding this by encouraging short but meaningful names would be great. However, a much shorter version of this guideline would be very much better, possibly with a link to the longer version for the extremely few people who wish to know more about the subject. --Robert Flogaus-Faust (talk) 22:27, 20 May 2024 (UTC)[reply]
as part of Commons:File renaming it's ok, because it means it's reasonable to "change from a generic filename to a more descriptive one". as part of a guideline on naming files during upload it's not ok.
imagine if Kimiko Nishimoto took photos of towns on board a plane from munich to zagreb. how would you expect a foreign elderly tourist give filenames more specific than "european towns seen from flight ab789 012.jpg"?
those who came up with this proposal have never had experience of uploading or handling something they dont know about, which is not uncommon for travelling photographers.
i myself have taken a lot of photos of things i have no clue about. all i can offer is the location where i took them. RZuo (talk) 20:06, 25 June 2024 (UTC)[reply]
If you don't know what is being depicted then this is valid explanation for why the title is not more descriptive, no problem at all...one could also use a title like "Close-up of unidentified animal in Ecuadorian Amazon" or "Animal in Amazon, 345" which already would be descriptive. Prototyperspective (talk) 22:22, 25 June 2024 (UTC)[reply]
There's no mandate with this that anyone has to use descriptive file in cases where they either don't know or have access that information. "The law of least resistance" or whatever it's called should apply though. In other words, "provide whatever description that you can. No more, no less." Just like with everything else on here. --Adamant1 (talk) 09:25, 27 June 2024 (UTC)[reply]
Here's the thing: I'm not quite sure what this does. It sets forth some best practices, but to what end? It doesn't say what should happen if a file doesn't satisfy these best practices, and that's probably a good thing because there's a lot of room for disagreement in the interpretation/application of these guidelines. It seems oriented towards getting the filename correct at the time of upload, but what happens when it's not correct? It doesn't address the issue that inspired it, which is about inclusion of the photographer name, but does open cans of worms by e.g. introducing the [English?] Wikipedia's NPOV policy. The relationship between this page and Commons:File renaming needs to be worked out as a fundamental element of how this page works in practice. In short, it's fine to say "please think about how to make your filenames precise" but when I think of making something a guideline I think of giving people a tool for enforcement. Absent clarity on what's to be done with this guideline, I'm inclined to Oppose, with thanks to the proposer for putting work into a challenging project. — Rhododendritestalk | 21:55, 19 May 2024 (UTC)[reply]
Of course they are. Otherwise just have an "information page" or something. The whole point of having a big discussion to formally make something a guideline is to give it teeth. — Rhododendritestalk | 15:00, 20 May 2024 (UTC)[reply]
The guideline is to clarify existing practice regarding renaming, and to help uploaders create filenames that do not need to be renamed.
As far as "teeth", I think the only thing this guideline really does is establish a standard for what filenames can be renamed to. So if a user is consistently renaming files to *worse* names according to this guideline, then there would be a strong argument to revoke their renaming privilege. Mathnerd314159 (talk) 17:43, 20 May 2024 (UTC)[reply]
How can you ask persistently uploading problematic filenames like "sdf.jpg" or "Jmse-10-01816-g001-550 hor.jpg" to choose beter filenames? And if they're willing to use proper names or are looking what proper filetitles would be, what page would give for guidance? I really don't get all this conservatism "if a policy on this doesn't exist since around the time of Wikimedia founding then let's make it near impossible for it to pass for no good reason". File renaming cited by Rhododendrites is only about moving files but this is about naming files at the time of uploading which is a separate subject and important for many reasons such as reducing workload and establishing good naming practices right from the get go (e.g. many problematic filetitles will never be changed). Prototyperspective (talk) 21:43, 20 May 2024 (UTC)[reply]
@Bidgee right, the current standard there is "A user repeatedly renaming files under invalid reasons can be stripped of the filemover privilege." If this guideline passes, there would be one more reason to consider a rename invalid (the filename is "worse"). In particular, for renames under reason 2, "change from a meaningless or ambiguous name to a name that describes what the image particularly displays", one would consider the various factors of the naming guideline and could conclude that the resulting name is not better. Currently, the renaming policy links the naming guideline, but it is not accepted as a guideline, so it cannot actually be cited as "common sense".
Or something like that, I am not a wikilawyer. Personally I am done - I wrote the guideline, nobody has any more constructive feedback on it, it has been months. Y'all have fun. Mathnerd314159 (talk) 02:01, 21 May 2024 (UTC)[reply]
Honestly I don't think the 15 different versions really helped. Especially since they were actively being changed while voting was going on, which at least IMO is a huge no no. You might try cutting it back and proposing something in a few months that just involves the basic points and makes it clear that it's only a guideline, not an enforceable guideline though. Since some people were/are still clearly confused about that aspect and it was never properly addressed. From what I've read so far I don't think anyone would necessarily reject a basic "guideline" about how to name files at the time of upload. There was some obvious things that could have been made clearer and done better from the get go about this particular proposal though. So it's not surprising that it didn't go anywhere. But again, that can probably be dealt with by simplifying it and not making the same mistakes next time around. --Adamant1 (talk) 03:36, 21 May 2024 (UTC)[reply]
There were only two substantial versions, and I stated up front "I would revise the draft to accommodate any comments and then once the draft is in a good state I would overwrite the main Commons:File naming page and there would be a vote on whether to adopt it." The process has been going exactly as I envisioned it, save for the fact that people can't read and keep bringing up points that have been discussed to death. Mathnerd314159 (talk) 16:01, 21 May 2024 (UTC)[reply]
From what I saw there was a vote on draft 1, draft 2, and then the "final proposal." That's to many iterations. It's just confusing and makes it hard to tell what exactly people have or are voting on. It's also rather tendentious to expect people to keep track of the various conversations, your edits, and repeatedly vote on the different proposals in the meanwhile. ou should have proposed and refined the draft in another venue and then done the final one here. Or conversely proposed the draft, gave it plenty of time for people to comment, and then edited it and created the final proposal after some time has passed. You can't just edit and propose 3 different versions of something in real time as the vote is happening though. There's no reason you couldn't have just proposed the draft to get feedback on it, made the changes, and proposed the final draft at some point in the future after you were sure all the kinks had been ironed out. --Adamant1 (talk) 23:03, 21 May 2024 (UTC)[reply]
Oppose In my opinion, we need not much more of a filename guideline than that the name should be unique, preferably fairly descriptive (in any language) and not contain anything defamatory or unnecessarily rude. Also, large-scale uploads by GLAMs often use rather short and not very descriptive file names but are valuable nonetheless; after all, a good description is more important than the file name. Gestumblindi (talk) 19:24, 26 May 2024 (UTC)[reply]
What, this is about the title not lengthy descriptions. You prefer filenames like "Jmse-10-01816-g001-550 hor.jpg" "PA166123135.png"? What's your rationale, have you thought about this? Prototyperspective (talk) 12:29, 20 June 2024 (UTC)[reply]
When you have a look to my uploads you can clearly see what I prefer. And yet, files are still occasionally renamed (in my opinion, without justification). This proposal will make this even worse instead of better. Stepro (talk) 12:46, 20 June 2024 (UTC)[reply]
@Stepro after looking at your recent uploads, I'm pretty comfortable in saying that what you seem to prefer goes against general consensus. Putting your name in photos of people, and leaving out the name of the person you photographed is, at best, confusing, and makes the filenames useless as anything other than unique identifiers (which they have to be by system requirements). - Jmabel ! talk17:21, 20 June 2024 (UTC)[reply]
That's exactly what I mean. My file names are anything but "meaningless", the respective event is always included in the file name due to the automatic naming. The description of the content of the photos is in exactly the right place - namely in the "description" field. And without wishing to praise myself, I think that my image descriptions are generally comprehensive, detailed and factually correct. The photos are also categorized accordingly. They are easy to find via both internal and external searches, as evidenced by the numerous external reuses (new ones almost every day).
And then "colleagues" like you come along and write that I'm doing everything wrong and that my uploads are against the "general consensus". This is extremely demotivating, especially when it comes from admins of this project.
I just have the faint hope that it's not "against general consensus", and I just keep working (for now!) to make free content available. Both for the Wikipedia projects and for external users. Stepro (talk) 23:00, 20 June 2024 (UTC)[reply]
You're not doing everything wrong, just the part of not including the name of the person pictured in the image title. I also think it's general consensus to name files in ways that are somewhat descriptive but it's not yet a policy hence this proposal. On category pages, one does not see the descriptions but only the filenames for instance. Prototyperspective (talk) 09:04, 21 June 2024 (UTC)[reply]
Sounds like you are trying to assume there is consensus for this draft while the point of this discussion is gather input about it.
Obviously, this reminds us where it came from: suppress the name of the creator/photographer from filenames. Oddly, people advocate adding the name of the uploader. Enhancing999 (talk) 09:10, 21 June 2024 (UTC)[reply]
I have had this discussion (too) often. So in a nutshell: a) I am not in a position to edit each file name individually when uploading several hundred (up to more than a thousand) photos of an event, these are generated automatically, and b) no one has yet been able to explain to me how file names should look when several people are pictured. Should the file names then span three screen lines? I think they are already very long.
And all in all, I stand by the argument I used to justify my vote: Descriptions of the photos belong in the Description field, and not in the file name. This is an attempt to solve a problem that simply does not exist. Stepro (talk) 10:24, 21 June 2024 (UTC)[reply]
@Enhancing999 it's more about what the established practice and expected titles are I think. I don't have an issue with including the uploader/photographer name but the person depicted (or content) should also be there.
@Stepro You are in that position by scrolling through the page and spending 5 minutes to add the name of each person depicted to each title (e.g. at the end of it). When 3 or more people are pictured name them all or add sth like "discussion at event", just something descriptive and people could extract an image of the individual person. This problem exists as demonstrated by your uploads as well as by already mentioned uploads like "Jmse-10-01816-g001-550 hor.jpg" "PA166123135.png" which make it harder to find the images, make image unclear where they're used, and degrade the usefulness of category pages. Your argument is just saying they belong somewhere else without explanation why and I gave several reasons why the file titles are meant to be descriptive. This really is kindergarten and should be self-explanatory, no idea why this proposal is still somewhat controversial. To anybody who has WMC best interest in mind it should be clear that file titles should be descriptive and useful. Prototyperspective (talk) 10:35, 21 June 2024 (UTC)[reply]
I think it's an error to assume filenames should somehow look good on category pages.
Even so, it's unclear what would be better in your approach. A picture of persons A, B, C will be in the categories for these persons with a filename that indicates when it was taken, at what event and by whom. You don't need to read the name of that person again. Enhancing999 (talk) 11:32, 21 June 2024 (UTC)[reply]
They shouldn't look good, they should be useful for the reader/user to see whether or not the file is about what they searched for / interesting to them (descriptive of the file content). Good point but these are also in other categories, not all files in the categories actually depict the person, and there's further reasons such as image content being unclear when editing Wikipedia in nonvisual mode. Prototyperspective (talk) 11:37, 21 June 2024 (UTC)[reply]
This is an attempt to solve a problem that simply does not exist. Just because it's not a problem for you doesn't mean it isn't one. There's plenty of files on here that never will be meaningfully categorized because the file names are to ambiguous. Photographers like you don't really care about the curation aspect of this though. You just want to have the benefit of uploading files to Commons as your own personal project without caring about other people's ability to curate then or anyone else's to find the images. And yes ambigious file names do get in the way of both. Especially people's ability to find the images since most people find images on here through Google Image Search, where file descriptions are essentially worthless. So at the end of the day your just screwing yourself with your attitude about it. Although your also screwing over every one else's ability on here to organize your uploads. --Adamant1 (talk) 10:37, 21 June 2024 (UTC)[reply]
a) People obviously find my pictures, I have new re-uses nearly every day.
b) Wording like "kindergarten" and "Commons as your own personal project" let me end this discussion. I am not prepared to be insulted like this. Stepro (talk) 10:44, 21 June 2024 (UTC)[reply]
@Stepro: People obviously find my pictures, I have new re-uses nearly every day. That's why I said "Just because it's not a problem for you doesn't mean it isn't one." Anyone can come along and derail a discussion by acting like something doesn't exist just because they don't have a problem with it. Have fun sticking your fingers in your ears about it though. You clear know better then the people who are actually do the work organizing files and are effected by it. Maybe mine and Prototyperspective are a little insulting, but not anymore or less then you acting like we are just making up the problem or otherwise participating in this when you clearly have no clue what the issue is or how the proposal would resolve it. --Adamant1 (talk) 11:00, 21 June 2024 (UTC)[reply]
Whether we adopt this particular proposed guideline or not, there is a very basic principle called "the law of least surprise". in building a web site, you want to give people as much useful information (and as little misleading or inaccurate information) as you can. Given that on Commons file names are exposed, they should be as revealing as possible of information that is potentially useful to the end user. - Jmabel ! talk19:05, 21 June 2024 (UTC)[reply]
I think some GLAM-archives rather take the opposite route: they add as little as possible to avoid anything that might be wrong, no dates, no creator, and we end up with endless files that mostly consist for their name, and their ids, but sometimes not much of any substance. I got the impression you participated in these uploads as you approached me once about one.
The advantage of Stepro's approach is that it includes event, date and creator. It's not even clear if that is contrary to the proposed guideline, as at some point it recommended repeating the category name and adding a number. Enhancing999 (talk) 19:18, 21 June 2024 (UTC)[reply]
I think the proposal aligns with the reality of Stepro's history. Stepro does not need punishment due to their filenames - they aren't entirely useless and this type of filename sometimes happens when uploading in bulk - but a few have been renamed, justifiably, because they could certainly be better. This proposal is aligned with our current practices of preferring most useful filenames (with recommendations and guidance, which is missing today) but does not suggest any kind of punishment for less-than-perfect filenames. Consigned (talk) 19:35, 21 June 2024 (UTC)[reply]
Oppose (translate.google) There are no good or bad file names. Even 123456789.jpg is acceptable. The description belongs in the description, the file name is just a technical crutch. There is no point in regulating this. --Ralf Roletschek11:39, 25 June 2024 (UTC)[reply]
The file name is not just technical, it shows on category pages, in the search results when hovering over an image, and is also used by external and the Commons search engine. I wonder why some people are so opposed to this, the only thing gained is a degradation of the quality and usefulness of WMC. Like the other opposers your rationale does not really include any explanation and makes two refuted claims. Prototyperspective (talk) 11:44, 25 June 2024 (UTC)[reply]
This proposal is about policy asking photographers to use descriptive useful titles, not so much about changing titles. Your example is descriptive in that it has the nonphotographic work's author and the work's name in the title rather than "paint03434.jpg" or "my photo of a picture 02353, by photographer Sam Donald in 2024, latest.png". This is not about what people "like better". I think your assumptions are quite disrespectful and not thought through while none of the claims have been addressed by your comment which rather clarifies that you don't see what this policy is proposing. You're still free to name your files as you want, they should just include some descriptive info. Prototyperspective (talk) 12:15, 25 June 2024 (UTC)[reply]
What's the impact for coats of arms? I see many replaced by files names "USA place COA.svg" like names. Is the general idea that people can continue uploading and we just have a guideline that suggests how they could do it better? Or just we terminate accounts and projects that don't follow it? Enhancing999 (talk) 08:35, 7 April 2024 (UTC)[reply]
In my opinion editors should of course keep on uploading, but uploaders who in the past used bad/serialized filenames will now be able to get suggested that they should use more adequate filenames. In the past I was also reverted as I added some files into a bad filenames category.Paradise Chronicle (talk) 15:06, 7 April 2024 (UTC)[reply]
The obvious impact would be that Commons:WikiProject Heraldry and vexillology#Naming of files would no longer say "There is no Commons standard for file naming", rather it could link to the guideline. (And I guess that would incorporate Wikivoyage's guidelines for place names by reference, which seem quite relevant here). And as you say, @Sarang seems to have made "LLL unitname COA" the recommended pattern - the "spelled-out" criterion would recommend expanding COA to "Coat of arms", and the concision criterion would recommend putting the place at the beginning. So I would say "Coat of Arms, Place, LLL" or "Place Coat of Arms (LLL)" are better naming schemes, more similar to the French and Italian styles. Mathnerd314159 (talk) 20:43, 7 April 2024 (UTC)[reply]
The proposal may be more suitable in the case of randomly-named image files that were submitted in some photo contests. Examples are the following image files that were submitted in the more-recent (like 2020s) editions of the Philippine leg of Wiki Loves photo contests, mostly organized by meta:PhilWiki Community:
The images themselves are good in terms of resolution and quality, but they have obscure file names. "File:Coastal lake.jpg" remains unidentified to the point that I cannot categorize it properly. For "File:Humbled by the Mountain.jpg", I resorted to asking the photographer off-wiki (on Messenger) just to determine the specific mountain for categorization purposes. Some file names do not exactly describe the images but only describe them in poetic or flowery sense, which I think should not be acceptable as hindering proper categorization and usability of files. JWilz12345(Talk|Contrib's.)02:22, 10 April 2024 (UTC)[reply]
If anyone wants another example check out the files in Category:Images misdescribed as postcards. In that case there's a bunch of normal photographs that someone decided to name as postcards for some reason when that's clearly not what they are images of. There's no legitimate reason files should be named that way to begin with though. --Adamant1 (talk) 07:18, 11 April 2024 (UTC)[reply]
I'm not saying files shouldn't have descriptions, categories, annotations or structured data to describe the images. Quite to the contrary. The samples here lack much of it. Weirdly people may support the above proposal or complain about it, but don't bother adding or fixing them. Commons is also platform for collaboratively describing images.
File:A Blooming Flower.jpg as name avoids problems we on project chat with some species database. Photographers may not be biologists and should be able to upload images without consulting one before. When even specialists get the species wrong, other information (photographer, id, date, location) would be the more stable filename.
Such a description is fine, actually it is encouraged by the "correct" guideline ("The title given to a work of art by the artist that created it is considered appropriate"). The only issue is that it is a photo of a place without enough specific or precise information to identify the location. So if it was "Humbled by the Mountain (Tenglawan)" it would be better. Mathnerd314159 (talk) 15:26, 11 April 2024 (UTC)[reply]
Comment I think the wall of text now requires a new write-up with a summary. If I counted correctly there are now 9 support vs 7 oppose (assuming Enhancing999 maintains the opposition; at least 3 of the oppose-votes were without rationale or clearly disproven explanation). I don't see why a reasonable baseline policy wouldn't be needed and useful. Would a structured arguments tree (Pro/Con format) help to visualize/provide an overview of the different points made and their respective objections? Re the clearly disproven rationale: file names don't need to be in English per this draft; I would however suggest that if EN is configured as language it could be made to show a specified or machine-translated English title even when the filename (default and url) is different. Currently file names like "flower.jpg" "sdf.jpg" or "Jmse-10-01816-g001-550 hor.jpg" are prevalent and it would be very useful to have descriptive titles when scrolling through a category page for example or searching for files. Much of this policy can already be inferred from the file-moving reasons, so having a policy just provides some guidance and reduces filemoving workload etc. --Prototyperspective (talk) 09:48, 16 May 2024 (UTC)[reply]
Some of the support votes don't really go beyond what we already have, so why do you try to assess some of the reasons, but not others? Enhancing999 (talk) 16:23, 19 May 2024 (UTC)[reply]
It appears that some of the participants who support this are neither active users of Commons nor have actually uploaded files. -- Enhancing999 (talk) 16:35, 19 May 2024 (UTC)[reply]
Now's a good time to follow up on Prototyperspective's comment. What's the right way of moving forward here? Is there sufficient consensus to publish this guideline? Should the proposed text be worked on to try to resolve some of the opposition before gathering feedback again? Consigned (talk) 10:08, 25 May 2024 (UTC)[reply]
I think we can archive the proposal and return to our respective WMF projects. Thanks for bringing the controversy at English Wikipedia about Commons photographers names to the attention of the Commons community and raise awareness about a need to better communicate issues users may have with non-English filenames and descriptions. Enhancing999 (talk) 10:13, 25 May 2024 (UTC)[reply]
This comment says nothing about the validity of the proposal, you're just attacking the participants. Please follow the UCOC and treat all Wikimedia contributors with respect. BTW I'm assuming that your comment was directed at me since you accused me of being a sockpuppet and of not being a real Commons participant, but it might also be directed at others; for your information I have no idea about any ENWP/Commons photographers controversy (do you have a link to that discussion?). Consigned (talk) 10:36, 25 May 2024 (UTC)[reply]
From your comment, I gather you didn't read the discussion about this proposal in full. The proposal was presented as one coming from the English language Wikipedia project to somehow remediate several perceived issues there. Do we need to censor comments on this aspect?
I'm not aware you participated in its elaboration. Maybe you can explain if and how you did and what brought you to this discussion. This would allow me (or others) to better help resolve an issues you may have. Enhancing999 (talk) 10:55, 25 May 2024 (UTC)[reply]
Ah I see, my mistake - I somehow missed that in the initial proposal, which I probably skimmed before going to the draft itself and finding that I supported it. I arrived here just by poking around the Commons Village Pumps. Consigned (talk) 11:28, 25 May 2024 (UTC)[reply]
I don't think there is sufficient consensus to adopt this. I think a good idea would be using it for some time, referring to it whenever you see somebody upload badly named files or when moving files and discussing things on its talk page so it naturally develops and gets changed to be in a better shape. Then it could be proposed again at a later version where any issues are sorted out and corrected. But maybe more people will weigh in, I doubt it though given that this discussion has been open here for quite some time and because of the wall of text and confusing sections here now. (Next time please try to avoid these two things so that more people will participate and things are clearer.) Prototyperspective (talk) 11:35, 25 May 2024 (UTC)[reply]
For what it is worth after such a long discussion, that seems almost to be closed:
Support File naming guideline. Thanks Mathnerd314159 for the research and proposal. It looks good, very useful, also as a guideline to reference to when addressing uploaders who continue uploading files with problematic file names.
I do think that proper filenames are important, no matter how well the descriptions, structured data and categories are. In an overview (like search results in Special Search and categories) you always can see the file name (in MediaSearch: use the cursor to see the URL with the filename, on the bottom left on my pc), but not the other elements, and then it is good to know what the file is about.
A bold proposal: can the controversial elements be left out, can the guideline then as soon as possible be implemented and can the issues/details be discussed later (for instance in the Talk page of the guideline) and then be adjusted piece by piece? As Adamant1 says: Perfect is the enemy of the Good, and then we have at least a guideline with the most important "rules".
I hope that there will also be a short version for end users, who just want to upload a couple of files (which indeed should be linked in the Upload Wizzard). I would already be happy if all filenames would include subject, location and year, as precise as possible, in whatever language that Google Translate supports.
My opinion about some of the discussed issues:
Generally accepted abbrevations does not need to be a problem if the full text is in the description and the title includes at least the subject, location (both fully written) and year.
Scientific (Latin) or ordinary names for organisms? My preference: Files uploaded by "ordinary" people can have ordinary names (do not make uploading more difficult than necessary); those uploaded by people who are familiar with taxonomy terms can have file names with scientific names and preferably have a description including the ordinary name.
English or other languages for general subjects/names is not a problem in most cases, as long as:
there is a Wikidata item for the subject, which has descriptions in many languages,
the structured data in the file are filled in (which might not alway be necessary when the file is in the correct category) and
you are searching with MediaSearch, which is the standard search and I guess will be used by most end users.
There is indeed a problem when a general word (like the Spanish silla/chair) has another meaning in another language. But should we make a "rule" that effects all uploads for these kind of exceptions?
Still one Question: what do you mean by "on CDs"? Compact Disks?
Strong oppose per [1] , there is no need to ban people because they dont wanna spend extra hours to properly name their pile of uploads and "only english names". commons is multilingual. but, Weak support if this becomes just a suggesstion and not a tool to ban people, im ok with that. modern_primatඞඞඞ ----TALK17:25, 17 July 2024 (UTC)[reply]
But I just clarified that this doesn't say "only english names".
Most people don't upload such large amounts and when they do that would be considered and/or a tool to rename many files easily be developed. One can easily rename large numbers of files locally by marking them all and then renaming, but renaming many files manually individually using WMC's file renaming would extremely laborious and take people a lot of time.
You asked somebody on their talk page to name all their files properly please do this in your all uploads when it's unclear what that means and apparently opposing this that would call for the same. Prototyperspective (talk) 17:45, 17 July 2024 (UTC)[reply]
Yeah I do not know where they take it from that it says "only" English filenames. I have also tried to turn an oppose for English language preferred into a support. How many have we come across that were banned for uploading multiple files protected by copyright? I can't name one. So I also don't believe anyone will get banned for uploading files with filenames contrary to the guideline. It would only be nice if people could make the work on commons a bit more collaborative by being more precise with their uploads. Paradise Chronicle (talk) 22:28, 23 July 2024 (UTC)[reply]
Support I read through the proposal and some of the discussion. I think proposed guideline accurately captures current best practices and would be an useful introduction for new users. --Jarekt (talk) 01:16, 20 July 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
First proposal was three support, two against. Second proposal two against. Both has couple of comments. Result from this is no-consensus for adding imagehashes using bots. --Zache (talk) 07:20, 22 August 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I asked this first on bot permission page, where they suggested that I should make this as proposal first.
So, I propose that the addition of perceptual hash (phash and dhash) values will be extended to all images on Wikimedia Commons as Structured Data on Commons (SDC) values. Currently, values are added only to a subset of images, such as images from Finna.
Background
Perceptual hashes are checksums which can be used to identify visually identical images even if they have been scaled, re-compressed, or subjected to minor alterations. Proposed hashes are effective for detecting if the images are identical but they are not effective for detecting similarity in cases involving cropping or rotation changes. Hashes are also implementation specific and in this proposal I am using Python Imagehash library.
Confirm that images in the Finna repository match those on Wikimedia Commons, ensuring higher resolution re-uploads and metadata updates are done to correct images in Wikimedia Commons.
Prevent duplicate image uploads.
Find existing duplicate photos.
Update identifiers pointing to external repositories if they have been changed.
These are common use cases for developers of mass upload tools and usage could be extended for other tools also. Adding perceptual hashes to SDC would enable users to easily access the hash values without needing to download the commons image files first, allowing for wider use of the hashes. Additionally, SPARQL queries can be used to detect duplicate photos. Example query: https://w.wiki/A6qZ
Currently, we have hashes for 94 million photos out of the approximately 100 million in Wikimedia Commons in our database. Plan is to calculate phash and dhash values for all Wikimedia Commons jpg, tiff, png, and webp photos during the summer of 2024.
About 40,000 photos from Finna have phash and dhash SDC values.
Web ui imagehash.toolforge.org and REST API for querying the hashes. Hash database can be also accessed usin SQL via imagehashpublic_p Toolforge user database.
For broader accessibility, adding hash values to SDC is the most straightforward approach. As adding hash values to all 100 million photos on Commons using bots is impractical, I suggest the following approach:
Begin by adding hash values to photos uploaded from GLAM archives and Flickr using bots. This would create a platform for tool creators to match photos between archives and check if a photo already exists on Commons. It would also serve as a shared platform with external parties such as GLAM and Flickr Commons to develop the idea further.
Investigate how to implement better methods for including automatically generated information in SDC without the need for adding these using bots. Other similar automatical values could include mime type, image width, image height, file size etc.
Support: This seems to me to be a good idea. Do you have any idea how you'll handle invalidating the hashes when a user uploads a new version of a file? --bjh21 (talk) 15:56, 23 May 2024 (UTC)[reply]
One solution could be to track recent changes to index all uploads and then set the latest value as "prominent" and the rest as normal if there are multiple values. --Zache (talk) 20:38, 23 May 2024 (UTC)[reply]
@EugeneZelenko: You are actually wrong. If we can calculate similarity by comparing the hashes it contains structured information about the content they represent. --Zache (talk) 14:19, 28 May 2024 (UTC)[reply]
Hashes could not create links between items (regular properties) or external sources (identifier properties), so why they are claimed to be structural? --EugeneZelenko (talk) 14:33, 28 May 2024 (UTC)[reply]
Structured information can contain other data types than URI:s and identifiers, such as numbers, booleans, strings, timestamps, etc. In this case, perceptual hashes contain information about the content's features in a well-defined format. --Zache (talk) 14:59, 28 May 2024 (UTC)[reply]
Support: I agree with the proposal. I already do it for the files imported by User:OptimusPrimeBot. I'm really happy to see new people interested in making things move forward for the perceptual hashes/detection of duplicates. It's still a pain to detect duplicates accurately and this proposal will help to improve the tooling. vip (talk) 22:20, 28 May 2024 (UTC)[reply]
Oppose. There may be value, but there is also cost. My watchlist is sometimes hammered with SD additions such as this SVG file is an SVG file. Make additions to millions of files, and the cost might be millions of seconds of people's time. Glrx (talk) 16:12, 17 June 2024 (UTC)[reply]
I am sure that you know, but you can also change visibility of the bot edits in the watchlist from settings. -- On more general level comment, I understand your argument, however, there is ongoing flow of files all the time and it is normal (ie. there are bot and other automated edits to categories, wikitext fixes, SDC additions) and solution for that it will fill the watchlist should not be banning those edits as it would block improving the metadata of the files, but improving the filtering/grouping of the changes so that only relevant are visible by default. --Zache (talk) 12:21, 4 July 2024 (UTC)[reply]
Question did the already added hashes turn up any duplicates?
Comment Note that the Structured Content team in the WMF has a ticket for something similar phab:T362352 - not on our roadmap for this quarter, but very likely to get attention this financial year CParle (WMF) (talk) 11:52, 16 July 2024 (UTC)[reply]
I planned to close this proposal after Wikimania, where I would talk with people about imagehashing. So this revised proposal is based on that and I would like to get quick poll what people think about it.
Based on the discussion above, there is no consensus for adding images by bot to SDC. One valid opposing opinion was that it would generate too many edits. Based on this current plan is to proceed by cleaning up the dataset, providing API and direct SQL access, and improving documentation which would support the upload tool development. I am also investigating how to publish the dataset for SPARQL via Ontop software. However, I still have one question related to adding information to SDC.
Would it be useful to add information about detected duplicates to SDC?
A very rough estimate is that there are 2-3 million photos in Commons that are almost identical. (Sample images: https://w.wiki/Asxj) The estimate contains many false positives and negatives and legimate duplicates. Added SDC properties would describe the relation between images and how the relation was detected. This would allow users to query duplicate images and support cleanup/organizing tasks.
Oppose. I looked at the earlier query a long time ago, and I just looked at the recent query. I am underwhelmed. TIFF and JPEG duplicates are deliberate and well known. Book titles that vary in capitalization can be found with text searches -- not necessarily to locate duplicates for clean-up but rather for users to locate material they are interested in using (a core function of Commons). If I'm searching for a particular image, then I'm happy if I find two or three or even more. If the titles are descriptive enough, then I might find them. Yesterday, I was looking at Category:Harper & Brothers logos; there are near duplicates there, but if I find one of those files, then I've found all in the category. To measure value, I need to see how much value these properties add and how much it costs. Near duplicates do not bother me. That takes me to another point: is there a need for deletions? So what if Commons has 1 million near duplicate files? If everything works, are we going to burden the community with 1 million DRs? The biggest benefit might be pairing images and merging their information. One image might have a good description but poor source information; a matching image might have a poor description but detailed source information. How frequent is that scenario? I need to see the benefits and the costs. Right now, I'm seeing lots of bot automation with a high human cost but little benefit. Glrx (talk) 14:29, 10 August 2024 (UTC)[reply]
Information that one image is same than some other is needed also to other things to deletions. One relevant use case is just to be able query what is there and filter out duplicates in results. Another one is to be able to sync and compare metadata between files. About deleting images, afaik, my guess is that any deletion would be focused on smaller sets. Ie. on cleaning up specific category/author/collection, not in million photos level. --Zache (talk) 15:17, 10 August 2024 (UTC)[reply]
There are obviously different points consider, but I found
"but if I find one of those files, then I've found all in the category."
somewhat funny, as it tend to add duplicates to the same category, because they hadn't been identified before. The other day, I did find a category full of duplicates, but haven't decided what to do about them. (It was by date of photography category). Enhancing999 (talk) 17:33, 10 August 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Processing deletion requests on empty or moved categories is a very often needed but not very critical task that has to be limited to admins. Therefore I would propose that we introduce a new right that allows trusted users to delete categories, galleries and (if possible) own user pages. GPSLeo (talk) 17:09, 24 May 2024 (UTC)[reply]
Comment The bar for adminship on this project is pretty low. Are there specific people you can identify that you think should have this new right that would not make good admin candidates? The Squirrel Conspiracy (talk) 17:26, 25 May 2024 (UTC)[reply]
I don't think this is technically possible. Per mw:Manual:User rights, it doesn't appear that rights like "delete" can be restricted to specific namespaces. (And given that pages can be moved between namespaces, it's not clear that any such limitations would be effective.) Omphalographer (talk) 03:58, 26 May 2024 (UTC)[reply]
It is currently not possible but we need consensus that we want this feature before we can request the development that is requited to enable such a feature. GPSLeo (talk) 16:36, 26 May 2024 (UTC)[reply]
Of the last 5000 (un)deletions, >90% were files; just 371 (7.4%) were categories, 3 (0.06%) were user pages, 8 (0.16%) were templates, and <10 were galleries. While I have no objections on principle to unbundling deletion rights, this doesn't seem like it would address any deletion backlogs. It would probably be better to focus our energies on cultivating well-rounded users who would make good admins. Pi.1415926535 (talk) 05:34, 28 May 2024 (UTC)[reply]
Support although not technically possible atm, we can request a phab task. Maybe ability to delete everything except files and MediaWiki stuff (similar to eliminator right on some wikis) is a better idea. Thoughts? —Matrix(!) {user - talk? - uselesscontributions} 15:45, 12 June 2024 (UTC)[reply]
Oppose No concept shown. Who appoints them, what is the requirement? Can the delete only, or also restore and view deleted versions? If or if not, how is this helpful, and why don't they become regular admins? --Krd18:02, 20 June 2024 (UTC)[reply]
Oppose No satisfactory answer to my question above. I'd be happy to entertain an RfA from someone that does category work and wants the mop to do categories for deletion closing, though. The Squirrel Conspiracy (talk) 05:54, 30 June 2024 (UTC)[reply]
I could certainly use it. I doubt anyone would give me full privileges just to delete categories though. Nor would I even necessarily want them. --Adamant1 (talk) 06:04, 30 June 2024 (UTC)[reply]
Oppose, a lot of users I've seen have an annoying habit of tagging good alternative titles for categories as speedy deletions (such as old names for a building or alternative names for a place in a different language), it's also not uncommon for people to empty useful categories and then tag them for speedy deletion as "useless empty categories". This user right will only make this type of behaviour worse. We need more useful redirects, not less. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:58, 19 July 2024 (UTC)[reply]
@Donald Trung: You happen to know much redircts effect load on the database like normal categories do? Because if they do have any effect it seems like the amount of categories that currently exist cause a lot of problems with the database and I think you could argue a lot of redirects are totally useless. I know I've seen plenty of them myself that probably aren't worth retaining. Putting aside ones for alternate names for things in different languages of course, which are probably worth retaining but at least from what I've seen make up only a small amount of redircts. --Adamant1 (talk) 15:31, 10 August 2024 (UTC)[reply]
@Adamant1: The complaints we get from the sysadmins don't relate to the number of categories, but to the number of category links: phab:T343131. That is, the number of connections between pages and categories that they're members of. Nothing should be a member of a category redirects, so category redirects are no more expensive than any other kind of page. If we wanted to make category redirects cheaper, removing them from Category:Category redirects would save 760,000 links, as would turning them into normal redirects. --bjh21 (talk) 17:14, 10 August 2024 (UTC)[reply]
Support No issues with the concept. The opposers don't seem to oppose the concept, just the implementation, which can be developed, and adjusted later on as needed. And if this right is abused, we can roll it back. --P 1 9 9✉12:35, 12 August 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
@Enhancing999: Shall I be in charge of this proposal then? It has overwhelming support. Attracting inappropriate comments by admins isn't that adequate for justify withdrawal. Instead, COM:AN/U should be used. --George Ho (talk) 05:47, 12 July 2024 (UTC)[reply]
Please don't edit my comments. In any case, the discussion ran its course, so this can be closed. We don't need it to be open for admins to make inappropriate comments. Feel free to redact any admin comments. Wonder why all other admins read them and only revert me. Is there some rule that admins are exempt from reversals? Enhancing999 (talk) 05:53, 12 July 2024 (UTC)[reply]
I did not want this to be closed as there are concerns they had not yet been addressed on this point. This is nothing against you I just want to leave this open to discuss with the users who raised the concerns. GPSLeo (talk) 06:21, 12 July 2024 (UTC)[reply]
It's in the nature of proposals that they can be withdrawn. The problem with your admin intervention is that you are censoring my contribution whereas you dont bother censoring another administrator's inappropriate comment. Implementation questions can be discussed elsewhere or part of separate proposals. Enhancing999 (talk) 06:33, 12 July 2024 (UTC)[reply]
Support Per my comments in the Village Pump discussion. Cross-wiki uploads are clearly an issue and making it only available to autoconfirmed users seems like the best option at this point baring anything else. But it doesn't seem like there's a workable solution for now beyond that. --Adamant1 (talk) 10:40, 30 June 2024 (UTC)[reply]
Support That research report confirmed what we already knew: that cross-wiki uploads are primarily used for out-of-scope promotional images and copyvios. Unless massive changes are made (restricting to experienced users, removing it from User: and Draft: namespaces, etc), the only solution is to turn it off. Pi.1415926535 (talk) 20:45, 30 June 2024 (UTC)[reply]
Support – Re-reading the study, the one you're proposing isn't listed as one of WMF's recommendations. Still, this should stave off un-autoconfirmed users (of any wiki) from abusing the cross-wiki upload tools. I can't help figure out why WMF doesn't list the idea you're suggesting. Maybe WMF wants all projects to be too newbie-friendly or something? Anyways, I'm thinking about creating a Phabricator ticket if there's overwhelming consensus favoring this. George Ho (talk) 21:02, 30 June 2024 (UTC)[reply]
The review of the study by the Commons community mostly came to the above conclusion. Several recommandations in the study could be summed up: do what UploadWizard already does. Enhancing999 (talk) 10:42, 1 July 2024 (UTC) Comment withdrawn Enhancing999 (talk) 05:27, 12 July 2024 (UTC)[reply]
@George Ho Just FYI, the study did not suggest ideas on purpose, since WMF thinks policy decisions should be taken by the community, and that there should be no interference from WMF about these decisions. Sannita (WMF) (talk) 11:09, 1 July 2024 (UTC)[reply]
Reading over the comments in that ticket gives me the impression that this might one of those things that needs a lot of follow up and push back on our side about. --Adamant1 (talk) 11:18, 1 July 2024 (UTC)[reply]
Support. If need be, we should just use an edit filter to prohibit the cross-wiki uploads. The upload wizard on Commons is capable of guiding complete newbies as to whether or not they can upload a file (in most cases). But the way that visual editor works on other wikis is insufficient, and leads to a lot of work from volunteers here. — Red-tailed hawk(nest)04:21, 2 July 2024 (UTC)[reply]
Support With the current situation this is needed. But we should allow uploads during editing of Wikipedia when the full UploadWizard is embedded there. GPSLeo (talk) 12:08, 2 July 2024 (UTC)[reply]
Comment This proposal should not be an internal navel-gazing exercise only. This proposal should be a broader RFC that is clear to all wikis and allows all wikimedians the ability to comment prior to implementation. Yes this is a Commons issue, though every user at the wikis uploads is a de facto Commons user, and every wiki is a direct stakeholder and impacted by this. There are means to highlight this proposal to the wikis seeking comment, and that should be undertaken. — billinghurstsDrewth11:38, 10 July 2024 (UTC)[reply]
@Enhancing999: Where did I say that this was not the place for the proposal. I said that the proposal needed to be more broadly put before the wider communities. That would be through promoting this proposal to those communities and asking them to comment here. There is nothing urgent in having this conversation closed and implemented. These communities and their users have a right to be engaged; it is not solely for Commons users to discuss; this will have consequences cross all the wikis. Why are you against broader consultation? — billinghurstsDrewth11:30, 12 July 2024 (UTC)[reply]
This is a Commons forum, the discussion was announced and even advertised on VP and should bring an incremental improvement. Possible implementation issues can easily be reviewed separately.
@Enhancing999: Stop making things personal. I act here upon the consensus of the community. I definitely did change that filter, to slightly increase the size of images, and that was done following an issue being raised, and addressed in my role as an administrator. It does not target individuals; it does not target people's newness or not; it solely is aimed at files that were problematic. It was done following research and reported back to the community.
Yes this proposal was announced at our village pump, and that is still internal to Commons. If we are putting in a crosswiki restriction that has large impacts upon all WMF wikis (WPs, WSs, WNs, WQs, ...) we have a responsibility to address that to those WMF sister communities, especially when it is within our charter to host files for them. There is no urgency to act, there is nothing new, simply a report on uploads, so two weeks, two months, +++ has no substantial impact on something that has been in place for years. There may well also be system-wide solutions that are better than abusefilters, and such a conversation is always worth having. — billinghurstsDrewth09:30, 13 July 2024 (UTC)[reply]
Support It's a concerning report, and its results are not unexpected. This action would seemingly help stem the flow of copyright violations and promotional material, so it's a step in the right direction, albeit unfortunate. — Huntster (t@c)03:12, 11 July 2024 (UTC)[reply]
Strong support I hold the (probably extreme) view that xwiki uploads in general are a net negative and we should just scrap 'em, but this is a sensible restriction. Queen of Hearts (talk) 04:58, 11 July 2024 (UTC)[reply]
We should inform other projects before we implement this, not on the day it goes live, or four days later in the Monday Tech News.
What's going to happen to the existing "Insert file > Upload" option on Wikipedia edit boxes? Will it neatly disable itself for non-autoconfirmed users with no settings changes required at Wikipedia projects' end? If not, will the button give a user-friendly explanation of why the user can't upload their file, or a technical error message?
Are there any instructional pages on Wikipedia projects that refer to this upload method, which would need to be updated? Belbury (talk) 17:06, 11 July 2024 (UTC)[reply]
There is Commons:Cross-wiki media upload tool, too, created years ago. We are having a merge discussion at the talk page (of the newer page mentioned above). Translation is disabled on the newer page until the merge (or any other conclusion to the discussion). The older page is translated into 10+ languages, by the way. whym (talk) 04:39, 4 August 2024 (UTC)[reply]
I agree with billinghurst. We should not only inform other projects, instead, we should consult with them and there should be a broader RFC (perhaps on metawiki or creating a separate RFC page on commons). SCP-200007:07, 12 July 2024 (UTC)[reply]
It's worth mentioning that there was an A/B test conducted in 2015 which showed a slight improvement in the quality of uploads if the restrictions were explained in more detail and/or the user was required to take more actions. Nevertheless, the conclusion was
The tested interface options weren't very successful in improving the quality of uploads, by new users or otherwise. The upload dialog was reverted to using option 1 for now.
I find that conclusion questionable, if not misguided, given that the numbers did show an improvement, albeit within 10%. Still, a lot of effort of users fighting copyright violations would be saved. It's also not specified on the test page what is the share of good uploads for new users not using the cross-wiki upload tool. E.g. if this number is 56%, and the numbers for a detailed and the current versions of the dialog are 46% and 36%, that's a big deal.So, I believe UI improvement should be a major focus here. Correct me if I'm wrong, but I don't see any fundamental difference between a website and a dialog apart from the level of detail and the number of steps required from the user. (If the improvement doesn't come from increasing those, then where else?) I'm not saying there is anything wrong with the initiative to require the autoconfirmed right, but that's basically an admission of inability to provide adequate UI. There is also a Phabricator task that suggests improvements to the dialog, phab:T249591.Also, I'd like to know more technical details. @GPSLeopointed out that "Other tools allowing direct upload from other Wikis are not affected by this". Could someone please clarify how the software would differentiate between uploads made by mw:Upload dialog and other tools? Because currently from what I see in the code it seems that all cross-wiki uploads get the "cross-wiki-upload" tag. Or would that be up to the tool maintainers when they receive a task to work on? Jack who built the house (talk) 13:40, 13 July 2024 (UTC)[reply]
This is a hotfix if there are improvements to the tool we might remove the restriction. But the testing of the new version should first be done by more experienced users. Other tools use the API in a total different way and therefore have other or no tags. GPSLeo (talk) 13:54, 13 July 2024 (UTC)[reply]
Other tools use the API in a total different way and therefore have other or no tags. What is different? Or could you provide an example of another such tool? The request that the upload dialog makes is quite generic, based on the contents of query.uploaddialog in the response to https://commons.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=uploaddialog. There is no indication there that this is a request made by this specific tool. Maybe the distinction here is uploads where credentials are provided by the browser (e.g. based on mw.Api) and uploads where the user supplies them explicitly, e.g. via OAuth? Jack who built the house (talk) 14:10, 13 July 2024 (UTC)[reply]
Comment I put together some quick statistics at File:Commons cross-wiki uploads 2016-2024 - deletion.svg. A break down of cross-wiki uploads. Red means deleted, blue means non-deleted (as of 2024-07-14). A few initial comments: 1) It seems safe to say a majority (>50%) is not deleted, and the ratio of bad uploads seems fairly stable over the years, if you take into account that more recent copyvios are less likely to be discovered yet. 2) What happened around 2016Q2-Q3? 3) The code is available at [2][3]. Feel free to fork it. I think it took 5-7 hours to run on Toolforge. 4) If someone is inclined to verify and/or investigate the data more, raw data is available at [4]. (~48 MB, compressed - please download it if you want, I don't intend to keep this file permanently.) whym (talk) 05:11, 14 July 2024 (UTC)[reply]
The problem is that we do not have a metric to see how many of the not deleted files are reviewed. I had a look a random sample of 50 files uploaded in January. 26 of these files are okay. 10 require VRT confirmation and 4 are clear copyright violations. 9 files are out of scope. I think the number of deleted files decreased because of insufficient capacities to review these files and not because there are less problematic files uploaded. The moderation needed in other fields dramatically increased in the last years. For example the amount of IP edits doubled in the last five years [5]. GPSLeo (talk) 06:21, 14 July 2024 (UTC)[reply]
@Enhancing999: Exactly. That's why I don't understand the proposal. What would not be uploaded that is not already filtered now? Is it only that some Wikipedia users would not see the cross-wiki option on Wikipedia, instead of having their upload attempts disallowed by the Commons filter? That could be less frustrataing for those users on Wikipedia, but the result is the same for Commons in that the files are not uploaded, no? Concretely, can you, or anyone, please provide at least one example (or preferably several, if there are any) of a file that was uploaded after June 2016, deleted or not, but that would not have been uploaded under the proposal? -- Asclepias (talk) 18:17, 20 July 2024 (UTC)[reply]
The new UploadWizard that asks multiple questions seems to reduce the number of uploaded copyright violations slightly. So guiding the people from the one click form the the wizard would help. GPSLeo (talk) 18:35, 20 July 2024 (UTC)[reply]
Support Based on my experience as a patroller on my local wiki, it is easy for new users to upload some files with copyright issues here through "cross-wiki upload". As mentioned above, the files that remain here do not necessarily have no copyright issues - it may be that no one has discovered that there are copyright issues, or the processing efficiency here is too low (for example Commons:Deletion requests/File:Chang'e-6 Landing Region in South of Apollo Basin.jpg, this guy is the third time). On the contrary, veterans will clearly understand the conditions of file copyright, and will know how to upload files through the upload tools here (traditional forms or wizards) instead of using the "oversimplified" tools on the editor of that local wiki. If possible, the upload function here can check the user's user groups in other business wikis (not including like mediawiki and metawiki, etc.) to quickly judge the user's editing skills (the user groups of other wikis may reflect their general editing level on those wikis, exclude some disposable new users, and accept veterans who are proficient in editing other wikis but come to commons for the first time). --Cwek (talk) 03:09, 16 July 2024 (UTC)[reply]
Support, one time I saw a cross-wiki upload that was a copyvio from Facebook. Limiting them will reduce the workload for patrollers. ToadetteEdit (talk) 17:26, 17 July 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
How about adding to that line that non-registered, or non-logged-in users see under the file history? Something like this:
"You cannot overwrite this file until you log in. See free registration."
Free registration would be linked.
See: The curse of knowledge. Wikimedia is mistakenly assuming that readers (the vast majority of which are not registered) will just magically know that any registered user can upload or overwrite files. As far as the reader knows, they may assume there is some special group of editors that do all the uploading.
I have often wondered why people do not update files that obviously need updating. And that have the source page linked from the file page. I think I now know one big reason. --Timeshifter (talk) 12:43, 12 July 2024 (UTC)[reply]
Actually, many logged-in users cannot overwrite files anymore. See COM:OVERWRITE -- it either needs to be your own upload, or you need to have autopatrol rights, unless it's a file marked to allow updates. Agreed though that there could be at least a link to further information, if not a fuller explanation directly. Carl Lindberg (talk) 13:32, 12 July 2024 (UTC)[reply]
I read that there are only 7,499 editors with autopatrol rights:
Is there a way to mark an image as eligible to be overwritten by any logged in user? There are many images that needed to be updated every year or 2 from the same source.
And will the upload software respect that permission? If not, it needs to be created. Wikipedia and the Commons are based on getting as many people as possible involved. --Timeshifter (talk) 15:11, 12 July 2024 (UTC)[reply]
Thanks. I am a longtime Commons editor and never really understood all of this. I think the word needs to get out. Some kind of notice on every file page:
"If you believe that any logged-in user (no special rights) should be able to update and overwrite this image with one from the same source, then please place {{Allow overwriting}} on the file page.
Can anybody put that template on a file page? That could be a problem. Maybe change that and leave this message instead:
"If you believe that any logged-in user (no special rights) should be able to update and overwrite this image with one from the same source, then please contact the autopatrol forum (linked) to place the {{Allow overwriting}} banner on the file page."
Or some other forum link. Maybe notify all the users with autopatrol rights to watchlist that forum, or visit it when they have time to help. --Timeshifter (talk) 18:18, 12 July 2024 (UTC)[reply]
We're dealing with two aspects of overwriting here: one, whether a particular user is authorized to do so, and two, whether it is permitted under the Commons guidelines: COM:OVERWRITE. Perhaps it is nice of us to give more information about that guideline, but I disagree that we should be urging people to place the override template everywhere they can, because this grants technical authorization, without addressing the guidelines. Perhaps the autopatrol right is there to ensure that overwriters are well-informed on the rules. Elizium23 (talk) 18:36, 12 July 2024 (UTC)[reply]
{{Allow overwriting}} could link to COM:OVERWRITE. But one assumes that an autopatroller had reason to add the template to a file. {{Allow overwriting}} says that "This template can only be set by users with patrol rights. Files with this template on the file page can be overwritten by users without autopatrol rights."
When I tried to add {{Allow overwriting}} to a file, nothing shows up. I guess my user rights of file mover and image reviewer are not inclusive of autopatrol.
Can someone give it to me? There are thousands of OWID PNG images, for example, that anybody could update if {{Allow overwriting}} could be added to those file pages. The OWID SVG images are problematic nowadays since the upload software blocks them due to there being @import URL in the SVG.
Does {{Recent}} or {{Current}} allow anybody to overwrite a file? They should, or they don't do much good.
The documentation for {{Allow overwriting}} doesn't show what the template actually says when placed on a file. What is it? I checked a few files it was supposedly transcluded on and could see nothing. Can someone link to a file with it showing, so I can see. --Timeshifter (talk) 19:11, 12 July 2024 (UTC)[reply]
The template does not have any text. The template is only for the filter as we have no other way to tag these files. There was a one time bot run adding the template to pages with the {{Recent}} or {{Current}} template. This is needed as these templates can be added by everyone and not only be the original uploader or users with patrol rights. As license reviewer you have patrol rights. GPSLeo (talk) 19:28, 12 July 2024 (UTC)[reply]
This template can only be set by users with patrol rights. -- is that a statement of technical limitations, or a statement of guideline-based limitations? Elizium23 (talk) 19:32, 12 July 2024 (UTC)[reply]
That is rather weak protection, since the template's only purpose is to add a category, so the abuse filter is only looking for the cosmetic front-end, rather than the actual nuts and bolts. Elizium23 (talk) 19:48, 12 July 2024 (UTC)[reply]
Okaaay... so another loophole is revealed. This is beginning to make sense, but don't y'all think that it would be easier on people like me if this stuff were documented? I can understand the need to use a patchwork of templates/cats/filters, but at least, you know, put some comments in there so that we can mentally glue this back together. Elizium23 (talk) 20:30, 12 July 2024 (UTC)[reply]
Jeff G. Something like: This file can be overwritten by any logged-in user. See: COM:OVERWRITE."
If anyone can add {{Recent}} or {{Current}}, then there needs to be a notice with them that they are awaiting approval from a patroller. And when/if that happens they will receive the {{allow overwriting}} tag, and the templates will change to {{Recent-approved}} or {{Current-approved}}. --Timeshifter (talk) 19:55, 12 July 2024 (UTC)[reply]
The {{Recent. Approved}} banner could only be added by patrollers, and would say something like this:
"This image is expected to always be the most recent one. Any logged-in user can update it when needed. Preferably from the same source. See: COM:OVERWRITE."
{{Allow overwriting}} "can only be set by users with patrol rights." So I guess {{Allow overwriting}} should be transcluded into {{Recent. Approved}}. It also should only be allowed to be set by patrollers.
I would not add a visible box as the information is only relevant for a very small amount of people visiting the page. We had many complaints that file pages with many templates are to confusing. But we could solve this by making the box only visible if the user is affected (logged in and not autopatrolled) using some Javascript. GPSLeo (talk) 18:30, 17 July 2024 (UTC)[reply]
That is an improvement. But it does not help with my main request of telling non-logged-in users how they can help. I just added {{Recent}} and {{Allow overwriting}} to all the maps (except the templates) in Category:English-language SVG choropleth maps of the United States made with templates. I created all those maps using the templates shown there. I have been trying to get people to help out with creating and updates. On Wikipedia anybody logged-in or not, can help. But not on the Commons. My understanding is that changed in September 2023 (see Commons:Overwriting existing files). I am trying to fix that.
I can not tell by looking at those map pages which ones allow overwriting, and which do not. I want non-logged-in users to know this too.
Many Wikipedia readers look at file description pages. To see what the sources are, for example, and whether they are believable. So we are missing out on getting those readers to help out.
The only thing non-logged-in readers see is "You cannot overwrite this file" under the file history. That is totally unhelpful. I don't know why I am having a hard time selling this. This is the whole point of Wikipedia. An encyclopedia created by everybody. Are we going back to Nupedia where only an elite class of editors can help out. At least as concerns updating images. This is why many images in Wikipedia articles are not being updated. I was wondering why this was happening. From Nupedia article: "It had only 21 articles in its first year, compared with Wikipedia having 200 articles in the first month, and 18,000 in the first year."
Just an idea 💡, but wouldn't it have always been a better idea to just block the ability to overwrite by either specific problematic users or on specific files. We already have templates that prevent files from being overwritten and it's already possible to partially block users from doing specific things, so it would make more sense to partially block a handful problematic users rather than millions of users. We could simply file a Phabricator ticket 🎫 for that and when that is technically possible reverse the earlier bad decision to block all new users from overwriting, or at least change it to an account with a number of edits or days since registration to keep the vandals out. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:52, 19 July 2024 (UTC)[reply]
That seems bad to block millions indeed! But perhaps the real issue is that far too few editors have been granted autopatroller in the first place! For me, I'd say that the risk and impact of overwrite by uninformed/uninitiated/malicious users is high. If our guideline dictates that overwriting is mostly to be avoided, then we should err on this side. As a parallel, on other projects, template vandalism has high impact and it's more difficult to detect, and so there's a lot of proactive template protections done, and indeed there's a template editor userright.
Perhaps we can consider granting autopatroller proactively, to nearly every trusted uploader. Let's not wait for them to request or beg. In fact, its name deceived me and I believed that it was a userright automatically granted by the MediaWiki system like autoconfirmed is! So I'm not sure I would support @Donald Trung's verion of the phab ticket before we consider this as a counterproposal. Elizium23 (talk) 20:50, 19 July 2024 (UTC)[reply]
It wasn't just a few bad users, it was most users -- and most of them well-meaning. The large majority of overwrites were against policy. Overwriting a file is really not that much different than deleting it, and we carefully manage deletions. A file is not the same as a wiki article, at all, but that is (understandably) the way a lot of users think of them. It turns out to have large problems, and problems that there are virtually no "watchers" for to correct mistakes. So yes, it was intended to block most users -- the preferable way is to upload a variant under a new filename, and switch the usage -- then other wikis have the choice of the old and the new version. The relatively few files that are intended to be updated can be marked that way. Carl Lindberg (talk) 00:07, 20 July 2024 (UTC)[reply]
OK. I guess then instead of "You cannot overwrite this file" it could say:
"You cannot overwrite this file until you log in, and not until you have overwriting rights. Otherwise, you can upload a variant under a new filename."
We have to tell them something useful, and try to recruit their help.
I gather that there is trepidation even to mark some images as allowing overwriting. Maybe only allow overwriting images that have a specific source with regularly updated images. Such as OWID images. Our World in Data.
The "Allow overwriting" banner for those images would clearly say that the image must come from the same source, and that using other sources will get the user blocked for awhile, or indefinitely if necessary.
Clindberg You wrote: "Agreed though that there could be at least a link to further information, if not a fuller explanation directly." That was concerning what to add to "You cannot overwrite this file."
Can you do that? I just added {{Current}} and {{Allow overwriting}} to the many image charts in this article I started long ago:
And is anybody going to have {{Allow overwriting}} actually SAY SOMETHING. It is pretty useless to the average Commons reader or editor unless people know that they, as any Commons reader or editor, can update the image as just a regular, non-super-elite Commons editor. Just by logging in.
I no longer have the time, energy, or health to update the images I have uploaded. Let alone the many others that need updating. --Timeshifter (talk) 11:07, 31 July 2024 (UTC)[reply]
GPSLeo. Concerning {{Allow overwriting}} you wrote: "But we could solve this by making the box only visible if the user is affected (logged in and not autopatrolled) using some Javascript."
That would be useful. Can you please do that? I do not see the need to block autopatrollers from seeing it. I did not even know I had autopatrol rights until this thread.
You said the reason you preferred this is the proliferation of templates. I don't think a one-sentence template is a problem. Does {{Allow overwriting}} only apply to autoconfirmed users? If so, here is the sentence:
I don't see the need to limit its view to logged-in users. Then you don't need Javascript.
Maybe we need to limit overwriting to an intermediate autoconfirmed user (as suggested elsewhere) with 5 edits (or whatever). Then the sentence would say:
There needs to be a better box than is currently used for {{Current}} and {{Recent}}. The text needs to wrap completely around the icon. The icon should not be in a separate cell. The icon should be at the top left or top right corner.
Such a banner would help with the complaints about there being too many templates on file pages. Because the templates would be narrower. And even when there are several templates, the total height of them would not be nearly as much. --Timeshifter (talk) 13:12, 5 August 2024 (UTC)[reply]
More appropriate MediaWiki translation structure for protectedpagetext templates
Hello, so despite MediaWiki:Protectedpagetext being one of the most seen interface messages on Commons, it has surprisingly few translations, nearly all of which are outdated. This is because of a few reasons:
To simplify the experience for translators, I'm proposing the following changes. I tested some changes on Beta Commons, most notably the introduction of a "translate this page" message (you can try editing [6] while logged out to see it, also try changing the interface language to British English) and the use of the translate extension. This should lead to more translations. I've only done this for the semi-protected template, but we can extend this structure to the other templates easily. Then in the documentation, we can tell the translator to create the mediawiki talk page (MediaWiki talk:Protectedpagetext/xx) and make an edit request. Of course this is not a complete concept, but it is better than the current (abscence of a) solution. Thoughts? —Matrix(!) {user - talk? - uselesscontributions} 06:52, 2 August 2024 (UTC)[reply]
For specific actions you execute, you earn points that rank up your level. This could motivate users to keep contributing. Points could be earned for files in use, promotions as Quality Image or Featured Picture, and contributing for a comfortable climate, or by helping other users.
The idea might seem unconventional, but I would like to know what the point of view is here. :)
Support overall but the details are debatable. This is why I was requesting making the Leaderboard and Achievements pages of the Commons app available on desktop too and then extending these to also consider other metrics all of which are similar to what you suggest here and/or could be used for such. Note that points can incentivize problematic things like adding media to lots of Wikimedia pages where they aren't useful, nominating way too many pictures, and so on. It's not an unconventional idea, it's quite logical and plausible that such things can motivate users and lots of other sites have such to facilitate user contributions for good reasons so nothing about it is unconventional. Prototyperspective (talk) 11:59, 5 August 2024 (UTC)[reply]
If we do anything like this, we need to be very careful to structure it in a manner where you cannot score points by doing things that are, in fact, counterproductive. We have had bad experiences such as a contest for adding "depicts" that rewarded adding bad "depicts" values to an image, or flipping back and forth over and over between a pair of values. Plus, we also need to be aware that whatever we reward will probably be done more, even at the expense of other things being done less.
Also, it needs to be an opt-in system. I'm sure I'm not alone in not wanting my actions here "scored" against some more or less arbitrary set of criteria. I want to work on what I think is important, not what some algorithm things is important. - Jmabel ! talk21:56, 5 August 2024 (UTC)[reply]
Oppose Sometimes gamification has benefits, but there's a huge risk of people making unhelpful edits just to rack up points. There's already enough ways to reward people for their contributions anyway. Plus I'm also not a fan of how things like edit counts and length of memberships are usually used on projects like these to either give people a pass for bad behavior when both are high or demean new users when they are low. Do we really need yet one way more thing people can do that with? Probably not. If people want another example of where this can and often does go wrong look into how many images are uploaded by people participating in Wikiloves Monuments events that just end up getting deleted as COPYVIO. A good percentage of the time people just participate in the events for clout, which leads to more work on our end. Anyway, If anything we should get rid of edit counts and account creation dates on the User contributions page. --Adamant1 (talk) 23:20, 6 August 2024 (UTC)[reply]
I had the idea on creating something I would call "Wiki Loves Allstars" or just "Wiki Allstars" where there are badges for thinks like "take photos of 100 differnt lakes" for one level and "take photos of 1000 lakes for the highest level" or "take photos of all townhalls in Berlin". But that is hard to count with the category system, that would only work with structured data. GPSLeo (talk) 05:17, 7 August 2024 (UTC)[reply]
Oppose As we know from experience with FP, QI, Wiki Loves xxx, Photo Challenge etc.pp., more competition among users does not necessarily add more quality where this is really needed, but instead more drama potential where it's definitely not needed. --A.Savin06:14, 7 August 2024 (UTC)[reply]
These are all about competing candidates for some recognition. But gamification mechanisms do not necessarily involve these – people simply get stats for their positive contributions and maybe things like badges based on them, so unlike these competitions there aren't 'winners' and 'disqualified or nonwinning' entries. One could build it to precisely increase quality where this is really needed, there is not one kind of gamification and maybe that's the wrong term here anyway.
Secondly, why doesn't WMC abolish these photo challenges then? I think they are distracting, misrewarding and misplacing focus – by now there are photos for nearly everything (at least when it comes to what these challenges are about). At the same time, illustrations are missing for very many even quite large Wikipedia articles even when those would be much more educational and helpful for readers to understand the subject. Currently, we have stats & leaderboards for the wrong or too simplistic things (like edit counts) and challenges for things that aren't that constructive (anymore). Building this more deliberately would enable a more nuanced and intentional approach that facilitates the site to become more useful, close gaps, keep people engaged or to join, and raise quality. Prototyperspective (talk) 16:54, 15 August 2024 (UTC)[reply]
Opposeat least for now. Similar concern with Adamant1's. The intent of the idea is good, but only invites media files that will eventually be either speedily-deleted (if either obvious stolen Internet pictures or out-of-scope personal or self-promotional files) or nominated for deletion (if the files show recent monuments from 100+ countries that do not allow or permit commercial panorama exception). Provided that around 50 more major countries (the likes of Romania, Philippines, Taiwan, Indonesia, and/or UAE) reform their laws to accept commercial uses of their public buildings and monuments (buildings+3D works at least), and that we gain the ability to efficiently filter obvious COPYVIOS or out-of-scope files, I'll be open to this suggestion (at least "weak support"). JWilz12345(Talk|Contrib's.)08:28, 7 August 2024 (UTC)[reply]
Comment short of any broad gamification, I think it would be great if someone wanted to put in the work to create targeted, judged competitions of various sorts. E.g. one specific to self-taken pictures suitable to illustrate some selected set of Wikipedia or Wikivoyage articles that currently lack illustrations (or that lack good illustrations). That might be specifically confined to ones where we know there shouldn't be an FoP issue. Or a judged competition to make new gallery pages (or to improve ones that currently have ten or fewer images). The issue is to have a group willing and able to (1) set an appropriate goal, (2) publicize the competition, and (3) judge the results. But they need to be things focused on quality, not quantity. - Jmabel ! talk18:50, 7 August 2024 (UTC)[reply]
Comment, I'm all for user recruitment and user retention and I genuinely think that there could be good models for gamification, but this would have to be an opt-in system. Overall, the best "prize 🏆" is that you know that your educational works will help other people learn new things, so I can't fully support such a system. However, the main issue with an opt-in system is that it won't have a wide reach, it kind of reminds me of that Wikipedia "video game" where new users can get points and rewards for doing things, while writing this comment I found it here where this video game is called "The Wikipedia Adventure", I believe that it's some sort of tutorial game and that could be helpful for newbies, but there are unfortunately also a lot of negative side-effects to gamification. We already have competitive games at the Wikimedia Commons with even real life rewards and even cash prizes, namely photo challenges.
This is why I’m glad Jimmy Wales has taken a hands-off approach to WM in recent years instead of using it as a vehicle to advance some weird ideological agenda like Elon Musk and Xitter or Larry Sanger and his half-dozen anti-Wikipedia pet projects. Dronebogus (talk) 07:58, 10 August 2024 (UTC)[reply]
{Explanation for why these two things would be the same missing} To answer your question, for example because it would motivate people, make contribution more engaging, retain contributors, and increase the quality or availability of content. NFTs and investors have nothing to do with this at all. And constructive contributions quantifications are exactly in line with being a nonprofit and a diametrical approach than monetary return you refer to with NFTs, investors and enshittification. This would address enshittification if anything. For that and in general, it wouldn't be good to positively acknowledge things like quantity of files uploaded – instead one could show number of files in use, number of original files in use, and number of files fulfilling media requests (closing any of the many gaps in free media). There are potential problems like people putting files into use that are not adequate but I don't think it would be a large problem and it can be addressed. Prototyperspective (talk) 16:32, 15 August 2024 (UTC)[reply]
Oppose as well, as per Adamant1. I have once participated in a Fandom-Wiki, where gamification was included, and it led to stupid things like awards for editing 100 articles the same day, and for editing at least once each day for a year. Awards for uploading images, for creating stubs, etc. While I think that the 10 most active users were genuinely interested in improving the content, we were competing for who got the most awards; and that may have been intimidating for newcomers who got demeaning starter awards with little chance to "catch up" on the leaderboard unless they rush-edited their way into it, or unless the big fish got lazy. At least nobody patronized or bullied the "lower ranks", but it was a pretty little harmonious community after all. The most benefitial effects for gamification of a wiki are: a) starting an entirely new wiki from scratch, quick. Or b) improve newcomer retention (and then you must cut off scoring rather early, to make clear that the game is not the purpose). --Enyavar (talk) 12:28, 14 August 2024 (UTC)[reply]
What makes you think the gamification would be similar to Fandom Wiki's instead of well-thought out? And it is not intimidating for newcomers but engaging and motivating if they get badges for reasonable tasks. Why would the gamification points be the purpose, people see quantifications of their contributions, and most wouldn't see any sense in trying to get the points for the points sake with nonconstructive edits which would quickly get detected anyway. Prototyperspective (talk) 16:19, 15 August 2024 (UTC)[reply]
Oppose any kind of "For specific actions you execute, you earn points that rank up your level" system for risking perverse incentives from the minority of players who care more about the points than the actions. I've recently been clearing up behind this year's meta:Wikipedia Pages Wanting Photos, where novice users are offered prizes for adding as many Commons images as they can to Wikipedia each July and August; it means well, but you can guess what the side effects are.
Listen: learn to differentiate. There is not one gamification and one type of way and type of platform to implement it. This comment just makes clear how unfounded and irrational these votes have been. Prototyperspective (talk) 09:40, 26 August 2024 (UTC)[reply]
The other day someone told me that I was probably working in a particular area just to easily increase my edit count. Not that I was, but some people do have that mentality and thing like edit counts are clearly a point of contention sometimes. Why add other stuff on top of it? I don't really feel like getting insulted by some thin skinned user just because I happen to get some stupid badge as part of normal editing. Although things like that could be mitigated by making the gamification private to the user, but then it kind of defeat the purpose to do the gamification that way. Regardless, we should be doing things to decrease the toxic and petty reactionary nonsense on here, not increase it. --Adamant1 (talk) 11:44, 26 August 2024 (UTC)[reply]
Then people don't look at irrelevant edit counts when considering other people's contributions which is just one way this can be used alongside for example motivation and general interest in one's own contributions. I think the case you describe is / would a very rare case and isn't a problem and when it comes to userfriendliness the least significant issue. Not only does such an example carry less relevance when it comes from you by whom I have heard many insults including against me and which may have facilitated this rare example you cite, but when a welcoming atmosphere is the subject, this would very much increase the positive atmosphere here and provide more feedback to users. The clearest cases of what could be described as toxic and petty reactionary nonsense that I witnessed here came from you so this is a quite strange comment.
In any case, I came to comment replies in this thread too late and the starting comment is quite suboptimal, for instance in that it's about monolithic points rather than different kinds of stats that one can look at separately. Prototyperspective (talk) 12:24, 26 August 2024 (UTC)[reply]
I mean, sure I can be petty sometimes. That's a different then if the pettyness is specifically based on arbitrary things like a person's edit count or gamification though. Which is what my example and this discussion has to do with. Personally, I don't tend to insult, put down, or badger people based on arbitrary things like how many edits they have or how long they have been a user for. Maybe that's your jam though. I don't really know or care, but it is an issue and that happens pretty frequently on these types of projects.
Even outside of Commons literally 99% of the way people handle things on Wikipedia is by looking at a users edits, account age, and then acting according based mostly (if not totally) on that information. Same for Wikidata and I image a lot of other user editable websites. The main reason people like you, me, and a few other users involved in this discussion haven't been indefed at this point is because we are valuable contributors (however that's being judged). It's certainly not because of our upright, civil behavior or whatever lmao. It doesn't magically stop being something people tend to do or judge people on just because the person your responding to acts petty sometimes either. Sorry. Enjoy the cope though. --Adamant1 (talk) 14:39, 26 August 2024 (UTC)[reply]
literally 99% of the way people handle things on Wikipedia is by looking at a users edits, account age, and then acting according based mostly (if not totally) on that informationDoubt to say the least. Prototyperspective (talk) 14:44, 26 August 2024 (UTC)[reply]
Oppose This will almost certainly incentivize the wrong kind of behavior. We already have contests, barnstars, etc. and let me go on the record (again) as stating that editcountitis is silly. —Justin (koavf)❤T☮C☺M☯12:33, 26 August 2024 (UTC)[reply]
Comment Complementary to my pro here are some challenges to this that could be considered coherent arguments against, specific to WMC, and may be of interest (incomplete list, each problem with some thoughts on potential remedial approaches):
People are facilitated to make changes (such as uploading files or adding their files to Wikipedia) for the sake of increasing their stats/points/badges/levels which can result in more problematic contributions
The things shown would need to be well-selected (like "Number of images in use on a Wikipedia" instead of "Number of files uploaded") and fine-grained (like "Number of files categorized" instead of "Edit count"). If we implement this intentionally then this can be done. It can't be done well if stats and contributions metadata are just some byproducts. Secondly, this would be noticed (for example by complementary stats of how large the share of self-uploaded files put into use only by the uploader) and considering results of similar features doesn't seem likely to be a big problem, especially when also considering the advantages in the context of Wikimedia projects that have a large lack of active editors and partly declining activity/users. Third, they would be shown separately so if a user intentionally or unintentionally propped up some contribution evaluation like "edit count" then the other ones can be looked at (also by the users themselves) or be considered as context when looking at a user's contributions to this volunteer project.
A lot of constructive contributions are not included and people will be disadvantaged/biased by that or complain (or vice versa if to them unconstructive things are included) – for example talk page posts that contribute constructively to a question by e.g. solving the problem a user had would also need to be considered as positive activity instead of e.g. just activities like uploading
This is already the case with the already implemented Suggested Edits. More things can be added over time, maybe even in a modular kind of way. Even when missing many things, this could be better than having nearly no such thing except for mainly edit counts. There would be some dedicated page about that and people interested in this subject could address or work on complaints about it there which would not annoy other users. It doesn't seem likely that these gamification points/stats/… would result in any tangible benefits for the users like anonymous monetary return based on the level of recent contribution so people wouldn't really care much about imperfections with it.
Things may be unreasonably weighed – for example when it comes to edit counts by moving 1 k files to another category at once using cat-a-lot is not the same as manually reverting 1 k manually detected cases of vandalism&co
This is already the case with Edit counts which is what people can see for their own contributions, may be motivated by, can compare to other users, and can glance over when looking at other users. If you don't like that and consider edit counts useless that doesn't change this reality and as is is nothing but a Pro to implementing more reasonable and comprehensive feedback/stats.
WMC community wouldn't agree on what gives points/badges or is facilitated or by how much
They don't have to. One could make it dynamic like a table with many columns can be sorted by whatever column(s) you're interested in. When there are different stats/badges/… whatever you think is irrelevant can be ignored. If there are levels per badge or even per user's magnitude of constructive contributions, like those of Wikipedia:Service awards, then the user could personally adjust the weightings or select a premade weightings-combination.
If closing identified gaps, such as by providing requested media, is recognized and facilitated with dedicated comparable badges, then closing of gaps and ~first provision of missing needed/useful files is left out.
One could also consider the number of used files in the categories by subject of the file and increase weighting if there are nearly no other media in the respective cats or only unused ones. This would be difficult but wouldn't really be needed as one could do this by greater consideration of whether and how files are being used.
@Prototyperspective: I think it is even tougher than you imagine. E.g. "Number of files categorized" => sticking lousy categories on a lot of files. That's almost a dead match for the problem we had when people were rewarded for adding "depicts". "Number of images in use on Wikipedia" => we already have enough people fighting to get their image used rather than someone else's possibly better image.
I'm all for contests of pretty much whatever sort with human judges looking for quality, not just quantity but remain completely skeptical of anything with an automated metric. - Jmabel ! talk00:07, 27 August 2024 (UTC)[reply]
"Number of images in use on Wikipedia" There really needs to be more and/or better collaboration between projects. I don't really see how gamification would solve that or anything else mentioned by Prototyperspective though. Mainly it just seems like solution looking for a problem. What are we actually trying to solve or improve here though? Is it purely increasing raw edit count? If so, there's already betters and less involved ways to do that. Is it to get more people to add images to Wikipedia? Again, there's already there's already better and less involved ways to do that to. So really what's the actual issue here that gamification is suppose to be fixing or otherwise improving? --Adamant1 (talk) 00:19, 27 August 2024 (UTC)[reply]
Well that could be the case. But I think it's worth working on this and I think the downsides may be substantially larger in extent and complexity than outlined but not as intense as you may think – people don't act so problematically if these things don't result in anything tangible anyway. Think of it like improving the Feedback system of the platform so people get more feedback to be more engaged / motivated / entertained when contributing and just track their stats out of interest.
For example, number of files categorized may be considered by some to not be positive compared to other kinds of edits that may be behind edit counts and this is breaking down edit counts by type to some degree so you can track your own edits by type for instance. Now I do think it should be encouragements but I wasn't suggesting this comprehensive component to reach some mature version right away rather being developed while already being usable before solving all its main problems. For instance, files to which only cats like meta maintenance cats like display resolution cats got added may also be tracked separately and most importantly: people adding inappropriate cats for increasing these numbers would get some notification because they get a large share of / multiple reverts among their edits. Also so many files lack categories that this may not be as big of a thing especially if there were more task requests that people could simply complete to increase their stats.
I haven't seen people trying to get their own image used vs others and the larger problem is that even people's own uploads remain unused when lots of articles miss images with e.g. tracking files put into use by the uploader getting tracked in special ways and e.g. a rule to not readd an own image yourself when some other editor removed it could solve this.
As for human judges vs automated metrics – the art would be to craft an automated system fed by human data including human judges' data (like FPs, photo challenges, file uses, new things) that results in high quality results. It shouldn't be some liveless undynamic algorithm giving feedback itself, it would be human judges / the platform community providing feedback through this systematic framework and functions. This means it's only less direct and manual. It's not just about quantity, neither solving a requested media nor uploading or creating files that are useful enough to illustrate Wikipedia articles is about quantity.
Adamant1, that is about illustrating how the metric would be better than merely "Number of files uploaded". It could be refined further or get substats/…. If you're asking about the general advantages of "gamification" (and I think it's more about "gamification-like feedback"): it would safeguard WMC's future not just over the next 10 years but over the next decades / long-term and greatly increase constructive contributions, make the platform more fun to contribute, motivate more users to become new active users here, and so on. I don't think the potential benefits can be overstated and I think starting somewhere with this would be better than worrying a lot about likely problems on which there is insufficient experimental data and many plausible ways to address them. Prototyperspective (talk) 00:14, 28 August 2024 (UTC)[reply]
I don't even disagree with most of your response. I think your mixing things up here though or have an unrealistic view of what exactly "gamification" is to begin with. I say that because we have some forms of gamefication already. For instance featured and valued images, badges, tracking edit, category, and page view counts Etc. Etc. The question for me is if those things need to be improved or do we need to implement something else and in exactly areas. To give one example, having "featured galleries" would certainly increase and improve galleries on here. But that's literally all "gamification" is. So then what specific areas do we need more or better versions of that in and how exactly should go about it? Because your certainly able to go off on winded diatribes about the general merits of adding "gamification" to Commons but 15 messages later I still have yet to you say exactly what your talking about or how it would be different or better then the gamification mechanisms we already have. You want badges, cool. We already essentially have those. So what should changed or improved about them? You want artificial systems ran by judges, cool. We already have that to a degree with the featured and valued images systems. So what exactly is wrong with or needs to be improved about those things? --Adamant1 (talk) 00:30, 28 August 2024 (UTC)[reply]
Yes there already are lots of gamification elements and components. To answer your question, more and better gamification such as not just mere edit-counts which aren't insightful and badges provided automatically (there are basically no badges here) as well as things not covered by the current system like valuing all sorts of contributions that aren't photographs nominated as featured pictures and ways to evaluate overall constructive-contributions. Not an artificial system run by judges but using judges' data and built and continuously refined by humans (the Wikimedia community) and possibly personalizable to some extent so people can change what they think is more constructive. For example, I think implementing requested Wishlist items and phabricator code issues is one of the most constructive ways to contribute. One thing I forgot to mention is that WMC probably is in less need of new active contributors and keeping people engaged and productive than Wikipedia. Prototyperspective (talk) 09:57, 28 August 2024 (UTC)[reply]
More and better gamification such as not just mere edit-counts which aren't insightful People don't do it on here as much as Wikipedia but I've certainly seen plenty of people list editing milestones on their user pages as if they are meaningful. Perhaps there could be a special message or award barnstar for them, but I fail to see how creating a basic "level system" would be any different. It's pretty much the same to me if I'm a level 2 user or have 200,000 edits. The former just has less zeros, but as far as I'm concerned there's nothing about it that's inherently more meaningful then the raw edit count.
there are basically no badges here We have award barnstars. I guess they aren't technically badges, but again, I've certainly seen plenty of people list them on their user pages as if it's an accomplishment and meaningful to receive one. You could just rename them badges and they be essentially the same thing though. I think the main issue is that they aren't given out enough on here and it's seemingly random. So there's certainly things that could be improved there, but I don't think replaces them with "badges" would really make that much of a difference at the end of the day.
like valuing all sorts of contributions that aren't photographs nominated as featured pictures I guess we just have different ideas of how you go about that. For me it's more about having a community that's welcoming to and usable by new editors, clear guidelines, manageable goals and clear projects to work on that involve calibration with other users, Etc. Etc. At the end of the day it doesn't matter if someone becomes a level 2 or whatever because they reached some editing milestone if their still spending 99% of their time aimlessly whittling away by themselves in some corner of the project while being attacked every time they have even basic interaction with anyone else on here. It's not magic, if you want people to be motivated and contribute more you have to give them a basic purpose for contributing and/or people who care about them and the work they do to interact with. Otherwise it's just an exercise in mindless clicking that ultimately leads to nothing but frustration and burnout regardless. Although I do agree that featured pictures probably doesn't really accomplish anything meaningful, but we do have a lot of photographs on here. So it's clearly not a complete waste.
And ways to evaluate overall constructive-contributions. What about telling other users they are doing a good job sometimes? I don't disagree that there's value in that, but it should be something that is evaluated and celebrated by other users. Not just some mindless automated standard that has nothing to do with collaboration or the wider community. At least it if being done on site. It would be interesting to see if there's a way you could something along the lines of what's being talked about here through something on ToolForge though. I just don't think it's within the goals or purpose of the project to do it on site so to speak. But something like that shouldn't come at the cost of the other things I've pointed out. We're better off making this more inviting, streamlined, and user friendly then having some arbitrary slot machine style badge and/or level system regardless. Although I understand and don't even disagree with your motivations for wanting those things. --Adamant1 (talk) 15:12, 28 August 2024 (UTC)[reply]
Cool. I like your idea. It seems to have a good balance of humor and flexibility without just being a mindless, automated exercise in button clicking to rack up points or whatever. --Adamant1 (talk) 16:50, 28 August 2024 (UTC)[reply]
Full gamification is probably bad, but it wouldn't be harmful to have more more specific suggestions somewhere for how users could contribute. CMD (talk) 08:51, 28 August 2024 (UTC)[reply]
Needs to be a better box for Current and Recent templates
There needs to be a better box than is currently used for {{Current}} and {{Recent}}. And other templates too. The text needs to wrap completely around the icon. The icon should not be in a separate cell. The icon should be at the top left or top right corner.
Such a banner box would help with the complaints about there being too many templates on file pages. Because the templates would be narrower. And even when there are several templates, the total height of them would not be nearly as much.
And large icons should not be used in any case if they make the banner taller. Smaller ones convey the point fine.
And the breaks need to be removed:
{{Recent|type=webpage}} on a small screen:
This image is expected to always be the most recent one. Feel free to update it when needed.
However, as a screenshot of a webpage, you may not need to upload new versions too frequently, until a big change on that page. If you upload a new version of this screenshot, you must add proper copyright tags to each of the images and other media displayed on the screenshot.
Without the breaks, and with a corner image where the text can wrap around it:
This image is expected to always be the most recent one. Feel free to update it when needed. However, as a screenshot of a webpage, you may not need to upload new versions too frequently, until a big change on that page. If you upload a new version of this screenshot, you must add proper copyright tags to each of the images and other media displayed on the screenshot.
@Timeshifter: Are you saying the second looks better to you? Something like that might work in principle, but that particular example looks much worse to me than what it intends to replace. Maybe with more padding around the icon? Plus, the icon in that second version actually displays larger than in the first, which doesn't seem like an improvement at all. (Also, for a good comparison, we might want to go with a particular width rather than 50%, because each of us is seeing something different, depending on their screen width.) - Jmabel ! talk22:12, 5 August 2024 (UTC)[reply]
Good point on the width. I changed it to 500px wide. I prefer the second one because it is not as tall. And when there are more than one template on a file page it can irritate some people as the number of templates pile up taking more and more vertical height. Especially on mobile screens.
Div was something I just threw together quickly. I don't normally do templates on Wikimedia. Main thing I wanted to do was let the text wrap around the image. Image size was arbitrary. I just wanted to show that when text wraps around the image, then a larger image is more feasible. But I prefer the smallest image that almost everybody can see well enough.--Timeshifter (talk) 22:56, 5 August 2024 (UTC)[reply]
I still don't necessarily agree wrapping is an improvement, but if you want to do it roughly like that, I think the following is a better layout; I'm keeping the icon at your larger size to minimize change from your example, though I prefer the smaller.
This image is expected to always be the most recent one. Feel free to update it when needed. However, as a screenshot of a webpage, you may not need to upload new versions too frequently, until a big change on that page. If you upload a new version of this screenshot, you must add proper copyright tags to each of the images and other media displayed on the screenshot.
Maybe its just the resolution of my screen or something but having the icon above the first line of text looks horrible. It should really be aligned better. Otherwise the new box isn't an improvement IMO. --Adamant1 (talk) 13:08, 6 August 2024 (UTC)[reply]
I prefer the smaller icons for single-line templates since they are better for the wide desktop templates at full width. Templates without added parameters:
This image is expected to always be the most recent one. Feel free to update it when needed.
This file may be updated to reflect new information. If you wish to use a specific version of the file without it being overwritten, please upload the required version as a separate file.
Thanks Jmabel for using float:left with padding. Changing padding solves the problem of top alignment with the top of the text:
This image is expected to always be the most recent one. Feel free to update it when needed. However, as a screenshot of a webpage, you may not need to upload new versions too frequently, until a big change on that page. If you upload a new version of this screenshot, you must add proper copyright tags to each of the images and other media displayed on the screenshot.
I still prefer non-wrapping, but that is the best layout for the wrapping version so far. And with that I think I've said my piece. - Jmabel ! talk21:24, 6 August 2024 (UTC)[reply]
I tend to prefer the non-wrapping, but not a strong opinion. I will note that the examples combine the text into one paragraph, which (given that only the first sentence is a constant), not sure is a good idea. The template hardcodes a <br/> between any secondary text which comes with the "type". That website text in turn ends up being most of the issue. I could see maybe a layout change where additional text (such as the website) comes in a row below the main template text, maybe with a divider -- that row could use the full width of the template, i.e. a colspan of both cells, leaving the smaller icon to only be in the row with the shorter main text, with any additional explanation able to take the full width. Carl Lindberg (talk) 22:09, 6 August 2024 (UTC)[reply]
You mean like this?:
This image is expected to always be the most recent one. Feel free to update it when needed.
However, as a screenshot of a webpage, you may not need to upload new versions too frequently, until a big change on that page. If you upload a new version of this screenshot, you must add proper copyright tags to each of the images and other media displayed on the screenshot.
This image is expected to always be the most recent one. Feel free to update it when needed.
However, as a screenshot of a webpage, you may not need to upload new versions too frequently, until a big change on that page. If you upload a new version of this screenshot, you must add proper copyright tags to each of the images and other media displayed on the screenshot.
I just noticed that this example text (which I took to be basically a bunch of lorem ipso) is actually the text of an existing template. It's terribly worded. - Jmabel ! talk23:02, 6 August 2024 (UTC)[reply]
Yes. And too much info.
{{Recent}} with the added info from type=webpage: {{recent|type=webpage}}
Another problem, besides verbosity, with templates is that some do not extend fully across the screen. See {{BadJPEG}}, For example at full size:
All images in this commons were uploaded in the JPEG format even though it consists of non-photographic data. This information could be stored more efficiently or accurately in the PNG or SVG format. If possible, please upload a PNG or SVG version of this image without compression artifacts, derived from a non-JPEG source (or with existing artifacts removed). After doing so, please tag the JPEG version with {{Superseded|NewImage.ext}} and remove this tag. This tag should not be applied to photographs or scans. If this image is a diagram or other image suitable for vectorisation, please tag this image with {{Convert to SVG}} instead of {{BadJPEG}}. If not suitable for vectorisation, use {{Convert to PNG}}. For more information, see {{BadJPEG}}.
And at 500px wide:
All images in this commons were uploaded in the JPEG format even though it consists of non-photographic data. This information could be stored more efficiently or accurately in the PNG or SVG format. If possible, please upload a PNG or SVG version of this image without compression artifacts, derived from a non-JPEG source (or with existing artifacts removed). After doing so, please tag the JPEG version with {{Superseded|NewImage.ext}} and remove this tag. This tag should not be applied to photographs or scans. If this image is a diagram or other image suitable for vectorisation, please tag this image with {{Convert to SVG}} instead of {{BadJPEG}}. If not suitable for vectorisation, use {{Convert to PNG}}. For more information, see {{BadJPEG}}.
Text needs to wrap around the image. At least after 3 lines.
It looks like Mbox and maybe some of the other related templates may be eliminated and replaced by TemplateStyles in order to help lower the kilobytes in Common.css. See:
That's a good thing, because they cause a lot of problems. On both Wikipedia and the Commons.
There is no reason we can't start now, and create better templates to solve the above-mentioned problems. And TemplateStyles is just another tool. It is not required to create the templates we have been discussing. There is no reason the above templates we created can't be used now. It is easy to add a light background color:
This image is expected to always be the most recent one. Feel free to update it when needed.
However, as a screenshot of a webpage, you may not need to upload new versions too frequently, until a big change on that page. If you upload a new version of this screenshot, you must add proper copyright tags to each of the images and other media displayed on the screenshot.
See similar wordwrap problem with a Wikipedia template box:
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I’d say that the overwhelming majority of new uploads depicting genitalia nominated for deletion are deleted, so it doesn’t make sense to have DRs for every single one. Therefore I propose a new speedy deletion rationale: F11 [I think that’s the applicable number]: low-quality or unremarkable close-up photos of human genitalia. Thoughts? Dronebogus (talk) 08:59, 10 August 2024 (UTC)[reply]
A good idea, but I'd limit this to recent uploads. If it's been there even a month, this is probably not a ground to request speedy deletion. - Jmabel ! talk19:18, 10 August 2024 (UTC)[reply]
My main issue with this is that we have anti-porn crusaders. There are some users who hate any type of nudity and these people might misuse this, heck, they might even remove all actual file usages on Wikipedia and then tag them as speedy. As I've seen some anti-porn crusaders remove images for Wikipedia and then claim that these images are "out of scope" here because they are not in use. Also, are there any statistics on how many low quality nudity images that aren't realistically educationally useful actually get uploaded here? Usually when I see them they are from single-purpose accounts and more often than not these accounts get reported and nuked. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:14, 10 August 2024 (UTC)[reply]
As with anything else, admins check before deleting. Repeated inappropriate use of speedy deletion tags is grounds for sanctions up to and including blocks. - Jmabel ! talk20:37, 10 August 2024 (UTC)[reply]
As nearly all these files already fall under F10 (and if not mostly under F1) I do not see the need for a new criterion. GPSLeo (talk) 22:17, 10 August 2024 (UTC)[reply]
I don't think it's super clear that they fall under F10 or F1 considering how many are nominated for deletion instead of speedy deleted. I certainly didn't know either one of those were an option and I'm pretty competent with when it comes to getting images deleted. So maybe there should at least be a note about it under either the section for F10 or F1 if nothing else depending on which one is actually applicable. BTW, one of the draw backs of not having it explicit is that someone can just cry foul about censorship if they want and turn the SD into a normal deletion request, which I think could be avoided by having it as a specific deletion rational as opposed to using a more general one. --Adamant1 (talk) 23:40, 10 August 2024 (UTC)[reply]
The reason why many things they are speedy deletion cases are nominated as regular deletions is just because people do not know that speedy deletion exists and the default interface does only show regular deletion nomination. GPSLeo (talk) 08:47, 11 August 2024 (UTC)[reply]
@Omphalographer: Can I just copy the code from your common.js file into mine to enable the extra features or will screw anything up? (I ask because apparently mind has some code for Cat-a-lot that I rather not mess up if I don't have to) --Adamant1 (talk) 11:43, 12 August 2024 (UTC)[reply]
@GPSLeo: You make a good point. Speedy deletions are kind of obscure. Maybe that's something that can or should be integrated into the interface somehow. I'm not sure a gadget would be best way to go about it since there's just as much chance that won't know about or use the gadget anymore then they do with speedy deletions to begin with. --Adamant1 (talk) 04:56, 12 August 2024 (UTC)[reply]
I think simplified speedy deletion should be a default feature for all autoconfirmed users (I’m not sure IPs and brand new accounts can be trusted not to abuse it or misunderstand it) Dronebogus (talk) 08:16, 12 August 2024 (UTC)[reply]
Oppose. I understand where you're coming from and I agree in principle, but "low quality or unremarkable" is too subjective for a speedy deletion criterion. Omphalographer (talk) 05:59, 12 August 2024 (UTC)[reply]
A better standard would probably be "self-created" but then it sounds like that's already adequately covered by F1 and F10. --Adamant1 (talk) 07:23, 12 August 2024 (UTC)[reply]
How about “close-up photos of genitalia that are of unusably poor quality and/or not substantially different from existing files?” “Unusably poor” would be things like being blurry, low resolution, badly lit, etc. Dronebogus (talk) 08:14, 12 August 2024 (UTC)[reply]
"Not substantially different from existing files" is still fairly subjective, and it isn't something that an admin processing speedy deletions can verify at a glance. Unusably low quality is more objective, but would that address a meaningful number of these uploads? Omphalographer (talk) 09:14, 12 August 2024 (UTC)[reply]
How is it more or less subjective than “Low-to-medium quality selfies and other personal images of or by users who have no constructive global contributions”? Not substantially different means it doesn’t illustrate any significant, underrepresented variation on the sexual anatomy— namely genital modification or medical conditions. If it is a completely normal penis or vulva without either of those, or depicts an example of modified or abnormal genitalia we have countless images of (i.e. a circumcised penis) it’s not substantially different from existing files. Dronebogus (talk) 09:21, 12 August 2024 (UTC)[reply]
Oppose I assume F10 "(selfies) and other personal images of or by users who have no constructive global contributions" should already be applicable. No need to give the religious bunch an extra rule. Alexpl (talk) 12:46, 12 August 2024 (UTC)[reply]
I propose moving the 2 links currently at Commons main page -> Content -> By type -> Images -> Maps (Atlas) to a new entry in Commons main page -> Content -> By topic -> Cartography Maps (see discussion below for the name change). Maps are a topic/subject in itself, not merely a type of media, and the Atlas of the World, as a system of galleries, is unlike any other link in "By type" section, and should be more easily accessible. MGeog2022 (talk) 12:02, 13 August 2024 (UTC)[reply]
Oppose "Cartography" is the wrong word for a gallery containing images of maps. Cartography has to do with map creation, not the maps themselves per se. Plus it's kind of a specialist term that most people outside of the industry don't use or know about to begin with. --Adamant1 (talk) 15:14, 14 August 2024 (UTC)[reply]
@Adamant1: From Wikipedia, cartography is "the study and practice of making and using maps". The word is quite familiar to me long before I started map making in Commons. So I find nothing wrong with using "cartography" to categorize map galleries and atlas pages. Sbb1413 (he) (talk • contribs • uploads) 15:18, 14 August 2024 (UTC)[reply]
I'm aware of what the definition of cartography is. I actually studied it in college. That's besides the point though. Things on the main page should 1. Be understandable to a general audience 2. Follow how the categories/galleries/files/Etc. Etc. are termed. At the end of the day these aren't galleries for images of people "studying or making maps." Their galleries of maps. So it's makes zero sense to call them that on the main page. Just like it makes more sense to have a link on the main page for Category:Animalia instead of Category:Zoology. Even though both technically relate to animals. As I assume the point is to link to images of animals, not people in lab coats dissecting specimens or whatever. --Adamant1 (talk) 16:33, 14 August 2024 (UTC)[reply]
@Adamant1, no problem if Cartography is not the best word: we replace it for Maps. The matter here is if you can see Category:Maps and Atlas of the World when you load Commons main page, or if you have to miraculously know that you have to expand By type section and have a detailed look to find them. MGeog2022 (talk) 09:35, 15 August 2024 (UTC)[reply]
Sorry, perhaps I used Cartography word wrongly because of Spanish (my native language) word Cartografía, which is often used to refer to maps themselves. Maybe English Cartography isn't used in the same way. MGeog2022 (talk) 09:47, 15 August 2024 (UTC)[reply]
I don't care if the term used is Maps or Cartography, since my native tongue Bengali often use মানচিত্র to cover both topics, although it has a specific term for the study of maps (মানচিত্রবিদ্যা). Sbb1413 (he) (talk • contribs • uploads) 09:53, 15 August 2024 (UTC)[reply]
Oppose. Current scheme better and more accessible. Maps are images rather than topics. Maps is more accessible than cartography. Glrx (talk) 17:43, 14 August 2024 (UTC)[reply]
@Glrx, please tell me in what way having to expand a section (By type section) to find it, is more accesible than having it already visible when you load Commons main page, as is the case with By topic. No problem with using maps in place of cartography, that wasn't the main thing here. Maps are images rather than topics: of course each map is an image and not a topic. But maps, as a whole, are more of a topic than a media type, as photos or diagrams (you wouldn't generally look for photos or diagrams without a subject; with maps, while searchs by subject are also frequent, you also may want to have a general look at a structured collection of maps from all around the world). MGeog2022 (talk) 09:41, 15 August 2024 (UTC)[reply]
We have 3 Support votes (including Adamant1 vote change) and 1 Oppose, and no votes within the last days. I don't know if this is enough to proceed with the change (in Commons main page, removing link to Atlas from By type, and adding new section Maps in By topic, with both links to Atlas and Category:Maps), and who could do it (that is, someone who can edit Commons main page). MGeog2022 (talk) 12:49, 20 August 2024 (UTC)[reply]
I don't know if there's a specific amount of time that needs to pass or number of votes that have to happen before a proposal is closed, but there's no reason this can't just stay how it is for at least a couple of more weeks to see if anyone else has comments or anything else changes about it. A week isn't really long enough to judge the wider communities opinion about anything. --Adamant1 (talk) 09:57, 21 August 2024 (UTC)[reply]
"Why isn't this limited to some skin or some type of devices like mobile view?"
We don't want to be asked again about pages at Commons not having upload links. I feel it's sufficiently embarrassing as such.
"why is this titled "bug/feature request"?
We don't really know if know if the missing upload link is a feature (people shouldn't upload at Commons? but then why?) or a bug (developers didn't implement that part of the specification).
"why can't I edit the initial proposal to my likening?"
The initial poster here took it upon him to formulate the proposal. If you wan't to do a separate one, add this in your comment".
Support for "upload file" link for mobile, thinking in the users who have no other option, without forgetting the concerns of administrators about the possible increment of COPYVIO cases and the possible need to take appropriate measures to prevent it. MGeog2022 (talk) 13:47, 15 August 2024 (UTC)[reply]
Oppose For the same reason's I gave in the Village Pump discussion. I'm not a fan of how this is being framed as a simple bug when that doesn't appear to be what it is either. Rather it appears to be something that just hasn't been implemented, not a problem due to a coding error or whatever that's causing the site to act differently then it should be on mobile devices. --Adamant1 (talk) 16:34, 15 August 2024 (UTC)[reply]
@Enhancing999: What evidence do you have that it's a bug and not just an unimplemented feature? I'm sure your aware that they aren't the same thing and that framing it as a "bug" just makes this looks like something that should already be implemented as opposed to a request for a new feature or whatever. --Adamant1 (talk) 16:34, 15 August 2024 (UTC)[reply]
The question was raised in the discussion, please feel free to comment there and explain why a site to upload media shouldn't have an upload link and how core feature was omitted. Enhancing999 (talk) 17:07, 15 August 2024 (UTC)[reply]
I already did. So why not answer the question? What exactly makes this a bug and not just something that hasn't been implemented? Your the one claiming that's what it is and saying it's only missing for some devices. So it should be easy to provide some evidence. Otherwise I'm just going to argue that this shouldn't be accepted no matter how the vote goes because of the misleading, false framing of the issue. --Adamant1 (talk) 17:18, 15 August 2024 (UTC)[reply]
No answer about how it's a "bug" then? Thought not. I guess you won't mind if I change the title to what it was in the Village Pump discussion then. --Adamant1 (talk) 17:26, 15 August 2024 (UTC)[reply]
Support Mobile users should also be able to upload images. Many people don't have a desktop computer but only a phone. Uploads through mobile devices could be tagged somehow so they are easier to check for copyvios the bulk of which a tineye-/google-image-reverse search bot could do. Prototyperspective (talk) 17:01, 15 August 2024 (UTC)[reply]
@Prototyperspective: Is there metrics anywhere saying exactly how many people on mobile actually use the site or would upload media to it in the first place? You'd have to agree that it doesn't really matter how many people do or don't have a particular device if none of them actually use the website to begin with. --Adamant1 (talk) 17:20, 15 August 2024 (UTC)[reply]
For me it is a bit unclear on what the proposal is about. Where should the link be added? Only on Commons in mobile view or also on other Wikis and the Wikipedia mobile app? GPSLeo (talk) 17:50, 15 August 2024 (UTC)[reply]
Where exactly have I signaled that people need to gain my approval to change the topic. I literally said on your talk page that you were free to change the title as long as it makes sense and accurately represents the original request. It's not me that you don't feel like rewording it to get rid of the spelling mistakes and use proper English. --Adamant1 (talk) 18:14, 15 August 2024 (UTC)[reply]
You can formulate an alternate proposal in a different thread and vote multiple times to oppose this one if you don't like it. Clearly you didn't change it to correct spelling. Enhancing999 (talk) 19:53, 15 August 2024 (UTC)[reply]
That was the title of the discussion that you linked to and told everyone to look at to see what this is about. Plus you can read Novem Linguae's comment below this one "Changing the apps is not part of this proposal. Just the Minerva skin, which is the mobile browser skin." So how exactly is the title wrong or for an alternate proposal when this is literally about adding a "Upload file" link to the mobile browser skin? --Adamant1 (talk) 20:09, 15 August 2024 (UTC)[reply]
Changing the apps is not part of this proposal. Just the Minerva skin, which is the mobile browser skin. It would go in the left menu towards the bottom. I currently have the patch written as affecting all wikis, but I am being pressured in gerrit code review to change it to just affect wikis with UploadWizard installed, for technical reasons. Commons is the most important stakeholder, so I see getting commons signoff as the minimum first step here to keep proceeding with the patch, and as a yardstick for what the other wikis are likely to think of this. –Novem Linguae (talk) 19:44, 15 August 2024 (UTC)[reply]
@Novem Linguae: I'd probably support the proposal if it was confined just to the Minerva skin and mobile. It seems like @Enhancing999: wants to make it about other things that have nothing to do with either one though. So I think you and him need to discuss this and figure out what's actually being proposed here before it's moved forward. Otherwise it's not really clear what exactly is being proposed here and @Enhancing999: doesn't seem to be willing to clarify things or change the proposal to be more specific. I'd probably support if I knew exactly what I was voting on though. --Adamant1 (talk) 23:22, 15 August 2024 (UTC)[reply]
I've boldly edited the proposal title to be minerva only. I have no interest or ability to patch the many different apps, so I think that is a misunderstanding. I hope everyone finds this clarification acceptable. –Novem Linguae (talk) 05:55, 16 August 2024 (UTC)[reply]
Thanks. I changed my vote to support. I have no issues with trying this out with Minerva and then expending it from there later if doesn't lead to people uploading a bunch of extra COPYVIO. --Adamant1 (talk) 07:40, 16 August 2024 (UTC)[reply]
For me it is still not clear if you want a link on every Wikipedia article to upload a photo on the topic or not. For Commons it is just making a link that already exists in the Infobox more visible. GPSLeo (talk) 07:43, 16 August 2024 (UTC)[reply]
The proposal is to add an "Upload file" link to the left menu of the Minerva skin, as in this screenshot. This link would appear on every page on Commons when the menu is open (it defaults to collapsed and needs to be clicked). –Novem Linguae (talk) 08:03, 16 August 2024 (UTC)[reply]
If only on Commons and not all Wikis I would Support. On category pages the link should open the Wizard prefilled with the category. GPSLeo (talk) 09:01, 16 August 2024 (UTC)[reply]
We can't really determine here what other wikis do. We can stop them when some users come through the wrong channel. What part suggests that this should be for other wikis? Enhancing999 (talk) 10:01, 16 August 2024 (UTC)[reply]
I restored the original proposal as "fix bug/feature of missing upload link in some skins/for some devices". As mentioned, some is tracked at phab:T372078, but I removed this from the top of the thread as not everything may be covered. Enhancing999 (talk) 09:28, 16 August 2024 (UTC)[reply]
You really sure you want to do that? You've had multiple people tell you the proposal was vague and two different users thought the title should be changed. Plus it's pretty clear that what Novem Linguae is working on is the only thing being worked on at this point. I'm more then willing to retract my support if your going to be that way about it, but I'd rather the proposal just be confined to Novem Linguae's original plan then oppose it just because you can't take other people's advice or deal with it being confined to just the Minerva skin for now. There's no reason there can't be a wider proposal to fix the bug or whatever after we try it with the Minerva skin for awhile to make sure it doesn't lead to more COPYVIO. --Adamant1 (talk) 09:33, 16 August 2024 (UTC)[reply]
You are free to post your opinion here. Please make sure to include plenty of points that come to your mind and repeat them over and over, even if ultimately you don't consider them relevant. Just let us know before. We can guess about repetition. Enhancing999 (talk) 09:52, 16 August 2024 (UTC)[reply]
I don't think I've said most of what in the message your responding to before. So I'm not really sure what your talking about with the repetition. It's pretty clear you don't have actual response outside of acting snide though. Please continue to be condescending in your messages and make a bunch of needlessly back handed personal comments in response to good faithed questions or attempts to resolve this in a way that everyone would be satisfied with though. --Adamant1 (talk) 10:02, 16 August 2024 (UTC)[reply]
I'd recommend re-titling this to "Proposal: Add "Upload file" link for mobile skin (Minerva) in browsers" and removing the FAQ. This will laser-focus the proposal into something small and passable. "Incremental progress" (get a little bit passed now, then a little bit passed later) is a good way to move things forward. I'd also recommend not dragging participants of this proposal to AN/UP. Seems like a sideshow that will just distract from the proposal and create animosity. –Novem Linguae (talk) 10:13, 16 August 2024 (UTC)[reply]
Oppose Per Enhancing999's clear ownership issues and unwillingness to confine this to the Minerva skin for now. As well as them making it needlessly personal in the FAQ. I'm more then willing to support an alternative proposal just for the the Minerva skin though. But I don't really see a reason to support a vague proposal about apparently none exiting "bugs" or "devices." Especially when the proposal can't even be bothered to explain exactly what their talking about. --Adamant1 (talk) 09:51, 16 August 2024 (UTC)[reply]
Qoute from Matrix "Enhancing999, COM:AGF is a policy. Calling Adamant1's changes "headline vandalism" from the start is clearly assuming bad faith. You also don't have to give a "final warning" right from the start. Just discuss the changes." Clearly you've completely missed the point. --Adamant1 (talk) 10:08, 16 August 2024 (UTC)[reply]
This is to allow underserved mobile users to upload directly without having to use a desktop or special app, or switch to another skin. Yes, I know that this would probably increase the percentage of copyvios uploaded, but that's what the tracking is for. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:55, 16 August 2024 (UTC)[reply]
As with the previous similar proposal, Support. The proposed tracking would mitigate the possible increase in COPYVIO cases, as Jeff G. said (I wasn't aware of it, but there is a Commons mobile app that already allows uploads from mobile devices, so perhaps allowing uploads from mobile browsers doesn't increase COPYVIO so much; on the other hand, having the app, this change isn't so critical, but in any case it would be useful for rare cases of users who can't or don't want to install the app). MGeog2022 (talk) 11:13, 16 August 2024 (UTC)[reply]
The app is only for Android and even of Android users an estimated >50% users probably either don't know of or don't want to install that app so it's not rare at all. Prototyperspective (talk) 17:36, 16 August 2024 (UTC)[reply]
Neutral. This seems to go the opposite direction than other recent proposals to reduce or eliminate cross-wiki uploads. I'd much rather see a link to the Commons Upload Wizard. - Jmabel ! talk16:27, 16 August 2024 (UTC)[reply]
Why would this proposal not be a link to the Commons Upload Wizard? I think that's what has been proposed but I'd also support another Upload form if it's either that or no upload capability. (Secondly, it would be nice if at some point mobile users were made aware of the Commons app here but I think it would first need to get a proper Explore/Home page.) Prototyperspective (talk) 22:37, 17 August 2024 (UTC)[reply]
Certainly, that would automatically detect an important part of copyvios automatically in a moment. Administrators then would have much more free time to investigate well the most complex cases and for other tasks. MGeog2022 (talk) 09:51, 18 August 2024 (UTC)[reply]
@Rudolph Buch: I see. Thanks for the link. Perhaps the current Admin team has a different perspective from the Admin team of ten years ago, I'd like to hear from them, so I requested their opinions at COM:AN. Regarding the repetitive nature of this proposal, I was trying to avoid a certain user's ownership issue. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:34, 17 August 2024 (UTC)[reply]
Interesting post from almost exactly 10 years ago. Supposedly this was before upload wizard and its tutorial and with mobiles from back then. Weirdly they then built a tool to do the same from Wikipedia directly (or was that before?). ∞∞ Enhancing999 (talk) 14:06, 27 August 2024 (UTC)[reply]
I know from WMF contacts who would probably rather not be named that they consider it a much worse user experience when people upload files, a large number of which are deleted, than when they cannot upload at all. I suspect that rather than tweak here and there, the whole issue around expansion of ability to upload should should be discussed broadly, including plans for how we will evaluate the results. In fact, those plans for evaluation should probably be the first step. - Jmabel ! talk01:11, 18 August 2024 (UTC)[reply]
I was initially against this myself but I don't see why we can't use Jeff G. idea to track files uploaded by the skin and then keep a tally of how many end up being COPYVIO going forward from there to see if it actually causes that much of an issue long-term or not. Then the skin can just be disabled if it ends being a problem. I'm not an expert on this by any means, but I assume that wouldn't be an option if uploads were enabled more broadly on mobile in general outside of Minerva. --Adamant1 (talk) 05:45, 18 August 2024 (UTC)[reply]
Support I understand people are gun-shy due to past events, but i think this is a good thing. Many of the past attempts involved "simplifying" the upload form to help mobile users, and ended up effectively simplifying away the part where users are instructed not to make copyvios. As long as this is linking to the normal upload wizard, than i suspect this will go a lot better than the previous mobile upload stuff. There is always a risk-benefit trade off with making things easier of course. I think the best way to reduce risk here, is to tag uploads via this method (as suggested above), but also agree before hand on a cut-off date where things will be re-assessed and disabled if they go badly. For example, after 1 month of trying this, have another discussion to decide on next steps. Bawolff (talk) 09:14, 19 August 2024 (UTC)[reply]
There is a new feature that allows AbuseFilters to require a CAPTCHA before uploading an edit. I would like to enable this for many IP edits, especially IP edits on mobile. The aim of this is to reduce the huge amount of accidental and nonsense edits. Are there any concerns against this? GPSLeo (talk) 10:06, 18 August 2024 (UTC)[reply]
No, it would be good to reduce maintenance time to free up time for other tasks. However, I doubt this is enough and have called for better vandalism/nonsense-edit detection like ClueBot does it on Wikipedia here which may also be some context for this thread. Prototyperspective (talk) 10:25, 18 August 2024 (UTC)[reply]
Detection of nonsense after is was published is not our problem, this is possible with current filters. We do not have enough people looking on the filter hits and reverting the vandalism. We therefore need measures to reduce such edits. If we do not find a way to handle this we need to block IP edits entirely. GPSLeo (talk) 10:56, 18 August 2024 (UTC)[reply]
I think we rather need measure to automatically revert such edits. Detection is a problem if it's not accurate enough that it contains too many false-positives that people don't implement them. The proposal is not just about detection but also about what follows from there – for example one could also automatically revert them but add the edit to a queue to check in case the revert is unwarranted. Prototyperspective (talk) 11:00, 18 August 2024 (UTC)[reply]
Very interesting! Thanks for the link, it's very constructive and if possible please let me know when WMC enables this or when there is some discussion about enabling it. It could save people a lot of time and keep content here more reliable/higher quality. I think there's not even auto-detection for when e.g. 80% of a user's edit have been reverted for checking the remainder and whether further action is due. Prototyperspective (talk) 23:18, 1 September 2024 (UTC)[reply]
Capchas are supposed to stop robots from spamming, right? Why would this stop some random human IP user from posting “amogus sussy balls”? Dronebogus (talk) 14:05, 18 August 2024 (UTC)[reply]
You did not consider the full rationale of OP, he wrote huge amount of accidental […] edits and this measure would be partly and probably mainly be about greatly reducing accidental edits. OP however failed to name some concrete specific examples which have been brought up in a thread elsewhere. I favor better detection of nonsense edits and automatic reverting of them but requiring captchas for IP edits on mobile or for certain actions may still be worth testing for a month or two to see whether it actually reduces these kinds of edits. Prototyperspective (talk) 16:43, 27 August 2024 (UTC)[reply]
I'd totally support requiring captcha's for edits on mobile in general, not just for IP addresses. I know personally I make a lot of editing mistakes on mobile just because of how clanky the interface is. There's also been plenty of instances where I've seen pretty well established users forgot to sign their names or make other basic mistakes on mobile. So I think having captcha's on mobile for everyone would be a really good idea. --Adamant1 (talk) 17:59, 27 August 2024 (UTC)[reply]
In Special:Preferences there is an option "Prompt me when entering a blank edit summary (or the default undo summary)". Enabling this seems like a good way to provide a chance to briefly stop and review what you are trying to do. I wonder if it's possible to enable it by default. A captcha answer has no productive value, but a good edit summary will do. whym (talk) 01:15, 1 September 2024 (UTC)[reply]
I'd support that as long as there's a way for normal, logged in users to disable it if they want to. I think any kind of buffer between making an edit and posting it would reduce bad edits though. Even ones that are clearly trolling. A lot of people won't waste their time if they have to take an extra step to post a message even if it's something like writing an edit summary. --Adamant1 (talk) 01:34, 1 September 2024 (UTC)[reply]
@Jeff G.: True. That's one of the main reasons I support requiring people to have an account since it seems to be much easier to track and ban editors that way. --Adamant1 (talk) 02:05, 1 September 2024 (UTC)[reply]
@Jeff G.: Anyone can still contribute if we require accounts. I could see not requiring accounts if there was legitimate reason for it, but I've put a lot of thought into this over the last couple of years and can't think of one single legitimate reason why someone wouldn't be able to create one. We'll have to agree to disagree though. I can understand why they let IP edit Wikiprojects back in the day though, but the internet and people are just different now and the project should be able to adapt to the times. --Adamant1 (talk) 02:21, 1 September 2024 (UTC)[reply]
This does not help in cases this is about as theses types of edits always have auto generated edit summaries and no way to edit the edit summary. GPSLeo (talk) 04:32, 1 September 2024 (UTC)[reply]
Maybe that is a software problem to be fixed? It already says "(or the default undo summary)" after all. Reminding users to add a bit more to what's auto-generated seems like a natural extension. whym (talk) 18:54, 1 September 2024 (UTC)[reply]
The Wikibase UI does not have such a feature and in the many years of Wikidata it was not considered a problem that changing the edit summary is not possible. GPSLeo (talk) 20:24, 1 September 2024 (UTC)[reply]
I make much fewer editing mistakes on mobile when I use my new portable bluetooth mini keyboard. Touch-typing in the dark, however, can still be problematic. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:52, 1 September 2024 (UTC)[reply]
There is definitely no consensus to use this feature for now but there were some people suggesting to make a test. Therefore I would propose that we make a one week test and then evaluate the results. GPSLeo (talk) 19:37, 2 September 2024 (UTC)[reply]
Why? How is that useful? No consensus to implement means no consensus to implement, period. I can guarantee it will not gain any more consensus with a test version. Dronebogus (talk) 21:08, 2 September 2024 (UTC)[reply]
Industry support & reception for jpeg XL is pretty mixed. It is rather unclear if this format will take off or be relegated to a footnote of history. Seems a bit early to add support unless there is some specific benefit to commons. Bawolff (talk) 00:38, 20 August 2024 (UTC)[reply]
I was just reading about AVIF files the other day. Both of them seem to be trying to unseat JPEGs but to mixed results so far. Although at least according to what I was reading AVIF is the more popular format between the two. Who really knows though. Regardless it's probably better to wait until it's clear which one will win out, if either one will, before adding support for it. --Adamant1 (talk) 12:50, 20 August 2024 (UTC)[reply]
Hmm... Chrome and Firefox currently don't officially support this format, from what I read. Rather only Firefox Nightly build has been testing it out for a long while. Chrome gave the format a try as an experiment and then gave it up. I see third-party browser extensions rendering JXL files for these browsers.
Safari currently supports the format only if the version is 17 or later, and iPhone XS (oldest so far), macs running Sonoma (version 14), iPad 6th-gen, iPad Pro 2nd-gen, or newer can capably run Safari 17.
Oppose obscure, experimental format that needs to be adapted by the wider internet community before we bother hosting it. Per Adamant1 AVIF files are probably a better choice for a new format to host. But why do we need yet more ways of storing a still image on Commons? We should focus on novel media types like 3D models, virtual reality, interactive software like games, etc. that could vastly expand our educational capabilities. Dronebogus (talk) 04:39, 25 August 2024 (UTC)[reply]
I'm proposing enabling the accessibility features beta features (like dark mode) by deafult for all logged in users using Vector 2022 skin. This will help us get more bug reports (here), and will make Commons more ready if we decide to switch to Vector 2022. English Wikipedia already has this by default for everyone. So I think it's a good idea to enable for logged in users with Vector 2022 now. Thoughts? —Matrix(!) {user - talk? - uselesscontributions} 16:12, 26 August 2024 (UTC)[reply]
Vector 2022 is not yet adapted to the special needs and functionalities of Commons. If I understood it correctly the WMF team will start working on it after the implementation on Wikipedia is done. We should therefore not make it a default for new accounts. Giving a beta feature to new users first is not a good idea. But of course having some people already using it would be good to find where adaptions to Commons are needed. GPSLeo (talk) 16:34, 26 August 2024 (UTC)[reply]
Vector 2022 is available, dark mode only if you add "?vectornightmode=1" to the url. There might be some possibility to enable it with user JavaScript but I could not find how to. GPSLeo (talk) 19:18, 26 August 2024 (UTC)[reply]
Well darn. That's a hassle. It doesn't look like the site works very well with dark mode at this point anyway. Although it would be nice to have without the weird URL thing being involved. --Adamant1 (talk) 19:26, 26 August 2024 (UTC)[reply]
@GPSLeo: It's actually in settings. First enable Vector 2022 as your default skin, then go to Settings > Beta features and accessibility features should be there. Then it will be in your sidebar. —Matrix(!) {user - talk? - uselesscontributions} 13:48, 27 August 2024 (UTC)[reply]
Oh, you are right. I did not try to save one setting change first and then look for new available options. Thanks for that hint. GPSLeo (talk) 13:57, 27 August 2024 (UTC)[reply]
You might have misunderstood the proposal a bit. Since Vector 2022 is not the default skin, most people using it on Commons are experienced users, so they should probably be able to handle a beta feature. It will not be a default for new accounts under this proposal. —Matrix(!) {user - talk? - uselesscontributions} 13:49, 27 August 2024 (UTC)[reply]
If only experienced users use it, they should already have made their choices about the defaults for beta features. If not, this just bothers inexperienced users with buggy features. ∞∞ Enhancing999 (talk) 13:56, 27 August 2024 (UTC)[reply]
I'm not sure lack of a US license is a speedy deletion reason, which is implied by such a template. Much of the time, a work will be PD in the US as well, if PD in the country of origin. And if not, it will usually involve the URAA restorations, which can be rather complicated and are not valid speedy deletions (you have to demonstrate renewal by the URAA, often involving historical copyright laws of a country, in order for deletion to happen -- a possibility of the URAA restoring a work is not enough for deletion per policy). Carl Lindberg (talk) 03:56, 29 August 2024 (UTC)[reply]
That is still closer to the speedy deletion process, and avoids a regular DR, which the URAA probably should require. You could always add {{Not-PD-US-URAA}} if you think the URAA applies, and mark for regular deletion, giving the explicit reason why the URAA applies. Current policy puts the onus on the nominator to show that the URAA actually does apply (or at least requires a review by someone who can show that); the policy states that a URAA claim without any further provided info is not enough for deletion, for something PD in the country of origin. This proposed tag seems like it would have no need to show that evidence, with a much higher chance of deletion -- i.e., it seems like a way to circumvent that part of policy, in a somewhat contentious area (even though I think we don't delete URAA-restored works enough). If we want a tag which points out there is no US license, though with no deadline, maybe that works -- something like {{Disputed}}, though less alarming. I think Not-PD-US-URAA would apply in virtually all valid cases, though, so if you can't add that not sure it's worth marking at all. Carl Lindberg (talk) 14:23, 31 August 2024 (UTC)[reply]
When a user lists a file for deletion using the AjaxQuickDelete or VisualFileChange widgets, and the file was originally uploaded from mobile, those widgets add the files to lists on these pages:
Both of these pages used to be archived by CommonsMaintenanceBot, but this process stopped in 2021, and the pages are now unreasonably large. This leads me to suspect that these pages are no longer being used.
Is anyone still using these pages? If so, can someone set up a bot task to start archiving them again; if not, can we stop adding files to them from the AQD/VFC widgets? Omphalographer (talk) 23:03, 29 August 2024 (UTC)[reply]
Support thanks for the work, I have made numerous move requests for nonsense filenames.Paradise Chronicle (talk) 08:47, 23 March 2024 (UTC).svg/15px-Pictogram_voting_comment_(orange).svg.png)
Comment — An important Commons constituency are third-party users. In the "Ideal" section I'd like to see a mention of the importance of choosing a name that is suitable for use/linking by third-party users. —RP88 (talk) 18:24, 23 March 2024 (UTC)
Oppose there are several problems with that approach:
Neutral), but there have been improvements after Enhancing999 pointed out flaws. Mentioned is now: local languages are recommended for subjects; English would be standard for generic subjects. I don't know how this can be formulated better, but please imagine that we have the scan from a Polish book that features the 436th portrait of Columbus for Commons. Is "Ritratto Cristoforo Colombo" (it-Standard) better than "Portrait Christopher Columbus" (en-Standard) or shouldn't it be "Portret Krzysztofa Kolumba" (pl-Standard) because of the language of the book? On the other hand, which language can we reasonably expect when naming a photo of the Finnish folklore band that a Korean tourist took on their tour in Paris? en/fi/ko/fr could all apply. I would say all languages would qualify for "ideal" titles, as long as nothing is misspelled. But I'd also support that we focus on correcting file names that don't fulfill the minimum standards; rather than try to bring every name into "ideal" territory.
Strong oppose: One seldom sees in Commons so many bad ideas bundled toghther with so much support from otherwise serious users. -- Tuválkin ✉ ✇ 23:35, 8 April 2024 (UTC)
Question: what do you mean by "on CDs"? Compact Disks?
Weak support if this becomes just a suggesstion and not a tool to ban people, im ok with that. modern_primat ඞඞඞ ----TALK 17:25, 17 July 2024 (UTC)
Strong support I hold the (probably extreme) view that xwiki uploads in general are a net negative and we should just scrap 'em, but this is a sensible restriction. Queen of Hearts (talk) 04:58, 11 July 2024 (UTC)
.jpg){kind=link}
.JPG){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg){kind=link}
.jpg){kind=link}
_Boeing_737-3H4(WL)_at_Albury_Airport_(IMG_4039).jpg){kind=link}
_by_the_NZ_Defence_Force.jpg){kind=link}
_Agusta_A109LUH(NZ)_post_maintenance_flight.jpg&action=edit&redlink=1){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
-_-_NARA_-_17443770_(page_700).jpg){kind=link}
