Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search

Shortcut: COM:VP/P· COM:VPP

  Welcome   Community portal   Help desk
Upload help
  Village pump
copyright • proposals
  Administrators' noticeboard
vandalism • user problems • blocks and protections
 
Welcome to the Village pump proposals section

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.

Commons discussion pages (index)


Please note
  • 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.
  • Have you read the FAQ?


 

Formatting of image or media descriptions[edit]

There is currently no guideline for the formatting of the descriptions of images (or other media). This includes the formatting of the Description field of the Information template.

Some editors (e.g., User:Look2See1) have been editing image descriptions, adding bold face (to show the main topic), bullet lists (to separate topics), and emdashes. Other editors have objected (see, e.g., User talk:Look2See1/Archive_1), saying that the formatting decreases readability. This controversy has been occurring since at least 2013, resulting in slow edit-warring.

I believe that the community should come to a consensus on a style guideline for image descriptions, to settle this controversy. Let me start with a proposal, then let's discuss and see if it needs modification. If we come to a consensus, Commons can adopt the proposal as a style guideline. — hike395 (talk) 17:58, 18 February 2015 (UTC)

Proposal[edit]

Descriptions of media files should be prose that describes the file, including the contents, location, or historical background of the file. The formatting of the description should be minimal: font styling (e.g., bold face or italics) should be avoided. The description can span multiple paragraphs, but paragraph formatting (such as bullet lists) should be avoided. The description should contain complete sentences, or clauses separated by commas. Informal language or formatting, including the use of em-dashes or ellipses, should be avoided.

The use of internal links to Commons (to galleries or categories) is encouraged, to assist in readers finding relevant media. Internal links to Commons are preferred to links to Wikipedia.

The use of the {{Information}} template to describe media is encouraged for uniformity.

Discussion[edit]

What do other editors think? — hike395 (talk) 17:58, 18 February 2015 (UTC)

  • Symbol oppose vote.svg Oppose the proposal, since each file is different and requires different style formatting, and I do not think there is a single style that works for most works. However in the example image File:Old senate debate.jpg I do Symbol keep vote.svg Agree that user:Look2See1 changes to that file decrease readability. Using proper Infobox templates (in this case {{Artwork}}) often helps avoiding this kind of disputes by decreasing the amount of information in each individual field. --Jarekt (talk) 18:59, 18 February 2015 (UTC)
Pictogram voting question.svg Question Without a simple consensus guideline, how do we get editors to avoid changing description formatting to suit their own taste? The lack of a guideline results in slow-motion edit wars. As you can see from User talk:Look2See1/Archive_1 and User talk:Look2See1#Graphic design questions….ongoing, formatting disputes have been festering for years, without resolution. It's easy enough to say "there can't be a general-enough guideline", but we have to realize the cost of no guidelines is a lack of harmonious editing.
This is not a rhetorical question: I am open to any mechanism to settle the long-running dispute. I just thought a short consensus-based style guideline is the most helpful way of doing it. — hike395 (talk) 19:29, 18 February 2015 (UTC)
Simply respect the uploader's choice … ? I'd Symbol oppose vote.svg oppose any general guidelines that go beyond "use a metadata-compatible info template" (and probably which sections to use).    FDMS  4    19:47, 18 February 2015 (UTC)
I am not a big fan of "uploader's choice" since it is counter to COM:OWN and at least in case of PD files who is the uploader should not matter. Disagreements about format of file pages are not different than disagreements about content or format of wikipedia articles. They should be discussed on the talk page of the file, in order to reach consensus. If there are only 2 voices (the usual state) than you can ask VP or other forum for additional opinions. By the way, the disagreement about File:Old senate debate.jpg seems especially pointless since the file is a scaled down duplicate of a different file and should be deleted. --Jarekt (talk) 18:19, 19 February 2015 (UTC)
Does respecting an uploader's choice mean we should not change an uploader's description? I think adding wikilinks from words in the description to Commons galleries adds value to the project. When adding {{Information}} templates, I often rearrange descriptions added by uploaders. — hike395 (talk) 20:06, 18 February 2015 (UTC)
Only when such changes might be controversial. I don't know all (or rather any of) the details of this Look2See1 case, but if he/she changed descriptions of files he/she didn't upload and there are reasonable objections, this should be revertable without much further discussion in my opinion.    FDMS  4    21:20, 18 February 2015 (UTC)
There was this draft User:Rillke/Technical file description policy by @Rillke: about this. Jean-Fred (talk) 19:55, 18 February 2015 (UTC)
Pictogram voting comment.svg Comment, I like {{information}} and many of its helper templates, e.g., the SVG zoo now mostly down to {{igen}} + {{vva}}, or the date zoo now mostly down to one esoteric scribunto module promising to be complex, or simple stuff like {{extracted from}}, license tags, derivatives, the works. I hate artwork variants, they are far too complex. So in essence dunno, but if you plan to add an "official guideline" tag on COM:MRD count me as "support". –Be..anyone (talk) 21:08, 18 February 2015 (UTC)
  • Symbol neutral vote.svg Neutral on the proposal - one of the reasons I like Wikimedia Commons is our reluctance to bog ourselves down in policies and guidelines, and I have some reluctance to adopt a guideline which might make it more difficult (primarily for novices) to upload media or create categories. Perhaps something much simpler ("Unnecessary formatting and punctuation should be avoided.")? Having said that, I Symbol keep vote.svg Agree that the formatting that user:Look2See1 typically adds to category and file descriptions decrease readability and are unnecessary, esp when (s)he breaks down simple paragraphs into bullets (but there is no need for a bullet list). Or the unecessary emdashes -- such as this recent example when he felt the simple description "Baroque Revival style churches in the United States" at Category:Neo-baroque churches in the United States needed a dash in the middle of that basic sentence ("Baroque Revival style churches — in the United States"). Look2See1 feels that the bullets and dashes are easier on his eyes, but it's a nightmare for everyone else, and on a multilingual project there is no need to be weighing down simple English-language prose with unnecessary formatting and punctuation. Dozens of editors have tried to discuss this issue with Look2See1 over the last 2-3 years, and it's like talking to a wall. (S)he otherwise seems like a pleasant person and a capable editor ((s)he seems to have largely stopped his/her past compulsion to COM:OVERCAT), so this problem is unfortunate. --Skeezix1000 (talk) 22:02, 18 February 2015 (UTC)
  • Pictogram voting comment.svg Comment concerning italics: Please note that italics are compulsory in certain cases such as for binomial names or prefixes in chemical nomenclature. --Leyo 23:05, 18 February 2015 (UTC)
  • Symbol oppose vote.svg Oppose the proposal, although I definitely support its goals; it has good purposes, but its blanket standard would be unhelpful when many of our 24M+ files need different types of descriptions. Bold and italics are occasionally useful (see Leyo's comment), and the bulleted list at File:Jefferson Street in downtown Huntington.jpg is easier to read than prose would be. This is significantly different from turning sentences into bullets. When we have a perennially problematic user who attracts tons of opposition and ignores or attacks those who question his edits, the solution is not to create a guideline for everyone that ignores exceptional needs. The solution is to treat it like disruptive editing on en:wp, warning and then following up with blocks and bans if the warnings are ignored. Nyttend (talk) 01:01, 20 February 2015 (UTC)
  • Pictogram voting comment.svg Comment Nothing against guides and help, but more carrots, fewer sticks please. Having uploaded a lot of files, my position now is that I prefer to avoid customizing templates or text unless I do not know of an alternative.
I am guilty of "deviation", some of my Flickr batch uploads have restricted status and multiple tags as well as album names; I use a custom field to stick these in as no standard template has something that formats them in a sensible way.
By "more carrots" I have in mind:
  • better guidelines for more experience uploaders, well crafted videos would be useful to show best practice
  • more barnstars and ways of thanking those for doing a nice job on upload formatting. FP/QI and so forth is nice, but these rarely get applied to images from old archives
  • just as we have 'grades' of language proficiency, maybe we can consider a ladder of grades for those that demonstrate better application of best practices. Much nicer than threats to block and ban those that deviate from the "norm". I'm actually getting very tired of seeing policing (and criminalization) becoming the first reaction rather than collegiate working
-- (talk) 01:20, 20 February 2015 (UTC)
  • Pictogram voting comment.svg Comment I do not think a complex codification of file descriptions is necessary. I do think however that:
  • File descriptions should be straightforward, informative, well-written, and easy to read
  • They should avoid unnecessary formatting such as bullets and dashes which break up the flow of text
  • The choices made by the original uploader, especially if they are also the author of the image, should be respected
  • Changes should not be made in file descriptions unless they are clearly necessary, for instance, to add pertinent information or correct bad information
Those four statements could serve as a simple guideline if we need one. Beyond My Ken (talk) 18:08, 20 February 2015 (UTC)

It's clear that my proposal has no support and I withdraw it. However, I do like BMK's lighter-touch guidelines, above. Do other editors think his version is acceptable? — hike395 (talk) 07:30, 21 February 2015 (UTC)

, please note that lots of people have spent years attempting to work collegiately with Look2See1, but he simply doesn't care. He's proven that nothing will stop him except for blocks and bans. Meanwhile, I agree with BMK. A file description should explain what we see, noting the significant elements, and especially explaining the reason for every category that isn't necessarily obvious. This is why I'll provide a bulleted list on the occasions when I categorise for buildings' construction years. However, it needs to be useful and easy to read, written in prose unless there's a good reason to do otherwise. And definitely listen to the preferences of the uploader, especially if he asks you to stop. I know one regular user (an admin, if I remember rightly) who uses "own work by USERNAME" instead of {{own}}, and although I started replacing them with {{own}}, I stopped when he encouraged me to stop. Why can't others do likewise? Of course, expanding the description is often helpful — even when an original description is good, uploaders often aren't aware of something in the picture, and someone reusing it can often add more details. For example, when I find a photo of a neighborhood that has a US federal historic designation, I often add a note about the designation. Of course, lots of descriptions need significant improvements; sometime I ought to copy the descriptions from File:Holy Trinity Catholic Church, Beaver Falls.jpg and File:St. Mary's Catholic Church, Beaver Falls.jpg into File:Beaver Falls, Pennsylvania (8480753956).jpg and File:Beaver Falls, Pennsylvania (8480754482).jpg, respectively. Nyttend (talk) 03:19, 22 February 2015 (UTC)
I agree with the spirit, but not the content, of BMK's suggestions. While we should avoid unnecessary formatting, bullets and dashes do occasionally have their place (the problem is users like Look2See1, who scatter dashes, bullets and bold text in every sentence and paragraph like sprinkles on a cupcake). While there are many times where the choices of the uploader should be given some deference, all files uploaded here are freely-licensed, part of the project, and subject to our practices and rules about categorization, etc. This is a collaborative project, nobody "owns" any of the files, and the uploader has no veto over the input of others. This is Wikimedia Commons, not Flickr. And I just think a "clearly necessary" rule for changes to descriptions is, ironically, completely unnecessary given the nature of this project (although, admittedly and to be fair to BMK, very tempting on occasion). Ultimately, changes are decided on the basis of COM:AGF and consensus. In reality and practice, however, most people try hard to work with the uploader. We don't need to translate any of that into rules.

I agree with Nyttend's comments (esp. his examples of proper use of bullets, and his description of trying to work with Look2See1), but am puzzled by his "own work by USERNAME" example. Did he provide a rationale? The benefit of {{own}} on a multilingual project is that it automatically translates to the user's preferred language, while English-language text does not. Maybe a hybrid of "own work by USERNAME"/{{own}} might have worked. --Skeezix1000 (talk) 21:49, 24 February 2015 (UTC)

Of course Skeezix1000 is correct that no one "owns" their uploads or the descriptions written by the uploader, that goes without saying, but there is a strong feeling of stewardship when one takes a photo, or discovers one through research, prepares it for upload, researches the history or circumstances and molds that information into a coherent and cogent description. That's why I suggested that these choices should be "respected", not held sacrosanct or inviolable.

I've used bullet points on my image descriptions at times -- for instance when the image portrays multiple buildings, and I want to provide information on each of them in a separate bullet -- so I would never say that they should be outlawed, just that if there's no distinct improvement to be had by altering the existing form of the description, then there's no real reason to do it.

In the instances that brought this about, the editor making the change simply replaced the uploader's format with his own preferred format, with no particular improvement and, in fact, a degradation of the readability of the description. For me, that's a three-strikes and you're out action: no respect for the uploader's choices, substitution of the altering editor's personal preference without good reason, and a lessening of the description's quality. It would be nice if one could point to a simple rule and say "Don't do that", but I see no need for a complex bureaucratic code. Beyond My Ken (talk) 01:59, 25 February 2015 (UTC)

I would agree that the use of 'localization' templates such as {{own}}, {{size}}, and {{oil on canvas}}, as random examples, is rather different from changing the wording of a description or simply adding formatting such as bullet points. Such edits are quite useful given that this is a multilingual project. Revent (talk) 23:18, 24 February 2015 (UTC)
Again a decisive dunno, if an image has no {{information}} I feel entitled to fix this, and trim unnecessary description essays + copyright considerations in prose to a minimum, as much of it as possible with the i18n templates like {{own}}. But {{own}} is hopeless if there are two or more uploaders. Very extreme example some hours ago, this is not how I ever did it before or plan to do it again soon: old vs. new. –Be..anyone (talk) 19:20, 1 March 2015 (UTC)
@Be..anyone: I think templates that are intentionally designed to make the file's metadata machine readable (like, specifically, {{information}} and it's variants) are a rather different issue. Among other things, everyone's favorite thing (Media Viewer) </sarcasm> is broken by the lack of an information template (or a 'real' license tag, for that matter). As far as that example, nice job (but ouch). Revent (talk) 22:17, 28 March 2015 (UTC)
  • @Hike395: I don't think there was any consensus generally for trying to translate current practices into a guideline, even a loose one, but I think the one consistent message from this discussion is that the Look2See1 formatting which concerned you is inappropriate, and contributors can point to this discussion (I see that you alerted Look2See1 of this discussion at the beginning, but (s)he chose not to participate) when they are removing such extraneous formatting. --Skeezix1000 (talk) 18:05, 3 March 2015 (UTC)

Use javascript to make a more suitable advanced search[edit]

The advanced search feature, isn't very advanced. Have we considered using javascript to add more advanced options specificly suited to commons? Our options are limitted somewhat due to what Cirrus supports (Perhaps this will change. Probably there are many features which would be useful here which aren't much effort. Making OR queries work would be really helpful here, and doesn't sound like that big a thing. Of course the big feature is transitive category search, which is probably not happening in Cirrus anytime soon. Maybe someone could make an extra tab on search specificly for category intersection which runs the query through FastCCI...).

To be concrete, I made a prototype (which may or may not follow commons coding conventions, if commons has coding conventions). To try it out, add importScript( 'User:Bawolff/search.js' ); to Special:MyPage/common.js. It adds fields to https://commons.wikimedia.org/w/index.php?title=Special:Search&profile=advanced so that you can specify to search only in categories, exclude things from certain categories, search by filetype (Sort of, it only checks that the extension is anywhere in the title, might have false positives), and limit to either PD or CC licenses. Obviously this still isn't very flexible, but I think its an improvement over just showing the one box.

Thoughts? Bawolff (talk) 22:17, 3 March 2015 (UTC)

I just added it to my common.js. If it is buggy, I’ll nag you. Face-wink.svg -- Tuválkin 02:28, 4 March 2015 (UTC)
(Pinging Bawolff…) Well, actually, it seems to wipe the search box after a queary, at least when the previous search (from which the search term is expected to be inherited from) is done through the basic interface searchbox (in Monobook), or through a "search this" link in a redlink page. Only happens to me? -- Tuválkin 08:48, 10 March 2015 (UTC)
@Bawolff: Nice. Please let me know when the script is stable, so that i can implement it as a gadget. --Steinsplitter (talk) 08:59, 10 March 2015 (UTC)
@Tuvalkin: That should be fixed now. @Steinsplitter: Its stable now. I don't plan to add anything else unless changes happen in cirrus allowing more specific queries. Bawolff (talk) 20:00, 10 March 2015 (UTC)
This script is now ✓ implented as a gadget. Opt-in here: Special:Preferences#mw-prefsection-gadgets --Steinsplitter (talk) 19:42, 28 March 2015 (UTC)

License templates for the Mozilla rebranded software by Debian[edit]

I just created the template {{User:Amitie_10g/Templates/Mozilla-Debian_MTL}}, that is a modified version of the {{MTL}} template, that indicates that is for the Mozilla software rebranded by Debian (Iceweasel, Icedove and Iceape) and indicates that these software is still licensed under the MPL/GPL/LGPL tri-license.

Is this template useful? Do I move this to the Template: namespace?

Thanks for your comments. --Amitie 10g (talk) 16:47, 20 March 2015 (UTC)

Confusing, so Iceweasel would be {{MTL}}, and your thingy is for what else? And what exactly is the difference, at the moment I see MPL 1.1 == MPL 1.1, GPL == GPL, and LGPL == LGPL, the only difference is that you mention and wikilink Debian. If that's not only promotional, how about a parameter debian=yes or similar in {{MTL}}? –Be..anyone (talk) 04:18, 26 March 2015 (UTC)

Make Categories more visible on file description pages[edit]

Categories have evolved to be our main tool for organizing our content. However, they are by default placed at the very bottom of the file description page, where hardly anyone who's not looking for them will ever find them. That's probably because that's how it's done at Wikipedia, where they play a minor role compared to Commons. In order to make non-regular users more aware of their importance, I suggest to make categories more visible at file description pages, hoping that this may encourage uploaders to better categorize their images and help to slow down the increase of our already enormous backlog of not or badly categorized files. A simple way to do that would be to move them up on the file page by switching on one of the already existing gadgets Place categories above all other content or Place categories above content, but below image on file description pages by default. What do you think? --El Grafo (talk) 10:33, 23 March 2015 (UTC)

  • Symbol support vote.svg Support (either gadget). -- Tuválkin 11:13, 23 March 2015 (UTC)
  • Symbol support vote.svg Support. Categorization, as part of content curation, is, IMO, the most important thing to do here. José Luiz disc 11:32, 23 March 2015 (UTC)
  • Symbol support vote.svg Support Below the image would be better, I think - the file itself is more important than the categories. It's arguable whether the description or the categories are more important, but the upload log and Exif data are purely technical info. However, splitting them would mean re-designing those sections somehow - is that possible, seeing that they are auto-generated? YLSS (talk) 15:51, 23 March 2015 (UTC)
    I don't know if categories are more important than the description, but they don't take too much space and wouldn't distract from the description if placed above it. You can go to the gadgets settings in you preferences and enable one of the gadgets I mentioned above to try it our for yourself (they are in the Interface: Files and categories section). Putting the categories below the description would probably mean putting them above the file history and below anything directly editable on the file page, which may contain a huge amount of various templates (FPC, WLM, etc.), so I don't think we would gain much visibility. I don't think it would be possible to display the categories between the description and the licensing section, for example. Or at least it would be much more complicated than just setting an existing gadget as default. --El Grafo (talk) 10:55, 24 March 2015 (UTC)
    I know, I know, just throwing in some things to consider as an alternative. I agree with everything you wrote, it's only that the description sometimes can (and ideally should) contain far more information than any categories, including some more precise information. Moreover, the categories are (currently) in English only, so they won't be helpful for those who don't know the language; while the description can (and should) at least include something in the local language WRT photo subject. But the other fields of {{Information}} are less informative, yes. YLSS (talk) 12:09, 24 March 2015 (UTC)
  • Strong Symbol support vote.svg Support. I rely on the categories when using Commons, wouldn't know how to do use it efficiently without them. I have them displayed below the image, which I think is the better option. -- Deadstar (msg) 16:05, 23 March 2015 (UTC)
  • Symbol support vote.svg Support I like Place categories above all other content option. --Jarekt (talk) 16:26, 23 March 2015 (UTC)
  • Symbol support vote.svg Support -- Stephan Kulla (talk) 01:34, 24 March 2015 (UTC) PS: The JavaScript-Code $("#siteSub").after($("#catlinks")); does what you want. You can place this code in the personal or global JavaScript files.
    No need for that, as you can already through the preferences with the two "gadgets" I mentioned above. --El Grafo (talk) 10:40, 24 March 2015 (UTC)
  • Symbol support vote.svg Support of course; personally I would prefer above content, but below image. --El Grafo (talk) 10:42, 24 March 2015 (UTC)
  • Symbol support vote.svg Support. Can be useful for users in case of lack in the description or file name.-- Geagea (talk) 09:09, 26 March 2015 (UTC)
  • Symbol support vote.svg Support below the image. This would also be useful to more prominently alert readers (and uploaders) to the absence of categories, since files needing categories are categorized as such. BD2412 T 15:03, 26 March 2015 (UTC)
  • Symbol support vote.svg Support The actual tool Place categories above all other content enabled per default (only for the file and category namespace). -- Christian Ferrer 07:57, 29 March 2015 (UTC)

Discussion[edit]

Pictogram voting comment.svg Comment I suggest a gadged (enabled per default), only for the file and category namespace. thoughts? --Steinsplitter (talk) 13:23, 24 March 2015 (UTC)

That might indeed be nicer, but I've had the above all content but below images enabled for years now and I don't really mind having categories at the top of other pages like – say – this one or FPC at all. If someone could do this, I would welcome it, but I wouldn't say we can't live without it. --El Grafo (talk) 15:30, 24 March 2015 (UTC)
  • I'd prefer a MediaWiki extension doing that to avoid Jumping Content. Same goes for the user uploads link. -- Rillke(q?) 15:13, 24 March 2015 (UTC)
No idea what you mean by Jumping Content or the user uploads link, but same as above: If someone was willing to do that as a proper extension, I'd welcome it. But if that leads to a "someone should do this, let's file a bug report and wait another 5 years" then I'd rather have the quick&dirty approach. --El Grafo (talk) 15:30, 24 March 2015 (UTC)
The bar containing the categories is moved after first content is displayed. If you have a German interface the link next to your contributions was called Hochgeladene Dateien, now it's Uploads, to - and it tends to appear there after all the other links, at least under certain circumstances. -- Rillke(q?) 08:50, 26 March 2015 (UTC)
A extension sounds reasonable. Agree that JS is not good in this case. --Steinsplitter (talk) 08:08, 29 March 2015 (UTC)
  • Symbol oppose vote.svg Oppose, new users arriving here are already completely confused where they are (no, this is not wikipedia, let alone enwiki), frustrated by never working upload wizards with 1001 better alternatives to pick from which might sometimes work, and thousands of right or wrong licenses triggering deletions or erroneous accusations to be thieves. That's not the month or day where they need to figure out categories. –Be..anyone (talk) 04:26, 26 March 2015 (UTC)
    Of course it is. I always wanted to suggest that both the default form and the UploadWizard do not accept files without some (existing!) categories added, like they do if no license is chosen, — but that's another topic for another discussion. YLSS (talk) 10:15, 26 March 2015 (UTC)