Commons:Village pump/Proposals/Archive/2014/06

Propose to update CC license tags

Expecting comments. Jee 07:45, 8 June 2014 (UTC)

Disable Slideshow Gadget

button to start the slideshow in a red box

Now that MultiMediaViewer (MMV) became default at Commons, I suggest either disabling the Slideshow Gadget completely or taking away the default bit. There are several bug reports on the gadget page and its help page I am not able to work on currently. -- Rillke^(q?) 15:52, 16 May 2014 (UTC)

•  Support un-defaulting it (as proposer), but if someone wants to still use it (f. ex. because he disabled MV) why not let him/her?    FDMS  4    16:31, 16 May 2014 (UTC)

• +1 Rillke. --Alchemist-hp (talk) 18:00, 16 May 2014 (UTC)

•  Oppose: No, keep your hands off what actually works. Media Viewer has enough bugs and obvious loose ends (zoom?) to keep its overpaid developers busy. Till then, let people who, like me, turned that monstrosity off so they could actually work, have some slideshow capabilities. (Slideshow Gadget gadget has bugs too? So what? So does Media Viewer and you don’t see a proposal to take it back.) -- Tuválkin ✉ 20:32, 16 May 2014 (UTC)

It's just because the bugs of the slideshow gadget are on my TODO list and those of MMV aren't, hence this suggestion. -- Rillke^(q?) 20:48, 16 May 2014 (UTC)

Buggy or not, Rillke, it is a great tool and we need it. Let’s keep it. If/when its bugs get squashed, it will be even better. -- Tuválkin ✉ 17:43, 9 June 2014 (UTC)

•  Support It is nonsense to take two tools of the near same overlapping issue as default. -- Perhelion (talk) 11:57, 17 May 2014 (UTC) (Changed → Perhelion     17:27, 9 June 2014 (UTC))

•  Oppose, per Tuválkin (although I would probably try to express it differently). I feel like Media Viewer will be a right tool for Wikipedias, with many changes and improvements, but I do not see it as a right tool for Commons, and I would prefer it not to be enabled by default. On the other hand I am a big fan of Slideshow Gadget, for when I want to see a slideshow. --Jarekt (talk) 17:10, 9 June 2014 (UTC)

wikEd as gadget

I have made the MediaWiki editor wikEd compatible with upload pages in addition to edit pages a while ago in version 0.9.125. It would be great if we could set wikEd up as a gadget on Commons (similar to most other large WikiMedia wikis). Please see here for technical help. Cacycle (talk) 20:03, 8 June 2014 (UTC)

•  Oppose Not useful for Commons. There are also many incompatibilities here. Additional all functions of wikEd are replaceable by other better tools. → Perhelion     20:18, 8 June 2014 (UTC)
  • wikEd is the second most popular gadget on the English Wikipedia with currently 30458 users. I am not aware of any relevant incompatibility with browsers, other gadgets, or scripts (wikEd does work for all browsers except MS IE, where it simply stays silent). wikEd provides many edit functions for advanced users (such as regExp search and replace, please check the full feature list here) that are not available anywhere else. Also, gadgets are optional, nobody will be forced to use them. Cacycle (talk) 20:36, 8 June 2014 (UTC)

@Cacycle: Did you test WikiEd on pages in the Campaign: - namespace? It's JSON and CodeEditor will be loaded. Does WikiEd interfere there? -- Rillke^(q?) 21:23, 8 June 2014 (UTC)

@Rillke: wikEd is compatible with CodeEditor (i.e. wikEd stays silent when CodeEditor is active). I have just confirmed that on Commons on .js pages in user space and shortly in the Campaign: namespace (read only as I am not an admin on Commons). Cacycle (talk) 23:17, 8 June 2014 (UTC)

@Cacycle: As we can see there are some heavy bugs open (ok this is not a main argu to give it a try as Commons gadget) I personally have made some simple bug reports and request to WikEd but you don't answer and also bug reports from some other people you do never responded (ok it was 1-2 years ago). That you don't know the other tools is very distinctive (but I don't believe you). PS: Unfortunately I'm the guy who made the first translation of your tool (De).

• So for example for the only real good features:

• Syntax-Highlighter – is better and more performant, compatible (IMHO)
• Diff-feature – cleanDiff (by TMg) / diff/core by Schnark (he also said your diff-modul is buggy and you not answer)
• Configurable editbar – Wikieditor with the default edit bar (by Schnark)
• InstaView can be installed separately
• RegExp – normally only useful with other tools like AWB, anyway there is also Regex menu framework as Gadget in En. Commons has also VisualFileChange (by Rillke) But I had never use it.
• It is also disturbing that WikEd remove the default hot-keys, also the c&p code formatting is very nerving.
• Compatibilities – we only need take a look at en:User:Cacycle/wikEd#Scripts, add-ons, and extensions Not WikEd is compatible the "other" tools must be changed for compatibility! (some people don't like to support WikEd)

This is only a short review, because I'm not a long time user of WikEd (I give it several times a try in En and then I deactivated it).

→ Perhelion     11:19, 9 June 2014 (UTC)

PS:

• Syntax cleanup/corrector – seems primitive and buggy against other tools of it. As we can see here w:en:Wikipedia:User scripts#Cleanup. I personally use none of them (except of autoFormatter (by TMg) which is implemented "as modul" in the Wikieditor by Schnark), I use WikiSyntaxTextMod (and Commons User:Magog the Ogre/cleanup.js which is not for general use)
• It seems you do try make all in one alone, that is also an intention which I don't support (it is only logical that quality is lower instead of....). It is also very distinctive that your self propose WikEd (where are the 30458 users?) → Perhelion     16:27, 9 June 2014 (UTC)

wikEd is a stable program that is regularly used and valued by a large base of MediaWiki users. wikEd is a gadget on over 70 Wikipedias (!) (including almost all large Wikipedias), has more than 30000 gadget users on the English Wikipedia alone (!), has been translated by users into 36 languages (!), and is already used on Commons by many editors (despite being somewhat complicated to set up). The program is actively developed in close cooperation with its users. There are no major bugs that would interfere with its use as a gadget here or anywhere else.

The questions we should discuss here are: 1. do Commons users benefit from this gadget and 2. are there any technical problems (which can be fixed). I am sorry and have no idea why Perhelion would have a personal vendetta against wikEd or me, but as I said above: nobody will be forced to use wikEd (it is actually aimed at more experienced editors). But it would be a great addition to the other tools here. And would probably be one of the most closely scrutinized gadgets ever :-) Cacycle (talk) 19:19, 9 June 2014 (UTC)

Now I give it another try and on my very first edit I recognize a heavy bug and also on the second here (some additional linebreaks). What I'm telling here are only logical objectively facts but you argue here with maximum hypotetical numbers. The bug is with CodeEditor (changes are not recognized also in the diff), but you telling WikEd stays silent, so you show what your words have for a value. (also my instant translate addon is not working anymore[1] but I've another per click which is working[2] but I prefer the first) This was only a review after 2 minuts (I see you have a bit improved the c&p behavior). PS edit: Another bug if you shut off WikEd (or syntax) you must make a full reload the page, because the completely bottom (of the edit field) text field with buttons is now full overlapping the edit field. I personally have not the time to analyse you tool for more bugs (sorry unfortunately as someone said your tool is a single bug, this year). → Perhelion     09:51, 11 June 2014 (UTC)

I'd describe wikEd somewhat differently: WikEd is a stable gadget, if by "stable", you mean produces bug complaints at VPT every week or two, because it conflicts with all sorts of things. It has 30,000+ editors using it, if by "using" you mean "mostly not using", because that number includes people who haven't actually edited for years, or who only make one or two edits every now and again. (There are only about 30,000 registered editors who made more than 5 edits at en.wp in all of last month. wikEd would have to have 100% saturation in that group to have 30,000 active editors using it.)

I don't mind what happens here. I've used wikEd in the past. I just don't think that the statements being marshaled in its favor are as accurate or relevant as they sound. WhatamIdoing (talk) 23:21, 16 June 2014 (UTC)

One map for rule them all

What about replace all (or most) infographic maps with one SVG map (for each type of map) in which we separate presentation from data. One way to handle would be use classes for associate color with a percentage, and defines for shapes. So the code would be something like:

<svg …>
<!-- DO NOT TOUCH THIS -->
<defs>
 <path id="ad" d="…"/>
 <path id="ae" d="…"/>
 <path id="af" d="…"/>
 …
 <path id="zw" d="…"/>
 <style type="text/css"><![CDATA[
  path {fill:#cccccc;…}
  .p00 {fill:#ff0000}.p01{fill:#fc0003}.p02{fill:#fa0005}….p99{fill:#0300fc}.p100{fill:#0000ff}
 //]]></style>
 </defs>
<!-- CHANGE class TO INDICATE PERCENTAGE -->
 <use xlink:href="#ad" class="p50"/>
 <use xlink:href="#ae" class="p30"/>
 …
 <use xlink:href="#ze" class="p18"/>
</svg>

Or maybe only modify the style to indicate color (then not indicated will remain gray):

<svg …>
 <defs>
  <style type="text/css"><![CDATA[
<!-- TOUCH THIS: -->
  #ad,#ar,#us,#it{fill:#e000d3}
  …
<!-- DO NOT TOUCH THIS: -->
  path{fill:#cccccc}
  //]]></style>
 </defs>
<path id="ad" d="…"/>
…
<path id="zw" d="…"/>

Benefits:

• Elegance and "legibility" (all maps are similar).
• Easy to create and update for humans and bots (even wikidata).
• Forward compatibility with plugins (Inline SVGe extension in template?)

Eloy (talk) 00:34, 17 June 2014 (UTC)

wikimedia commons app

I have a proposal to develop commons app . I want to develop a gallery part in the app so that people are able to see all the uploaded pictures until now it has only one feature i.e to upload but by having a gallery part , users are able to see various pictures also . — Preceding unsigned comment added by 14.139.238.98 (talk • contribs) 14:42, 25 February 2014‎ (UTC)

Time stamp for archive -FASTILY 23:41, 17 June 2014 (UTC)

File summary—upload date vs date of creation

Notification only: At the Village pump, I made a proposal to change the File summaries on every file page, and to change the upload form. --Wickey-nl (talk) 07:32, 26 June 2014 (UTC)

Massive deletion requests

I've recently had a very unpleasant experience with the undeletion request process here, giving my opinion against the indiscriminate mass culling of images, as appears now to be a trend. Mass deletion requests should not be allowed because they do not allow individual images of be debated on their own merits, and many educational and in-scope images are being indiscriminately deleted. Better efforts are needed to properly categorize images, and mass deletion nominations to cull over-populated generic categories is resulting in the loss of many educational and in-scope images. Dolovis (talk) 03:28, 29 June 2014 (UTC)

Mass deletion requests are supported in our deletion policy, and that's not about to change, at least not until we start throttling uploads. We simply don't have enough volunteers to deal with batch uploads of copyright violations by sockpuppeteers one by one. And for many uploads, it makes absolutely no sense to pretend they exist in a vacuum without the context of other uploads by the same user. Consider Commons:Deletion requests/Files uploaded by Hoteles City. Obviously, the uploader can't be named Carlos Hahn, Salvador Mariña Coy and Oscar Zarate, which calls all of the uploader's authorship claims into question. But if, as you suggest, we refuse to look at the big picture, one claim is as likely as the next. —LX (talk, contribs) 09:19, 29 June 2014 (UTC)

Show images in a category on Commons

It would be nice if you see all images in a category in one place by clicking a link saying Show Images in Category. You should be able to choose between images on all levels and images on top level only. Images should be shown 100 at a time with a link to the next 100 divided in subcategories. Soerfm (talk) 11:45, 30 June 2014 (UTC)

I'm not sure what exactly you have in mind, but it sounds a bit like bugzilla:43424. —LX (talk, contribs) 12:24, 30 June 2014 (UTC)