Wikipedia:Village pump (proposals)/Archive 93

We already do this to some extent, but do it at the bottom of articles, usually in the "see also" section rather than the infobox. Just a random example, see Federalist No. 51, which contains a little box near the bottom that tells you about the Wikisource document. --Jayron32 17:09, 11 September 2012 (UTC)

I know, that's why I mentioned the commonscat template. My point is that at the bottom is not as good as at the top, through I see no reason not to have both. I am not suggesting removal / replacement of the current templates, I am just suggesting adding their functionality to the infoboxes, to increase their visibility. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 17:52, 11 September 2012 (UTC)

Navigational templates are for links to pages within each Wikipedia itself (internal links only). Not that we are trying to trap our readers here within each encyclopedia, but our info should be linked well before any external links that lead readers to info beyond what is offered here. External links should not be incorporated info the article text or nav boxes - they should be in the External links section to indicate to our readers there leaving English Wiki - as per Wikipedia:Wikimedia sister projects#Where to place links.Moxy (talk) 18:42, 11 September 2012 (UTC)

Wikipedia:Wikimedia sister projects is not a policy, so we should treat it just as an optional suggestion. The links I propose would be clearly labelled ("See gallery at Wikimedia Commons"), so people should not be overly confused. Any confusion from leaving our site should be well compensated for by the fact that it will be easier for people to access highly relevant content (galleries, source texts, quotes). Polish Wikipedia also includes clearly labelled external links to organizational home pages, which I think is also a good idea, although please note that I am not advocating adding this functionality in this proposal (I don't want to get too off topic here). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 19:02, 11 September 2012 (UTC)

I think this is a good idea. Sister project links generally go in the "External links" section these days, which doesn't really make sense to me, since they're not "external" from Wikimedia. Wikimedia content should not be considered the same as external content. --Yair rand (talk) 18:57, 11 September 2012 (UTC)

Indeed. If you look at English Wikisource (ex. http://en.wikisource.org/wiki/Author:Samuel_Langhorne_Clemens), you see sister project links featured at the top, not the bottom. Commons also links back to us (and other sister projects, like wikisource) prominently (ex. http://commons.wikimedia.org/wiki/Creator:Leonardo_da_Vinci). Only we (the English Wikipedia) try to hide our sister projects. I don't see why; they do good job and we should be promoting them (where it fits our mission and scope, and I think my proposal reinforces it). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 19:05, 11 September 2012 (UTC)

"Sister projects" are external links in my opinion (as seen at Wikipedia:External links#Links to be considered) and due to the fact they require separate registration for the end user. I personal believe any external links should be after the "See also" section - Refs - Bibliography - Notes - Further reading - External links .. all lead readers away from English Wiki, thus should be seen last. I do however believe "Sister projects" links should all be listed on the left side of pages like with our other "language wikis" or even there own section under "See also". I believe having 9 external links in an info-box/navbox is simply overwhelming.Moxy (talk) 19:41, 11 September 2012 (UTC)

Sister projects are external links, and that's the section where they belong, not in the infobox, and not in "see also". Imzadi 1979 → 19:54, 11 September 2012 (UTC)

That is completely incorrect. Sister projects haven't required separate registration for years. --Yair rand (talk) 19:59, 11 September 2012 (UTC)

(ec) - Pls see Unified login - its a process - not at all the norm.Moxy (talk) 20:29, 11 September 2012 (UTC)

Actually, it is the norm. It's only old users who have to go through any sort of process. Anomie⚔ 01:20, 12 September 2012 (UTC)

You wouldn't have 9, just 1-3. And it wouldn't be overwhelming, just helpful (have you bothered to look at the linked example before you invented the 9-link strawman? Anyway, I find it discouraging that so many will fall back on policy, rather than consider the arguments abut readability and usefulness. Here's a heresy to consider: policy should be changed to accommodate user experience, not the other way around. But if anyone want's to wikilawyer the policy here, note that Wikipedia:External_links#Templates_for_external_links encourages the use of links to sister projects in templates, and infoboxes are templates. QED :) --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 20:12, 11 September 2012 (UTC)

"invented the 9-link strawman" Pls see how many sister projects there are at Wikipedia:Wikimedia sister projects - I think your misreading that guide - its about templates "for" external links - not "about" external links. Its talking about making templates for external links - like Template:Official website that you may see in a musicians info box (that I believe should only be seen in external links anyways). I have not relied solely on policy for my position - but have explained that having links that lead our readers away for English Wiki so fast is not helpful. English wiki is not here to produce traffic to the other wikis, but to inform our editors here - for more info they should see below the "See also" section that will lead them to pages that do not comply with our policies of neutrality and verifiability etc. That said I believe our internal portals should be linked in the fashion you mentioned above. (Moxy (talk) 20:28, 11 September 2012 (UTC)

Portals? They are usually off topic and pretty useless. As our polices suggest moving certain type of content to our sister projects (quotes, source text, galleries), I think it is only fair that we should inform our visitors of that through easy to access links. As I said above, I have had people complain to me they cannot find associated galleries because we don't make the links to commons galleries visible enough. To fulfill our mission to inform the readers, we must make those links more prominent. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 23:01, 11 September 2012 (UTC)

I would say that Template:Sister project links (the solution used here on English wiki at teh bottom of pages) is much more visible then tiny little links as seen here in this nav box.Moxy (talk) 23:41, 11 September 2012 (UTC)

Unless you can cite results of a survey, I am not convinced; I would counter hypothesize that many people don't look at the bottom, past references and such, they stop where the main text ends and thus never see this template. Therefore, why not have both? We are not paper, we have space for helpful redundancy. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 15:49, 12 September 2012 (UTC)

Wikipedia:Wikimedia sister projects is not a policy, but that style guideline is not just an optional suggestion, either. And even if it were an official policy, it could be changed.

I don't really care one way or the other, but I understand that some readers jump straight to the end of articles, because they believe the most interesting stuff is in ==External links==. It all depends on what the reader wants. WhatamIdoing (talk) 04:32, 16 September 2012 (UTC)

I do a lot of editing around Wikipedia, and it's important for me to confirm that my edits are proper. By default, when I hit the Preview button, the servers handle the rendering and send it back to me. I have recently discovered the preferences setting that lets Javascript handle it instead of the servers. I know we're not supposed to worry too much about performance, but seriously, if this was enabled by default (obviously one could disable it after) I'm sure it could cut down on server load. Javascript works just as well and it's faster, so why put extra strain on donation-run servers? Thus I propose that the setting be enabled by default. • Jesse V.^(talk) 15:37, 15 September 2012 (UTC)

I assume Jesse is talking about the setting in Special:Preferences#mw-prefsection-editing->"Use live preview (requires JavaScript) (experimental)"

I think(?) that is using this code: https://bits.wikimedia.org/static-1.20wmf11/skins/common/preview.js

What about user:js/ajaxPreview (~185 uses) ? (see also WP:Gadget/proposals archive for when that was added as a gadget, 2.5 yrs ago. I'm not sure when it was removed?)

I've used that one (and previously Anomie's) for years, and love it. I'd support making it a default-On gadget for logged-in users, or even a site-wide-default.

Tangent: Are all the best features of the other 'quickpreview' scripts, merged into either of those? Because there's also

• User:Anomie/ajaxpreview.js (~60 uses),
• User:Alex Smotrov/qpreview.js (~70 uses, and the Gadget at Commons: is (or was?) based on this one. Both the Gadget and the "Use live preview" are available at Commons, currently.),
• User:CBM/quickpreview.js (~15 uses),
• and maybe more? (Many "uses" are in user/monobook, so might just be remnants of old setups)

See also the (needs an update) section at Help:Show_preview#Quick preview/AJAX preview, and the list at the bottom of User:Js/ajaxPreview#Similar scripts.

HTH. (I know I'm confused/ing...) —Quiddity (talk) 18:59, 15 September 2012 (UTC)

Wow. See there you go, plenty of client-side scripts to choose from. I had no idea those even existed. Let's embrace the new technology. • Jesse V.^(talk) 19:05, 15 September 2012 (UTC)

The problem with all of them, is that they are unable to load JS and CSS that is specific to your view. So for instance, if you add a video, then preview, the JS code to handle the video won't be loaded. This is one of the primary reasons this functionality isn't on by default yet I presume. —TheDJ (talk • contribs) 23:23, 15 September 2012 (UTC)

AFAIK, all of the currently available options do in fact use the servers anyway; most are posting to the MediaWiki API, while the "live preview" option in the preferences seems to contact its own private "API" on the servers. The VisualEditor and Parsoid projects may change this. Anomie⚔ 02:20, 16 September 2012 (UTC)

Since the last debacle where a super-usefull software feature has been killed purely for aestethic reasons, I am intent on reinstating this feature again. This time I expect no complaints; Two updates ago, the watchlist has had an extensive CSS makeover, which allows us to control the styling much better (so no more bold is needed). Even the bullet can be changed; which is exactly what my proposal is: Each unwatched item will be displayed with a green bullet (), instead of the default blue one. This would also be the case for History pages on your watchlist, where the bullet will replace the "updated since my last visit" message. Now surely... no-on can object to that...

Code to test:

/* Watchlist and history of watched pages */
.mw-special-Watchlist #mw-watchlist-resetbutton {
    display: block;
}
.mw-special-Watchlist .mw-changeslist-line-watched .mw-title {
    font-weight: normal;
}
.mw-special-Watchlist li.mw-changeslist-line-watched,
#pagehistory li.mw-history-line-updated {
    list-style-image: url(//upload.wikimedia.org/wikipedia/commons/c/c2/ChangedBulletVector.png);
}
#pagehistory span.updatedmarker {
    display: none;
}

— Edokter (talk) — 13:42, 31 August 2012 (UTC)

As you've inadvertently forgotten to link the discussion two months ago in which a majority of 101 to 43 voted to make this change opt-in only rather than foist your personal idea of "how a watchlist ought to work" on everyone else, this is the previous RFC. I take it you're going to keep on playing shoot-till-you-win until you find a board where people agree with you, at which point you'll declare that you've found "consensus" and unilaterally screw about with everyone else's user interface again? 188.29.114.59 (talk) 16:28, 31 August 2012 (UTC)

That's right, at least from your point of view. Everyone else will hopefully read my message more clearly and understand that cincumstances have changed an now allows for a non-intrusive way to have a default functionality enabled once again, in a way that will even please those that complained on purely aestetic reasons. — Edokter (talk) — 16:43, 31 August 2012 (UTC)

I've followed the directions to manually turn on the bold face text (just like all the other WMF projects!), so I'd kind of forgotten that this problem still existed. I support making this feature available to everyone, with the old power users opting out if they dislike it. Someone who knows how to complain at VPT has a better chance of being able to opt-out than a newbie has for opting in.

That said, this particular proposal probably falls afoul of

WP:ACCESS because some users with color blindness won't be able to see the change. WhatamIdoing (talk

) 20:40, 31 August 2012 (UTC)

The blue and green are very distinguishable, plus the green dot is bigger. But anything is possible now with the new CSS; any suggestion is welcome. — Edokter (talk) — 23:38, 31 August 2012 (UTC)

Please do. This is really unobtrusive. FWIW, I've updated my style-selector user script to include this new option. Anomie⚔ 00:42, 1 September 2012 (UTC)

• Strong oppose; the opt-out I had used earlier is not 100% complete. I feel that this feature is still too obtrusive on an extremely large wiki; I'm fine with it on smaller wikis like Meta and MediaWiki.org.--Jasper Deng (talk) 00:52, 1 September 2012 (UTC)

  What difference does the size of the wiki make? Besides, Commons is much bigger, with 3.5 times as many mainspace files as en.wp, and they use it. WhatamIdoing (talk) 19:40, 1 September 2012 (UTC)

  On this wiki I have 9500+ pages on my watchlist, while on other wikis I have far less. With much more activity on my watchlist than other wikis the change is a big intrusion on this wiki. I would imagine that Commons has far less changes per page than this wiki.--Jasper Deng (talk) 19:45, 1 September 2012 (UTC)

  So how do you keep those changes you have already visited on your watchlist apart from those that you haven't visited yet? Must be a pain to click on a page, only to discover you already saw that change. — Edokter (talk) — 22:07, 1 September 2012 (UTC)

  I know my timestamps. I also use pop-ups to view changes without clicking on them if I'm ever not sure (which I'm not) of whether I saw it or not.--Jasper Deng (talk) 22:24, 1 September 2012 (UTC)

  Then how would a green bullet disrupt your way of working? (Note that most of us don't have 10,000 items on their watchlist.) — Edokter (talk) — 22:45, 1 September 2012 (UTC)

  Because I don't need to be told what I already know.--Jasper Deng (talk) 23:13, 1 September 2012 (UTC)

  So from that viewpoint comes the presumption that no one needs to be told what everyone already knows? — Edokter (talk) — 00:42, 2 September 2012 (UTC)

  That RfC I started on the day of the original change tells the whole truth.--Jasper Deng (talk) 16:32, 2 September 2012 (UTC)

  That no longer applies with the new CSS. Hence the new proposal. — Edokter (talk) — 16:56, 2 September 2012 (UTC)

  This particular design was tried and failed on that same day.--Jasper Deng (talk) 16:58, 2 September 2012 (UTC)

  Must be a pain to click on a page, only to discover you already saw that change -- I fail to see how that comment even makes sense. Click "diff". Boom the link changes color and it's marked as visited in the browser. Refresh watchlist two hours late, diffs since that time are back to unvisited color. ♫ Melodia Chaconne ♫ (talk) 17:38, 3 September 2012 (UTC)

  Ah, so the bit about the "extremely large wiki" is irrelevant, a complete red herring. The relevant factor is "the size of my own personal watchlist", which doesn't seem like a good reason to keep this feature away from 99% of users. I'm pretty sure that someone of your capability can figure out how to turn the thing off. I'm even more certain that 99% of users won't know that it exists, or be able to turn it on, if it's not on by default. This situation sounds like a good time for the very small number of technically adept people who don't want it to manually modify their own environment, rather than having them impose their personal preference on the vast majority of people who would probably benefit from it (based on the positive experiences at the other wikis). WhatamIdoing (talk) 17:11, 3 September 2012 (UTC)

• This particular desing was not even possible during the RfC. This is not te same as the stars which were displayed inside the list. Did you even bother to look at the atached image that Anomie posted? — Edokter (talk) — 17:06, 2 September 2012 (UTC)

Why are we making this into such a big deal. Some people like it and some don't and thats ok. Why can't we just make it opt in or opt out at least and move on.

Opt-in is a sure way to cause 99.9% of new editors never knowing about this feature. What is the big problem of having everyone benefit from a standard function in MediaWiki? — Edokter (talk) — 17:12, 2 September 2012 (UTC)

I would support opt out. I find the feature very useful, and guess that many relatively inexperienced users would too. Including those who wouldn't ever suspect the existance of the tool if they had to look for it and opt in. Providing the opt-out works, I see no reason why anyone should object, but expect some will anyway. One other thing I would find very useful would be a way to mark a notice as checked without having to open the page. This would make things a lot quicker as the mouse-over display is enough in many cases. Cases where someone you trust has edited also don't always need to be opened. • • • Peter (Southwood) ^(talk): 18:51, 2 September 2012 (UTC)

• Support - I definitely think this would benefit me, with an ample watchlist (about 300 pages). Further, I'll support opt-out, which is a reasonable compromise as those who don't want the feature won't have it.
  talk
  ) 23:48, 2 September 2012 (UTC)
• Support - As proposed. With opt-out. --Anthonyhcole (talk) 00:30, 3 September 2012 (UTC)
• Support - By default, the opt out is already implemented, it's called Special:MyPage/common.css. Since I did not participate in the earlier RFC, I reserve the right to 'ignore' it's results when stating my opinion. —TheDJ (talk • contribs) 11:32, 3 September 2012 (UTC)
  • It's great that you understand how to use CSS, but most people don't. Therefore stating that others can just opt out using CSS is a very, very weak argument. — Preceding
    talk • contribs
    ) 15:42, 3 September 2012 (UTC)
    • OTOH, basing your argument on people not knowing CSS when a gadget can trivially be provided is similarly a very, very weak argument. Anomie⚔ 15:57, 3 September 2012 (UTC)
      • Actually, i'm also against a gadget. Things that will only be used by 20 or so folks should not be a gadget in my opinion. And that is the amount of users of the gadget that I predict when we choose the CSS that edokter is currently proposing. —TheDJ (talk • contribs) 18:26, 4 September 2012 (UTC)
• Support for opt-in only because it's a purely aesthetic choice that a large number of people objected to last time around. Very strong oppose if it is opt-out or mandatory.
  Wha?
  15:42, 3 September 2012 (UTC)
  • It seems to me it's a functional issue, not purely aesthetic. And despite the wording of the RFC, people mainly opposed the bolding and the lack of a gadget (because the feature was overridden before a gadget could be written) last time around. This proposal involves something that is so inconspicuous that I for one worry that users who would find it useful won't actually notice it. Have you looked at the screenshot? Anomie⚔ 15:57, 3 September 2012 (UTC)
    • I did finally manage to poke an admin to add a gadget for bolding unvisited changes as an opt-in (thanks Edokter!)
      1217 ^{What I've done}
      16:43, 3 September 2012 (UTC)
• Oppose watchlist already have triangles, little m's little b's now bold green dots are next annoying must have feature. Also I find this Since the last debacle where a super-usefull software feature has been killed purely for aestethic reasons, I am intent on reinstating this feature again. This time I expect no complaints rather ugly surely if the feature is such an essential item to the functioning of the watchlist that you wouldnt need to ask the community it'd be added at the next upgrade. We all do this voluntarily a little consideration for the opinions of others would go along way to getting people to even voice an opinion. What that comment has ensured is that many editors wont bother to respond, so we'll get your little bold green dot irregardless of what we want, like all non-essential gadgets I'd prefer it be an opt-in. Gnangarra 12:26, 10 September 2012 (UTC)

  Note this feature is not any sort of gadget, it is a standard part of MediaWiki, although the default styling is much more obtrusive than is being proposed here. Unfortunately, when it was rolled out here, a bunch of people complained and MediaWiki:Common.css was edited (without sufficient thought or discussion) to hide all visible effect of the feature. This discussion is a proposal for something much less obtrusive, hopefully enough so that this vocal group will stop insisting we hide the feature from all new users just because they are too lazy to enable a gadget to hide it for their accounts only. Anomie⚔ 17:57, 10 September 2012 (UTC)

  and again the language being used is creating the issue, why not just provide both options rather then deride those that dont want it. If it was that obtrusive that a sufficient number people odjected to it in the first place then is not reasonable to address those needs, then respond in a

  civil manner. Gnangarra

  23:32, 10 September 2012 (UTC)

  Look at how much people also complained about the new diff colors, which were released at around the same time. But there the complaints were handled well: a gadget was created for the complainers to enable to change it back, rather than forcing the old colors on everyone who doesn't know enough to look for a gadget to get the MediaWiki default back. Anomie⚔ 23:53, 10 September 2012 (UTC)

• Support, a very useful feature. --Yair rand (talk) 18:16, 10 September 2012 (UTC)
• Support OPT-IN ONLY AS IT IS NOW!. We've already BEEN through this crap! STRONGEST POSSIBLE OPPOSE FOR OPT-OUT OR MANDATORY Barts1a / Talk to me / Help me improve 03:26, 17 September 2012 (UTC)

• Like a dog to its vomit, the community to this sick.—The community has well spoken on this and I feel no need to oppose a grossly premature revisitation of a point on which such a strong consensus has previously been displayed. Fifelfoo (talk) 03:29, 17 September 2012 (UTC)
• Support opt-in Seems the safest route. • Jesse V.^(talk) 03:33, 17 September 2012 (UTC)
• Eh... While I would in a heartbeat support putting the MediaWiki default back on as the default, as making it opt-in for the sake of satisfying existing users simply puts new users in the dark about it existing at all (and no, expecting them to go through all 48 gadgets and try them all to see what they do simply is not reasonable), these alternate proposals have not only already been shot down same as the rest, but would only serve to make the function less useful even if they were used. -— Isarra ༆ 03:52, 17 September 2012 (UTC)

Is possible to add a user count in every wiki ?

We can see how many read wiki.

Example: There are xxx users in this wiki right now.

What do you think ? --Tegra3 (talk) 06:50, 16 September 2012 (UTC)

If this was updated in real time and displayed on your screen it would be more clutter and software bloat - slowing things down, when those of our editors who don't have very fast connections are already getting slow load times. But if you want pages to go to that will tell you how many readers we have and how many editors then I suggest you look at Wikipedia:Statistics and the pages it lists. We have a lot of stats, some updated in real time and some less frequently, I that that includes both of the things that you are asking for. ϢereSpielChequers 08:01, 16 September 2012 (UTC)

Also keep in mind that the number of accounts Wikipedia has is a horribly misleading number. We have people that register and never edit, people that register only to upload a picture of their cat and stick it on their userpage, sockpuppets, vandalim-only-accounts, test accounts, bot accounts (both used and unused), secondary accounts (both used and unused), secondary bot accounts (both used and unused), and users that were active in 2003 for a month and a half and haven't been heard of since. That makes the number less than useful.

Wha?

02:56, 17 September 2012 (UTC)

I believe that the request is for a real-time number that is equivalent to "There are X users reading this forum right now", not a request for the number of registered accounts (which is currently 47,272,838, updated in real time). WhatamIdoing (talk) 22:38, 17 September 2012 (UTC)

It seems quite reasonable to implement this proposal, as it would give us a more thorough understanding of how trafficked this wiki actually is. We should also add to this a measure of how many pages are currently being edited, how many of these edits are comprehensive (±10,000 characters to an article), what namespaces these edits belong in, and how many page creations/deletions have occurred up to that point on that particular day/week/month/year/since the beginning of Wikipedia. These should be displayed both as raw numbers as well as in a graphical format, and should go back until as far as data exists. Of course, there should be an option to turn on and off various features of this panel, if a few kilobytes every ten seconds causes a problem for anyone.

Proposal moved to Wikipedia:Village pump (proposals)/Simplify the edit window.

Please comment, though. -— Isarra ༆ 03:00, 17 September 2012 (UTC)

There was a need for a

Expert advice is not really how Wikipedia works, for example I happen to be a world famous expert in carpetology , thats right, the study of car pets, but if I say the nodding dog in your car is actually a sign of your own deep rooted anxieties about poodles, that doesn't make my point remotely useful unless I have a reliable source to back it up--Jac16888 ^Talk 19:59, 17 September 2012 (UTC)

Please read the page. The idea is to encourage people to contact the people who produce reliable sources to get their opinions to help resolve disputes. Since most of the people who generate our sources have easily discoverable e-mail addresses, this makes them accessible to our queries. They can refuse to talk to us, but there is no harm in asking their opinion to help resolve content disputes. As it is, there is no way to access expert opinions to help resolve content disputes. Such a system helps mitigate this problem. Junjunone (talk) 20:02, 17 September 2012 (UTC)

I'm not sure if all academics would appreciate editors emailing them in this way. What counts as an expert? Let's pick an example, say

talk

) 20:07, 17 September 2012 (UTC)

I think the academics will manage. Who counts as an expert in physics? Many, of course. Chose someone from This list, for example. This isn't meant to be anything more than a way to get an outside opinion on, for example, a topic where expertise may be needed to actually understand the dispute. Junjunone (talk) 20:29, 17 September 2012 (UTC)

Who decides on the expert? Say there are two editors, one religious and one not, are having a dispute over a religious topic (hey, it could happen you never know) and decide to get an "expert opinion". Editor A emails Bishop X, a well known religious scholar. Editor B emails Professor Y, a well known atheist scholar. Both experts reply with their opinions, each supporting the editor who contacted them. Result is nothing changes, their is simply more to argue about--Jac16888 ^Talk 20:35, 17 September 2012 (UTC)

Ideally, the disputants would have to agree on which expert to e-mail together. It would require a bit of "assuming good faith". It could be that the two cannot agree on who is an expert or not in which case the "Ask an expert" option fails and other means of dispute resolution have to happen. But this happens with all the other avenues, apparently. For example, on

WP:3O they will sometimes say that a third opinion cannot be offered because the dispute isn't suited to it. Not every dispute will be resolved by asking for an expert opinion, but I have a feeling that this could be a good option for more academic oriented disputes. Junjunone (talk

) 20:45, 17 September 2012 (UTC)

There is a proposal for an an umbrella organization for chapters and other groups in the US called the Wikimedia United States Federation. A draft of the bylaws is now up at meta. There will be an open comment period on the bylaws 17 September, 2012 to 1 October, 2012. The comments received given will be incorporated into the bylaws and they will be put up to a ratification vote from 8 October, 2012 to 15 October, 2012. --Guerillero | My Talk 21:48, 17 September 2012 (UTC)

• Where exactly do we go to, you know, discuss the organization as a whole? The bylaws page is a mass of legalese specifics, while the main page for the organization is mostly old discussion and doesn't do a very good job of explaining why it ought to exist or how it will be useful. Is there somewhere I can go to read about why we need this group, what it will do for wikimedians, and why the bylaws are necessary to allow it to do those things? A fluffernutter is a sandwich! (talk) 21:57, 17 September 2012 (UTC)

• There is more of a summary proposal at meta:Wikimedia United States Federation/Draft bylaws#Proposal (which has recently been expanded). Discussion would go at the RfC talk page--Pharos (talk) 01:52, 18 September 2012 (UTC)

Hi. There's a proposal to add an API/Developer/Developer Hub link to the footer of Wikimedia wikis. Further information is available here: <http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063257.html>. Please comment on the relevant bug, as necessary and appropriate. --MZMcBride (talk) 01:09, 18 September 2012 (UTC)

Reiterating my comment from Wikipedia_talk:Manual_of_Style/Layout which was mentioned by another user at Wikipedia_talk:Stub, I propose that all stub templates are eliminated. Some similar proposals have been raised before without generating much discussion:

• Wikipedia:Village_pump_(policy)/Archive_83#Stub_templates_are_useless_content_and_belong_only_on_the_Discussion_page.
• Wikipedia:Village_pump_(policy)/Archive_70#Eliminate_stub_classes.2C_use_categories_instead.

I shall paraphrase my previous comment to :

PROPOSAL: Stub templates should be completely eliminated. RATIONALE: There are a variety of reasons. It is often unclear to editors when to remove them. For instance, it is very common to see articles that are way past stub status yet still have stub a template (or templates!) attached. Sort of opposite to the previous case, there are very many articles that are unlikely to ever get past stub status and so the templates just linger providing clutter. Spoiler tags were removed in part because it was "generally expected that the subjects of Wikipedia articles will be covered in detail" and were clutter. A template reminding us that we can expand an article is equally useless. It is always true that we can help expand an article so a template reminding us of that is clutter. A case could be made that the templates encourage new editors to start editing but stub templates have always been sold as helping organize articles, not as an "editor engagement" method. Even if the "editor engagement" benefit of footers is worthwhile, it could easily be done sans all the categorical (in the sense of requiring Wikipedia categories) baggage that stub templates entail. For example, simply putting "You can help Wikipedia by expanding this article" at the bottom of every article does the same trick. The other benefits of stub templates (which seem to be limited to just allowing editors interested in a topic to find short articles to edit) could be subsumed into the article class rating of Wikiprojects. Any editors that like to expand short articles could locate them through Wikiprojects. We currently have this duplication of article "rating" which can cause a Wikiproject article class rating to be incongruent with the presence of a stub template. This proposal eliminates that duplication.

I anticipate from the other similar proposals that somebody will claim that stubs templates help expand articles. There is, to my knowledge, no study to support (or deny) that claim. My anecdotal experience lends me to believe there's no significant expansion of articles due to stub templates so I skeptical of such claims. If you are going to claim this, either cite a study or recognize your own view is also anecdotal. Jason Quinn (talk) 15:06, 12 September 2012 (UTC)

Personally I think that the stub templates could be cut way way back but not eliminated. I think we have way too many stub templates, a lot of which aren't used or IMO needed and it just causes too much maintenance to continually add them and remove them as necessary. Its a full time job for a dozen or more people just doing stub sorting. I think its better to use less stub templates and spend more time working on the article. More to the point, here is why I don't think they can be completely eliminated.

1. Some projects gauge the stub "assessment" differently than the stub tag.
2. Most people don't mess with talk page templates so far less are likely to add them
3. Adding stub tags, to me, is an important part of sorting the articles
4. tagging as stub is a good checks and balances between the aritcle and the talk page. Many assessment bots look for the stub tag to assess the article automatically.
   talk
   ) 17:06, 12 September 2012 (UTC)

• A stub template really serves two functions. First, it is an invitation to edit. Subjectively, I don't believe it helps much, if at all, in this regard. The second reason is stub sorting. So my question, which I believe Kumioko may be able to answer, is what is the value in stub sorting? Resolute 17:19, 12 September 2012 (UTC)

First, I personally agree that its unlikely to me that an editor is going to edit the article because they see a stub tag buried at the bottom of the page. That's always been a stretch for me. As I mentioned above I also think that in many cases we over complicate the stubbing/categorization process by adding too many layers. For example, all of the following stub tags add the articles to the same category (Category:American painters, 20th century birth stubs):

• Template:US-painter-1900s-stub
• Template:US-painter-1910s-stub
• Template:US-painter-1920s-stub
• Template:US-painter-1930s-stub
• Template:US-painter-1940s-stub
• Template:US-painter-1950s-stub
• Template:US-painter-1960s-stub
• Template:US-painter-1970s-stub
• Template:US-painter-1980s-stub
• Template:US-painter-1990s-stub

We also have

• Template:US-painter-stub
• Template:US-painter-1800s-stub
• Template:US-painter-1810s-stub
• Template:US-painter-1820s-stub
• Template:US-painter-1830s-stub
• Template:US-painter-1840s-stub
• Template:US-painter-1850s-stub
• Template:US-painter-1860s-stub
• Template:US-painter-1870s-stub
• Template:US-painter-1880s-stub
• Template:US-painter-1890s-stub

Which relate to similar categories and IMO this level of granularity is completely uneeded and just overcomplicates and overburdeons the process unnecessarily.

This is just one example, for one niche group of articles but the end result IMO is self evident. It takes a lot of time to sort these things and properly categorize them.

With all that said, I do think we need to keep some process of tagging articles as stubs. I think its important for several reasons to identify these articles outside the assessment on the talk pages as stubs because as I said above most folks wouldn't look at the talk page and if they did the project could characterize a "stub" as something different than the "stubbing" system with templates on the Main article page. Also, categorizing articles as stubs helps us as editors to identify which ones are 1) In need of the most work, 2) which ones aren't and 3) and probably the most important, allows us a lower level of granularity than the assessments onthe talk pages. By grouping them into like categories (American painters for instance as shown above) it allows editors who are interested in that topic to edit them without having to dive through the categories, which may or may not cover that topic. I hope this helps. I would also add that to me the Stub template name should match as closely as possible to the associated category. Using the Example above if the Category is called American painters, then the stub template should be

talk

) 20:51, 12 September 2012 (UTC)

• The one thing I would be wary of claiming (in addition to how some WikiProjects use the stub assessment differently) that one could use the talk page, is that there will be articles without a talk page, ergo, they will not be tagged for a WikiProject. My $0.02. --Izno (talk) 22:18, 12 September 2012 (UTC)

This is an excellent point worth more than 2¢ that would have to be taken into consideration. Also important would be articles that do not naturally fall under the auspices of any particular existing Wikiproject. Both these situations warrant a solution, perhaps requiring a slight weakening of the proposal. Overall I think it is a minor issue compared to the one being solved though. Jason Quinn (talk) 01:18, 13 September 2012 (UTC)

• Support - it's blindingly obvious that an article is a stub...it's really short, right? So why do we need yet another annoying template to say so. Wikiprojects can look at the length of the article using any number of tools which are guaranteed to deliver a realistic appraisal - rather than some subjective judgement that might just be entirely wrong (either false-positive or false-negative). SteveBaker (talk) 22:41, 12 September 2012 (UTC)
• Oppose - I agree it is unlikely that a stub tag would prompt editing from someone who wouldn't otherwise, but to be honest I feel the same about virtually every cleanup/wikify tag, and most of those are a lot more visible. To me, the point of stub sorting is the categories: An editor who fixes/expands/references/etc a particular 19th century American painter article because that is their area of interest/expertise can find 120 more articles on the same topic for expansion using the stub category, whereas a category like Category:Articles lacking sources from April 2008 has 2000+ effectively unrelated articles on hundreds (if not thousands) of topics. I can't of course offer any studies to say this happens besides relating that I have used it that way before (looking for newer articles likely to be missing certain infoboxes, navboxes, etc, without having to search the entire much larger category). So I think the stub category structure is of far more value than the visible stub tags. --Qetuth (talk) 03:05, 13 September 2012 (UTC)

Just to clarify why I think the stub cats are valuable: The Wikiproject categories should be good for this, but in practice, in the vast majority of cases, they are not. Maybe one day this will have changed. Is sorting American 19th century painter stubs by decade too much? Probably, yes, which is why that category recently got merged. But most of those articles (from random sampling) have a Wikiproject category of Category:Stub-Class biography articles (620,000 articles), except a few who have been sorted into Category:Stub-Class biography (arts and entertainment) articles (a mere 50,000 articles). Some few have interest from a second WikiProject, but these are completely inconsistent (some have a US state, some another country, some wp: Visual Arts, etc, or something completely different). For 'allowing editors interested in a topic to find short articles to edit', this is completely useless --Qetuth (talk) 03:22, 13 September 2012 (UTC)

• Comment I'm pretty sure that we don't have a wikiproject to cover the scope of every article, and if we don't have a project to cover an article, what then? Or if the wikiproject that covers the article doesn't support assessment? or if they have been classified as inactive, and therefore the banner doesn't support assessment anymore? -- 76.65.131.248 (talk) 05:57, 13 September 2012 (UTC)

A new "Wikiproject Misc." could be created to cover articles that fit into no Wikiproject. If a Wikiproject doesn't support assessment, that's their prerogative. I was unaware that inactive projects no longer support assessment. I don't know. Would have to think about it. Jason Quinn (talk) 15:24, 13 September 2012 (UTC)

I think it unlikely that many pages will fall under at least one WikiProject. I will, however be even more iconoclastic and suggest that the whole values of many WikiProjects, much of the work around WP 1.0 and the several million banners are pretty much up for dispute. Also creating talk pages with just banners has the deletoray effect of making it impossible to tell if there is discussion on a page without actually opening the tab. Rich Farmbrough, 21:12, 13 September 2012 (UTC).

I think this was a stronger argument back in 2006 or so; as it is, in many cases the discussion that would turn the tab blue is a few passing comments from several years ago. The semantic value of a blue talkpage link (even without templates) is reduced the longer the page has been there. Andrew Gray (talk) 09:11, 14 September 2012 (UTC)

If you create a WPP-Misc, that could solve the two other problems, by adding a Misc-banner (so WPPs without banners, or whose banners don't do |class=, or whose banners has been inactivated by the inactivity setting, will be covered) ; If every page uses WPP-Misc for general quality assessment (stub/start/FA/etc), and page-type assessment (type=article/list/dab/etc), then regular WPPs could be reduced to just assessing importance (or not assessing if its their wont) -- 76.65.131.248 (talk) 23:06, 13 September 2012 (UTC)

I think there is a good case to be made for amalgamating all the quality assessment system into a single template, and hanging project/importance tags off that, rather than the other way around. But that's another discussion, I think ;-). In an idea world, we'd be able to move all this metadata to be separate from the discussion, helping alleviate things like Rich's concern above.

Regarding inactive, my understanding is not that the banners don't support assessment because they're inactive, but rather that because the projects are inactive they were never "upgraded" when article ratings became standard practice some years ago. Originally, these banners were very little more than "ownership tags"; rating appeared later. Andrew Gray (talk) 09:11, 14 September 2012 (UTC)

{{

WP:COUNCIL I suppose, determines that a WPP's activity level shows no activity, it is tagged as inactive, and the banner is converted into a non-assessment form. The existing assessments are still on switches at the talk pages, but they don't get categorized or do anything anymore. (like any other template parameter that is used but not coded for) It doesn't have to do with upgrading, it concerns the amount of activity seen at the WPP. If the WPP doesn't use WPBANNERMETA, it can't have an inactive banner. There are still WPPs that don't do assessment, and WPBANNERMETA also supports not assessing (it's optional) so even then, lacking assessment is not a sign of not using current banner technology. -- 76.65.131.248 (talk

) 19:41, 14 September 2012 (UTC)

The French Wikipedia uses a single project banner template that does quality assessment, and subbanners for assessing each project's importance assessment. -- 76.65.131.248 (talk) 19:45, 14 September 2012 (UTC)

• There are two separate issues here: (a) is it useful for articles to be labelled as "stub"; (b) is it useful for them to be "stub-sorted", ie labelled as "this-subject-stub" and put into category "This subject stubs" (or sometimes a parent category, where the template is an "upmerged" one like the US artists above). I have spent many, many, hours
  stub-sorting over several years. As far as I know, this whole structure was created in the belief that there are editors out there who look for articles in category "This subject stubs", in order to work on them and improve them. I do not know whether this is (still?) the case, and would welcome any evidence one way or the other. Activity at Wikipedia:WikiProject Stub sorting seems pretty low right now, and sadly one of its leading lights has left Wikipedia "owing to the over-officiousness of several users who have made this site no longer the enjoyable place it used to be". But I urge that any decision to abandon this whole structure (stop stub tags, or stop sorting them) should only be done after wide discussion. PamD
  07:09, 13 September 2012 (UTC)

There are at least two issues occurring, maybe even three if you include my "new editor recruitment" idea. Weaker proposals that target only individual issues might be a better approach. For instance, if it is true that stubs are unwanted clutter for the article but stub categories are beneficial, then stub templates could just be converted to hidden stub category inclusions. Jason Quinn (talk) 15:36, 13 September 2012 (UTC)

Oppose Quite often one finds either an error or ommision in a particular stub. The assumption that a similar error/ommmision is in similar stubsize articles is usually not wrong. So after finding an improvement the stub-category is the first place to go to in order to duplicate that specific improvement. Project assessment categories are far too wide to accomplish this and serve a more shotgun approach purpose. Even at the reduced stubsorting activity due to the people that make life on the wiki unbearable the work that has already been done and is still happening make it worthwhile to keep the templates. If stubsorting is totally abandoned for more than a year we can look at this again as the incomplete categories will start to loose their purpose. Removing them now would be premature. 09:15, 13 September 2012 (UTC) — Preceding unsigned comment added by Agathoclea (talk • contribs)

• Comment: 'Oppose' because it would put Pam out of a job she has been doing meticulously and with great devotion for years. On a more serious note, before deciding this on a simple straw poll, some metrics are required, such as for example, how many different stubs are there? (I would guess a couple of 1,000); How many are there of each kind in use? How much time does it take for a user to find and apply the right one? (I only have a few dozen in my head, and for the others I just leave a generic 'stub' tag (sorry for all the work I cause you Pam); How many stubs get expanded to when the stub tag is removed? How many articles get developed due to having a stub tag? (probably impossible to say). How many projects actually go through their stub articles and try to improve them? (probably impossible to say). Kudpung กุดผึ้ง (talk) 10:50, 13 September 2012 (UTC)
  • I don't know the exact number but its more than 10, 000. There are more than 1000 just related to the US.
    talk
    ) 11:15, 13 September 2012 (UTC)
  • Comment The idea of similar errors replicated across a category because of the same editor populating those categories is noted as a good point. It does however rely on people actually fixing stub cats for it to be important which is questionable. Yet it remains a valid issue. Jason Quinn (talk) 15:41, 13 September 2012 (UTC)
• Comment - I have I think propose din the past, and I do so again, the idea that stub templates could, without loosing much functionality, be invisible, leaving just the category as the useful semantic structure. Rich Farmbrough, 21:14, 13 September 2012 (UTC).
  
• Oppose I think the stub system works fine; I often use it to find articles worth editing, expanding, or cleaning up. Yes, sometimes the template doesn't get removed when it should be, but other than that I don't find merit in the other rationales for such a sweeping change. --Jayron32 05:23, 14 September 2012 (UTC)
• Oppose Jayron could not have said it better. It works fine and is the source of countless great ideas for articles. Mugginsx (talk) 20:32, 14 September 2012 (UTC)
• Oppose/Comment. Stub templates are there for a reason. It's to invite potential users to help expand the page. it's up to the editor if they actually want to do edit it. As for false positives, one possible solution is for a bot to remove a stub template from an article once it reaches a certain length and/or if its classification in a WikiProject is not Stub or Unassesed. The problem with this is that not all articles have such WikiProject templates on their talk pages, so, especially in the case of newly created articles, this may prove problematic. Perhaps the same bot can also automatically tag an article with a stub template if its classification is stub. I'm not sure if any of my suggestions above will be practical however.
  csdnew
  12:00, 16 September 2012 (UTC)
• Oppose per "Stub templates are there for a reason. It's to invite potential users to help expand the page." from the above user.
  Wha?
  03:08, 17 September 2012 (UTC)
• Delete There is no reason to let us know that an article is a stub. If it needs expanding, then we have other templates for that, and if it is supposed to be a short article, then all is good without the stub template. Debresser (talk) 20:23, 18 September 2012 (UTC)

No, there isn't - but that's like arguing we should delete the category system because it should be clear from reading an article what categories it should be in. We may have other templates that say to expand, but we do not currently have a (working) system which does what stub cats do. Category:Articles to be expanded for example has over 100,000 articles, with no sorting by topic/field whatsoever - and it is currently not present on most stubs (which there are a lot more than 100,000 of). --Qetuth (talk) 04:57, 19 September 2012 (UTC)

Shame the discussion was closed.... we were having so much fun discussing it... :)

After a bit of sleuthing, I discovered that the term used in Wikimedia Commons for images at Featured status are called: Quality images.

Quality images are diagrams or photographs which meet certain quality standards (which are mostly technical in nature) and which are valuable for Wikimedia projects.

— [4]

Why are there two different categories of images - Featured Pictures in Wikipedia and Quality Images in Commons? Seems rather weird to me. And why not rename our featured articles to match this naming? "Quality" seems embedded within the wiki culture, so it's not like we're completely changing tradition - one of the many rebuttals in the original conversation. (P.S. I'm aware of the wiki/commons squabbles but surely we can sort out of differences and share the wikilove :D)

If memory serves, the words being tossed around included exemplary, exceptional, prime, top article, premium, (and of course) featured.

Also, as a side note, something that grabbed my attention in the previous discussion was the fact that we have many different quality levels for articles, and we still only have "list" and "featured list". Why not change this to match the article quality levels, although of course changing the criteria for each level.

Not trying to be that annoying rash that never goes away, but the new information strongly seemed to support the validity of a change, and so I wanted to bring the issue up again.--Coin945 (talk) 12:54, 18 September 2012 (UTC)

Please keep in mind that the name Quality article

is taken. That was mentioned above, among many other things, --Gerda Arendt (talk

) 13:05, 18 September 2012 (UTC)

Ohh I see. Quality article in that context refers collectively to good/featured/featured candidate articles. Good point. There was so much text confusingly written up there I was bound to get lost in it all. Thanks for pointing that out. Well i guess that means this discussion is null and void. I wonder where that "withdraw" template is...--Coin945 (talk) 14:11, 18 September 2012 (UTC)

Um. Featured images on Commons are called featured images. Common's Quality images are like Wikipedia's Good articles; however, so are Common's Valued images. Rmhermen (talk) 23:08, 20 September 2012 (UTC)

Based on the previous discussion

Resolved

 – Template created, placed, and numerous instructions updated. Check back in a month to see whether it helped. —Cupco 01:22, 19 September 2012 (UTC)

How about creating a template doing what a user tried to do here: [5]?

This article is being discusssed at the

Perhaps with a little icon like the one shown on the right? Might bring additional eyes to any ongoing BLPN thread, and would be a convenient means of letting other users know that a BLPN thread has started. --JN466 11:04, 18 September 2012 (UTC)

Not a bad idea, but mentioning a noticeboard on the front of the article would probably confuse most readers. This sounds like something you want on the talk page.... Here I'll subst {{BLP unverified}} and edit that:

Something like that? —Cupco 11:12, 18 September 2012 (UTC)

Yes, very nice, thank you. But I think it would actually make sense having it on the article page rather than the talk page, if you want to involve people. We already have many templates asking people to add sources, or advising them that the article's neutrality is disputed and they should look at the talk page. Telling them about a discussion at BLP/N is not much different really, and BLP/N could always do with more eyes. Just my 2 cents. --JN466 14:30, 18 September 2012 (UTC)

I'm a bit hesitant... do we really need floods of people heading over to the

WP:BLPN? Think about what 500 inexperienced editors who happened to be reading an article all charging to the noticeboard would do. I think a talk page notice is more than sufficient, IMHO. Theopolisme

20:49, 18 September 2012 (UTC)

Having a template on the article page (along with the existing BLP sources template, in this case) was my initial preference, as few editors might bother checking the talk page (or for that matter check out even recent article history). Great work, anyhow. Esowteric+Talk 08:59, 19 September 2012 (UTC)

Is it safe to say that anything on BLPN should also have an article tag directing people to look at the talk page? —Cupco 21:09, 19 September 2012 (UTC)

Note, one reason I added the text to the top of the article was because I wasn't convinced that a registered user and two IPs were even looking at the page history, the article talk page or their own talk pages and reading the advice and warnings given; but I did know that they were reading the article itself. (They were making individual edits, not reverting).Esowteric+Talk 09:22, 19 September 2012 (UTC)

I went ahead and created {{BLP noticeboard}} and have populated the existing BLPN articles and its instructions, and will try to keep an eye on the articles and their discussions to see if it helps or hinders. —Cupco 01:02, 19 September 2012 (UTC)

Fabulous, thank you. That was quick work! Esowteric+Talk 08:43, 19 September 2012 (UTC)

+1. Great work. I still think the thing should go onto the article page, though; not least because I think it is more likely to be forgotten (and left on indefinitely) on the article talk page. But so far, so good. JN466 14:35, 21 September 2012 (UTC)

I think you're right. I've been discussing automating removal with a couple bot authors. —Cupco 22:45, 21 September 2012 (UTC)

You are invited to participate in an RfC at Wikipedia talk:Requests for mediation/The Beatles on the issue of capitalising the definite article when mentioning that band's name in running prose. This long-standing dispute is the subject of an open mediation case and we are requesting your help with determining the current community consensus. Thank you for your time. For the mediators. ~ GabeMc ^{(talk|contribs)} 23:34, 22 September 2012 (UTC)

Hi. Per the shown bug, I would like to propose setting $wgPrependCategoryInCategoriesSpecialPages to true on English Wikipedia which means that namespace name "Category" would be added to category lists on the following special pages:

• Special:MostLinkedCategories
• Special:UncategorizedCategories
• Special:UnusedCategories

This makes it easier to copy all category names and paste it to a file to be used by bots (like to nominate all these categories for deletion or mass categorized them) instead of having to add the namespace name manually. --Meno25 (talk) 13:23, 23 September 2012 (UTC)

After combing through a template category to find exactly what I want for the umpteenth time today (this particular time, Category:Table and column templates), it struck me that templates are visual devices, and visual devices are best recognized visually, not by name. It would be massively useful if it was possible to be able to create thumbnail images representing the output of a template and associate them with that template for display in template category listings.

Points:

• Thumbnails would be small images containing either a shrunken view of a complete rendering of that template, if practicable, or a representative selection of part of it distinctive enough to give a quick impression of what the template is for.
• A good layout would be for the thumbnails to be rectangles and displayed immediately underneath the name of the template they apply to.

• The images would be optional and manually produced; editors' judgment would be required to select the best thumbnails.
• Settable by a magic word in the template? {{THUMBNAIL:Template Example thumbnail.png}} Or a new field in the editing interface?
• Some people would prefer not to see thumbnails in listings, so there would need to be a preferences option to disable the behavior.
• Template documentation pages could use the thumbnails in them in addition to textually describing the contents of templates. Consider the case of "see also" lists.

I see this as a way of improving the sometimes very difficult process of navigating our template system, which is often extremely opaque, even to editors who've been around as long as me.

Only minutes after thinking this I happened across Category:Image with comment templates, which is a sort of crude manual example of what I'm imagining.

What do you think? --

Per the discussion at Wikipedia talk:Featured picture candidates#Wikipedia:Picture peer review I propose marking Wikipedia:Picture peer review as historical. Just in case there are people beyond the Featured Pictures community who are interested, I'm asking here first to see if there is a broader community consensus, or a lack of community interest, regarding keeping PPR active. The consensus among the Featured Picture community appears to be that PPR can be closed. Pine^✉ 08:08, 24 September 2012 (UTC)

About a month ago Jimbo created User:Jimbo Wales/Personal Image Filter as a followup to the perennial image filter issue. Discussion on that has petered out (no comments in last 4 weeks), and we don't seem any nearer to a solution that meets the criteria listed at User:Jimbo Wales/Personal Image Filter.

So, here's my suggestion, a (very) partial and (hopefully) uncontroversial answer to the perennial image filter question by giving users more control over what they see. It is simply a tool that will

1. put an images on/off switch at the top right of every article, defaulting to images on.
2. in images off mode, leave the image space blank, and show images after clicking them. Icons (images below a certain size, say 50 pixels) and images transcluded by templates would be excluded from this mode: neither should ever present images that someone would want to hide.
3. allow logged-in users to change their preferences, so images can be off by default (i.e. shown only after clicking), and to hide the images on/off switch.
4. the switch in point 1 gives users the option to apply the choice to the page or to the site; and for logged-in users, remember per-page on/off settings.

Now, I asked recently at

So, does the community support development of such a tool? Rd232 ^talk 18:54, 29 August 2012 (UTC)

• Strong support if implemented EXACTLY as proposed here (points 1. - 4.). -- Toshio Yamaguchi (tlk−ctb) 19:04, 29 August 2012 (UTC)
• 'Tentative support of 1-4, on a trial basis. My main concern would be breaking the page through the hiding/showing of images. Also, how would page caching affect this? We could end up with unhappy, or at least confused, readers, something we should want to avoid. Also, the switch should be clearly located, but not so glaring as to be distractive. Maybe place it over in the toolbox? - jc37 19:57, 29 August 2012 (UTC)
• Comment - a trial run could be beneficial. I think it would need to be codified right from the start, and stated directly by the Foundation, that under no circumstances will the filter ever default to 'hide images', either on a site wide basis, or for any individual article. Resolute 20:09, 29 August 2012 (UTC)
  • Well if that's what it takes, fine. But images off sitewide by default is completely and utterly implausible, whilst off by default on individual articles hardly less so, and in any case would require a system to choose which articles to apply it to - and there's no evidence there will ever be any agreement on that type of issue. Rd232 ^talk 23:47, 29 August 2012 (UTC)
    • Coming to an agreement on such a use is not my concern so much as the incessant arguing that certain editors would create on certain articles. Basically, what I would like to see in an image filter policy is a statement that "default to censorship will never happen. Don't even bring it up because the discussion will be ended immediately, with a block if necessary." But, as a personal concept, I can get behind a simple filter like this. Resolute 23:54, 29 August 2012 (UTC)

• Support for all 4 points. -- P 1 9 9  ✉ 23:21, 29 August 2012 (UTC)

• Tentative Support Fine with everything but allowing an account setting to hide the on/off switch. It must always be easy for a reader to easily turn an image, or all images back on. Also, my support is conditional on this finally resolving the image filter debate, if discussion suggests that a substantial portion of contributors view this as a step towards a more involved image filter, then I will be switching to strong oppose. Monty₈₄₅ 00:01, 30 August 2012 (UTC)
  • It must always be easy for a reader to easily turn an image, or all images back on. - yes, clicking a hidden image should always show it; and maybe hiding the switch would turn all images back on. Rd232 ^talk 13:44, 30 August 2012 (UTC)
• Comment. If the feature is not strictly limited to hiding the images in the article currently being viewed then, from an intuitive design point-of-view, the on-off switch should not be located within the area of the screen given over to the article but instead at the very top of the screen or in the left-hand menu (i.e. locations where we expect to find features with a site-wide application). Formerip (talk) 00:14, 30 August 2012 (UTC)
• Conditional support. I've long supported the general idea. Of the points noted above, I oppose only the part about excluding icons and images transcluded by templates. The statement that "neither should ever present images that someone would want to hide" is exactly the sort of subjective judgement that we need to avoid.

  For an image filter to be acceptable at Wikipedia, it must be completely neutral. It's impossible to anticipate all of the images that people will want to block, but the many examples cited include

  David Levy
  00:31, 30 August 2012 (UTC)

  Well my concern is not to unnecessarily break interface images. I suppose the solution is to give users control over whether to hide icons/template images, so they can decide for themselves. Rd232 ^talk 13:44, 30 August 2012 (UTC)

  That would be fine, provided that the distinction isn't drawn by default. (In other words, the image suppression should apply to icons and template transclusions unless the user specifies otherwise.) —

  David Levy

  14:09, 30 August 2012 (UTC)

• Conditional support, like David Levy: I can imagine any number of reasons why someone would want to block icons or template images, ranging from arachnophobia to template vandalism, so the simple image filter should hide those images as well. In "images off" mode, the only images this should let through are user-interface elements like the disclosure triangles on the enhanced watchlist. --Carnildo (talk) 00:54, 30 August 2012 (UTC)
• Right at the top of every article? There really isn't any extra space left there. The upper area of the page is already stuffed with tons of icons, buttons, links, and notices. In my opinion, that area already has much more than it should, and an images toggle button wouldn't be that high in the list of priorities. --Yair rand (talk) 11:46, 30 August 2012 (UTC)

  I echo that sentiment. Can't we figure out a better location ? —TheDJ (talk • contribs) 12:03, 30 August 2012 (UTC)

  The toolbox was suggested above. —

  David Levy

  13:25, 30 August 2012 (UTC)

• Please educate me - I kinda want to support something like this - but I don't understand how this proposal works. If the switch is on the page itself - and it defaults to "ON" - then it's 99% certain that when I visit an article with NSFW (or whatever) images on it, I'll see the image before I have the opportunity to turn it off - and if my employer logs my Internet access and sees that I downloaded a porn image, I'll still get fired even if I turned images off on that page subsequent to it initially being loaded. Doesn't this seem a bit pointless? If I'm an arachnophobe and I can't bear to see images of spiders - then I need to state that globally so that if I visit (say) A Romance of Two Worlds - and innocently click on the unfamiliar word "gossamer" (which happens to redirect to Spider silk), I'm not confronted with two images of spiders before I can click the "Yuck no spiders please" button. What I need is a user-preference to say "No spider pictures" (or "No porn" or whatever) and have that operate globally. SteveBaker (talk) 13:02, 30 August 2012 (UTC)

  The third point of RD232's proposal addresses that. There would be a 'master switch' available in your profile that would allow you to default all images off. Resolute 13:17, 30 August 2012 (UTC)

  And it's been stated at the Wikimedia Foundation level that the idea of an image filter based on content tagging is off the table. If someone wants such a setup (i.e. one that identifies and suppresses images depicting specific subjects), they're welcome to develop and deploy a third-party solution. —

  David Levy

  13:25, 30 August 2012 (UTC)

  The idea of an image filter with categorizing of content etc was of the board (mostly because of the contentiousness of classifying content). This is however a much simpler approach of everything on vs. everything off. I think it is within the realm of what might reopen the discussion at WMF level, especially if there are volunteers implementing this. —TheDJ (talk • contribs) 21:36, 30 August 2012 (UTC)

  Yes, that's my point. The idea of developing and deploying an image filter system based on content tagging has been abandoned by the WMF, but the type proposed here remains a possibility. —

  David Levy

  22:19, 30 August 2012 (UTC)

  Is there any way of incorporating the user preferences in such a way that a supervisory program not under the individual users control cannot alter the default setting? DGG ( talk ) 13:37, 30 August 2012 (UTC)

  Really? You imagine a supervisory program trying to fiddle with a user's Wikipedia preferences over image display, instead of just blocking images directly? Paranoia should be attenuated by Ockham's Razor, at least. Rd232 ^talk 13:49, 30 August 2012 (UTC)

  If I'm an arachnophobe and I can't bear to see images of spiders - the concept here is that it's better to give an arachnophobe an easy way to quickly turn off all images on a given aagh spiders page, so they can still read the text, rather than be forced to deal with the images or give up and close the page. Giving the user some control is better than not. Rd232 ^talk 13:44, 30 August 2012 (UTC)

  OK - thanks for the background. Then, I'm going to have to oppose. Seems kinda useless to me. SteveBaker (talk) 23:07, 31 August 2012 (UTC)

• Support - this is a good starting point for giving readers more control over their viewing experience. 28bytes (talk) 03:39, 31 August 2012 (UTC)
• Oppose proposal, but support principle. I strongly oppose the switch anywhere outside Special:Preferences, and specifically for IP users: cookie pollution is no good thing, and if anybody wants to customize his UI experience, he may just register and log in. — Dmitrij D. Czarkoff (talk) 16:48, 31 August 2012 (UTC)

  So you support the idea, but only for 1% of users? Why are you concerned about "cookie pollution"? What if I'd personally prefer a cookie instead of another username and password to remember? WhatamIdoing (talk) 20:33, 31 August 2012 (UTC)

• Broadly support but agree with Dmitrij D. Czarkoff comment. The primary use of an image filter for me is that I frequently edit Wikipedia on my laptop while in public: on trains, in libraries, at conferences, at events etc. If I'm doing anti-vandalism work or, say, fixing issues with an article on a sexuality-related topic, I'd rather not subject my fellow travellers on the commuter train to some of the delightful images on, say,
  WP:NOTCENSORED, then we can think more about enabling it for IP editors. Alternatively, we could just have it as a user script you could import into your vector.js or monobook.js. Does the script actually exist? I thought about building one a while back but the inner lazy programmer never got around to it. —Tom Morris (talk
  ) 21:48, 31 August 2012 (UTC)
• Oppose in principle. "Think of a the children" and religious considerations really don't sway me. If you don't want to deal with reality, don't go online. Even Tom Morris's argument above doesn't sway me. Yes, it's more convenient, but it's not worth what I fully predict to be a poorly constructed and poorly imitated shadow of the plan put out at the top of this section. If it's written, and it functions as intended and isn't intrusive, I might support, but I'm still opposed now.
  Wha?
  22:41, 31 August 2012 (UTC)
• Oppose - without some way to select what kind of content one wishes to have filtered, it seems kinda useless. Unless someone is prepared to forgo all images (which seems unlikely), they'd have to first see an objectionable image, then turn it/them off...which is really useless. This is just a waste of effort and more GUI clutter on every page. I would seriously consider supporting a measure that allowed for some kind of classification - but even that is highly problematic. SteveBaker (talk) 23:07, 31 August 2012 (UTC)
• Support I follow Steve's reasoning, but I don't agree that using a global no-images setting is so unlikely. If you're using WP from work, it sort of makes sense — turn off images, and click on them if you need them, in articles where it's clear they won't be a problem. Sort of similar to how I leave images off in my e-mail by default (even though the exact motive is different — I'm not so concerned about taboo pics showing up in my browser cache so much as about
  web bugs). --Trovatore (talk
  ) 23:18, 31 August 2012 (UTC)
• Support ~Something for personal image control is better than nothing. Mikeatnip (talk) 00:39, 1 September 2012 (UTC)
  • That's not really true though. If adding this had zero impact on people who don't want/need it, then you might be correct - but that's not the case. It adds an additional GUI element to every single page. Since it's not the fully effective thing that most people seem to wish for, it actually can be "worse than nothing" - which is why I oppose it. SteveBaker (talk) 18:53, 1 September 2012 (UTC)
• Support. It's not strictly a filter, since a filter lets some things through and filters others, but it's a feature some will find useful, with minimal impact on the experience of others. It should prevent images from loading (not just hide them), so as to aid readers with slow connections or limited bandwidth. I'd like to see a commitment to take this back to the community three months after deployment for the community's final ratification. It's not a substitute for a real filter. If we ever adopt a filter, this can be included as a filter option. --Anthonyhcole (talk) 22:32, 1 September 2012 (UTC)
• Support. There are enough people who object to seeing certain images that we should do our best to cater to them in a way that won't affect everyone else. From the technical angle, couldn't we implement this with something comparable to the fundraiser banner? Having a little box to click that will remove the hide-images button from all pages for a certain number of days would seem reasonable. The proposal of permitting the user to click on images to see them is also good, since this might blank images that users would want to see anyway, such as the calligraphic representation of Muhammad's name in his infobox. What's more, Anthonyhcole's comment makes a good point; there are still people with dialup who would benefit from the lack of images. Nyttend (talk) 22:41, 1 September 2012 (UTC)
• Question. I have a question about point 3: "allow logged-in users to change their preferences, so images can be off by default (i.e. shown only after clicking), and to hide the images on/off switch." I'm not sure what "to hide the images on/off switch" means. SlimVirgin ^(talk) 01:29, 2 September 2012 (UTC)
  • It means that if you get annoyed by the button being there (which now that I think of it, it probably would to me), you can hide it from appearing on your screen.
    talk
    ) 23:39, 2 September 2012 (UTC)
• Support - This is a no-brainer. It hurts no one and could help many. ~ GabeMc ^{(talk|contribs)} 07:46, 2 September 2012 (UTC)
• Support - Put very nicely by User:GabeMc above me, there's not really any ways this couldn't be a useful addition to our MediaWiki installation. Personally, when I'm editing at the school library, I sometimes find myself frantically scrolling down, closing tabs and such when I mistakenly enter an article with a NSFW image. This would definitely benefit me; since I don't really work with images much at all, I could simply turn image display off whenever I'm editing in public. ❤ Yutsi ^Talk/ Contributions ( 偉特 ) 17:49, 4 September 2012 (UTC)
• Support It was disappointing to see Jimbo's effort peter out in this way, after the confident promises he made at the beginning. As a token gesture, this, little as it is, is at least better than nothing at all. --JN466 01:03, 7 September 2012 (UTC)
• Conditional support. I like the concept, but also follow SteveBaker's reasoning that we can;t single out images transcluded by templates as completely inoffensive. I would support only if images transcluded by templates are hidden by default when the tool is activated (preferably through Special:Preferences for registered users). CtP (t • c) 01:30, 9 September 2012 (UTC)
  • I actually realise now that the templates thing is a bit of a red herring; I really mean icons, which are often provided via templates, but some templates (infoboxes!) provide relatively big images. So the additional option I'm asking for (whether it's on or off by default is less important to me than having it) should be whether the on/off switch affects small images (say <=50px). Rd232 ^talk 12:15, 11 September 2012 (UTC)
• Support - hell yeah. I've wanted a simple "images on/off" switch for ages. - David Gerard (talk) 12:02, 11 September 2012 (UTC)
• ABSOLUTE oppose: We exist to educate not to enable willful ignorance. This proposal is wholly incompatible with our stated values and objectives. Abyssal (talk) 16:17, 11 September 2012 (UTC)

• So...it's critical to our mission to force people to look at unwanted images when they want to read text? It's critical to force people to download images on slow connections when they only have time to download the text? Nyttend (talk) 21:49, 11 September 2012 (UTC)

• Support - This very simple edit filter would be ideal for work/public situations as a general precaution against unwanted Not Safe For Work (NSFW) pictures. Its often a hop and a skip to an article containing something that is awkward, hard to explain even if it is not religious or sexual in nature. Though many individuals would have difficulty in explaining Mastectomy's pictures if for some reason you hopped to it from another article. While it is more common the Human body to expect something like that, but as the spider analogy above shows, ignorance of the subject does not necessarily mean a desire to be ignorant of visuals. This simple edit filter will also prevent the weird looks from stumbling into any questionable pictorial content long before such an opportunity presents itself. And before anyone gets any ideas about the Muhammad article, yes it could be a watershed for those who wish to learn, yet not see any pictures. It wouldn't be censorship either, because the restriction is self-made and is no different then using other technological means to do so. A simple toggle would be of unquestioned benefit, with its uses far outweighing any potential negatives. ChrisGualtieri (talk) 04:20, 12 September 2012 (UTC)
• Mostly support, but only at the level of "all images on"/"all images off", including templates. I think the setting should not be an icon, but an entry in the Toolbox which will work for all skins whereas an icon elsewhere could easily break things, that applies to the current page only. I do not support the option of hiding the toolbox option other than through special:preferences. Control for multiple articles should only be via special:preferences. I support the one-click unhide, and don't object to one-click hide as long as it doesn't interfere with the existing click to load the image description page. Ideally an images off setting should somehow interact with the maths display setting so that, where possible, text is displayed to the user (change "always show png" to "Math Jax"?). Although mathematical equations are unlikely to be NSFW that isn't the only reason people might be using this and exempting large maths images would not assist with bandwidth issues (although how much bandwidth MathJax uses I haven't the foggiest). Thryduulf (talk) 05:07, 12 September 2012 (UTC)
• Oppose There is no reason for people to access pages on topics that likely have objectionable images if they would get in trouble for that. And existing policies should deal well with images that don't belong into an article. I also have issues with the "Think of the children" arguments as these seem to be speculation at best. Jo-Jo Eumerus (talk) 09:31, 12 September 2012 (UTC)
• Support - Would be very useful for a variety of reasons and gets around many of the issues associated with other image filter proposals.
  CT Cooper · talk
  12:33, 13 September 2012 (UTC)
• Comment a browser add-on might be better because:
  • It wouldn't cruft up WP
  • It wouldn't be a thin end of the wedge
  • It would give faster browsing.

Rich Farmbrough, 06:17, 15 September 2012 (UTC).

• oppose extremely rarely useful but takes up space on the screen. Feels like a Wiki-politics solution to what I think is a nearly non-existent problem. I'd have no objection if this was done in preferences or some other way that didn't take up screen space). Hobit (talk) 01:16, 16 September 2012 (UTC)
• Weak Support - The "think of the children" ideas aren't really fixed by this isn't it? Children can probably figure out that this one button can turn all of the awesome pictures of Wikipedia on. I'm weakly supporting this because of it's not intrusive to your work, ability to opt-out, and mainly for the people with slow connections (which I sometimes land on) and only have time to read text.
  talk
  ) 15:09, 16 September 2012 (UTC)
• Weak Support Sure. May be of use for certain people. People with sensitive eyes can simply use Wikipedia Zero.
  talk · contribs · email
  ) (if I write on your page reply on mine) 08:48, 17 September 2012 (UTC)
• Support. Although extremely primitive, it is quite adequate to address certain scenarios, such as allowing a person to continue reading an article that they would otherwise be too disgusted to look at. The censorship potential does not concern me as it is simple for anyone to turn off. It also has technical applications such as low-bandwidth browsing on browsers/devices that don't support an images-off feature. The usage data would help inform more complex and useful projects in the future. Dcoetzee 00:14, 18 September 2012 (UTC)
• Weak oppose. Unnecessary. Users can turn off images in their own browser options. (I've done that myself on slow connections when trying to improve load times.) For NSFW images there is a simple way out: don't visit the page. If you're not supposed to be looking at such images at work then you are almost certainly not supposed to be visiting that page either.
  talk
  ) 08:16, 19 September 2012 (UTC)
  • Concur (i.e. Oppose): This is a blunt instrument, redundant to browser options. A finer instrument is not going to happen any time soon either, so just stop trying already. --NYKevin 21:37, 19 September 2012 (UTC)

Prototype

A gadget should be able to do this well enough, since gadget CSS is loaded at the top of the page. The gadget would set visibility:hidden on all images, and then some Javascript would unhide interface icons and set up the click handler on the rest. I've written such a gadget, and it seems to work on my local test wiki using Firefox 14, Chromium 21, Safari 5, and IE8.

It may not work quite right as a userscript, but you can try it out if you'd like. First, copy this to your common.js:

importScript('User:Anomie/hide-images.js');

Then copy this to your common.css:

@import url('//en.wikipedia.org/w/index.php?action=raw&title=User:Anomie/hide-images.css&ctype=text/css');

Note that this does not attempt to implement the in-page on/off switch; if enabled, will always hide images. To turn it off, remove the lines (at least the one in common.css). Anomie⚔ 03:20, 1 September 2012 (UTC)

Note also this doesn't prevent the images from being downloaded (at least not in Firefox 14), it only prevents them from being displayed on the screen. Anomie⚔ 03:20, 1 September 2012 (UTC)

It is better to limit it to the images within article content: '#mw-content-text img'. I do not think anything questionable can reside outside that area. Ruslik_Zero 19:01, 1 September 2012 (UTC)

That's definitely a start, thanks. It works quite nicely in conjunction with NavPopups, so you can get some info about the image before clicking it to show. Can we develop this a little further, and work towards making it an optional gadget fairly quickly (default gadget is a discussion for later I suppose)? An easily accessible switch would be nice even if it's only globally on/off to start with, as would a means to display any alt text (maybe by tool tip when hovering, if it doesn't clash with NavPopups). Rd232 ^talk 11:41, 7 September 2012 (UTC)

I still oppose. The primary use is censorship. I recognize the problems with slow connections, but this is a browser issue. If such is needed for WP, it will be needed for other pages also. Software whose primary use is censorship should not be in any way associated with WP. If implemented here in any manner, expect an MfD as contrary to policy. DGG ( talk ) 18:01, 26 September 2012 (UTC)