Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
introduction
Help deskVillage pump
copyrightproposals
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P · COM:VPP

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?

 

Upload Wizard feedback[edit]

I have just uploaded 70 or so shots using Upload Wizard. The tech boys have done a great job- with respect can I add a few thoughts for improvements.

  1. On the select images to upload button- could we also just drag and drop selected images on the button as well as directory select.
  2. on a shakey line- the tab crashed while I was adding description- Firefox asked did I want to reload the tab?- obviously yes- and I am thrown back to the adding images page (where I was 40 minutes earlier)! Could we tweak the code so I am thrown back to where I was on the description page. It was a bad line. I made the same mistake by attempting to refresh the page to display some images that weren't thumb nailing.
  3. now a bigger one- I use shotwell as an image editor- could we add the facility to add simple image editing facilities to the wizard- crop, straighten principally or a link out to our favourite editor.

CheersClemRutter (talk) 21:00, 7 August 2018 (UTC)

After blocking[edit]

Currently, the eponymous section of the policy provides that the sysop must

I propose an amendment that these points are not mandatory for any account of a known or evident serial abuser where this account has no positive contributions on Commons. “Accounts of a serial abuser” include (but are not limited to) those globally lockable by stewards as LTA (long-term abuse) or similar reasons.

Many sysops don’t follow these procedures wrt sock puppets for many years. For block-evading vandals I deem {{indefblockeduser}} or similar unnecessary, since such worthless accounts only clutter categories, hindering possible review or research. Incnis Mrsi (talk) 07:43, 12 August 2018 (UTC)

  • Symbol support vote.svg Support.   — Jeff G. ツ please ping or talk to me 03:38, 13 August 2018 (UTC)
  • I support the general point made, that all blocked accounts should receive a user block template which advises why the block has happened and how to appeal. It is less important that an administrator is required to watch the user page, however there has to be a system to ensure that appeals are not overlooked by accident. I disagree that accounts which are thought to be run by a LTA may opt out of having a formal notice or an appeal process, regardless of who is doing the blocking or the evidence, there are many years of evidence showing that accidents and misunderstandings have often lead to wrong accounts being caught up in an anti-spam or anti-sock campaign. -- (talk) 08:17, 13 August 2018 (UTC)
    First of all, it is indeed important that “an administrator is required to watch the user page” – it discourages some of them from hiding behind others’ backs. Misidentifying an account as a “known or evident” LTA must be qualified as a sysop error. Where your data about frequency of this kind of error come from? If a sysop has too bad judgement wrt blocks, then is it not a problem specific to user_talk. Of course, you can pick several purely accidental mishaps off myriads of LTA blocks, but would it be a significant problem in the context of where this account has no positive contributions on Commons? This and this are excluded by a huge margin. It is a very low-probability misfortune for a good-faith user to have his/her account identified as LTA before any positive contributions appear. And even in this case an appeal is still possible (Meta-wiki, posting as an IP, Email…). Incnis Mrsi (talk) 11:09, 13 August 2018 (UTC)
  • A long time ago I was on a forum and I got angry and wrote whole bunch of mean things repeatedly, in the morning I realised that I probably have overreacted, but was not able to even contact anybody to tell them that I apologise for this occurrence. I know that here you are distinguishing a single act of anger from the "long-term" abuse, but often these things tend to be left to interpretation. Sometimes I see that people equate abuse to uploading media to a category that others consider well saturated (categories of sunrises, roads, body organs... especially sexualised ones, etc). So a person who is honestly trying to contribute may easily be first threatened with the block, and after that individual (quite rightly, in my opinion) will decide to just move on and not engage is flame war and simply continues uploading content can be blocked with no way to even demand the explanation or ask how to upload educational media differently. Now with sockpuppets or throw-away accounts the issue is quite different, but then again, is there really no way somebody can be mislabeled as a sock? ℺ Gone Postal ( ) 09:37, 13 August 2018 (UTC)
    I don’t understand how this forum memoir is relevant. Again, the amendment is not about “abusers” in general, but about 1) serial abusers, 2) accounts thereof having no positive contributions. Also see my comment above. Incnis Mrsi (talk) 11:09, 13 August 2018 (UTC)
    Did you read past the first sentence? Because you have simply written the first part of my second sentence in different words. ℺ Gone Postal ( ) 15:54, 13 August 2018 (UTC)
  • Symbol oppose vote.svg Oppose, the term "long-term abuse" has no actual meaning and every user (except for those banned by the Wikimedia Foundation) should be able to appeal or at least understand why they're blocked and how and where they can appeal. I agree with Gone Postal 📯 about the mislabeling, in fact a good faith user who uploads aviation related images could be mislabeled as a Russavia sock (something INeverCry did a lot in their day). Maybe we should split the categories and create "Category:Commons sockpuppets blocked in August 2018" for example to make sure that "main account" categories don't get overpopulated. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:44, 20 August 2018 (UTC)
    @Donald Trung: indeed, the bulk of blocked accounts—on Commons or elsewhere—pertains to sock puppeteering (including a common block evasion). Again, the proposal is not about puppets in general, but serially manufactured vandalistic filth. Incnis Mrsi (talk) 07:38, 31 August 2018 (UTC)

No longer allow OFL as the only option for symbol-only uploads[edit]

While the community is bending backwards trying to prove to itself that GFDL is unfree we apparently have absolutely no problems allowing Open Font Licence (text here). This licence in its preamble clearly states "The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves" and then the condition section repeats that limitation "Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself." As such it is a non-commercial licence when used for font elements (which it often is).

Now I do not argue that the images should be outright deleted. Some of them (for example File:Libertine sample.svg and File:Blason ville fr Laurac-en-Vivarais (Ardèche).svg]) are also available under the free licence. Some of them are quite complex images simply utilising elements of the font and licencing the font as a part of the whole, in such case it becomes the same argument as COM:DM or COM:Stamps, where some of the individual elements maybe non-free but the work as the whole is non-the-less free. However, images like File:Font Awesome 4.7.0 icons.svg where the only licence is {{OFL}} and the only content is actually the presentation of the font would be disallowed.

I propose to add the following text to the licence template: "Note: This licence is for the font within the work and does not apply to the work as the whole. OFL is a non-commercial licence and you are not allowed to extract the elements of the font for the purposes of using them if you intend to use them commercially. The work as the whole must also provide its own licence."

We should also recategorise this licence as an unfree licence. ℺ Gone Postal ( ) 02:17, 28 August 2018 (UTC)

  • To be transparent, some of the points of the opposing opinion are listed on the talk page of the template. I am copying them here
I saw the Deletion requests. I think the prohibition of selling the font itself doesn't necessarily mean it is non-free because:
  • It is approved as a free license by Free Software Foundation and by Open Source Initiative. See SIL Open Font License, FSF, OSI, Open Source Definition, The Free Software Definition.
  • You can sell a software package that includes the font according to OFL's FAQ.
  • Why won't the OFL let me sell the fonts alone? Because "the only people who ought to profit directly from the fonts should be the original authors" according to OFL's FAQ.
  • Some people consider that GPL'd software itself cannot be sold, either. In this article, the author thinks "you can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself". --Tomchen1989 (talk) 10:01, 19 August 2015 (UTC)


Do we even allow direct uploads of fonts? Pretty sure we would only have usages of those fonts in other works, so not sure those usages would matter either way for that clause of the license. And if that many other organizations think the license is free, not sure we should be different. Carl Lindberg (talk) 17:20, 2 September 2018 (UTC)
  • There is a big difference between a working font and a collection of glyphs extracted therefrom. Selling a graphic that uses a font, or even a complete specimen, is not selling the font: none of the ‘machinery’ is included that selects & positions the characters, and would optimize their rendering on a device in which the font is installed. Fonts are generally considered a form of software, which I would argue is out of scope here. (But it would be great if the WMF had better font support on the SVG-rendering servers, in both breadth and depth, so to speak.) Even commercial fonts usually allow embedding of their output in other works, such as PDF documents. At any rate, I think a limitation that applies solely to ‘live’ fonts is irrelevant here.—Odysseus1479 (talk) 04:04, 9 September 2018 (UTC)

Template:Dont recreate[edit]

This template takes one parameter - the page that has been re-uploaded. In general, most of the time I find that the uploader will change the file name (obviously in the hope that it will be missed...). I would like to suggest that it be changed to have a second (optional) parameter (the original file name), so to remind the user what the page was called, and suggest he requests undeletion of the original. So for example one would post {{subst:dont recreate|File:Martin Poch.jpg|File:Martin Poch (2017, foto Jana Plavec).jpg}} to the user's talk page Ronhjones  (Talk) 19:51, 28 August 2018 (UTC)

Empty categories[edit]

Commons talk:Criteria for speedy deletion#Speedy deletion of **empty** categories seems to result into a solution, to replace the current criterion "Empty category" with a new criterion "Unuseful empty category". Previous discussions (e.g. Commons talk:Criteria for speedy deletion/Archive 1#Empty categories, Commons talk:Criteria for speedy deletion/Archive 1#Criteria c1) had no effective conclusion, but as I can see, they tend to similar opinion.

You can help to improve the criterion or its wording before its incorporation to the policy text, or just support or oppose the change.

@Guillom, Thryduulf, Slaunger, Croquant, Lx 121: @Blurpeace, Saga City, Axpde, Fetchcomms: --ŠJů (talk) 15:00, 8 September 2018 (UTC)

  • Based on that discussion, I think the only reason empty categories should be speedily deleted is if they (a) were created by mistake; (b) they are abusive; (c) are obviously and unquestionably incorrect; (d) are vandalism or used only for vandalism; or (e) the sole author requests deletion and the category hasn't been used by others. These situations are all covered by other criteria (a) is G1, (b) is G3 (c) is C2, (d) is G3 and (e) is G7, so there isn't a need for a separate criterion. What is and is not an "Unuseful" category in other circumstances can only be determined by a discussion. So repeal speedy deletion criterion C3 entirely. Thryduulf (talk) 12:12, 12 September 2018 (UTC)
    • As I've written in that discussion: +1. Sebari – aka Srittau (talk) 16:01, 12 September 2018 (UTC)
  • Symbol oppose vote.svg Oppose: a) It's not a hard job to re-create a deleted category if it is needed. b) An unuseful category had to be defined exactly and that would take a long time I think. c) It's an illusion to discuss the deletion of an empty cat, look at the CfD and DR backlogs. My 2 cents --Achim (talk) 19:50, 12 September 2018 (UTC)
    • @Achim55: Backlogs could be avoided by stating that unopposed deletion nominations can be closed as delete if the following people have been notified of the nomination: The creator, those with significant edits to the category or category talk page, any known major contributors, anyone who participated in previous discussions about the category (in most cases the latter three groups will not contain any members, so this is not onerous). Thryduulf (talk) 16:23, 15 September 2018 (UTC)

Allowing cross-namespace redirects from (Gallery)/(Main) to Category[edit]

I've been informed that cross-namespace redirects are not allowed on Commons (tho I can't seem to find the documentation). Even if we want to have that as a rule generally, I think a big exception should be from the main/gallery namespace to the category namespace. Since we mostly use categories here and have only a fraction of images as galleries, it will be very useful for incoming links and search until such time as we really populate that namespace in earnest. I think this has high value and I don't see any immediate downsides. What does everyone else think? —Justin (koavf)TCM 03:21, 9 September 2018 (UTC)

  1. Symbol support vote.svg Support, I actually wanted to propose this myself a couple of months ago but got distracted by other projects. It would be very handy if mainspace pages could direct to categories as it would make searching a lot easier, and this would also allow for names in different languages to be redirected to the same subject. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:22, 10 September 2018 (UTC)
  • Pictogram voting comment.svg Comment If you ask me: move all galleries to a dedicated Gallery: namespace and automatically redirect the "main" namespace to Category:. --El Grafo (talk) 11:53, 12 September 2018 (UTC)
  • Symbol support vote.svg Support per nominator. In addition cross-namespace redirects between Commons: and Help: namespaces should be freely permitted as there is overlap between them (see for example the location of pages in Category:Commons help). Thryduulf (talk) 23:34, 12 September 2018 (UTC)
  • Symbol support vote.svg Support per nominator. There are times that a simple gallery is best replaced with a category, but we should possibly still prefer incoming links go to the gallery page until such time that a better curated gallery is made. Carl Lindberg (talk) 01:28, 13 September 2018 (UTC)
  • Symbol support vote.svg Support - Jmabel ! talk 15:42, 13 September 2018 (UTC)
  • Symbol oppose vote.svg Oppose - it gives the false impression that a gallery page exists. Also, allowing this would cause a situation in which random pages redirected to categories. If we want non existing gallery pages to link to the category, we should request a software change instead. Either all non existing gallery pages should redirect to the category or none. Jcb (talk) 15:54, 13 September 2018 (UTC)
  • Symbol support vote.svg Support El Grafo's solution, all of the main namespace should be categories, and the old main should be moved to Gallery:Gone Postal ( ) 16:36, 13 September 2018 (UTC)
  • Symbol oppose vote.svg Oppose per Jcb. Good idea, bad way to implement it.--BevinKacon (talk) 22:04, 13 September 2018 (UTC)
  • Pictogram voting comment.svg Comment My first choice is to redirect all non-existent galleries to the category, if the category exists, per Jcb. If the developers tell us this isn't feasible, I'll support this proposal to allow redirects. Guanaco (talk) 00:52, 14 September 2018 (UTC)
  • Pictogram voting comment.svg Comment Some websites with encyclopedic tendencies gives links to other websites that can talk about similar subjects. Those links are, I think, given in an automatic way, with a string of characters (a part of the web adress) and of course the name of the subject treated. I saw it several times, but I remember only one precise example "mycobank". Example, in the page Coprinopsis candidata you go to the section "Link out to external resources" and you will see that a list of links is given automatically. Then if you click on "wikimedia" you come to [1]. However we have good media files for this subject. I think is is really a kind of issue, and I think the sentence "You can search for this page title in other pages or create this page." is far not enough. But I'm neutral on the way to solve this. Christian Ferrer (talk) 17:10, 14 September 2018 (UTC) I add I think that this page should clearly say that we have media files within a existing corresponding category. Christian Ferrer (talk) 17:21, 14 September 2018 (UTC)
A kind of solution could be the creation of a Wikimedia Commons template, a bit as {{Wikidata Infobox}} but with different presentation and specifically intended to the non-existing galleries. Example I just created manually Dytaster, however the totality of what is displayed (included the links to the images) is available in Wikidata, therefore this gallery could very well have been created automatically. It's a fact, and everyone agrees, that not all categories can have matching galleries, however maybe that all subjects that are worth to have both a Wikidata item (therefore notable enough) and a category here, should have a gallery. And when this gallery don't exist, it will created by a bot with a dedicated template which would bring relevant content from Wikidata, and then, we will keep the possibility to add manually some content in addition to the template, or to replace manually the template by some content. This should solve the issues for the incoming links. @Mike Peel: who is used to relationships Wikidata/Commons. Christian Ferrer (talk) 08:39, 16 September 2018 (UTC)

{{DEFAULTSORT}} for UK churches and pubs[edit]

It's my belief that categories are there to assist users in finding media we host. So it should be a given that users should find media where they expect to. However, we seems to have inherited a system from en:WP of default sorting churches and pubs by location first, then name. So "St Bernard's church, Sometown" is defsorted so that it appears under "S" rather than "B" (obviously sorting under "St" is unhelpful because most would then sort under "S", which would be overwhelmed and thus useless). Similarly, "The King's Arms, Anytown" appears under "A" rather than where a user would expect to see it, i.e. under "K" (Again, "The" is redundant). There is one user who persists in perpetuating this error, as I see it, claiming that "it's the way it's always been done" is a taxonomically valid reason for the current system. So my proposal is this:

Churches and public houses in the United Kingdom should be sorted by name first, then location, except where the name is part of the category, in which case sorting by location is used..

I realise it may take some time to correct this error, but I don't see that as a reason for not doing it, as I'd prefer to get things right than confound our users, and I invite all to participate in a straw poll to determine consensus. Rodhullandemu (talk) 08:32, 10 September 2018 (UTC)

@Rodhullandemu: Who is the "one user"?   — Jeff G. ツ please ping or talk to me 11:49, 10 September 2018 (UTC)
@Jeff G.: I don't want to embarrass him by naming him, but I confirm he has been made aware of this proposal. Rodhullandemu (talk) 17:10, 10 September 2018 (UTC)

Support[edit]

  • Symbol support vote.svg Support As proposer. Rodhullandemu (talk) 23:57, 10 September 2018 (UTC)
  • Symbol support vote.svg Support Because we already have Category:Churches in the United Kingdom by city which makes it possible to find what you are looking for if you only know the city. ℺ Gone Postal ( ) 17:57, 10 September 2018 (UTC)
  • Symbol support vote.svg Support The location isn't part of the name, for "The King's Arms, Anytown" it would be under "King's Arms" then under "Anytown" (such as here when the name of the topic is the same, we then go by location), since the "The" is not useful, the same with "St Bernard's church, Sometown" where the "St" is redundant it should be under "Bernard's", then "Sometown". Crouch, Swale (talk) 12:02, 14 September 2018 (UTC)

Oppose[edit]

Technical proofment from Wiki Commons Category (used as url) to Wikipedia[edit]

I suggest that a categegory should be checked in Wikipedia automatically before someone (admins) edit or erase the category in Wiki Commons.

Picture galleries in Wikipedia (|Commonscat=) needs a category, other possibility seems to generate special category (maybee hidden) or marks the commonscat (with colour) to seperate them from only text based material. Otherwise nexus and the function will get broken.--Hans-Jürgen Neubert 12:20, 12 September 2018 (UTC)(talk)

Hans-Jürgen, I'm sorry but I didn't get it. Pictogram-voting-question.svg Question: Meinst du, dass überprüft werden sollte, ob eine Commons-Kategorie von Wikipedia aus verlinkt ist, bevor sie auf Commons gelöscht bzw. umbenannt wird? --Achim (talk) 19:58, 12 September 2018 (UTC)
Exactlyǃ Genau das... siehe hier als ID-Beispiel "D-5-73-134-60"

--> https://de.wikipedia.org/wiki/Liste_der_Baudenkmäler_in_Zirndorf

https://commons.wikimedia.org/w/index.php?title=Category:Leichendorfer_M%C3%BChle&action=edit&redlink=1

Die meisten Anwender suchen in Wikipedia (Reader, read only), nicht Commons. In Commons werden hingegen die Zusammenhänge von den Bilderlieferanten (Quelle und Ziel) erstellt (Writer). Ein admin kann auf wikicommons anscheinend bisher nicht erkennen ob der Inhalt in wikipedia bereits genutzt wird.
Er müsste bei Änderungen beide Seiten bearbeiten, erst die auf commons, dann in Wikipedia und zumindestens die Material-Galerien snchronisieren.Es geht hier nicht um "leere" Kategorien (was ja gar nicht möglich ist) und auch der Hinweis "the only contributor" macht logisch keinen Sinn, einer muss ja anfangen. --Hans-Jürgen Neubert 20:19, 12 September 2018 (UTC)(talk)

At this time a solution is not feasible. The commons database contains a table called globalimagelinks that shows the use of images in other wm wiki projects. So one can see quickly where an image is in use (example: Special:GlobalUsage/Puchtastraße_47_001_(Cadolzburg).jpg). That doesn't work for categories because unfortunately there is no table globalcategorylinks. So one had to work the other way round looking up all of the ~180 wiki databases whether or not there is a link inside the iwlinks or externallinks tables pointing to the commons cat, what might take up to a few minutes per category name and thus is not practicable. I hope that one day the commons db will have a table globalcategorylinks or even the existing globalimagelinks will be extended to other namespaces. --Achim (talk) 12:27, 15 September 2018 (UTC)

GFDL deprecation concerns[edit]

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. To allow archiving Guanaco (talk) 17:23, 17 September 2018 (UTC)