Commons:Village pump/Proposals/Archive/2012/08

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

Why does 'What links here' not show the links from other (i.e. German) Wikipedias)? For example the stamp of Nelly Sachs is used Nelly here and the stamp image links to File:Nelly_Sachs_(timbre_allemand).jpg. But this link does not show when looking at 'What links here' on Commons. What is the cause for this or is this feature just not (yet) implemented?--Dudy001 (talk) 17:37, 7 August 2012 (UTC)

Special:WhatLinksHere is a local function for Commons. For global use there is Special:GlobalUsage/Nelly_Sachs_(timbre_allemand).jpg. --Martin H. (talk) 18:07, 7 August 2012 (UTC)

Ctrl-click to open search in new tab

I suggest putting this gadget in preferences.

This is a way to open search buttons in new tabs by using ctrl-click. It was discussed here:

Add the following JavaScript (JS) to Special:MyPage/common.js (for me it is User:Timeshifter/common.js).

/* Ctrl-click to open search buttons in new tab */

$('#searchform, #search, #powersearch, #searchbox, .search-types, #search-types').bind('keyup keydown mousedown', 
  function (e){ $(this).attr('target', e.ctrlKey?'_blank':'') })

Ctrl-click now works for opening search buttons in new tabs. All types of search buttons: top-right search form on almost every page, Special:Search, archive search forms, etc.. There is no need to enter search terms to test this. Just ctrl-click the submit buttons. Try some archive search forms here:

In Special:Search the search options initially found below the search form are in the form of links. The search form itself uses a submit button.

In Firefox and Internet Explorer one uses ctrl-click to open links in new tabs. One can shift-click to open links in new windows. Since this is how most people have things set up for their browser, this gadget conforms with this. So it is easy to remember this method.

I have tested this on both Wikipedia and the Commons. On Wikipedia add the JS to en:Special:MyPage/common.js (for me it is en:User:Timeshifter/common.js). --Timeshifter (talk) 17:39, 12 July 2012 (UTC)

Note that Ctrl-left click only is used in Linux and Windows. I suggest that you add Cmd-click for Mac users. I don't know about other users, but I always use middle click instead of Ctrl-left click since I don't have to use the keyboard for that. I suggest that you also add middle click functionality. --Stefan4 (talk) 19:01, 12 July 2012 (UTC)
I also middle-click to open new tabs (didn't know you could use Ctrl-left-click), so it'd definitely be good to have that included! --Philosopher Let us reason together. 20:13, 12 July 2012 (UTC)
Stefan4 and Philosopher. Sound like good ideas to me. Feel free to add the necessary JS to the above JS and test it. If it works, paste the revised JS below. I do not understand JS. I just hacked the JS from others. See the discussion at en:Wikipedia:Gadget/proposals#Ctrl-click_to_open_search_in_new_tab. --Timeshifter (talk) 01:45, 13 July 2012 (UTC)
Probably no problem with publishing this w/o the change, we can always update it later. Unfortunately I don't know how to add the middle click, so I can't do it either. --Philosopher Let us reason together. 18:24, 13 July 2012 (UTC)
A couple of things: 1) Opera (except Opera for Mac) already opens a new tab if you control-click a button, and 2) you can't control-click on a Mac, since the OS maps "control-left click" to "right click", to permit right-clicking with a one-button mouse. --Carnildo (talk) 00:26, 13 July 2012 (UTC)
I guess then Cmd-click and middle click needs to be added to the JS per Stefan4. I don't have a Cmd key on my PC keyboard. So I assume adding it to the JS should not mess up anything for PC users. I found this about the Cmd key, also called the Apple key:
http://www.answerbag.com/q_view/36210 --Timeshifter (talk) 01:45, 13 July 2012 (UTC)

Revised version that also works for Mac users

I don't know enough Javascript to rewrite the code, but per this article (section 3.1), event.metaKey is the equivalent of event.CtrlKey for the Command/Apple key on Mac in most browsers. Internet Explorer of course doesn't behave itself, sending event.CtrlKey for the Command/Apple key, which fortunately is fine here. Middle click is more complicated and I don't want to get into it ... so I leave that as an exercise for the reader ;) Rd232 (talk) 07:19, 17 July 2012 (UTC)

So I need to add event.metaKey or e.metaKey to the JavaScript somehow? I dont have a Mac; so someone else will have to test it after it is added correctly to the JS. I don't understand JavaScript at all. --Timeshifter (talk) 13:55, 17 July 2012 (UTC)
Be careful with that: "meta" is an actual modifier key on some *nix systems. --Carnildo (talk) 21:17, 17 July 2012 (UTC)
$('#searchform, #search, #powersearch, #searchbox, .search-types, #search-types').bind('keyup keydown mousedown', 
  function (e){ $(this).attr('target', e.ctrlKey||e.metaKey?'_blank':'') })
^ --Yair rand (talk) 02:05, 18 July 2012 (UTC)
Thanks, Yair rand! Now we need a Mac user to test Cmd-click (the Apple key). I added it to my JS, but I only have a PC. After adding this version to Special:MyPage/common.js ctrl-click continues to work fine on my PC. --Timeshifter (talk) 05:09, 18 July 2012 (UTC)
We would also need a Solaris user to test that Meta-click doesn't open it in a new TAB... --Stefan4 (talk) 07:03, 18 July 2012 (UTC)
Would it be so terrible if it did? Rd232 (talk) 11:31, 18 July 2012 (UTC)

Comment. Is there a place we can leave a note asking for JavaScript help that will get noticed by JavaScript experts? I am going to start a new category called "Commons JavaScript experts" and pin it to any JavaScript experts I can find. --Timeshifter (talk) 21:51, 17 July 2012 (UTC)

If you ask over at en:WP:Village Pump/Technical, you'll probably find someone who knows how to do it. --Philosopher Let us reason together. 23:24, 17 July 2012 (UTC)
I left a request for help there, and pointed to here. --Timeshifter (talk) 01:20, 18 July 2012 (UTC)
Ehm, on safari and firefox (mac), cmd-click already opens a new tab for me, no script needed for that. TheDJ (talk) 07:52, 18 July 2012 (UTC)
OK, so in Safari, i might need something like this only for the suggestions drop down of the main search field. The script however does not seem to interfere with 'default' behavior'. On Firefox I need it for all submit buttons and the drop down list. Both seem to be working just fine icw the script. TheDJ (talk) 08:14, 18 July 2012 (UTC)
Great. Thanks! Now we need the JavaScript so that middle click will open search in a new tab. --Timeshifter (talk) 10:53, 18 July 2012 (UTC)

(unindent). I added this JS version to a Bugzilla thread. I described this JS addition for PCs and Macs here:

If I click in the search box (either #searchInput or #powersearch) and then press CTRL and then release it, the target="_blank" will stay there, so whenever I press CTRL it will be removed (and added as soon as I release it again). This behavior should be the oposite: target="_blank" should be there only if I'm not holding CTRL. I tested using Chrome 20.0.1132.57. Helder 15:58, 29 July 2012 (UTC)

I don't understand what you are saying. On my PC when I press CTRL, hold it down, and then press the search submit button in either Special:Search or in the search box at the top right of every page, then it opens up a new tab. I am using Chrome 20.0.132.57. --Timeshifter (talk) 20:17, 30 July 2012 (UTC)
  1. Go to Special:Search using Chrome
  2. Press CTRL+SHIFT+C to open the source code of the page
  3. Press CTRL+F to find the element "powersearch"
  4. Now, click in the search field (i.e. "powerSearchText"). This will add an empty "target" attribute to the "powersearch"
  5. Type "test"
  6. Press and hold the CTRL key (target will stay empty)
  7. Release CTRL (target will be set to "_blank")
  8. Press and hold the CTRL key (the "_blank" will be removed from target)
  9. Release CTRL (target will be set to "_blank" again)
Repeating the last two steps will continue the wrong behavior. Helder 19:57, 31 July 2012 (UTC)
I can not find "powersearch" in the source code of Special:Search using ctrl-F in either Chrome or Firefox. I must be doing something wrong. --Timeshifter (talk) 18:23, 1 August 2012 (UTC)
I found "powersearch" in the source code of the advanced search page with the dropdown of choices. Go here:
http://commons.wikimedia.org/w/index.php?title=Special:Search&profile=advanced
I still do not understand the rest of what you wrote. I am not any kind of expert in code. I understand some basic CSS and basic HTML, and that is about it. --Timeshifter (talk) 20:57, 2 August 2012 (UTC)

(unindent). This tool can now be imported into Special:MyPage/common.js. See

See proposal farther down to add this gadget to Special:Preferences#mw-prefsection-gadgets. --Timeshifter (talk) 05:35, 15 August 2012 (UTC)

Middle click to open search in new tab

If someone comes up with a version that also allows a middle click to open search in a new tab please put the JavaScript below. --Timeshifter (talk) 07:12, 19 July 2012 (UTC)

This (below) seems to work in latest Chrome and Opera and in IE8 (not tested in other browsers). —AlexSm 04:56, 21 July 2012 (UTC)
//Open search in new window on middle-click

$('#searchform').mousedown(function (e){
  if( e.which != 2 ) return
  $('#searchform')
  .attr('target','_blank')
  .submit()
  .attr('target','')
})

$(document.body).delegate(
 'div.suggestions, #searchInputSuggest', //1st - vector, 2nd - all other skins
 'mousedown', 
 function(e){
  if( e.which != 2 ) return
  $('#searchform').attr('target','_blank')
  $(e.target).mouseup()
  $('#searchform').attr('target','')
})

AlexSm 04:56, 21 July 2012 (UTC)

I haven't tried this yet. Busy now, back later. But where would one add the whole list of search form IDs and classes?:
(#searchform, #search, #powersearch, #searchbox, .search-types, #search-types')
I know nothing about JavaScript. --Timeshifter (talk) 07:19, 22 July 2012 (UTC)
Thanks AlexSm! It works on Firefox, but only for the search form at the top right of every page. It does not work on Special:Search, nor archive searches:
Template:Village pump archives
Commons:Village pump/Proposals/Header
Commons:Village pump/Header
It does not work on IE9. --Timeshifter (talk) 19:29, 22 July 2012 (UTC)

Embedded search automatically opened in new tab. Ctrl-click and Cmd-click for Special:Search

Note: Here are the component parts and what they effect:

#searchform - embedded search form at top right of every page.
#searchbox - embedded archive search forms. For example; Template:Village pump archives.
#search, .search-types, #search-types - Special:Search.
#powersearch - advanced search at Special:Search. This is after one clicks the advanced search link at Special:Search to get the dropdown of search choices. Then when one clicks the search button #powersearch applies to it.

See:

I guessed, hacked, and combined the relevant parts of the JavaScript (JS) used and discussed in the above-linked pages with the Ctrl-click and Cmd-click methods discussed higher up on this talk page. The combined JS is below. Add the following JS to Special:MyPage/common.js (for me it is User:Timeshifter/common.js).

/* Embedded search automatically opened in new tab */
/* Embedded: at top right of pages, and talk archive searches */

$(function () {
    $('#searchform, #searchbox').attr({ target: '_blank' });
});

/* Ctrl-click and Cmd-click to open Special:Search button in new tab */
/* Cmd-click is Command-click. Command key is Apple key on Apple keyboards */ 

$('#search, .search-types, #search-types, #powersearch').bind('keyup keydown mousedown', 
  function (e){ $(this).attr('target', e.ctrlKey||e.metaKey?'_blank':'') })

The purpose of this is to prevent search from covering over the page one is reading. So clicking embedded search form buttons automatically takes one to a new tab . That new tab is always Special:Search. So once there one has the option of opening further search in new tabs by clicking Ctrl-click (or Cmd-click on Apple keyboards).

It works fine in Firefox, Chrome, and Internet Explorer 9 on my PC. --Timeshifter (talk) 07:27, 25 July 2012 (UTC)

introduction of each lemma

Isn't it possible to include the introduction into the contents table - because if you only want to change something in the introduction you always have to work on the whole file. If the introduction be part of the contents (with "===introduction===" or something like that) it would be possible to make changes to the introduction without editing the whole file. This idea fits also to the category and wiki sections at the end of each lemma. Thanks! Maybe this would reduce memory space on the servers if one could work on each section of an article s-e-p-a-r-a-t-e-l-y!?--Dudy001 (talk) 17:57, 7 August 2012 (UTC)

It's already possible, there's a gadget in preferences which includes an edit link for the introduction. -mattbuck (Talk) 18:10, 7 August 2012 (UTC)
Specifically, it is (currently) the first gadget of the second section at Special:Preferences#mw-prefsection-gadgets, labelled Add an [edit] link for the lead section of a page. (in English interface). Rd232 (talk) 09:31, 15 August 2012 (UTC)

Bundled rights (Filemover) - +1

We bundle the autopatrol right in "Image reviewers" and "OTRS members". I'd like to propose that we bundle it in "File movers" as well. As Morning Sunshine recently noted, "Filemovers are experienced enough to have their edit automatically marked as patrolled." --Philosopher Let us reason together. 23:26, 4 August 2012 (UTC)

And what about their uploads? Copyright is complex that's why I always check the uploads when assigning autopatrol despite the fact that no one uses COM:CUP. -- Rillke(q?) 07:36, 5 August 2012 (UTC)
 Support. I couldn't agree more. Right now we always have to give the autopatrol right together with the filemover right and that's just silly. Trijnsteltalk 14:41, 5 August 2012 (UTC)
Comment. autopatrol right was not bundled in "Image reviewers" and "OTRS members" groups. It was added only because any group must have at least one userright assigned to it in order to exist. So, autopatrol was chose because it is the least consequential. Ruslik (talk) 19:10, 5 August 2012 (UTC)
I didn't realize that, thanks for pointing it out. --Philosopher Let us reason together. 06:05, 6 August 2012 (UTC)
Comment for reference, autopatrol is described here. Are we completely sure that filemovers' uploads and edits do not need patrolling? (I'm not involved with patrolling, and only rarely see unpatrolled edits by chance.) Rd232 (talk) 22:25, 5 August 2012 (UTC)
Several admins currently do make that assumption and grant the (unrequested) autopatrol when granting filemover. This would just avoid the extra busywork. But on its merits, sure. If your edits need patrolling, you probably shouldn't be moving files around. --Philosopher Let us reason together. 06:05, 6 August 2012 (UTC)

Transcluding old file versions

User:Rillke mentioned the idea of transcluding old file versions. This could work something like
[[File:X.jpg#nnnnnn]]
where nnnnnn is the unique file version number (like page id). I'm not sure if files currently have unique version numbers like pages do though. Any thoughts? Rd232 (talk) 11:38, 16 August 2012 (UTC)

I think that could lead to some very confusing situations if the file description page doesn't match the image. LX (talk, contribs) 14:48, 16 August 2012 (UTC)
Good point. I think that could be addressed if clicking through from the #nnnnnn transclusion gives a warning message at the top of the page. And presumably such transclusions would normally be done for a reason which would involve explaining why an old version is being displayed. Rd232 (talk) 14:52, 16 August 2012 (UTC)
I think, when clicking on such an "old version"-image, the reader could be directed to the closest file description revision (the devs will have to reconsider how they cache parsed text). Old versions are already included into articles in Wikipediae that have flagged-revs enabled where a new version was uploaded to Commons. I just think there should be a way for the file-user to say "I want this revision" for various reasons (e.g. explaining a Hotpixel in a file) or to say, "I prefer getting updates - It doesn't matter as long as the content is what the file name/descriptions says". -- Rillke(q?) 20:26, 16 August 2012 (UTC)

It turns out that MediaWiki already provides a way to do this! Several ways in fact! The obvious one would be mw:Manual:$wgAllowExternalImagesFrom, set to allow images from upload.wikimedia.org. With that enabled, giving a full link to a file version (https://upload.wikimedia.org/wikipedia/commons/archive/a/a9/20060307155131!Example.jpg) would render the image, instead of making a link to it. (For the irredeemably curious, there's also mw:Manual:$wgEnableImageWhitelist to create an admin-editable whitelist page, and mw:Manual:$wgAllowExternalImages to allow all external images.) Whilst somehow not quite as neat as my idea above, it is ready to go right now: we'd just have to file a bug to get someone to change Commons' settings. Rd232 (talk) 15:49, 16 August 2012 (UTC)

Rd232, thanks for your investigations. I think we should not encourage a new syntax (your proposal using #nnn sounds reasonable, could be also a parameter like |version=nnn) and also the URL pointing to the raw files might be subject to changes if the MediaWiki developers attempt to refractor the Media-handling. -- Rillke(q?) 20:26, 16 August 2012 (UTC)
I think if they did refactor the media-handling (change the format of upload URLs) they would have to provide backwards compatibility, at least for old files. Anyway, I don't imagine there are that many uses for this tool that would be affected by breaking it; much of it would be old discussions where it's not so bad. A few help pages and the like can be updated if necessary without too many problems. I think we're talking here about low cost, low-to-medium gain, low risk. Rd232 (talk) 21:10, 16 August 2012 (UTC)

A definitions input sidebar for quick, concise look-ups

One good habit in ‘reading skills’ is to look up their definitions’ and further meanings . . . keeping a dictionary close by. The advent of cyber exploring brings ease of approach, but at a cost of time and direction loss. How possible would it be to have a small side bar that would take a ‘word’ directly to your site for its meaning . . . a kind of ‘DefQuick’ or ‘WikiDef’ maybe ‘WikiQuick’. No additional page loads or site selection lists . . . just the definition. Possible, yeah . . . but probable? Rick vipservice@netzero.net — Preceding unsigned comment added by 71.50.91.47 (talk • contribs) 15:52, 18 August 2012‎ (UTC)

The Opera browser already provides this function: double click on any word in a web page and right click to see links to the local Wiktionary and the local Wikipedia. Is that what you mean? There are also addons for Mozilla Firefox but I have not tried any. -84user (talk) 23:10, 18 August 2012 (UTC)
I have both of these Firefox addons installed:
https://addons.mozilla.org/en-US/firefox/addon/quickwiki
https://addons.mozilla.org/en-US/firefox/addon/context-search
Google definitions:
define: term or phrase
--Timeshifter (talk) 02:13, 19 August 2012 (UTC)

Support or oppose adding gadget to open search in new tab

See also: #Ctrl-click to open search in new tab.

Please indicate your support or opposition, and why. Of the various search gadgets I am focusing on this one. I think it gives the most options to users. Can this gadget be put in Special:Preferences#mw-prefsection-gadgets?

This gadget enables the opening of search result lists and search suggestions in a new tab by using Ctrl-click (PC) or Command-click (Mac). See JavaScript (JS) here:

See import info, and other info here:

I started a discussion at en:Wikipedia:Village pump (technical)/Archive 102#Support or oppose adding gadget to open search in new tab. --Timeshifter (talk) 05:52, 16 August 2012 (UTC)

 Support sure Rd232 (talk) 11:39, 16 August 2012 (UTC)

 Support --Philosopher Let us reason together. 22:58, 16 August 2012 (UTC)

Wikipedia Village pump discussion shows strong support for adding gadget

Please see:

Grandfathered old files

This is an old proposal, but it still needs more input from the community: Commons:Requests for comment/Grandfathered old files. Kaldari (talk) 20:48, 19 August 2012 (UTC)