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: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]

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

Parkinson Factor

In reference to Parkinson's Law I propose to periodically calculate the Wikipedia:Parkinson Factors, Page-PF, defined to be the ratio of the number of pages in the "Wikipedia:" space (including talk archive pages) to the number of pages in the article space, Byte-PF, the same in terms of bytes. This would be a gauge of bureaucratization of wikipedia, with its multitudes of policies and guideliness. Not to be confused with Parkinson's Coefficient of Inefficiency).

Individual Parkinson Factrors might be of interest as well.

Is this idea technically feasible? `'mikka (t) 18:58, 11 April 2006 (UTC)[reply]

What is the formula? Ardric47 05:11, 12 April 2006 (UTC)[reply]

it was actually defined in the original post - Page-PF = n_pages(Wikipedia:*) / n_pages(*) FleetfootMike 19:02, 18 April 2006 (UTC)[reply]

What is the general formula? Ardric47 00:18, 21 April 2006 (UTC)[reply]

Sections archived on 00:15, 30 April 2006 (UTC)

Multiple levels of adminship

There have recently been a plethora of complaints about admins abusing their powers, such as indiscriminately blocking users who offend them or are involved in an edit conflict with them. Some of these complaints can be found at User_talk:Jimbo Wales. I have once experienced been repeatedly blocked for no reason by a rogue admin, which forced me to temporarily leave Wikipedia.

A possible reason could be because it is relatively easy to become an admin in Wikipedia, so many new admins make mistakes, or deliberately abuse their powers.

I suggest Wikipedia have multiple levels of adminship, and different levels of admins have different types of admin rights. In some online groups services, for example, one level can only moderate posts, one level can moderate posts and ban members, and one level can do both and change group settings as well. Could we implement something like this for Wikipedia?

Once an admin at a certain level has proven to be trustworthy, capable, consistent and commited, he can be promoted to a higher level. However, this might require an approval vote by multiple (e.g. 5) members of a HIGHER level, to prevent abuse. This allows admins to gradually gain trust, and be "put on probation" with the powers they already have before gaining new powers. If the admin receives complaints from users, he risks being demoted or stripped of his admin powers.

Do take my issue and suggestion into consideration, and expand on it further. --J.L.W.S. The Special One 11:28, 20 April 2006 (UTC)[reply]

We already have editors, admins, bureaucrats, stewards, Danny, and Jimbo. How many more layers of hierarchy do you want? -- Donald Albury^(Talk) 11:37, 20 April 2006 (UTC)[reply]

Please explain the rights of each of these levels of adminship. --J.L.W.S. The Special One 04:02, 22 April 2006 (UTC)[reply]

See [[3]].

I would support having admin-light (or whatever name you like) that cannot delete/undelete nor block. Only protect/unprotect and edit protected pages. This would be great for template maintainers like me which often stumble upon protected pages which have a template call that needs to be changed due to a change in a template. Or editing protected templates which were protected because of their high usage. This would be a more technical admin. --Ligulem 18:54, 20 April 2006 (UTC)[reply]

admin's with disordered user page: go through approval againalex 12:21, 20 April 2006 (UTC)[reply]

This isn't the place to argue your politics. — Saxifrage ✎ 18:03, 20 April 2006 (UTC)[reply]

sorry i removed it. IMO admin user page's should give a good example. alex 16:37, 21 April 2006 (UTC)[reply]

I have seen some admins with offensive user pages, and I agree that they are setting a bad example. --J.L.W.S. The Special One 04:02, 22 April 2006 (UTC)[reply]

This kind of "admin level" thing gets suggested from time to time, here and on WT:RFA and elsewhere, and I used to support something like it. But it's ultimately instruction creep, I think... especially as you have a ton of levels, different voting procedures for every one, all kinds of pages, etc. I do think a "trusted user" level could be nice... able to view deleted pages, use rollback, and issue blocks for simple vandalism, for example. It could be bestowed and taken away by beaurocrats at will. But ultimately to get the ball rolling on this, see Wikipedia:How to create policy, it's going to take a whole lot to effect a change on this issue, I'm afraid. --W.marsh 20:18, 20 April 2006 (UTC)[reply]

You don't need tons of levels. Three to five are enough. All can use similar voting systems. For example, if there are 5 levels, 1-5, 5 being highest, and you are at level X (it can be 0, for non-admin), and want to be promoted to level X+1, you need N (say, 5) admins of level X+1 to approve you before you officially become an admin of level X+1. --J.L.W.S. The Special One 04:02, 22 April 2006 (UTC)[reply]

Two levels would be enough. Admin, as we have today, and admin-light. No new voting system. Each candidate states in her/his acceptance of the nomination whether she/he applies for admin or admin-light. Admin is the default. Admin-light is no prerequisite for admin. Of course an admin-light could later apply for admin. Admin-light rights would comprise the admin set without blocking/unblocking and without delete/undelete. That's it. No new bureaucracy. No new procedures. No new voting system. RfA remains as it is. --Ligulem 13:59, 22 April 2006 (UTC)[reply]

Sections archived on 00:18, 1 May 2006 (UTC)

WP:PP

I have a protection script[4] that takes out all the slow, tedious paperwork of listing on WP:PP for every single (un)protect. Is there a way to have something like this enabled if people check it in there preferences or something? The list at WP:PP often gets VERY out of date and I think the problem is that people just don't feel like updating it since we already have the category.Voice-of-All^T|@|ESP 22:46, 22 April 2006 (UTC)[reply]

Strongly object. A category doesn't explain why an article was protected, nor when. User:Zoe|^(talk) 05:21, 23 April 2006 (UTC)[reply]

Auh...I am for the list. That is why I made the script. The script does the paperwork for you, and part of it asks "enter an explanation". People don't bother to update, so I made this script that automatically delists whatever they unprotect and vise versa (when the use the script's protection tabs).Voice-of-All^T|@|ESP 06:16, 23 April 2006 (UTC)[reply]

As someone who uses VOA's wonderful script, I highly recommend it for, well, every admin really. But particularly those who involve themselves regularly with RFP. · Katefan0^(scribble)/poll 06:26, 23 April 2006 (UTC)[reply]

Thanks. I think that it works quite well. The only bug that lingered was the mis-parsing of special characters like accented letters, which was fixed on the 22nd (yesterday). It almost always finds and delist articles, and it works best when more people use it, since it can always recognize and delist what it lists, where as people sometimes use the wrong template/no template/redirects to the actual articles, which may cause it to be unable to find the article. The only thing to work on know is to trim the size, which I can do by having more general variable that switch to the constant ones, so that I can have one or two command blocks for each function.Voice-of-All^T|@|ESP 06:31, 23 April 2006 (UTC)[reply]

Sorry, VofA, it wasn't clear to me that that was what your script was doing. I retract the oppose. User:Zoe|^(talk) 22:25, 23 April 2006 (UTC)[reply]

Sections archived on 00:13, 2 May 2006 (UTC)

slash page(s)

It means to add a sub-page to an entry. In example i would like to "outsource" the information about "discriminatory usage of watermelon imagery" within the watermelon article. For the reason (I believe this) the majority of people does not seek "neagtive information/communications".

It would be included by "discriminatory usage of watermelon imagery", which links to watermelon/discrimination. There seems to be various occurance of such usage, but most of it connnected to north american racism.

Your ideas/do you agree/how can it be done? I have already performed it for an explicit illustration (within another article). I have seen "need for action", because the illustration is illegal to display in certain countries. It is still possible to access it, but people do not need to see it all of the time. Is it possible to understand the idea/concept of "slash page", any idea for a better indentifier (the name for this sort of pages)?

alex 15:05, 18 April 2006 (UTC)[reply]

I'm not quite clear on what you are proposing. As for your last question, they're called "subpages", but no longer work in the main article space, i.e. watermelon/subpage is a free-standing article that happens to have a slash in the title, not a subpage of watermelon. Note that this won't keep it from being displayed where it is "illegal", since clicking "Random Page" will still deliver them to readers randomly. — Saxifrage ✎ 20:26, 18 April 2006 (UTC)[reply]

Well i am basically asking if it is accepted most likely (if i believe the majority of people does not seek a specific information, but it is required for completeness sake). Important, i do not wish to prevent anything from being displayed, just to add a sub-layer to skip around explicit information. Then, it requires an additional action of will to display the information. Probably it is useful to apply/rewrite articles generally (if they contain cruel/illegal illustration, information on racism and hate, etc.) It is absolutely not about omitting any information, just the way how it is displayed. alex 12:10, 20 April 2006 (UTC)[reply]

Wikipedia is not censored, so I don't think the idea of adding extra layers to prevent information from being displayed will be accepted by anyone. This is currently done for some pornographic images, but this is reserved for the very small number that are uncontestedly pornographic, not for things that people "might" find objectionable. — Saxifrage ✎ 19:27, 23 April 2006 (UTC)[reply]

I just do not know if it is acceptable to put information into a slash page (which is linked clearly visible): -If the article gets shorter and better readable. -If negative information is not longer scrolled by default. And how about to add statistics tables (i.e. south american countries) but not to the article itself (it would expand too much). Such tables are not original research, but applying a static method (addition/division, standard degression). It is also possible to put them into an external site (they do not take much bandwidth). I do not (yet) need to do it, just asking in general. The watermelon article has improved on its own, i checked it today. The proposal itself is that such pages are not counted as articles on their own (however it wont bug very much if they are). alex 08:38, 24 April 2006 (UTC)[reply]

Generally, no. Do not use slash pages. Instead find an appropriate title. For example. Instead of Melbourne/transport, we have Transport in Melbourne. For your example you may have wanted to start the article called simply Discriminatory usage of watermelon imagery, but that is only if that section of the watermelon article got too long. Hope that clears things up —Pengo 08:46, 24 April 2006 (UTC)[reply]

Well i can live with this method. However such articles are hard to find (by search) sometimes. Hence it is required to include a link into the basic article...i am just thinking in MSDOS directory structures. It takes additional thought to understand "wikipedia is not a MSDOS directory tree" alex 09:04, 24 April 2006 (UTC)[reply]

And how about Watermelon(discrimination) ? A link to explicit naming policies? alex 09:06, 24 April 2006 (UTC)[reply]

Parentheses are only used to disambiguate subjects, such as to tell the difference between Spore and the game Spore (game), not to separate different sub-topics of a subject. — Saxifrage ✎ 09:37, 24 April 2006 (UTC)[reply]

patern of abuse from certian ip ranges?

I've noticed that approximatly 99.9999% of wikipedia vandalism, by ip users seems to come from the same ip range,

NetRange: 1.0.0.0 - 255.255.255.255

I suggest that if it were blocked, nearly all vandalism could be ceased indefintly--152.163.100.134 21:06, 18 April 2006 (UTC)[reply]

You amaze me. --Osbus 00:54, 19 April 2006 (UTC)[reply]

April Fools was half a month ago, 152.163.100.134 … Nihiltres 03:29, 19 April 2006 (UTC)[reply]

and the other's are from 0.0.0.0 - 0.255.255.255 -> now it includes 100% of vandalism, and we can ban the entire range. please excuse if this sentence is grammatically incorrect/figures a language abuse alex 12:13, 20 April 2006 (UTC)[reply]

But people will just go to the ISPs with IPs like 301.341.287.1023 and then we would have to block an even larger range!!! r3m0t ^talk 20:44, 23 April 2006 (UTC)[reply]

It looks like the end of the 8bit ISP age to me alex 08:24, 24 April 2006 (UTC)[reply]

Email message

I suggest that users ought to have the option to enter a message to be displayed to other users emailing them, for example Please have the subject line as Wikipedia10 for my spam filter. Any opinions?--Keycard ^(talk) 08:08, 23 April 2006 (UTC)[reply]

If somebody emails you by clicking on the "email user" link on your User or Talk pages, the default header is "Wikipedia email". User:Zoe|^(talk) 22:27, 23 April 2006 (UTC)[reply]

I know, and most people will change it, unless they're requested not to.--Keycard ^(talk) 06:47, 24 April 2006 (UTC)[reply]

Alt. text to give a description of link

I don't see this mentioned anywhere else, but maybe it's just because I don't know exactly how to describe it. I always see a little text box pop up when I mouse over links in articles. It is usually exactly the same text as the link. A lot of the time, I wish this contained a short definition or description of what is contained in the article that is being linked. That way, if I didn't know what something was, I could just mouse over it for a quick definition and then continue reading the article I went to in the first place. Netflix does an incredible job of this. When you mouse over a movie title, you get a summary and a picture of the movie packageing. I'm not even sure if this could be implemented on wikipedia, and it wouldn't have to be anything complicated, but it would be very nice.

Brilly 22:54, 23 April 2006 (UTC)[reply]

You may be looking for Lupin's popups tool, which gives a popup with the beginning of the page and the first image whenever you scroll over a link. Flcelloguy (A note?) 22:58, 23 April 2006 (UTC)[reply]

Yes, that is exactly what I was looking for. Thank you. Brilly 23:33, 24 April 2006 (UTC)[reply]