Village Pump - Archive

DO NOT EDIT OR POST REPLIES TO THIS PAGE. THIS PAGE IS AN ARCHIVE.

Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

Post replies at Wikipedia:Village pump (proposals), copying or summarizing the section you are replying to if necessary.

Note: Please add new material at the bottom of the page. Preceded by the following: =Sections archived on ~~~~~ =

Sections archived on 00:13, 23 April 2006 (UTC)

Cognitive Map of a Wiki Space

I'm looking for the ability to create, maintain, and manage a set of wiki spaces using a cognitive map or graphical interface. I've found a couple of open source tools for creating mind-maps, but they are limited to single paths to the leaves. A wiki space is more appropriately modeled as a 2-D or 3-D network. The idea would be that a user would be given an interactive visualization of the pages (content) and the links to other content. If made flexible and powerful, such a visualization tool could be used to create, manage, and navigate a wiki; brainstorm projects; create complex plans; or map out detailed decision making processes. Of course, the power of the wiki is the ease of use by the community and the openess for adding new content..

This just isn't technically feasible for a wiki of this size. A private wiki might benefit from such a feature, but there's proportionately less demand for that. — Saxifrage ✎ 00:08, 8 April 2006 (UTC)[reply]

There are many ways to make such a system scaleable. It is technically feasible for any size. Kevin Baas^talk 22:20, 8 April 2006 (UTC)[reply]

Perhaps you're right. I still remain dubious, considering that just the navtools popup is considered too taxing on the servers to implement by default. — Saxifrage ✎ 07:58, 10 April 2006 (UTC)[reply]

If you're looking to learn about methods in general, you might get a broader response at Wikipedia:Reference desk/Science or Wikipedia:Reference desk/Mathematics. Melchoir 22:37, 8 April 2006 (UTC)[reply]

I'd be interested to know how you could make it doable, I tried taking just one moderately large article Permaculture and graphing the link relationships. There were about a 100 incoming and outgoing links and just graphing those filled the screen. --Salix alba (talk) 16:40, 15 April 2006 (UTC)[reply]

The Re-addition of Wikifun

The Re-addition of Wikifun link to the community portal and other areas where user whether new or not can find it easily. I think this is important due to the fact that it has slowed severely and in addition this comment made by a user on the discussion page: " this participation made me learn several features of WP I didn't yet know". so as you can see there is a large benefit. --Larsie 16:10, 13 April 2006 (UTC)[reply]

The draft for the new Community Portal includes links to Wikipedia:Department of Fun and Category:Wikipedia games. I'd suggest making an infobox for the tops of those 2 pages with the more active games listed. --Quiddity 02:42, 15 April 2006 (UTC)[reply]

I made one quickly for you (using an orphaned template page). Template:Wikigames Go edit it and reorganize it and place one on each mentioned page. If ya like :) -Quiddity 03:06, 15 April 2006 (UTC)[reply]

Sections archived on 00:13, 24 April 2006 (UTC)

Wikipedia:Wikiethics

Please review and make suggestions for improvement and completion of the proposal Wikipedia:Wikiethics. Resid Gulerdem 23:57, 1 April 2006 (UTC)[reply]

Fellow editors please be aware of Wikipedia:Wikiethics's previous proposal on Village Pump. Netscott 00:12, 2 April 2006 (UTC)[reply]

This idea has been beaten to death, polled, and rejected. Time to move on. John Reid 03:43, 2 April 2006 (UTC)[reply]

The proposal is active and improving. Community input and constructive suggestions are wellcome. Thanks in advance. Resid Gulerdem 04:24, 7 April 2006 (UTC)[reply]

The "Editorial standards" section in particular contradicts itself (with respect to censorship). Ardric47 03:24, 14 April 2006 (UTC)[reply]

The proposal was/is a mess and has been soundly rejected. Resid Gulerdem is now indefinitely blocked for various misbehaviour. Nothing more to see here, as John Reid says. Sandstein 12:35, 16 April 2006 (UTC)[reply]

wikipedia page layout

I've been using google as the home page for my browser for years now. However, I've recently switched to using wikipedia instead. I don't know how many other people are doing this.

I am finding lately that for most searches, the links at the end of the articles give me much better results than google.

My guess is that the first thing most people do when arriving at wikipedia is conduct a search.

A more prominent placement of the search box, up near the top and centered, and auto-selected like the search box on google would be great. A larger search textbox would be nice. Making the external links more convenient (side column? closer to top?) would be helpful.

Just some suggestions.

Wikipedia is currently moving away from having a single "External links" section in articles, toward having a "References" (or "References and notes") section and a "Further reading" section. This makes that part of the suggestion a bit difficult technically. A separate social reason that I would argue against such a design is that Wikipedia deals with a tonne of spam links every day and a prominent placement of external links would only encourage vandals and spammers. And, now that I think of it, it would also make our policy that Wikipedia is not a link directory harder to say with a straight face.

However! I like the idea of having a prominent search box for just the main page. — Saxifrage ✎ 17:31, 11 April 2006 (UTC)[reply]

We are? I hadn't been informed. IIRC we still keep both further reading and external links; the former is for meatspace stuff, and the latter is for stuff available online. Johnleemk | Talk 17:58, 11 April 2006 (UTC)[reply]

The change (and I think it's fairly community-driven) was because that distinction was causing all kinds of problems with where people thought references should go when some were "external links" and some were dead-tree references. It's not very well publicised, but you can see the shift in practice reflected at WP:CITE#Further reading/external links. — Saxifrage ✎ 18:35, 11 April 2006 (UTC)[reply]

I guess I should have added that reading the wikipedia entry for whatever search term I've entered makes me a more educated surfer before going off to an external link or doing a search via google, etc.

It seems to me that even though "Wikipedia is not many things", for many it is filling the role that the early google did.

For the first couple years, conducting a good factual search at google was easy -- the first page of results wasn't clogged with commercialised links -- it was real, useful, data. I don't know what the future holds for google (they are doing great financially) but to me they are gradually just becoming a glorified advertising engine. This may be hard to believe, but their usefulness might fade over time. What once took me a few clicks on google now requires wading pages deep into the results, carefully constructing queries, etc.

I don't know of any algorithms that are better than a human at sorting good data from junk. So... with that said, it seems to me that working on the search features within Wikipedia could be a good thing. Maybe my post here should have been titled "wikipedia search" ?

Where could I learn more about the roadmap for Wikipedia?

...

..ok, now I've read all the current entries on this page, and I see there is already a discussion about a more prominent location for the search box. If anyone is counting, I vote for top center, just above the "Welcome" and to the right of "your continued donations..."

I find myself doing this as well. Wikipedia is like Google except it organizes the best info from the best google results into one neat, concise page. :) --Matt0401 15:55, 16 April 2006 (UTC)[reply]

In the news - pictures

copied from Talk:Main Page archive, (removed irrelevant tangent)

Further to people's complaints above regarding how it is confusing at first as to which article belongs to the picture; There is a little (pictured) caption in the text so it's not a huge issue but how about somethig like this?.. (Rough mockup, it might look stupid in your browser)

In the news

The 39th Canadian Parliament begins in Ottawa, with the newly-elected government of Stephen Harper commanding a minority in the House of Commons.

Zacarias Moussaoui

A jury finds Zacarias Moussaoui (pictured) liable for the deaths in the September 11 attacks. Moussaoui's trial now enters the penalty phase, where he may be sentenced to execution.

Former Liberian President Charles Taylor pleads not guilty to war crime charges at the Special Court for Sierra Leone.

The Kom Chad Luek newspaper critical of Thai Prime Minister Thaksin Shinawatra agrees to stop publishing for five days amid protests about the way it referred to the King of Thailand.

Wikinews – Recent deaths – More current events...

...to highlight the appropriate article entry? --Monotonehell 06:30, 4 April 2006 (UTC)[reply]

And maybe a thin blue border for the picture to link them better intuitively. Great idea. --Quiddity 06:56, 4 April 2006 (UTC)[reply]

Heh I wanted to do that but couldn't work out the wiki-table layout >.> EDIT:messed with it a bit--Monotonehell 07:02, 4 April 2006 (UTC)[reply]

Sounds good to me – it won't make much of a difference to the page, but if people find the current arrangement confusing, it ought to be changed – Gurch 12:09, 4 April 2006 (UTC)[reply]

Personally, I'd still prefer just putting the pictured news on top. Seems like the easiest solution to me..

Still, I like your suggestion. Two questions though. Can the border on the pic be a bit larger? It took me a while to actually notice it. second, mort importantly, doesnt this makeup get messy once the news item moves more towards the bottom? The Minist e r of War ^(Peace) 13:40, 4 April 2006 (UTC)[reply]

This is just a QaD mockup in wiki:table markup, I imagine that the CSS for the front page could include a special element for the appropriate box somehow. So yes the border can be any thickness (I couldn't work it out in wiki markup though). It would get separated from the picture if it slid down yes. But if it were the only highlighted entry the viewer's eyes would be drawn to it more quickly than the obscured (pictured) tag. --Monotonehell 14:41, 4 April 2006 (UTC)[reply]

I'd still support some changes to show the link between text and picture more prominently. Is this one of those things that everybody is going to agree on, but gets archived without ever being implemented? The Minist e r of War ^(Peace) 09:06, 10 April 2006 (UTC)[reply]

Well, there have been no negative reactions. How do we get this implemented? --Quiddity 18:42, 16 April 2006 (UTC)[reply]

Sections archived on 00:14, 25 April 2006 (UTC)

Local categories for "requested pictures"

Since only a small proportion of picture-lacking articles are listed as requiring pictures, but the category and list for requested pictures are quite large, and additionally it is not generally worth a Wikipedian's time to check either out just in case a local listing has occurred, I have suggested a local (depending on need, by city/region/country) category system for requested pictures. Some comments at Wikipedia talk:Requested pictures#Subcategorizing Category:Wikipedia requested photographs would be appreciated! TheGrappler 03:24, 15 April 2006 (UTC)[reply]

This may be a good idea. We need to encourage those in the area and who have digital cameras to actually take those pictures and submit them here. Denelson 83 23:54, 15 April 2006 (UTC)[reply]

I copied this comment to the talk page where the discussion is - hope nobody minds! TheGrappler 05:45, 17 April 2006 (UTC)[reply]

Improving categories

metawikipedia:Improving categories proposes Customizable links in category lists :

[[category:category_name|sort_key|display_text]].

Please, SUPPORT this proposal. This is a great and simple improvment. <STyx 20:55, 17 April 2006 (UTC)[reply]

That it is. Melchoir 21:18, 17 April 2006 (UTC)[reply]

I registered on meta just to support this! ericg ✈ 21:20, 17 April 2006 (UTC)[reply]

Ditto! Melchoir 21:26, 17 April 2006 (UTC)[reply]

Item sizes

The max is 500. It would be useful if this was larger. Skinnyweed 22:48, 17 April 2006 (UTC)[reply]

You can manually edit the string in the URL to show however many you want, e.g. http://en.wikipedia.org/w/index.php?title=Special:Contributions&limit=1000&target=W.marsh. Use sparingly though because it eats up a lot of your bandwidth. --W.marsh 23:00, 17 April 2006 (UTC)[reply]

Sections archived on 00:14, 26 April 2006 (UTC)

Filmography "hide" feature tables.

Filmography on popular actor pages is usually a big list or missing stuff. I propose we create this format for filmography. It is illustrated in this horrible picture I created Image:Filmography temp illustration proposal.jpg.jpg.

Basically it works like this. First table shows all popular movies the actor was in. The user can press "show all" button and the table expands to show all roles.

The second table features all minor roles and naturally is completely hidden. Once expanded it will show all the minor roles.

Now this will require some coding which I am not aware of how to do but does anyone think this is a good idea? its stylish and space preserving in my opinion. It also allows for more information to be available without clogging up the page.  Tutmøsis ^(Talk) 14:48, 16 April 2006 (UTC)[reply]

That would take tons of time but is a good idea going forward. --Mets501^talk 20:11, 16 April 2006 (UTC)[reply]

The time spent would be worth it...--Osbus 22:08, 16 April 2006 (UTC)[reply]

I was thinking also the filmography can be converted into a template so that it be harder to vandalize for n00bies and on the actual page would only have one sentence under that section yet so much contents. So does anyone know how to make such tables?  Tutmøsis (Talk) 00:10, 17 April 2006 (UTC)[reply]

Also to note its maybe alot of work coding the first tables but after that its only a matter of mostly copying and pasting for other actors.  Tutmøsis (Talk) 00:14, 17 April 2006 (UTC)[reply]

Well what about a slash page (added to entry by "...../roles" ). It may make sense for some entries. I am trying to discuss it currently for other purposes (outsourcing information which is not of major interest, but still required for completeness reason). alex 15:22, 18 April 2006 (UTC)[reply]

A way to rate user confidence for each article

I suggest an algorithm be developed which gives an idea of the ratio of viewers of an article to the number of editors over a given period of time. This would show how many eyes have seen an article and what proportion felt it needed changing. A low number of changers to viewers would indicate that it was fairly consensual. A high number would show it to still be in a state of flux. I'm not sure if the measure would be best if it showed the number of individuals concerned regardless of number of edits or viewings or whether repeat activity in either category should be included in some way. The rating could be dispayed in the corner of the page for each article. The algorithm could be constructed so that it ranged from close to zero (low confidence) to almost 1 ( high confidence). Lumos3 01:02, 17 April 2006 (UTC)[reply]

I'd love to have access to such a statistic, but it shouldn't be displayed with the articles-- at least, not at first. That step would require a huge debate and probably the mother of all straw polls, with several versions competing that had all been fine-tuned for some time. Melchoir 01:10, 17 April 2006 (UTC)[reply]

There is an entire category of proposals related to this, please see Category:Wikipedia editorial validation. In particular, please note m:Article validation which has led to a feature in the software which is not quite deployed related to this suggestion. -- Rick Block (talk) 01:14, 17 April 2006 (UTC)[reply]

This would be a very poor indicator imo. There are many factors other than quality involved, eg level of controversy, how many people are capable of contributing, whether it started out as a fairly full article, whether one or two people have ever taken it up and done most of the work of the same result has been achieved by many hands, whether it is a current topic which requires regular updating for new happenings or a historical topic etc, etc.

A hint to get statistics: create a good external page with additional information (however this is only possible for a few articles), add a link to "external links" and watch the site statistics. At least it can give evidence the article is continiously displayed/visited. It requires website programming knowledge. Probably it makes sense to host a "website poll", but from own experience i can say "5 percent do vote" is a good number...don't expect hundreds of votes for a tiny article. alex 15:18, 18 April 2006 (UTC)[reply]

proposed change to css (.references)

After seeing a number of articles' references sections use a cite.php tag wrapped in container divs (ie <div style="font-size:90%;"><references/></div>), I was wondering if the .references class in the sitewide css could contain this sizing information instead. If it was changed, it would be a simple task to fire up AWB and convert the existing shrunken references sections to simple <references/> code. ericg ✈ 02:53, 17 April 2006 (UTC)[reply]

Consider updating the sitewide CSS, not just for a single skin. Rob Church (talk) 04:58, 17 April 2006 (UTC)[reply]

Changed wording accordingly. ericg ✈ 05:03, 17 April 2006 (UTC)[reply]

This has been proposed before. The reason for not doing so is that short reference sections look bad in the small font, while very large reference sections look better in the smaller font. Leaving it out of the CSS allows for appropriate variation. Now, if the trend was to having all reference sections in the 90% size, this would be a good idea. Until then, though, I would oppose this—most of the article I work on have very short reference lists and they really don't need the smaller font. — Saxifrage ✎ 05:44, 17 April 2006 (UTC)[reply]

I'm opposed to smaller font's for references alltogether, because they are hard to read. I tried to increase the fontsize on a series of articles, but found no consensus. I'm a bit frustrated, that people who have trouble reading small fonts are treated like this. But however, I see a lot of articles having small fonts for the references. I think it would be better to do it in the sitewide CSS (per ericg). Those that would like to have larger fonts (like me) would then have a chance to override that in their own css file, which is one of the ideas behind CSS altogether. Font sizes for article text (also for the references) should not be specified in articles. I support to move that into the sitewide CSS file per ericg (or monobook.css, maybe this should be decided per skin, but I don't care that much on this subpoint). Font sizes belong into the CSS. As an AWB user I would also help to remove the <div> fontsize tags from references sections. But only if there is consensus to do so. --Ligulem 08:16, 17 April 2006 (UTC)[reply]

You could override the style if the divs contained a class, such as "small-reference". You could add that to your CSS and add that to pages with small-font reference sections as you find them. It won't affect anyone else, so no-one would have any reason to oppose. — Saxifrage ✎ 08:54, 17 April 2006 (UTC)[reply]

Yes, good idea. The difficult part is gaining consensus for "if the divs contained a class, such as "small-reference"". And wouldn't that interfere with the class .references? Would be better if there was just one consistent style for references, I think. But if we can gain consensus for using a small-references class (or whatever name), I'll support that. I believe this is still better than hardcoding 90% into the wikisource for articles where editors want the references in smaller font. At least we could then eliminate the difference between those that use 80%, 85% and 90% (there is absolutely no need to have three or even more "small" reference fonts). We could probably solve the above mentioned two cases with this (articles with long references sections, and articles with short references sections). --Ligulem 09:30, 17 April 2006 (UTC)[reply]

If it were just put in the div, then it wouldn't interfere. The div would then have a class that people can hang a CSS declaration on (essentially moving the current style="font-size: 90%" into the class' definition) and the #reference id (it's not actually a class) on the ol tag would keep doing its thing.

I don't think that putting such a class definition in the existing divs would need consensus. It wouldn't get in anyone else's way and would offer a way for everyone to see the font size they prefer. If someone doesn't care, they can safely ignore its presence. — Saxifrage ✎ 10:12, 17 April 2006 (UTC)[reply]

Ok. I'm for adding a new css class "references-small" to MediaWiki:Common.css, it could then be overridden in specific skins when needed. BTW this would also make the transition easy, because if we would hammer in the 90% into .references then we cannot remove the existing div 90% from the articles in light speed. So we would have 90% of 90% for a transition time. With the separate references-small, should we later decide to apply the same style for all references, we can define the class "references-small" to be empty and everything goes smooth. So what name shall we take for that CSS class? At the moment I'm for "references-small". --Ligulem 10:33, 17 April 2006 (UTC)[reply]

I'm not actually suggesting getting it in the site-wide CSS now, rather adding the class to all the existing divs so that you and others can use personal CSS files (such as User:Ligulem/monobook.css) to scale the references back up. It's not a perfect solution, but it has three advantages: 1) it doesn't require getting anything into common.css (yet!), 2) it doesn't disrupt the pages for people who don't care, and 3) seeing it will pique people's curiosity and promote awareness that a CSS solution in the site-wide files is easy and advantageous. — Saxifrage ✎ 19:35, 17 April 2006 (UTC)[reply]

Hmm. What's the problem with defining .references-small { font-size:90%; } in common.css? It would still have to be used on articles to have any influence. I mean we could then say <div style="references-small"> <references/> </div> in articles where the small references are requested by editors. On those articles where normal size references are requested, just don't use divs around the <references/>. Fontsizes just don't belong in article text, not even via templates. --Ligulem 20:12, 17 April 2006 (UTC)[reply]

I agree 100% with the method suggested above. ericg ✈ 20:18, 17 April 2006 (UTC)[reply]

The problem is that you have to get everyone who's currently doing reference sections like this to support it or it will cause all manner of argument and headache. Not only that, but you'd have to get an admin add it to common.css. Without a good show of support, the likelihood of getting an admin to agree to change common.css is low. The way I suggested is something you can do right now and has 0 potential for controversy. It also would give exposure to the issue as people see "class=references-small" popping up everywhere. — Saxifrage ✎ 07:16, 18 April 2006 (UTC)[reply]

The admin thing is no problem. And I believe if there is no class definition for references-small people will just remove that from articles. There is no point in using a CSS class that is only used by some users. Also please have a look at Formatting issues in the MoS which says that font sizes should go into CSS. We already have a whole lot of articles specifying 90% or 85% font size for the references. How much more evidence do you need that a CSS class for small references is needed and justified? --Ligulem 07:44, 18 April 2006 (UTC)[reply]

I'm not saying it's not justified, I'm saying there's no consensus support to do this yet. Without consensus, going ahead is going to be the same as making a conscious decision to crash and burn this proposal. If you want to go and get the consensus going first, by all means. I only suggested that you could personally get this benefit right now and get some interesting social-engineering effects from it too. For the record, I don't think people would be dickish enough to remove harmless class definitions just because they're not seeing any difference, especially if the edit summary adding them explained why. — Saxifrage ✎ 20:30, 18 April 2006 (UTC)[reply]

I vote for consistancy. Either all of them are 90% (or whatever), or none of them are. Having some small, others normal, looks bad IMO. —Locke Cole • t • c 08:59, 17 April 2006 (UTC)[reply]

Even having given the rationale for not putting it into the site-wide CSS, I still would prefer it if they were consistent. I'd rather see the references all left a normal font-size. Wikipedia isn't paper and doesn't really need to save the "space" that shrinking the references "saves". — Saxifrage ✎ 09:08, 17 April 2006 (UTC)[reply]

Assuming that this unification is not going to happen (There will stay articles where wikipedians want small references, and other articles where they want normal size references), couldn't you agree to at least ameliorate the current situation by reflecting that in the CSS (i.e. by supporting the adding of the CSS class "references-small". See also [1] for how that would be done on an article. --Ligulem 08:59, 18 April 2006 (UTC)[reply]

Well, yes, some sort of standardization is better than none (and by standardization, I support including these in MediaWiki:Common.css and insisting people use small or normal and not some code they created themselves). But I strongly feel we should work towards a single size for all articles. —Locke Cole • t • c 09:04, 18 April 2006 (UTC)[reply]

Well, I wouldn't do this by css. I think the optional parameter I introduced for {{subst:footnotes}} this morning (default 100%) does what is needed. For the time being I put {{subst:FootnotesSmall}}, which is to be used without parameter, at a standard 92% size (90% is probably too small in most cases, but can still be achieved by typing {{subst:Footnotes|90%}}) --Francis Schonken 12:58, 17 April 2006 (UTC)[reply]

The advantage to doing it in CSS is that editors who really don't like the smaller font size (and there appear to be a lot of them, judging by how often I stumble across this ongoing controversy) can override it in their personal CSS pages. That said, if a CSS implementation doesn't get off the ground, that's a nifty template. — Saxifrage ✎ 18:58, 17 April 2006 (UTC)[reply]

Francis, what do you say per the argument that the MoS favors CSS (see Formatting issues) instead of using font-size in articles? I don't believe that font size for article text should go into templates. Templates cannot be overriden locally like CSS. Please also take a look at [2] for how that would be done on an article. --Ligulem 09:13, 18 April 2006 (UTC)[reply]

I don't know what would be the most practiced "action" if text is too small to read. My intuition would be that a user who has trouble reading small lettering rather would use the "increase text size" function built in to most browsers, than program private css settings. And the present template reacts perfectly to the "increase text size" functionality of my browser (try it out on Winzip, the footnotes are at 95% there currently).

But I don't think we should be even forcing users to do that. That's why I wrote in the wikipedia:footnotes guideline (and on the {{footnotes}} page in the "noinclude" zone): "For readability it is however only exceptionally advised to reduce lettering size of footnotes, and not below 90%. So in most cases, no need to insert a parameter."

If I still left any doubt, I'm one of those "editors who really don't like the smaller font size", and wholeheartedly subscribe the MoS: "Formatting issues such as font size [...] should not be dealt with in articles except in special cases", where IMHO footnotes are not a "special case". The case is certainly not "special" enough to warrant it to be hard-coded in css. If it would be possible, I'd rather programm the css thus that any attempt at reducing size of footnotes text would be made impossible (just as a "maximum usability" principle). But some editors are bent on reducing size on very long lists of references. I'd rather like to see that limited to 92% than what I put in the guideline based on some prior practice. --Francis Schonken 09:45, 18 April 2006 (UTC)[reply]

I agree with a lot of things that you wrote. I also would like to have normal size for the references. But there is no consensus to have normal font for the references on each and every article. A lot of featured articles use fontsize 90% for the references. What I do not understand is: why do you oppose to add a new class .references-small { font-size:90%; } to Mediawiki:common.css? This class could be used in the articles instead of

<div style="font-size:90%"> <references/> </div>

like this

<div class="references-small"> <references/> </div>

Or did I misunderstand you? Please correct me if I'm wrong. Thanks! --Ligulem 10:05, 18 April 2006 (UTC)[reply]

(note that what follows is no more than my personal opinion): allowing the class="references-small" has some disadvantages IMHO:

It is too inviting to standardise footnotes at 90%, while I would prefer standardization at 100%. If breaking away from that standard of 100%, I think it would be best to allow that only under the "exception" inscribed in the MoS ("Formatting issues such as font size [...] should not be dealt with in articles except in special cases"), so the editor who induces the font resizing, should be able to gain consensus for "special case" on a per article base. Not as a standard call to the css. I'd put that as sharp as possible in the wikipedia:footnotes guideline (that is: sharper than I did yesterday, unaware I could have made a reference to the general MoS principles)
The code visible in edit mode (" <div class="references-small"> <references/> </div> ") doesn't even give a clue what the size is, and how to change that size. If an editor reads "font-size:90%" in edit mode, he'd be able (without much of a technical background) to change that size to, say, 95%. A wiki principle is that editing should be easy. You don't need to know that class="..." is a css call, and how css works and/or how it is modified.
The threshold built in to the MoS to do size changes preferably by css, is IMHO also intended to avoid that such changes would be done before gaining consensus by the community. I see there are many eminent proponents of the reduced size. But there are also many who oppose it. I also would think this is something that should be discussed (or at least notified) in the wikipedia:usability project. Presently, anyhow, I don't see consensus (not even "narrow" consensus) to append the css in this sense.

--Francis Schonken 10:38, 18 April 2006 (UTC)[reply]

If you're going to change the font size, change it for all of the references, with site-wide CSS. But I don't see any reason why the font size should be changed. — Omegatron 10:57, 18 April 2006 (UTC)[reply]

Would this be a good summary?:

Refer to the MoS ("Formatting issues such as font size [...] should not be dealt with in articles except in special cases") in wikipedia:footnotes;
- done, see wikipedia:footnotes#Helping editors unfamiliar with this system of footnotes and "footnotes" template
Don't inscribe class="references-small" in the css (unless consensus can be established, which is not the case currently);
Start a TfD on {{FootnotesSmall}}
- started, see WP:TfD#Template:FootnotesSmall --Francis Schonken 11:47, 18 April 2006 (UTC)[reply]

The only thing I'm not sure about yet is whether I'd remove the "optional parameter" from {{footnotes}} - if that would be experienced as too inviting for font size reducings in individual articles (which I'm personally inclined to believe now), I'd be happy to remove that option from that template. --Francis Schonken 11:13, 18 April 2006 (UTC)[reply]

Ok. I give up. This is sad. --Ligulem 11:16, 18 April 2006 (UTC)[reply]

Possibly I started this heated discussion here by putting 90% in the subst template in the first place. I didn't realise people would feel so strongly and apologise for just going ahead without consulting. I do think 90% size text is highly aesthetically pleaseing in articles though and it seems likely lots of editors think so too. Having two CSS classes "references-small" and "references-standard" would be a compromise to make everybody happy surely... Editors who like 100% can use the 'standard'. What's more if the standard ever needs to include any other style info, it'd already be in place Wikipedia-wide. Donama 13:05, 18 April 2006 (UTC)[reply]

Deprecating {{qif}}

It has been proposed to officially deprecate the mother of meta-templates, qif. Please contribute to the discussion so we can gather consensus over a template which has the potential to crash Wikipedia. Johnleemk | Talk 16:02, 18 April 2006 (UTC)[reply]

Sections archived on 00:14, 27 April 2006 (UTC)

recommendation - automatic referencing

i was just using wikipedia and though - hey - Wiki should have a link at the bottom of every page that appears that automatically generates a proper refernce in MLA and APA, to assist those doing scholarly research?

It's not on the bottom; it's in the "toolbox" on the left side of the article. It's called "cite this article", and you'll get a page like this. — Knowledge Seeker দ 01:44, 15 April 2006 (UTC)[reply]

I'll point out, though, that citing Wikipedia in your scholarly research doesn't currently go over well in academia. You should follow the sources given by the article and cite those instead. (And if the article doesn't give sources, what are you doing trusting it for your research?) rspeer / ɹəədsɹ 02:32, 19 April 2006 (UTC)[reply]

Sections archived on 00:16, 28 April 2006 (UTC)

Highlight search box

Final suggestions at bottom of section

A proposal that came out the Main Page Redesign discussions was:

Improve visibility of the left-nav search box, with an orange-colored border (as used on the active tabs at the top).

This would be to aid new users in finding the search box. (a frequent complaint at WP:SEARCH)

this is easily shown by adding this line to one's user/monobook.css.

#searchBody {border-color: #FABD23;}

The proposal was initially offered as an alternative to a second search box that was appearing in the headers of many redesign-drafts. (links to discussion archives: 1 - 2 - 3 (main discussion) 4 (vote and three colour examples))

It is possible to code this highlight to only display on chosen pages.

3 questions:

Does anyone disagree with this plan in general?

Which pages should the highlight be displayed on?

just the Main Page
All Help/Community pages (+ Main Page)
All pages.
other.

What color? (we can shade the background or the border)

thanks. --Quiddity 19:25, 6 April 2006 (UTC)[reply]

This is a bad idea. It looks utterly horrendous. It's a horrid mismatch of styles. By all means make the search box more prominent, but this is not the way to do it. It doesn't fit in with the overall site design at all. The colours are not just randomly applied. They are semantic, and this box is not part of the group with the orange borders. I'm all for making Wikipedia easy to browse, but not at the expense of making it ugly to the extent that it's unpleasant to browse. Sam Korn ^(smoddy) 19:35, 6 April 2006 (UTC)[reply]

The colour used is changeable. Do you like any of the other colour options, or have one to suggest? --Quiddity

To be honest, I think using colour is not the right way to achieve this. I don't know what is, though I support highlighting it in principle. I think consistent site design is very important and lends a sophisticated, integrated feel to the encyclopaedia, rather than a slip-shod mess of styles. Sam Korn ^(smoddy) 22:57, 6 April 2006 (UTC)[reply]

Strong Support. with a very weak preference for on just the Main Page, and orange as on tabs (and in example). --Quiddity 19:55, 6 April 2006 (UTC)[reply]

I like it too, as long as it is the same shade of orange used on highlighted tabs. Ideally, it should be pushed up, to be above the navigation bar, but I don't know if that will happen anytime soon. Tito xd^{(?!? - help us)} 06:36, 10 April 2006 (UTC)[reply]

That was another suggestion we talked about during the redesign. The main objection was that the search box breaks up the boxes of test in the nav bar, in a useful way visually.

A third suggestion was retitling the box to be "find" instead of "search", as search is the label of the secondary button, and hence confusing. I think both are worth discussing some more. --Quiddity 06:54, 10 April 2006 (UTC)[reply]

–M^T]]

Strong Support moving the search to the top, or setting the border to the orange of the tabs. On all pages. Orange is a highlight, and does not indicate "you are here" (indicated by bold text, and the missing border-bottom on the tab). It is not out of place in the current style. The blue border looks terrible and the yellow background is indistinguishable. Those two options should be removed. The border should be set for all pages. While it may not be perfectly appealing, it is of great benefit to the new user. As for moving the search box, I recall the top right as the correct position, but perhaps not appropriate here. I can't disagree more with the opinion that the search provides a "good seperator" between the two boxes. Moving it to the top makes the leftnav look much more uniform, much less scrambled. A related point I'd like to bring up is the severe error of bolding the "Go" button when it is not the default action of that form.–M^T 15:05, 10 April 2006 (UTC)[reply]

Strong support: Just love the concept, what else is there to say. Should be orange and on all pages. Tutmøsis · (Msg Me) 22:13, 11 April 2006 (UTC)[reply]

Strong Oppose. The argument against a search box in the body of the Main Page was the possibility of the newcomers becoming reliant on it and not seeing the one to the left. By putting that here, you eliminate that. but there was another concern, not brought up as much but still mentioned: "What makes this search box different from all the other search boxes? Will it search off this site and the others won't? Will it bring up things using Google and the other's won't? Why is it highlighted?" And NO, we are NOT highlighting it on all of the pages. People see it. Do you see "Can I search your site for articles?"-type complaints from anons and new users? Please.--Here T oHelp 22:21, 14 April 2006 (UTC)[reply]

Talk:Main_Page#Search_Box_Location and Talk:Main_Page#Suggestion:_Removal_of_the_.22Search.22_box_caption. and Talk:Main_Page/Archive_59#Position_of_search and a cpl others i can't find. But i understand/agree that it might be confusing because of "Why is it highlighted here and not there, do they do something different?" concerns.

Frankly, i'm more in favour of raising it above the Nav box in the sidebar, than the highlight. Or just give it a darker-gray/black border instead of the orange.

It does tend to blend in/get ignored more than it needs to, so something needs to be tweaked. Somehow. :) --Quiddity 23:53, 14 April 2006 (UTC)[reply]

"[S]omething needs to be tweaked". I'm not sure it does. People see it. Like I said above, we are not flooded with "how can I search your site" complaints. I think it needs to stay where it is and divide the two sections of text. A slightly darker grey may also get some people wondering what's special about it, but not much. I'm still opposed to it, but not as much. Getting them to see it subconsciously is interesting, but still not necessary. If it's not broken, don't fix it.--Here T oHelp 17:11, 15 April 2006 (UTC)[reply]

If the search box on only the main page is highlighted, nobody is going to think that it performs some special function that the other searches do not. Suggesting that is ridiculous. As is suggesting that a user can be competent enough to post a question, and yet is unable to spend the few seconds searching. This is clearly targetted towards uncommited users, and towards promoting the use of the search function. Imagine arriving at a site from google, and the page isn't what you were looking for - a prominent search box would prevent you from exiting. Perhaps you're interested in some other subject, but have found no good site yet. It's a very minor change for a minor/moderate gain. Constant users will quickly come to ignore the color, so that isn't an issue. Another point is that the seperation is a problem. When I first arrived, I didn't notice the toolbox at all. The languages box caught my eye, and I assumed that anything below such a prominent seperation was not relevant to me. Amusingly, the first times I uploaded a file, I had to repeatedly use the search box to get to a page that linked me to the correct one. But :moving the box up might be a different proposal. –M^T 14:24, 18 April 2006 (UTC)[reply]

final suggestion

My final suggestion: A darker gray border, that ever so slightly draws the eye. Change site-wide --Quiddity 22:54, 19 April 2006 (UTC)[reply]

What shade of gray exactly are you suggesting? -Kmf164 (talk | contribs) 00:50, 20 April 2006 (UTC)[reply]

#searchBody {border-color: #444;}

At first I liked the idea of highlighting the search box with color, but less so as I've tried various options in my monobook.css. This particular shade of gray seems a bit too dark, as it makes the border around the search box seems busy to me with the search being lost in the chaos. I've tried several shades of gray. I found that actually a lighter shade than the present gray made the word "search" and the actual search box stand out a little more to me. Or the status quo is fine with me, or I'm still open to the idea of moving the search box above the navigation box. -Kmf164 (talk | contribs) 14:06, 20 April 2006 (UTC)[reply]

I like lighter too, say #searchBody {border-color: #ddd;}

I'm also in full favour of moving the box up to the top. I'll make a final screenshot, and minimize those at the top.--Quiddity 23:53, 20 April 2006 (UTC)[reply]

Media Watch Feature

Can I propose that Wikipedia features a new section entitled "Media Watch" which details any recent media coverage (whether in newspapers, televisions, radio or through other media) of Wikipedia? On U.K. television this week, on "The Gadget Show" on Channel Five (April 17), Wikipedia was mentioned. A summary of this and other media snippets could summarize and assess such coverage. ACEO 08:24, 19 April 2006 (UTC)[reply]

Please see Wikipedia:Wikipedia in the media. -- Rick Block (talk) 02:20, 20 April 2006 (UTC)[reply]

Search Queries

When we search for something, all the results that have an entry in any of the other wikiprojects should also be displayed.

Please reply.

Thanks.

24.70.95.203 23:40, 10 April 2006 (UTC)[reply]

A unified search of all projects would be useful, yes, though perhaps not on Wikipedia.

Golbez 23:45, 10 April 2006 (UTC)[reply]

How not?

Please reply.

Thanks.

24.70.95.203 08:22, 11 April 2006 (UTC)[reply]

Hmnn, now that I think of it, a unified search of all projects would be useful, but not on Wikipedia. Why? Because this is the English Wikipedia, and people come here to read/edit encyclopedia articles. Wikipedia is cluttered enough as it is. Btw, get a username.

Osbus 01:03, 15 April 2006 (UTC)[reply]

Oh, your being VERY fair. So to say that littering the ENGLISH wikipedia WITH MY PROPSAL IS crap, & all others aren't? Not to say that even you agree it is a good idea. No, do you want to make Wikipedia better then stop hating on me! Oh, & get a username, how the hell do you have the right to tell me what to do; FYI, I'm not getting a username, cause I coudn't delete once I get it!

68.148.165.213 07:04, 19 April 2006 (UTC)[reply]

Um, when did I ever say that your proposal was crap and all others aren't? I assume you are angry because you thought I meant that, but I really didn't. And besides, I was only suggesting you get a username...I still think you should. That's what I suggest to all anons.

Osbus 20:31, 19 April 2006 (UTC)[reply]

It's possible this user was talking not about languages, but about wiktionary, wikiquote etc. I think it would be useful to integrate searching of these. That way, if there is a wiktionary article on the thing I search for, but not a wp article, I see it, and, am not tempted to create a wp article on it.

For great justice. 22:19, 19 April 2006 (UTC)[reply]

That's probably true, but I never told this anon that his/her proposal is crap and everyone else's was better. And in no way was my statement hateful...was it?

Osbus 22:24, 19 April 2006 (UTC)[reply]

I don't really care. I was just saying that I thought the proposal had some merit.

For great justice. 22:27, 19 April 2006 (UTC)[reply]

Yea, I believe a unified search would be better, I guess since the search WILL be made more powerful [its on the list of things to do for the developers, but @ the bottom], maybe Search could also be changed so that it searches for in ALL of the WIKIPROJECTS. Yes, I did mean IN THE WIKIPROJECTS, NOT WITHIN THE OTHER LANGUAGES, but that might not be as important, cause a word spelled the same in another language usually has nothing to do with the word spelled excatly the same in another language.

68.148.165.213 02:09, 20 April 2006 (UTC)[reply]

Buttons

Sometimes, the radio buttons don't show up. Is this an issue that has been brought up? Will this be worked on?

68.148.165.213 08:36, 19 April 2006 (UTC)[reply]

Which radio buttons, where?

Brion 18:26, 19 April 2006 (UTC)[reply]

I've seen this happen on edit pages (like where I'm typing right now). The alt text shows instead of the graphics, so you see "Horizontal line (use sparingly)" as a button to click on. I think it's related to slow graphics elsewhere in the system, but maybe it's part of the revision of the javascript (see several questions back, where I replied). Ctrl-Alt-R refreshes the javascript cache in Firefox, and fixed it for me.

Dhartung | Talk 23:32, 19 April 2006 (UTC)[reply]

That's been happening to me for the last two days. I've refreshed everything in sight, including clearing Firefox's entire cache, and I still can't get editing button graphics - just the alt text. Somebody broke something in the last change, I suspect. --John Nagle 05:22, 20 April 2006 (UTC)[reply]

No, I'm sorry, Dahrtung, that's not where I'm talking about; I'm talking about the history pages.

68.148.165.213 01:49, 20 April 2006 (UTC)[reply]

Page protect levels

Right now, we have page protection, but it only has two settings, "on" and "off", and must be applied manually. It might be useful to have more options. Not all pages need to be protected, but when a page has been vandalized more than once in a week, some kind of protection should kick in for a while. Maybe levels of protection are needed, like this:

Unprotected - the normal case
Protected against anonymous edit - kicks in after vandalism by an anon, turns off after a few days/weeks.
Protected against edit by named but unverified user - kicks in after vandalism by a logged in but unverified (no verified e-mail address) user, turns off after a few days/weeks.
Protected - as at present, applied manually; only an admin can edit

This would provide some additional options, and cut down on casual vandalism, without giving up the "anyone can edit" goal of Wikipedia. The vandalism-reversion bots would be empowered to turn on the lower levels of protection. Comments? --John Nagle 05:36, 20 April 2006 (UTC)[reply]

There is semi-protection already, blocking IP and new users from editing an article. It doesn't turn off automatically, though. I'm not sure whether automatically unprotecting pages is all that useful. Kusma (討論) 05:46, 20 April 2006 (UTC)[reply]

Protected against anonymous edit makes sense, probably just as "reminder" display - people can still edit without logging in, but it is explicitely seen as bad style. alex 12:16, 20 April 2006 (UTC)[reply]

As Kusma already said, we already have that. — Saxifrage ✎ 18:02, 20 April 2006 (UTC)[reply]

But it's not automatic. We need more automation in the anti-vandalism area. Too much effort is going into reverts. --John Nagle 18:32, 20 April 2006 (UTC)[reply]

How can we possibly automate turning protection on? Tawkerbot2 is good, but not good enough to be in charge of automatic page protection. — Saxifrage ✎ 19:41, 20 April 2006 (UTC)[reply]

How do you automatically detect a vandalism revert as opposed to someone reverting for POV, testing, redundant information, etc.? How is it justifiable to have widespread protection of pages (which this would seem to imply)? I think that would be counterproductive. --W.marsh 20:13, 20 April 2006 (UTC)[reply]

Request for expansion/rewording of CSD:A7 policy

Please visit Wikipedia talk:Criteria for speedy deletion#Adding more examples to A7 for a discussion on changing the wording of CSD:A7. I consider this an expansion of policy. The proposer considers it a "clarification" of existing policy. --Rob 11:35, 20 April 2006 (UTC)[reply]