Commons:Village pump/Proposals

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

Shortcut: COM:VP/P· COM:VPP

Community portal
Help desk
Village pump
Administrators' noticeboard
vandalismuser problemsblocks 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?



The page Special:UnusedCategories isn't very useful the way it is because category redirects are there listed too which are of course unused by this point of view. Therefore imo it would be better if this page didn't contain category redirects. --Achim (talk) 10:10, 1 August 2015 (UTC)

Achim I agree and so do a lot of other people. There has been several requests to fix this but its not very high on the developers list so it may be a while. Reguyla (talk) 21:31, 30 August 2015 (UTC)
Problem is that MW doesn't really understand the commons notion of a category redirect. If they used normal #redirect syntax, this would be trivial, but that's kind of broken for categories. Bawolff (talk) 09:38, 12 September 2015 (UTC)
Are there any reasons why a category page can't have both? #redirect for mediawiki (not only for this but for search functionality) and {{category redirect}} for stuff like HotCat? sısɐuuǝɔıʌ∀ (diskuto) 09:34, 19 September 2015 (UTC)
Yep. A hard redirect will remove it from Special:UnusedCategories, as well as assist in search functionality, without breaking anything, near as I can tell. Should we have a bot add these? sısɐuuǝɔıʌ∀ (diskuto) 08:18, 27 September 2015 (UTC)
What about disambiguation categories? --Zhuyifei1999 (talk) 13:35, 27 September 2015 (UTC)
Hmm, good question. We could modify {{Disambig}} so that every disambig category contains itself, and change the counter of Category:Non-empty disambiguation categories from more than 0 to more than 1. I don't think that'll break anything else? sısɐuuǝɔıʌ∀ (diskuto) 17:47, 27 September 2015 (UTC)

SVG help button[edit]



I'm trying to improve usability of SVG contribution to Wikipedia. Since SVG is troublesome and buggy as I explained here, I wanted to improve this by adding a "SVG help" button to file description pages in case of SVG. Additionally it will only be visible if a loggedin user is visiting this page so it will have a small impact to the majority of visitors on commons. Since it is overall a simple task I've hacked a prototype of it: User:Menner/svg-button.js. It is a button with a pull down menu and four options to choose.

Can such a script be embedded on Commons by default? --Menner (talk) 16:47, 22 August 2015 (UTC)

My suggested prototype has evolved and I would call it ready for productive use. --Menner (talk) 07:14, 19 September 2015 (UTC)




  • I think it should be implanted in MW directly instead of loading it via resource loader. But i think it will take ages until the wmf is implanting this in mw, so js would be a solution. The script does not support i18n. --Steinsplitter (talk) 09:54, 23 August 2015 (UTC)
Its too Wikimedia specific to be implemented in MediaWiki generically. Its possible that it could be implemented as a php extension that's only installed on wikimedia wikis (Or included in WikimediaMessages extension), but honestly, its probably a lot easier just to do in js. Bawolff (talk) 07:06, 24 August 2015 (UTC)
Obviously there is no general refusal of such a SVG button script. How can I start the vote/discussion to add this on commons as default by every user? -- 06:13, 31 August 2015 (UTC)
Hello? How will this proposal proceed? --Menner (talk) 19:14, 7 September 2015 (UTC)
@Menner: The script still does not support i18n. --Steinsplitter (talk) 10:03, 19 September 2015 (UTC)
@Steinsplitter: The help pages and the rest of the technical web are neither fully i18n. What kind of i18n do you request?--Menner (talk) 11:55, 19 September 2015 (UTC)
There should be a way to translate the makepLink. --Steinsplitter (talk) 11:59, 19 September 2015 (UTC)
i18n happens before calling makepLink and not everything going into it needs translations due to given Terms. -- Mennerk aka 14:03, 19 September 2015 (UTC)
But only the links are i18n. Not the text of the link? --Steinsplitter (talk) 14:14, 19 September 2015 (UTC)
When there is a link destination with translation then the text of the link is also i18n. -- Menner (talk) 07:20, 20 September 2015 (UTC)
Also I strongly oppose the current position of the button – already the crappy MediaViewer button is annoying the hell out of me. File description pages are for the file description. They should only contain specific information on the current file. Everything else is navigational and should therefore go into one of the navigation bars (possibly adding it to the #filetoc would beacceptable like the Stockphoto gadget does). Otherwise we're pushing down the information people want to actually see when visiting a file description page! --Patrick87 (talk) 11:11, 19 September 2015 (UTC)
The button is only visible to loggedin users and further only on file description for SVG files. I'm not pleased with #filetoc. The Add note and the Media Viewer can go to the no ones watching because it is useless area. They make every file descriptions popping around while loading. -- Menner (talk) 11:55, 19 September 2015 (UTC)
That's what I'm talking about! If every extension/gadget just carelessly adds buttons below the preview image sooner or later we have more buttons on our file description pages than we have file descriptions.
Since you basically seem to agree with my I'm afraid I have to ask though: Why treat your button differently than the others you dispise? If a button is useful or useless depends on the specific user. I (logged-in Face-wink.svg) would not need the SVG help button – I know my way around SVGs – and I would think of it as "useless area" as you think of the MediaViewer/Add Note buttons as useless area. Other users certainly will profit from those buttons. Therefore we have to find a way to include them seamless into the navigational areas given to us instead of trying to judge by usefulness which is highly subective as pointed out above. --Patrick87 (talk) 12:41, 20 September 2015 (UTC)
I'm asking to treat the SVG button equal to other gadets. If previous things got that place I have the same rights. I even think the other (especially add note) are less important. Just look at how many people already find their way to the help page although it is "hidden" to the common uploader. It has nearly as much visits as Commons:Upload help according to which is very prominently placed at the Upload Wizard.
I could imagne to further limit the visibility of the SVG Button to the last uploader if there is support to gather last uploader.
-- Menner (talk) 16:57, 20 September 2015 (UTC)
"I'm asking to treat the SVG button equal to other gadets.": phab:T113177, MediaWiki talk:Gadget-ImageAnnotator.js#Position_of_the_.22Add_a_note.22_button. I for my part surely want to treat them equally Face-wink.svg. That other Extensions/Gadgets got their button there does not mean that was the right decision... --Patrick87 (talk) 17:27, 20 September 2015 (UTC)
I see options to reduce visibility of SVG button to the last uploader. I'll choose the best and implement it after the button gets accepted. I don't see other area as a option. Tools are gathering already there and users aren't used to look elswhere for that reason. Cleaning-up MediaWiki is not the job of a Tool with very little visibility. -- 2A02:810D:2C40:13F8:4848:9B95:A258:6F6C 17:49, 22 September 2015 (UTC)

Creation of PD template for Korea between 1910 and 1945[edit]

I found an old korean picture from the 1930s. Discussing the actual copyright status in COM:VPC, I propose to create a PD template for korean pictures (in my sandbox) taken/published between 1910 and 1945 (when Korea was occupied by Japan and before its splitting in the two current States), in similar way as {{PD-China}}.

For now, the tag shows texts indicating that the work is in the PD in the three countries, in Japan, the Republic of Korea and the Democratic People's Republic of Korea, and the three license tags {{PD-Japan-oldphoto}}, {{PD-South Korea}} and {{North Korea}}.

How can we improve this license tag? and more important, is actually viable to implement it? Please discuss, is very important to the several korean works unproperly licensed. --Amitie 10g (talk) 03:45, 26 August 2015 (UTC)

The tag should not say "taken" -- if photos were published elsewhere, that becomes the country of origin, not one of the Koreas. Also, I'm not sure I would include North Korea here. It appears they were not a part of any copyright treaty until 2003, and their law is from 2001. I have no idea what that law did to existing works... If they retroactively restored everything, then they have 50pma terms which cannot be guaranteed to have passed yet. There are no provisions in the law that I can see about what to do with existing uses of previously OK-to-use works, which you would normally expect if protection was being created for existing works. So, maybe it only applies to works published 2001 and later. It may be a law more for show than actual practice as well, which means it's anyone's guess what their protection for pre-2001 works is. Really, using the South Korea tag is probably enough for Commons purposes, since it was at least simultaneously published there, and that country probably has the shorter term anyways. Could add Japan I guess too.Carl Lindberg (talk) 07:15, 26 August 2015 (UTC)
Well, then I'll remove the DPRK, leaving just RoK and Japan, but I still considerig to keep the term taken, because is part of the {{PD-Japan-oldphoto}}; both term may coexist depending the date of making and publishing, IMHO. --Amitie 10g (talk) 09:14, 26 August 2015 (UTC)
No, Carl is correct, "taken" should not be in the summary at the top; this template is only appropriate for works that were published between 1910 and 1945 in occupied Korea. Works that were created between 1910 and 1945 in occupied Korea but published anytime or anywhere else should use the copyright template for where they were published (since the Berne convention defines the country of origin as where something was first published). For example, imagine a photo taken in 1940 in occupied Korea by a photographer who died in 2010 but first published in 2006 in the U.S. Such a photo could not use your proposed template as the photo's country of origin would be the U.S. and since the U.S. is pma+70, it's copyright would not expire until 2080. —RP88 (talk) 20:00, 26 August 2015 (UTC)
Whm, Carl is right, considering the overlapping the conditions of the both the Copyright Law of Japan and the RoK. Therefore, I added at the bottom the following centense
«This license applies only to works created in Korea and first published in that country. For works first published outside Korea, please use {{PD-South Korea}} only.»
Therefore, this template applies only for works first published (and created according to the Japan Copyright Law, but that term is somewhat questionable) in Korea and the author died after 70 years. How we can deal with the both Copyright Laws and the copyright status? --Amitie 10g (talk) 21:03, 26 August 2015 (UTC)
You should never use PD-South Korea for works first published outside Korea. Works first published in country X should use the appropriate rules for that country.--Prosfilaes (talk) 23:26, 26 August 2015 (UTC)
Whm you're right. Then, I changed to the country of the first publication instead. What about the prhase «applies only to works first published in Korea, and the author born in Korea and died after 70 years»? --Amitie 10g (talk) 04:38, 28 August 2015 (UTC)

Administrators and trusted users: After one month of this proposal and discussion started, please confirm if this license tag is correct, to be moved to the main Template: and start its use. --Amitie 10g (talk) 03:01, 28 September 2015 (UTC)

  • The template begins with this text:
“This photographic work is in the Public domain in the Republic of Korea and Japan, due it was first published in Korea between 1910 and 1945, and the copyright expired according to the following:”
All photos published between 1910 and 1945 are in the public domain in both Japan and the Republic of Korea, regardless of where the photograph was first published. The country of first publication identifies the source country (the country from which we require a country-specific copyright tag), but knowing the source country is not relevant for establishing the copyright status in Japan or South Korea in this specific situation. The template should warn users that Commons policy requires a different country-specific template if the photograph was first published outside the Government-General of Korea, though. --Stefan4 (talk) 15:39, 28 September 2015 (UTC)
Well, I followed your suggestions and I changed the text as follows:
  • I replaced first published in Korea with published by a korean author, between 1910 and 1945.
  • I replaced the second line (after the DPRK statement) with If the work has been first published outside of Korea, you should apply a country-specific license tag in addition of this license tag.
Shold be that enough? --Amitie 10g (talk) 16:18, 28 September 2015 (UTC)
Korean authors can publish things outside Korea and non-Korean authors can publish things in Korea, so that doesn't help. --Stefan4 (talk) 16:28, 28 September 2015 (UTC)
So, what you suggest? I'll keep just due it was published between 1910 and 1945, and the copyright expired according to the following in the first line. --Amitie 10g (talk) 17:12, 28 September 2015 (UTC)

Idea Portal for any Wikipedia user[edit]

translated with Google Translate:

The following links an implementation of a portal for ideas I like very much: simple, user-friendly and clear and with a voting option. I would like that very well for every Wikimedia user ...

The German original of my proposal:

Der nachfolgende Link einer Umsetzung eines Portals für Ideen gefällt mir sehr gut: einfach, bedienerfreundlich und übersichtlich sowie mit einer Abstimmungs-Option. Das würde mir sehr gut für den jeden Wikimedia-Benutzer gefallen . . .

Template for huge SVG files[edit]

I've created a template for huge SVG files (>10 MB), because the MediaWiki software is unable to render thumbnails for these files. This is intended specially for complex SVG like maps.

  • Could be this template useful, to be placed in the main Template: namespace?
  • Are these huge SVG (like this file) be ussable, if them can be replaced with hight-resolution raster version with lower filesize?

--Amitie 10g (talk) 22:41, 7 September 2015 (UTC)

I like your new template and I do think that it should be moved to Template namespace. These huge SVG are not unusable, just unusable by our current software. They should be scaled down and reuploded under new name, but the full version should be kept as the source. --Jarekt (talk) 13:26, 8 September 2015 (UTC)
OK, your opinion should be enough. I'll move the template. --Amitie 10g (talk) 16:19, 8 September 2015 (UTC)
btw, I expect the limit is 10 decimal MB, which is closer to 9.5 normal MB (or MiB if you prefer). Bawolff (talk) 09:39, 12 September 2015 (UTC)

Removing lightbox previews in UploadWizard[edit]

Hi, all!

As part of the changes we've been making to UploadWizard, we're updating the style of the dialogs used to display errors, display license previews, and so on. One dialog we're updating is the lightbox preview dialog, which you can summon by clicking on any of the small thumbnails in the deed or describe steps in the wizard.

My question to you is: Should we bother? Having a slightly bigger thumbnail of the image seems like a waste of time and code, and if we can axe this particular code path, it will simplify our lives in a few different ways. If nobody seems to actually use the lightbox, then we can safely delete it. If a few people do, then maybe we can learn about why and how, and possibly make the feature better.

Please let me know what you think here, or on IRC, or via e-mail if you prefer. Thanks! --MarkTraceur (talk) 18:40, 16 September 2015 (UTC)

I’d say you should not bother: Whoever is uploading anything is expected to have other ways to visualize the image(s), one Alt+Tab or Ctrl+Tab away. -- Tuválkin 00:06, 17 September 2015 (UTC)
I agree. I am using the upload wizard quite extensively (often uploading batches over 50 photos), and I have never needed a bigger preview. --Sebari (talk) 00:21, 17 September 2015 (UTC)
In fact I never even noticed its existence. :) Well, or maybe I noticed it few years ago and then stopped noticing. --Nemo 06:33, 18 September 2015 (UTC)
Me neither, but then again I rarely use the Wizard at all. If removing a bit of non-essential functionality makes it easier to get the UploadWizard work more reliably, then I'd say: Just axe it and don't look back. --El Grafo (talk) 13:19, 18 September 2015 (UTC)
User:Rillke/bigChunkedUpload.js is the only tool I use nowadays. Yesterday I'm a bit confused as the upload links are moved from "tools" menu to "edit source" as a drop-down menu. Jee 14:29, 18 September 2015 (UTC)

Available Download Resolutions[edit]

Hi, I'd like to discuss the different resolutions that are available to download on file pages. Currently, these seem to be the sizes where the long edge of the file is scaled to pixel counts of:

  • 320
  • 640
  • 800
  • 1024
  • 1280

As far as I can tell, this system was introduced around September 2011. In my eyes, there is a number of arguments for adding higher resolution options here, if the servers can handle them:

  1. The number of great files that we have that are larger than can reasonably be displayed in a browser for many people has grown significantly since then. If the browser refuses to display the full size, the next best option is the next smaller size that is offered - and that's 1280 pixels - not a size for enjoying any photo.
  2. We ask for the highest resolution photo that a photographer is willing to offer. The argument is that you can always scale down but not scale up. That's a weak argument if the user can only view a 1280 pixel thumbnail of an image or the full resolution version that often does not look very good if viewed with a 1:1 screen pixel ratio. Generally, I feel like the largest option should be an option that is actually useful for most situations. In a recent discussion about FP standards, there seemed to be a consensus that most files should be judged at around 6 megapixels, which is somewhere between QHD and UHD. For someone viewing an image on a full screen monitor, that allows for a bit of zoom to see some more detail. It is also roughly what you get in terms of actual sharpness with decent photography gear and technique, in most situations, even if your sensor gives you a much larger file. As a result, at this size and with some sharpening, most files look good or very good at 100%.
  3. Screens with resolutions of 1920 pixels or more had a less than 9% of total usage share in September 2011 according to data. This number has grown to over 17% globally (approximate numbers, I hope I didn't mess up the sums). So if people just want a wallpaper or a file that fills their screen for normal viewing, more of them are only left with downloading the full (sometimes huge) file nowadays. You can get a (good) 4k monitor for under $400 right now, so these are becoming common right now.
  4. Many users need to download vector graphics as pixel graphics because the software they use (MS Word is one example) can't deal with svg files. That's sad, but it's a reality that we have to deal with. Currently, there are additional (mostly overlapping) download resolutions for svg files, most notably adding a 2000 pixel option. Even though that's much better than 1280 pixels, it's still not enough to see a lot of detail in many files. Small countries on a world map are hard to find, just to give one example. It's also not ideal that a separate tool is necessary for that.
  5. Anyone can change to pixel size in the image retrieval url to a larger size. The server is happily serving me images at 8K and beyond. All that's missing are a few links for people who don't know that changing the resolution in the url is possible. If people don't need or use these, they don't put any load on the servers. If they do use them, I feel like that load is worth investing.

So to me, it feels like we should add a few more resolutions. The following ones seem reasonable to me:

  • 1366 (#1 worldwide)
  • 1440 (~#5 worldwide)
  • 1600 (~#6 worldwide)
  • 1920 (#2 worldwide)
  • 2560
  • 3840 or 4096

I would welcome a few opinions and thoughts on this, including good reasons why this would be a bad idea. Thanks, — Julian H. 11:06, 20 September 2015 (UTC)

  • Symbol support vote.svg Support With high-resolution "Full Frame" cameras becoming increasingly common, I would very much welcome having a preview image that actually fills my screen without having to open the full resolution file. --El Grafo (talk) 09:53, 21 September 2015 (UTC)
  • Symbol support vote.svg Support I have thought about this for some time. Thanks for taking the time to bring this up. Yann (talk) 09:55, 21 September 2015 (UTC)
  • Symbol support vote.svg Support, and glad that in the nominator’s planet 400 USD is petty change. -- Tuválkin 17:59, 22 September 2015 (UTC)
    • Didn't say that, but it used to be ten times that. A good monitor has never somthing that you can buy with petty cash. — Julian H. 05:59, 23 September 2015 (UTC)

Categories "looking more required" in UploadWizard[edit]

No-categories confirmation dialog

We have a patch (239418) for UploadWizard which will change how the category field works. If you don't enter a category, we pop-up a dialog (see picture) asking if you're sure you want to upload a file with no categories, and explains that categories are an important part of the Commons ecosystem. You can still upload files despite this warning, but it will make sure that users understand they should put categories on the file. I'm hoping to hear from people whether this is a worthwhile change, or if we should take it out. Thanks! --MarkTraceur (talk) 18:27, 23 September 2015 (UTC)

This was originally requested and developed two years ago (see phab:T51710), but it's always been broken and seemingly no one noticed. We're just restoring and refreshing the feature, assuming it is still wanted. Matma Rex (talk) 14:37, 24 September 2015 (UTC)
Yes, please do that! I'd also change the message to say something like "some categories" as the current wording (kind of) implies that one category would be the default. Maybe even include another link to Commons:Categories right there in the message (opening in a new browser tab)? --El Grafo (talk) 15:01, 24 September 2015 (UTC)
Thanks, I updated the wording in the proposed patch. A link to Commons:Categories is already present in the tooltip on the '?' icon next to the input field, I think that's enough.
Given that no one seems to mind it here, I think we'll go ahead with the change. Matma Rex (talk) 12:13, 28 September 2015 (UTC)

Request for input regarding video proposal[edit]

Dear Wikimedia colleagues:

I am developing a proposal for a video series that's designed to introduce Wikimedia to new contributors (particularly in GLAM and education programs), and to motivate them to participate in the community in a constructive way. I would appreciate your input. The video is intended for translation into multiple languages; there are already volunteers for Spanish, German and Greek translation.

The proposal's main draft page is here.

The proposal talk page is here; it includes a draft outline of specific subjects that the video may cover.

Please note that the scope and budget of the project are still under consideration. At this point it would be especially helpful to have input on the subjects that the video should cover, and how best to cover them. This information will help as the project scope and budget are refined.

Please add your questions and comments to the talk page.

If you would like to support the project with your endorsement, please do so here

If you would like to volunteer to translate the video, please email me or comment on the talk page.

Thanks and regards, --Pine 23:35, 24 September 2015 (UTC)

Retire Commons:Upload Wizard feedback and replace it with "How to file a bug report" page[edit]

This has been proposed by Jdforrester at phab:T112666 (and modified by AKlapper and Steinsplitter). Nemo bis objected because it wasn't discussed here first. So let's do this now … --El Grafo (talk) 10:15, 25 September 2015 (UTC)

As someone who goes through the entire feedback page backlog every now and then, I think the proposal is very harmful, because most people don't know how to login in Phabricator and forcing them to use it will effectively hide any problems in UploadWizard rather than help us fix them. Moreover, Phabricator cannot be used for two current legitimate uses of the page, namely
  • writing in your own language,
  • writing other comments not related to UploadWizard specifically (which can easily be moved elsewhere by someone who knows they aren't).
Finally, if you are really interested in helping improve UploadWizard, you should focus on getting the user-agent, which is the one missing piece which would be high impact and very easy: phabricator:T43291. --Nemo 06:31, 2 October 2015 (UTC)

A note of correction[edit]

Ref: The page for Hans Sebald Beham.

I have seen the print "Head of Christ crowned with thorns (LACMA) as an item belonging to Sebald. But the print bears the visible sign of A.Dürer. So it should be moved from Sebald page to Dürer page.


H.Erdemol — Preceding unsigned comment added by (talk • contribs) 11:20, 5 October 2015‎ (UTC)

✓ Done here, moved to File talk:The Head of Christ Crowned with Thorns LACMA M.2003.53.1.jpg, follow up there. --Achim (talk) 18:02, 5 October 2015 (UTC)