Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The proposals section of the village pump is used to discuss new ideas and proposal that are not policy related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are discussed at Wikipedia:Village pump (perennial proposals). If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

• If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
• If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
• If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

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.

Date on Main page

Why don't we put the date on the front page? The only thing relevant to the date is the "On this day..." But I think the main page would just look "more complete" with a full day.month.year sort of date in one of the corners or at least somewhere on the page. If infact there is already a date (i've tried looking), then maybe you can make it a bit more apparent because I can't seem to find it for the life of me. 17:27, 8 May 2006 (UTC)someguy.

Indeed that's a good question. But I like the layout as it is; it seems like any new addition might disturb the balance. But that may just be me. joturner 22:47, 14 May 2006 (UTC)

I have created a copy of the main page in my user sandbox, and added the date to it in what I think is a good position. Could someone with a more experienced eye than myself please take a look at it to find out what effect the date has on the layout of the page? Andrew 23:15, 17 May 2006 (UTC)

I barely noticed it. (In fact I only noticed it because I was looking for it). I don't think the date disturbs the balance in anyway, although I'm not sure what the point of putting the date on is? The only use I can think of is in screenshots, and even that is of only a little use. Captainj 17:05, 18 May 2006 (UTC)

I delibrately made it small so that it didn't interfere with the layout of the page. However, I'm only an amateur at web design; has anyone else got any ideas on where the date should be placed on the Main Page, if at all? Andrew 22:56, 18 May 2006 (UTC)

I also couldnt find it easily. Although, if it is too large, people will complain that it messes it up. Adding a date in small writing below the title cant hurt, can it? I think someone should just put it in - • The Giant Puffin • 19:33, 19 May 2006 (UTC)

I would like to modify the idea. The date would be useful for identifying the approximate version of WP when printed, but then it would have to show above every article. I don't see much use in putting it on the main page, as I think the main page is rarely printed. In addition, real estate on the main page is very expensive, even if the date would fit. -Pgan002 03:42, 21 May 2006 (UTC)

The last-modified date already shows up on every page, at the bottom, at least with the default page style. Isn't that sufficient? —johndburger 02:00, 26 May 2006 (UTC)

What's the point of putting a date on a front page? I've always found the idea annoying except as when stated by johndburger as a last modified date. If you want to know the date, why don't you just look on your computer? - Rudykog 00:32, 28 May 2006 (UTC)

And the date would change when it is midnight EDT (where the servers are) or midnight universal time? Either way lots of people would see a date which was not correct for their location.Filceolaire 13:11, 30 May 2006 (UTC)

I definitely support the date on the main page. How about a box somewhere like this:

Thursday 28 November 06:26 UTC

—Mets501^talk 21:28, 30 May 2006 (UTC)

What about removing permanently the "redirect button" from the editing tools?

I'm asking for this action since I have the feeling Wiki users fail to see hidden information because of automatic redirection. A simple link to the page where the first page is redirected to would do better in my point of view, since you would always first stop at that word which you really entered. Different opinions? Suggestions? Have a nice day! --Tom David 16:18, 10 May 2006 (UTC)

You mean users should be forced to click an extra link on every alternate spelling or shortcut, rather than being automatically redirected? I don't follow. —Simetrical (talk • contribs) 03:17, 11 May 2006 (UTC)

Yeah, that's not working for me either. I think the fact that it says at the top of the page where you were redirected from is enough. —Mets501^talk 11:09, 12 May 2006 (UTC)

Why this should be such a big problem to make one single click more? Yes I mean that the user should be forced to click an extra link. The information that one has been "redirected" is so small and almost invisible that every second user doesn't remark it. Well, think what you want. I don't like the automatic redirection. If you correct somebody always automaticaly, I'm not sure whether he will be able to correct himself one day on his own. --Tom David 07:44, 15 May 2006 (UTC)

In any case, you can always return to the redirect page by clicking the "redirected from" link just below the title. I think it makes more sense to keep articles easy to find by putting automatic redirections on pages with alternate spellings/names, and giving those users who wish to access the redirect pages a way to do so by using the "redirected from" link. The reason why its small is because people wouldn't normally need to access the redirect pages. I think we'll have to agree to disagree here :-) Andrew 22:55, 17 May 2006 (UTC)

I have the feeling that some articles you can't find because of the automatic redirection, especially if you are a fast user (then you don't see everything), but it looks like everybody has to make his own experience concerning "being automated" :) --Tom David 09:37, 18 May 2006 (UTC)

I have two points to make:

1. Disabling automatic redirection would break several templates, whose transclusion links point to the redirect page.
2. I find it incredibly annoying when I click on a page and get a double-redirect. I know that I could easily click the link, but it is unexpected and confusing for some.

--Max Talk (add) 03:27, 23 May 2006 (UTC)

People get redirected by web servers all the time, perhaps without noticing it. For instance, if you type en.wikipedia.org to your browser, the server redirects you to en.wikipedia.org/wiki/Main_Page. I suspect we'd all get real tired real fast if we had to click through something in that case, and I don't see how wiki redirect pages are any different. —johndburger 02:09, 26 May 2006 (UTC)

Well, if web servers are regarded as encyclopedias, ok. Nevertheless, clicking on a link is not the same as entering a word in a search mask. It's clear that links should always point to the correct address. Anyway, perhaps it's better if one doesn't need to click too many times. Just let's make sure not to bury something useful behind a redirection... --Tom David 17:34, 28 May 2006 (UTC)

Wiki Currency

Similar to the barnstar and user templates, this is a counter that keeps track of Wikipedia "currency." Currency is earned automatically for different actions (such as page edits by byte count), but is meant more as a reward or gift. One can give others currency for helping with an article, finding information, or some other action, which can be put up as a request and accepted by others- once the task is completed, the originator can "accept" to pay the user for the task, adding currency to their counter. Creating a "task" template allows the payer to specify an action and close the task when the payer sees the task is finished.

Currency would also be given for acts of notoriety, resolving disputes, and other honorable actions. Since the currency is kept track of server side on a different server, users cannot edit their total, but can add or subtract by giving or paying to a specific user by typing the username and amount and hitting submit. Hopefully this will bring a sense of unimaginable chaos. Ihavenolife 01:55, 15 May 2006 (UTC)

• Definitely see the article on Wikipedia:WikiMoney. Now, I agree that having a currency system would be potentially beneficial; however, we need to figure out why wikimoney didn't work the first time around. I think that keeping the currency data protected and having a standard method of distribution would be an improvement over the previous attempt. --Mlandau 02:45, 15 May 2006 (UTC)

• What could the WikiMoney be spent on, however? Andrew 22:51, 18 May 2006 (UTC)
  • The original wiki money seems to have been spent on article requests, which ain't a bad idea. I'm not sure what else it could be spent on, though of course, I'm partial to owning shares of articles. But what good would that do? Bragging rights? Voting power? I think it could serve a useful function, but I don't know what that is, though bringing order to chaos seems useful enough. --Mlandau 03:07, 19 May 2006 (UTC)
  • For prestige in the WP community, similar to the list of contributions of each editor. -Pgan002

• A good idea, but we should put this discussion somewhere where it might get some more views. Felixboy 18:36, 23 May 2006 (UTC)
  • Agreed, and I just thought of one possibly useful function of wiki money: dispute resolution (oops, should have read above, Ihavenolife beat me to the punch, but here's one way it could work). If it's worth 100 wikis for me and my compadres to maintain position X, and worth only 90 wikis for those against X, then me and my compadres would win because we value X more, but would have to give the opposing side 90 or so wikis because that's what they valued their opposition at. --Matthew Benjamin Landau 04:12, 24 May 2006 (UTC)
    • We shouldn't have to pay for justice... --Username132 (talk) 17:36, 26 May 2006 (UTC)

Disgusting images

hey there, I just want to say that there is a line between censorship so kids can't see "dirty images" and somthing being completly disgusting, maybe some of you guys don't care about seeing pictures in articles such as penis, clitoris, vulva and other articles like that, but most of those pictures are taken at home of some fat guy's dick, that's just messed up. The article Masturbation is nice because it uses drawings to illustrate the topic, no real images (thank god), and remmember, there are kids using wikipedia these days, thank you. --mo-- (^Talk | _#info | ) 06:08, 16 May 2006 (UTC)

See the relavant policy at Wikipedia is not censored Raul654 06:09, 16 May 2006 (UTC).

I know it's not censored, that's why i said "there is a line between censorship so kids can't see "dirty images" and somthing being completly disgusting" --mo-- (^Talk | _#info | ) 07:12, 16 May 2006 (UTC)

You seem to saying that sterile photographs of gentilia, similiar to the kind one might find in a medical journal, are "disgusting". I assure you that this is a minority view, and that even those who wish to apply some sort of system to make potentially disturbing images optional would most likely disagree. In any case, until you clarify what exactly you're proposing, what kind of standard would exist etc. this will not be supported or implemented (largely because there's nothing to support or implement).--Sean Black 07:27, 16 May 2006 (UTC)

I seriously doubt that is a minority view among users of all ages and all countries, as opposed to the right-on young Westerners who are massively over-represented on Wikipedia. 62.31.55.223 02:50, 17 May 2006 (UTC)

Really? I can't imagine that finding relatively sterile images of normal human body parts "disgusting" is anything but a minority view. In any case, I was speaking about Wikipedia editors, rather than the world at large, so I can be relatively certain that it is not a majority viewpoint.--Sean Black 05:59, 17 May 2006 (UTC)

You think those images are disgusting? They're far less disgusting than a lot of those on articles linking from here! Grutness...wha? 08:53, 16 May 2006 (UTC)

We had some discussion here recently about forming a Wikipedia Junior that was suitable for children to browse. Some opposed the idea, others were enthusiastic. The SOS Children's Charity actually did some work along this line, publishing a free version on CD with carefully selected Wikipedia content. The free version can be found at http://www.soschildrensvillages.org.uk/charity-news/education-cd.htm --Dave 21:40, 16 May 2006 (UTC)

I'm sorry that images of the human body disgust you. Maybe you should consider configuring your browser so as not to be forced to view images. User:Zoe|^(talk) 23:14, 16 May 2006 (UTC)

If one goes to those articles, one should expect to see those pictures. Ardric47 05:04, 17 May 2006 (UTC)

Seems to me that when one human being finds images of another (or part of another) "disgusting" that says far more about their state of mind than wikipedia, western culture or anything else. Graham 05:55, 17 May 2006 (UTC)

Indeed. Articles on human body parts should be illustrated with images of human body parts. There are instances on Wikipedia where an inappropriate images are pushed into articles where it is tasteless or unhelpful (e.g. this happened on Nicole Kidman), and I think that can be opposed. But this is not one of those instances. Christopher Parham (talk) 18:38, 17 May 2006 (UTC)

Using Special:Random/Image goes to a random image, which could potentially be disgusting. I think that on these pages, users should have to click on a warning link (maybe javascript) before the disgusting image is shown. Kids using wikipedia therefore will be protected from unintentionally seeing disgusting images, but there is no "censorship" since the content is still available. Pcu123456789 21:52, 23 May 2006 (UTC)

I don't know why wikipedia can't just adopt the PICS meta tag capability for individual pages and images. Perhaps implemented through a template? Alternatively, since Wikipedia is uncensored, every page and image should be given an adult content meta-tag so the parent filters can block it. — RJH (talk) 20:09, 26 May 2006 (UTC)

To fix the Japanese tile on the Wikipedia logo

I'd like to propose that the Japanese tile in the Wikipedia logo be slightly altered to better represent the pronunciation of "Wikipedia" in Japanese. The Japanese tile is the one directly above the "W".

If you view the logo in the upper left corner of http://ja.wikipedia.org/ you will notice that while the graphic part of the logo is the same, the text for Wikipedia does not match the symbols in the tile.

It is written "ウィキペディア". The first character, ウ, represents 'u', but when ィ is attached it shifts the pronunciation to something closely resembling 'wi'.

The artist who made the Wikipedia logo almost had it right. He used ワ as the first character (wa), and attached ィ to shift the pronunciation to what only could be considered to be 'wi'.

The problem is that this combination is very rare in Japanese, and the pronunciation is ambiguous. When asked how to pronounce the ワィ in the Wikipedia logo, Japanese people often respond with a confused, "...wai? wi?... wai?". On the other hand, when confronted with ウィ, as I propose (and which is used in all Japanese writings of the word Wikipedia), all Japanese people will respond with an appropriate 'wi'.

The truth is, the Japanese language lost the 'wi' sound centuries ago, but everyone seems to agree that the closest thing to it is the combination ウィ.

How hard would it be to change that ワ to a ウ? (ワィ $\rightarrow$ウィ)

Wesarnquist 07:51, 17 May 2006 (UTC)

The logo was created by user:Nohat. You might want to ask him directly, or post this to the talk page for m:Logo. -- Rick Block (talk) 18:34, 17 May 2006 (UTC)

Are the characters supposed to represent a W sound? If so, then the Hebrew and Greek letters need changing, too (ר is an R sound, and Ω is an O sound—the Wikipedias in question use ו and Β instead). —Simetrical (talk • contribs) 05:06, 18 May 2006 (UTC)

Oh my - on closer examination and after briefly talking to the creator of the logo, it looks like the symbols are not intended to match the first sound of Wikipedia in the various languages, but simply to show internationalism. The only scripts I can read reliably are Japanese and English (Roman script, I suppose), and have forgotten how to read some of Greek, Hebrew, and Korean over the last few years. The ר didn't strike me as strange because it looks a bit similar to ו, and I just assumed the Ω was correct (I thought perhaps Greek forms the W sound in this case as a combination of vowels, similar to Japanese).

I still don't like the way it's set up, however - especially the ワィ on the Japanese tile. It's simply odd - like an input error. Perhaps it would be better to change the name of this proposal to something related to changing all tiles that don't match the pronunciation of Wikipedia in the respective language. Apparently another user brought this up before and said the only way it will change is if we can build popular support. Does anyone else feel it should be amended? Wesarnquist 08:16, 18 May 2006 (UTC)

I support the modification of the Japanese on the logo, and propose similar modifications for the other lanuages represented. -Pgan002 04:04, 21 May 2006 (UTC)

I have already talked to Nohat a couple months ago, as well as some administrators on the Japanese wiki. Nohat has no interest in changing it, for 2 reasons. Creating logos for other wikis is already a hectic job for him, and restyling logos for all those wikis would be a huge pain for him. This isn't an issue of only changing the English Wikipedia, users of smaller wikis that don't know how to edit images themselves would want Nohat to do it for them. Secondly, he pointed out that it is not meant to represent the Japanese name of Wikipedia, which is obviously a convenient defense, but there's no point in arguing that. I don't like the weird inconsistancies any more than you do (it's hardly an "international logo" if it's covered in strange international alphabet inconsistancies) and to tell you the truth, I don't like the logo at all, but this route isn't going to get you anywhere. I'd much prefer a newly designed logo, but the way media wiki is designed almost dooms that idea to fail, so I don't see any other apparent solutions.  freshofftheufoΓΛĿЌ  05:22, 24 May 2006 (UTC)

Non breaking space in links

Especially in template blocks with lots of names I would like to be able to make all the names non breaking, i.e. [[First Last]]. However if I do that it tries to link to page with a space in the name.

My proposal: just like spaces in links are automatically converted to underscores also convert   to an underscore.

Or perhaps some other symbol to use that will mean non breaking space. A __ maybe? (Since it has special treatment right now.) i.e. [[First__Last]] will become First Last with a link to First_Last.

A symbol might be a good idea since I can imagine this being used a lot (see the uses section of nbsp). 71.199.123.24 04:46, 18 May 2006 (UTC)

For now, use [[First Last|First Last]]. It works. r3m0t ^talk 08:27, 19 May 2006 (UTC)

Good idea--support. Pcu123456789 21:53, 23 May 2006 (UTC)

Wikipedia Zeitgeist?

I may have been looking in the wrong place but I couldn't find anything which lists which are the most searched articles. I'm thinking along the lines of Google Zeitgeist or eBay Pulse. Yorkshiresky 17:29 20 May 2006 (UTC)

To the best of my knowledge, no such list exists. You could try asking the devs at WP:VPT. —Simetrical (talk • contribs) 03:26, 24 May 2006 (UTC)

Wikicafe

Where Wikipedians can book a meeting with their favorite admin. Wallie 21:42, 20 May 2006 (UTC)

They could just use their favourite admin's talk page. Andrew 23:02, 20 May 2006 (UTC)

But at Wikicafe, users buy coffee for admins for their time.  freshofftheufoΓΛĿЌ  05:31, 24 May 2006 (UTC)

Change Requests

Could we formalize this whole process, and allow Administrators or Users to come up with Change Requests. This form would detail exactly what is required. The requests could be logged into a tracking system, like Test Director as an example. The Change Requests could go before the Administrators on say a Monthly basis. At that stage they could be prioritized for implementation or dropped. Wallie 08:38, 21 May 2006 (UTC)

Ack! What a nightmare! Why don't you just make the edits yourself, that's what Wikipedia is designed for. User:Zoe|^(talk) 19:33, 21 May 2006 (UTC)

Not for edits! For new proposals. For example, next month's suggestion, buy Zoe a new Porsche. Wallie 22:11, 21 May 2006 (UTC)

Software changes can be put on Mediazilla. You could always suggest that another branch of that be opened for Wikipedia-specific policy suggestions, but I doubt you'll get much support. (As for going before the admins, you may want to read up on how to create policy. —Simetrical (talk • contribs) 03:29, 24 May 2006 (UTC)

Leaving Messages on User Talk Pages

I have noticed that many users have placed a link of the form:

Please click here to leave me a new message.

on their user talk pages. I think this is a very good idea for several reasons:

• New users may not know how to leave a message by just editing the page.
• It ensures comments are categorized by headings.
• It provides some sort of edit summary automatically (the subject given).

For all three of these reasons, but mostly because of the ease of use for new users, I would like to propose that a leave message link be added automatically to the top of every user talk page. I can see no real downsides, so long as we leave some formatting freedom to allow users control over their own talk pages. Any comments/suggestions are welcome. Thanks. Cool3 21:46, 21 May 2006 (UTC)

Not everyone may want a large bright blue box at the top of their user talk page, but feel free to use this as a template (say, at Template:User_Message_Link). Andrew 12:56, 22 May 2006 (UTC)

A version with an orange box is already a template, at Template:User new message. -- Rick Block (talk) 14:13, 22 May 2006 (UTC)

I agree that not everyone, quite possibly not the majority of people would want a large blue box, but I'm not necessarily suggesting a large blue box (blue is merely my personal choice), I'm just suggesting an automatically present leave me a message link. The template is a good step, but I think that having some kind of automatically appearing "Leave me a message" would be better, maybe even at the top of the page next to the "edit this page" button. Cool3 23:40, 22 May 2006 (UTC)

You mean, kind of like the tabbed "+" that's already there? But with the "+" replaced with the text "Leave me a message"? -- Rick Block (talk) 00:15, 23 May 2006 (UTC)

Yes that sounds good. I hadn't quite thought down those lines, but that's, in my opinion, a perfect idea and probably an easy change to enact. Cool3 01:07, 23 May 2006 (UTC)

The issue is this text ("+") is used for all talk namespaces (specifically user talk and talk pages for articles). It could be changed to "Add a comment" or something somewhat less specific. The official place to bring up a suggested change for this text is MediaWiki talk:Addsection, although if you do so please add a pointer in a new section of this page. -- Rick Block (talk) 01:57, 23 May 2006 (UTC)

Naming convention (capitalization) for specific events

I was wondering if there is a naming convention that deals with capitalization of specific events, like earthquakes, floods and fires, or if one could be created. I could not find anything specific at Wikipedia:Naming conventions. Right now, it seems to be left up to the creator or decided on a case by case basis. For example, there is Johnstown Flood and Burchardi flood, Great Chilean Earthquake and Whittier Narrows earthquake, Reichstag fire and Great Chicago Fire. I'm not sure which version is most favored. I got a lot of results capitalized and uncapitalized when I searched Google. It appeared that the uncapitalized versions may be favored in academic writing, with journalists and other sources favoring capitalization. However, it also varied individually and it's too small of a sample size to make any accurate judgment. I prefer the capitalized versions because they are specific events and "flood", "fire" and "earthquake" are part of their names. However, lowercase would be okay if it would make the names consistent. -- Kjkolb 01:31, 22 May 2006 (UTC)

I would say we should capitalize when it's clearly a specific name rather than just a descriptive one. A good indication of this would certainly be anything with "Great" in the title.--Pharos 01:51, 23 May 2006 (UTC)

Proposal: striped table CSS class + JS

I think that sometimes, wikitables are hard to read and would benefit from having so-called "striped" rows. It's possible to do this pretty easily with some JS and CSS. I've tested this in my own CSS space and found that it works quite well.

Here's an example of how a table should look like with some small JS and CSS additions:

Example of striped table rows

You type...	You see...
{| class="wikitable-striped" |+ Table tags ! Tag ! Description |- | <table> | Defines a table |- | <th> | Defines a header |- | <tr> | Defines a row |- | <td> | Defines a cell |- | <caption> | Defines a caption |}	Table tags Tag Description <table> Defines a table <th> Defines a header <tr> Defines a row <td> Defines a cell <caption> Defines a caption

I think that this would make new tables that use this CSS class much more readable. Since it uses a new CSS class rather than the old one, it also won't break any old tables or cause discontent for those who don't like the stripes.

To get this to work, you'll need the JavaScript:

var stripe = function()
{
  // This function will add stripes to all tables that have the "wikitable-striped" class attribute.
  var tables = document.getElementsByTagName("table");
  for (var a = 0; a != tables.length; a++) {
    var table = tables[a];
    if (!table) { return; } // If there are no tables, abort.
    if (table.getAttribute("class") == "wikitable-striped") {
      var tbodies = table.getElementsByTagName("tbody");
      for (var b = 0; b < tbodies.length; b++) {
        var even = true; // We start with an even stripe.
        var trs = tbodies[b].getElementsByTagName("tr");
        for (var c = 0; c < trs.length; c++) {
          if (even) {
            trs[c].className += "even";
          } else {
            trs[c].className += "odd";
          }
          even = !even;
        }
      }
    }
  }
}

// Perform the striping.
window.onload = stripe;

... and the modified CSS:

table.wikitable,
table.prettytable,
table.wikitable-striped {
  margin: 1em 1em 1em 0;
  background: #f9f9f9;
  border: 1px #aaaaaa solid;
  border-collapse: collapse;
}

table.wikitable th, table.wikitable td,
table.prettytable th, table.prettytable td,
table.wikitable-striped th, table.wikitable-striped td {
  border: 1px #aaaaaa solid;
  padding: 0.2em;
}

table.wikitable th,
table.prettytable th,
table.wikitable-striped th {
  background: #e8e8e8;
  text-align: center;
}

table.wikitable caption,
table.prettytable caption,
table.wikitable-striped caption {
  margin-left: inherit;
  margin-right: inherit;
}

tbody tr.even td {
  background: #eee;
}
tbody tr.odd td {
  background: #f9f9f9;
}

Note: the CSS was also changed slightly to make colors with the striped tables more visible. Normal wikitable headers would also get a background of #e8e8e8; with this change, although we can of course always change that if this is not desired. Anyway, if there is support for this, please let me know. I, for one, think this is nice. It would be best to do it in PHP, of course, but this will do for now. —Michiel Sikma, 05:18, 22 May 2006 (UTC) PS: this discussion was originally initiated at Village pump (technical) but then moved over here.

I second this proposal as far as its goal is concerned. Actually CSS3's pseudo-selectors would provide an elegant solution to the problem but... until then, I don't see any other approach than using JavaScript (at least if we want to avoid the user to manually apply classes, of course). I haven't checked the script code, I just noticed that it uses two distinct classes for "even" and "odd" rows; of course one class is enough, as you can assume rows without a class attribute are "of the other kind" :) I also think the script should treat as a special case rows to which a class attribute is already attached. Anyway, I'll repeat, I like the proposal. There are many uses where striped tables highly increase readability and accessibility. —Gennaro Prota^•Talk 13:01, 22 May 2006 (UTC)

Yeah, it's true that you can just use one class, but I figure that it might be most useful to keep editability to a max (in case someone wants to set that color differently in his own monobook.css, for example when he wants three colors). I've heard of CSS3 being capable of doing this, which might indeed be a neat solution. I don't know anything about CSS3, though, and I guess that not a single browser probably supports it now. It's too bad we can't make PHP enhancements to MediaWiki. I'll code in a little check to see if there is a special style in an element to have it ignore that element. —Michiel Sikma, 13:27, 22 May 2006 (UTC)

I don't know what the current level of browser support is. I had heard Gecko 1.8 has some, but I don't follow this news very closely. In fact I don't "follow" them at all, as 99% of all the HTML I write is documentation for C++ libraries, which usually doesn't need amazing special effects :). Also, in that case I can live with a preprocessing phase which is part of the build process. Anyway, I guess the percentage will vary a bit now that I'm here on Wikipedia :) As to PHP and MediaWiki I suppose you could write an extension. From what I've seen in Cite.php it's all quite straightforward and self-explanatory even if, like me, you start with no knowledge of PHP. What I wonder is how many chances exist to get the extension accepted by the MediaWiki developers. —Gennaro Prota^•Talk 14:52, 22 May 2006 (UTC)

Er, why would you need an extension? Any admin can add this Javascript at MediaWiki:Monobook.js et al. —Simetrical (talk • contribs) 03:35, 24 May 2006 (UTC)

Can this be made modular, having the striping be independent of other Wikitable formatting? One should be able to use <table class="striped"> to apply the stripes only, and both classes <table class="wikitable striped"> to also have all the other wikitable formatting. With background tone defining every row, there is absolutely no reason to also add table borders.

How about striping rows in groups of three? This has been used to good effect in a number of articles, for example Romanization of Ukrainian#Table of romanization systems.

This may be a bit much to ask, but can this be smart about table headers, implementing a third background colour for them (e.g., the link above)? I suppose wikitext would have to allow <thead> and <tbody> for this to be implemented.

And why not maximize the contrast, using #fff for the white rows instead of #f9f9f9? —Michael Z. 2006-05-22 15:00 Z

Well, I am one big fan of consistency in articles. That's why I used the wikitable CSS class to build this. I don't intend to make it easily support anything else since there will always be many exceptions. I do think that there is a reason to add table borders, since that's simply part of a good table design. I'm also not sure about multiple rows; how would you pipe that data to the script? class="wikitable-striped-3"? Again, possible. —Michiel Sikma, 18:16, 22 May 2006 (UTC)

As someone pointed out, there's no reason not to have separate classes for wikitable and striped, since browsers support having two classes on a table, and wikitable is not used everywhere. --Interiot 18:44, 22 May 2006 (UTC)

I thought that entities with two classes don't validate? I guess I'm wrong about that, then. I'll modify the code later. —Michiel Sikma, 06:52, 23 May 2006 (UTC)

Space-delimited lists of classes are a standard, under-utilized feature of the CSS cascade. I suggest these class names have a standardized prefix, like t- for 'table', because I could see other modular classes being applied to do common things like left-align headings, right-align body text for tables of fixed-decimal numbers, etc.

HTML 4.01 Specification: "This attribute assigns a class name or set of class names to an element. Any number of elements may be assigned the same class name or names. Multiple class names must be separated by white space characters" [1]. —Michael Z. 2006-05-23 15:10 Z

It seems that Internet Explorer doesn't like multiple CSS classes. I still don't really know how I would do this. Maybe someone can give me another tip as to how to make the rendering occur with any style? —Michiel Sikma, 21:39, 24 May 2006 (UTC)

Non-admins should blank pages with attacks

I have suggested at Template talk:Db-attack, that {{db-attack}} should have a message telling people that they should blank the contents of the attack page. This would help keep attacks out of Google cache and wiki mirrors, while the page waits for admin action. --Rob 20:12, 22 May 2006 (UTC)

I assume you mean inline with WP:RPA. I disagree with that idea since the entire idea of removing personal attacks is fairly controversial except for the most blatant cases, especially attacks that aren't on your user talk page where you have slightly more leeway. Pegasus1138^{Talk | Contribs | Email} ---- 02:58, 23 May 2006 (UTC)

A new feature on Wikipedia?

Hi, I was told to post here, after posting at the Beauro's noticboard.

I was wondering if a group could be made (hopefully with me in it), and a very low, restricted block privlidge's be given. Perhaps no more than say an hour, so it at least immobilises the Vandal, and gives Admin enough time to look into the case, and give a longer block if necessary. I understand that it's a big priv, and should be used very carefully, and perhaps have a system like WP:RFR did, where you could report abuses of power etc.

Thanks In Advance. --Deon555 03:11, 23 May 2006 (UTC)

Blocking even for short periods of time is a reasonably serious thing to impose. I suspect most people would not want to hand it out to inexperienced users. In addition, the change you suggest would require modification of the software, I believe. If you are having problems with vandals I suggest that you post a notice at WP:AIV. I think people deal with reports there pretty quickly. --best, kevin [kzollman][talk] 03:26, 23 May 2006 (UTC)

Indeed. Blocking is probably the most delicate admin tool (certainly it is the source of the most devastating conflicts) and would be the last thing to offer any sort of semi-admins. Christopher Parham (talk) 07:28, 23 May 2006 (UTC)

How about just a 5-minute-block thing? To deal with urgent issues while waiting for a response from WP:AIV. —Mets501^talk 23:48, 23 May 2006 (UTC)

Again, such changes would require MediaWiki modifications, and I am, and I'm sure much of the community, would be hesitant to hand out even the rights for 5-minute blocks. (Side note: even a 5-minute block can trigger the 24 hour autoblock.) Thanks! Flcelloguy (A note?) 23:51, 23 May 2006 (UTC)

Syntax Coloring

Currently, source code in Wikipedia looks rather dull:

/*
 * This is fake Java code to demonstrate syntax coloring.
 * */
public static void main(String[] args)
{
  String s = new String("This is a test");
  char ch = 'c' + 123;
}

Would it be better if syntax coloring could be applied to the code? Here is an example:

/*
 * This is fake Java code to demonstrate syntax coloring.
 * */
public static void main(String[] args)
{
  String s = new String("This is a test");
  char ch = 'c' + 123;
}

To implement this, I had to use several <span> tags to achieve this, which makes the code almost incomprehensible. What I am suggesting is a modification to MediaWiki:Common.css or MediaWiki:Monobook.css. We would define styles for various types of words in a syntax block:

/* CSS code */
syntax key {
color:blue;
font-weight:bold;}
syntax string {color: maroon;}
syntax char {color: orange;}
syntax number {color: teal;}
syntax comment {color: green;}

In the source code, we could simply write out:

<syntax>
<comment>/**
this is a comment</comment>
<string>"Hey there!"</string>
</syntax>

This makes future editing much simpler. If a certain user wished to customize the colors and styles, or turn them off, all he would need to do is modify his own CSS file. This would also pave the way for a possible syntax highlighting tool, much like the <math> tool. The parser would already have the styles in place.

Please, relay your thoughts to me. --Max Talk (add) 04:04, 23 May 2006 (UTC)

---

In general, there shouldn't be much source code in Wikipedia. Nor should there be much HTML markup. --John Nagle 05:22, 23 May 2006 (UTC)

What are you talking about? What a poor excuse to not include a potentially very useful thing in the Wikipedia code. So you're against including it because "there shouldn't be much code"? Says who? What's the problem with a lot of code? This actually reduces the amount of code in articles themselves because people no longer have to make style tags in case they want syntax highlighting. People who copy Wikipedia content simply won't have those highlights, but they'll still have the code. It's perfectly transparent and usable this way. —Michiel Sikma, 10:34, 23 May 2006 (UTC)

There shouldn't be much code because code obfuscates the source, making it difficult for people who don't understand the code to edit. Christopher Parham (talk) 21:01, 23 May 2006 (UTC)

I find the idea great. I'm totally for implementing something like this if it's possible to do so (are there free resources available on how to do syntax highlighting in PHP?) It would certainly greatly increase the quality of articles about programming. —Michiel Sikma, 10:34, 23 May 2006 (UTC)

Instead of modifying the Common.css and Monobook.css, wouldnt it be practicable to use an extension such as this. You can find samples here --Oblivious 11:12, 23 May 2006 (UTC)

My thoughts are that both would be used. We would modify common.css like I suggested above, which would allow us to color code without the PHP extension. The PHP extension would use the CSS styles to format the text, which would still allow users to customize it to their own tastes, or turn it off. If the extension did not support the language, we could still use the styles to manually format it.
As for Nagle's comment, there already is a ton of source code in Wikipedia, in articles like Java programming language, C++, Java syntax.--Max Talk (add) 15:27, 23 May 2006 (UTC)

I've written an extension ("codeblock") for Wikimedia at my own wiki that performs syntax highlighting in many languages. The regular expressions are editable right on the wiki. This is a lot more flexible than your solution, but requires software changes. Visit any article at http://literateprograms.org/ to check it out. You can also view the regular expressions. You can view the source of my extension, which is released under the same license as Mediawiki. Deco 21:23, 26 May 2006 (UTC)

It might turn out that it doesn't matter. The folks on MediaWiki talk:Common.css#Syntax highlighting proposal don't seem as eager for the idea.--Max Talk (add) 00:09, 28 May 2006 (UTC)

Permalink archiving is underrated

Please see Wikipedia_talk:How_to_archive_a_talk_page#Permalink_archiving_is_underrated. Thanks. --DanDanRevolution 07:29, 23 May 2006 (UTC) Update: This issue is, generally, resolved. --DanDanRevolution 14:17, 23 May 2006 (UTC)

Serbia and Montenegro

I posted a few months ago stating that Wikipedians should anticipate the split of Serbia and Montenegro and create/expand the seperate articles for each so as not to be caught out. However, I got shot down by several Serb users, but I thought now that the matter has been settled perhaps we can launch some drive to create/expand these articles, which are very poor in both quantity and quality. I have placed a small list here, but there will be many more areas to cover. Grunners 17:50, 23 May 2006 (UTC)

pcu123456789's proposals

I have a list of several random proposals on my user page. Pcu123456789 21:47, 23 May 2006 (UTC)

AfD reform

Please take the time to review my (revised) proposal for AfD reform. Thank you for your consideration. El_C 12:47, 24 May 2006 (UTC)

A new structure for Wikipedia

When I first started using wikipedia, it was fairly easy to find the articles I was looking for, but the pages are often messy and confusing. I have a few ideas:

1 - Add a "new users" function to wikipedia, whether it is a link on the navigation bar or something that appears in the user's functions. This could include an article link to a 'new user' article that would tell the user how Wikipedia works, what portals, articles, stubs, etc. are, how to start and edit articles, etc.

2 - Add a "create new article" and "sandbox" link in the navigation bar - they are really hard to find.

3 - A nicer looking User Interface might be good too, if possible. It might just be a change in the arrangement of everything, to make it easier to understand and use.

As far as the "new users" function, I'm not quite sure what you're talking about, but the Welcomming Committee usually puts welcome messages with links to those pages on the talk pages of new users. As for the "create new article" link, just type in the name of the article you want to create in the search box, and then click "Create this article!" link. For the sandbox, just type in Wikipedia:Sandbox. For the user interface, I have no problems with that, but I'll leave it up to others to decide about that. Also, don't forget to sign your posts using ~~~~. —Mets501^talk 01:31, 25 May 2006 (UTC)

WikiTeX

Can we include some of this on Wikipedia? WikiTeX It would really be awesome, especially for music and chemistry-related articles. —Mets501^talk 22:20, 24 May 2006 (UTC)

I don't know what the problem is, but I think people have been asking for this for years. I could be wrong, though. Ardric47 02:14, 25 May 2006 (UTC)

It would really be useful. I wonder what the problem implementing it is. —Mets501^talk 02:53, 25 May 2006 (UTC)

Wow, I remember that. Devs, any comments? I totally want this feature. Comments can be made at http://bugzilla.wikimedia.org/show_bug.cgi?id=1792 Ingoolemo ^talk 03:02, 25 May 2006 (UTC)

Holy carp! Just looking at that example page makes my mouth water! It's awesome! Especially the music: I didn't know it was that easy to typeset music readably. Brilliant!--Slashme 10:24, 25 May 2006 (UTC)

But it's not that easy [on Wikipedia], because it's not available! Ardric47 00:37, 26 May 2006 (UTC)

Great feature, should be added Pcu123456789 02:52, 26 May 2006 (UTC)

Good Citizen

I was going over the perennial proposals, and I saw the conflict over semi-protecting the entire project. After much thought, I wanted to add to the discussion. I found that, since I was using a school computer, I was blocked.

Blocked. Yes, some immature idiots, probably at a middle school (my school's IP adress conducts an entire school district), have gone and vandalized Jesus, and we—all ten thousand of us!—have been blocked. This naturally frustrates the living daylights out of me.

This got me to thinking—Why? I understand the need to prevent vandalism, but surely there's another way. I think there is.

If the software allows it, I propose that we have a new category of Wikipedians, called, for the moment, "Good Citizens". These are REGISTERED WIKIPEDIANS, who have never (or almost never) been cited for vandalism or maliciousness, who have at least, say, 100 edits to their names. Nomination could be by anybody, including oneself, and then reviewed by a sysop to certify that the applicant meets the standards.

Now what would a "Good Citizen" do? Essentially, the only thing that would distinguish a "Good Citizen" from any other Wikipedian is that, since this "Good Citizen" is exactly that, he/she would be given the right to edit from computers with blocked IPs when logged in.

I know what some of you might think—this creates an "aristocracy" in which most Wikipedians will be discriminated against. On the contrary, I think that most Wikipedians meet this standard. It would prevent the unfair blockage of good editors—for example, there have to be a few good editors out of ten thousand people in one of the best school districts in the state of Michigan—so long as they register and qualify. Perhaps a better term would be "Certified Non-Vandal", but "Good Citizen" is just as good in my opinion, and has a better ring to it.

And for those of you concerned about vandals getting "Good Citizen" status, any "Good Citizen" is on a policy of strict nonvandalism. Any "Good Citizen" who is cited for vandalism can, should, and will have his or her "Good Citizen" status revoked summarily. Perhaps, after a time, the status may be returned, but it would take a long time, a deep investigation, and a good explanation.

With that, I present my proposal to the WikiPublic. Lockesdonkey 20:38, 25 May 2006 (UTC)

See Wikipedia:Blocking_policy_proposal, think someone is working on it but when it will be implemented I do not know. Stefan 08:27, 26 May 2006 (UTC)

Question = When an IP gets blocked, does someone who is logged in but connects via that IP also get blocked? 'Cause if so that's lame. --Username132 (talk)

Yep. Lockesdonkey 19:37, 26 May 2006 (UTC)

This happened at my work too, a company of over 60,000 employees, a large percentage of which have high potential for being good contributors. I could've just waited for the block to run out (most blocks are short), but since I'm an admin I tracked down the party responsible and discussed the situation with them. It was just a misunderstanding and I unblocked them. I marked all the IP pages in our web proxy block with warnings that they're shared between many people, but these kind of things really only go so far. Deco 21:19, 26 May 2006 (UTC)

See Mediazilla:550. —Simetrical (talk • contribs) 21:52, 26 May 2006 (UTC)

Whose in charge of deciding to implement proposals?

There are plenty of great ideas on here, but who is in charge of deciding to okay it? (for example, my syntax highlighting idea above)--Max Talk (add) 22:46, 25 May 2006 (UTC)

It varies based on what the proposal affects, but nearly always involves some Wikipedia:Consensus process somewhere. Your syntax highlighting proposal should be taken to MediaWiki talk:Common.css. Requests for software changes end up as entries in Wikipedia:Bugzilla. Policy changes end up on the talk page of the affected policy (see Wikipedia:How to create policy). -- Rick Block (talk) 23:55, 25 May 2006 (UTC)

I read that Jimbo Wales and someone else have over-ruled concensus before, and went ahead and did what they wanted. --Username132 (talk) 18:54, 26 May 2006 (UTC)

Jimbo is the founder and Chair of the Board of Trustees of the Wikimedia Foundation, which is the non-profit foundation that owns and operates Wikipedia. I don't think he overrules consensus lightly, and when he does so it is in his capacity as the Chair of the Board of Trustees. User:Danny is Jimbo's assistant and occasionally executes decisions on behalf of Jimbo. -- Rick Block (talk) 19:49, 26 May 2006 (UTC)

A solution to some major problems

Some discussions which recently took place on Wikipedia talk:Featured article candidates found some support for the idea of a static version of wikipedia, and the notion that the tools that work so well for developing articles become our enemy when considering articles which can be considered finished. WP:STABLE proposed the marking of revisions in the article history; a new idea is under development which goes a step further and seeks to separate the finished articles from those in development by creating static versions of finished articles which would be the default view for visitors, and which would only be editable by a subset of users. A 'live' version would still exist and improvements could be incorporated into the static version.

The incentive to vandalise that comes from seeing the results instantly would be removed, for articles with static versions. The authoritativeness of static versions would be greater than live versions because the reader could be sure that no vital facts had recently been changed maliciously.

Details of the idea and full discussion of the numerous advantages it could bring are at Wikipedia:Static version. Your comments are invited. Worldtraveller 00:20, 26 May 2006 (UTC)

Not all stable version proposals are based on marking revisions in the history. I largely agree with this proposal, but disagree strongly with the idea that an article can be "finished" or at a point where it only gets worse, not better. I like to compare a stable version to a release version of a piece of software. Although it's mostly static, even released software gets hot fixes, patches, and service packs for critical issues - articles should too, just as you propose incorporating changes from the editable article. However, software also gets new releases that incorporate large changes, corresponding here to large addition of content or article refactoring that has had time to stabilize. I also don't take a side on which version should be the default view - the argument that hiding the editable view discourages editing is compelling. Deco 10:19, 26 May 2006 (UTC)

Well I usually put finished in inverted commas when discussing this idea, because I do agree that perfection is rarely attained. I think articles do reach points where changes are more likely to be harmful than positive though - what's really making me keen for a static version is my experience with helping to bring Sun and Mercury (planet) up to featured status - the former has attracted masses of poor quality revisions since featuring, the latter less so but it is so frequently vandalised that its edit history is dominated by vandalism and reverts.

It would seem very odd to me to have a static version and then not have it as a default view. The static version would be guaranteed vandalism-free, and would have been in some sense validated and approved. User preferences could easily include an option to change the default view to the live version, and a clear link to the live version from the static version, something like 'work on next update', would still encourage editing, I think, while taking away one of the major incentives to vandalise. Worldtraveller 10:53, 26 May 2006 (UTC)

It's an interesting idea and I would not dismiss it out of hand. I would favor it more for preserving the quality of articles than for stopping vandalism because it would initially be used on only a small percentage of articles, as few are complete and some of those that are about contemporary topics and are subject to more rapid aging. It would help to preserve article quality by stopping bad, but good faith, edits that decrease article quality and it would reduce the small percentage of vandalism never caught or not caught for a very long time on that article. It would also increase confidence in Wikipedia's accuracy. Having a link to the stable version rather than prohibiting changes to the article might be a good compromise. I think that Wikipedia is eventually going to have something like this as it matures. -- Kjkolb 11:46, 26 May 2006 (UTC)

Yes, it would definitely be aimed at preserving quality - a reduction of vandalism would just be a very positive side-effect. There would always be an editable version of any article, but changes to the live version would not be visible immediately. Worldtraveller 13:09, 26 May 2006 (UTC)

New Proposal

A new proposal regarding Trivia sections in articles has been created. Input is appreciated! --Osbus 00:59, 26 May 2006 (UTC)

HTML tag extension

Someone should write an extension and enable on Wikipedia a <html> tag. The nowiki tag not only disables wikitext, but also disables html tags. The html tag should allow users to directly code html for whihc wikitext and templsates are insufficient. E.g. they could create a custom form by simply adding this text to a wikipedia page.

<!-- This displays a random wikipedia image in place of google logo on google wikipedia search -->
<html>
<div style="width:130px;float:left;text-align:center;position:relative;top:-8px">
<a href="http://www.google.com/" style="padding:0;background-image:none">
<img src="http://en.wikipedia.org/wiki/special:random/image" alt="Google" style="border:none" /></a></div>

<form method="get" action="http://www.google.com/search" style="margin-left:135px">
  <div>
    <input type="hidden" name="domains" value="en.wikipedia.org" />
    <input type="hidden" name="num" value="50" />
    <input type="hidden" name="ie" value="utf-8" />
    <input type="hidden" name="oe" value="utf-8" />
    
    <input type="text" name="q" size="31" maxlength="255" value="gsgs" />
    <input type="submit" name="btnG" value="Google Search" />
  </div>

  <div style="font-size:90%">
    <input type="radio" name="sitesearch" id="gwiki" value="en.wikipedia.org" checked="checked" /><label for="gwiki">Wikipedia</label>
    <input type="radio" name="sitesearch" id="gWWW" value="" /><label for="gWWW">WWW</label>
  </div>
</form>
</html>

This will never become a reality, period. HTML is too dangerous. That would allow Flash/Javascript/ActiveX and goodness knows what else, all of which can be easily used for malicious purposes. Disabling specific tags out of the HTML stable would be another way, but it would require about as much work as adding wiki equivalents of specific HTML features when and if needed, which is what we do at the moment. Sure it's slower, but it's safer in the long run. Garrett^Talk 11:55, 26 May 2006 (UTC)

The Mediawiki software already supports raw html inside a <html> tag, but it's disabled on the Wikimedia projects, for the very good reasons outlined by Garrett. Worldtraveller 13:06, 26 May 2006 (UTC)

Opt-in ads on pages

I suggest giving people the ability to have ads, such as google adwords. This would be good for 2 reasons, it would generate some more money to help run wikipedia, and often the ads are relevant and useful. I recomend that it be optional, and off by default, with something simple like a checkbox in preferences. I personally would turn them on as they are often useful, and people that dislike ads could choose not to turn them on (and unless they check their preferences every day, may not even know they can have them). A vertical ad block would fit quite nicely under the toolbox.

Absolutely not. Wikipedia has done fine with donations so far. Voluntary ads would only raise a small amount of money, but they could have a catastrophic effect on people's willingness to donate. I suspect that most donations come from the small minority of users who are registered (less than one percent based on comScore data), so these are the most essential financial supporters of the project. Bhoeble 13:45, 26 May 2006 (UTC)

Why can't it be tried? I don't think wikipedia is fine at all. The pages fequently take a long time to load if at all so I think it's worth a short. I personally would have ads turned off. I don't see how anything useful could come out of being advertised to whilst I read about intermediate filaments or whatever, but it doesn't harm me if someone else is using them. --Username132 (talk) 18:53, 26 May 2006 (UTC)

If ads are going to be turned on, I would tend to agree that they would have to be mandatory, at least for anons. If those were implemented, Wikimedia's budget would increase by at least several times even if everyone stopped donating. User:Robchurch estimated a billion hits a day for Wikimedia projects, and even at the pathetically low rate of one cent per thousand page views, that works out to about $3.8 million dollars a year, something over four times the current Wikimedia budget. I think server lag would become a nonissue at that point.

But a ton of people are virulently anti-ad, for some reason that's always baffled me, so the basically trivial income that voluntary ads would produce would in fact probably be outweighed by the backlash. —Simetrical (talk • contribs) 22:11, 26 May 2006 (UTC)

Advertising corrupts. It is extremely difficult to maintain neutrality in any medium supported by advertising.Dpbsmith (talk) 00:43, 27 May 2006 (UTC)

Agreed. It's hard enough keeping spammers out of our articles now-- imagine them saying "Whadaya mean I can't add my external link to this page-- I'm paying for this site!" There's no such thing as free money. -- Mwanner | Talk 01:03, 27 May 2006 (UTC)

But wikipedia wouldn't need to advertise spammer's services? I don't see why wikipedia would need to bend over backwards to maintain sponsorship - they pay, they get a space on the website and nothing more. They mess around/try to influence the things that go on, they're gone and let someone else who wants the space have it. Plus it'd be further incentive for anonymous users to register. --Username132 (talk) 11:09, 27 May 2006 (UTC)

Using Google AdSense to deliver relevant ads would be good for Wikipedia. These ads would be useful for users. For example, if I went to the Free web hosting service article, the ads could suggest me some free web hosting services. Some people would go to the webmail article, for example, to find a webmail provider. In addition, Wikipedia could form a partnership with Google. What about Google Wikipedia Search? --J.L.W.S. The Special One 15:58, 27 May 2006 (UTC)

You're kidding, right? Like it's really difficult to find Free web hosting services or webmail providers? Wikipedia does not need to be a replacement for Google and other search services-- they're good at what they do, we're good at what we do. -- Mwanner | Talk 16:15, 27 May 2006 (UTC)

I don't think wikipedia is quite good at what it does. For example on this university internet connection where I've seen download speeds in excess of 800 kbit/s, it took 10 seconds for this edit page to load. If wikipedia has got the money, spend it; if not, get it (and then spend it). --Username132 (talk) 14:39, 28 May 2006 (UTC)

I don't see any way that advertising could possibly corrupt Wikipedia. You do understand how AdSense works, right? We get advertisements, no question (Google will never threaten to withdraw ads based on our content; they just ensure we don't cheat). Advertisers could, in theory, withdraw their ads from being displayed on Wikipedia, but a) there are so many AdWords customers that it would probably make a negligible difference, and b) we, the editors, are not receiving money under any circumstances, so it wouldn't significantly affect our judgment. Similar schemes exist in all reputable ad-using services: the authors are completely separate from the advertisers, and neither know nor care what ads will end up in their product. Admins who ban people for posting spam will have no interest in whether the advertiser withdraws money, providing policy says to ignore such threats (possibly add it to WP:NLT, in fact). —Simetrical (talk • contribs) 05:21, 29 May 2006 (UTC)

Whitespace handling

One thing that bothers me about how this wiki handles whitespace it handles newlines. One single newline is ignored and two newlines means a new paragraph, but once it becomes more newlines then it starts to behave odd. It starts to add <br/>s and paragraphs containing <br/>s. I think that the behvior is on purpose but I still think that it is odd. It's probably there to make one newline in the source to mean one newline in the html, but is that a behaviour the editors want to have?

What this behaviour means is that additonal empty lines between papragraphs in the source will show up when the html page is generated, which I don't think that most editors desire. It's not often one wants to force newlines (other than to separate paragraphs) and in those few cases I think that <br/> would do.

What I propose is that addtional line breaks other than the first two will be ignore. 100 empty lines will be the same as one empty line. But one single line break should be handled as now. I think that this is the way LaTeX does it and also what I think is easiest for the editor since he doesn't have to care exatly how many empty line he has between paragraphs. And this changes wouldn't affect the readers other than making the layout more consistent. Another plus would be that my suggest behaviour makes more sense than the current with skins that separate paragraphs in other ways than newlines.

I have been around Wikipedia for some time now and I haven't seen this discussed anywhere. I personally think it is a quite major issue since it is easy to add too many newlines between paragraphs. Is this a no issue? What do you think about my suggestion? Jeltz talk 15:27, 26 May 2006 (UTC)

I would agree strongly with this. Especially in the presence of templates, I often come across unsightly paragraph spacings that are larger than intended. They're rarely useful, and in those instances advanced users can bring in HTML tags. Deco 21:11, 26 May 2006 (UTC)

Yes, I agree that this is likely a good idea. More than two linebreaks can be added manually if desired. I do have to question why the software makes the assumption that a presentational double-<br /> is equivalent to a semantic <p>, though (try setting something like p { text-indent: 4em; padding: 0px; } in your personal stylesheet and see how many things look bizarre). —Simetrical (talk • contribs) 22:17, 26 May 2006 (UTC)

Haven't tried it myself and never thoguht of that way of styling (it's rare in html documents) Wikipedia until I started writing this proposal. Indented prargraphs should really look weird when users have extra linebreaks. It would also somewhat break the styles for users who have other margins between paragraphs than the default in their skins. Jeltz talk 22:53, 26 May 2006 (UTC)

I like this idea. I would add that HTML comments (the <!-- --> kind) should be ignored by any code that implements this to avoid strangeness. (It would also allow comments to be nicely formatted, instead of requiring careful placement of the opening and closing tags to avoid introducing unsightly whitespace as they do now.)

I would suggest that this section be linked to at or moved entirely to Wikipedia:Village pump (technical) to get the developers' attention. — Saxifrage ✎ 01:16, 27 May 2006 (UTC)

Forums

Its difficult to continue discussions on wikipedia and some dedicated forums that kept a list of links ("subscriptions") where I had posted would be valuable and stop me from having to look for the page I'd posted on (usally a few clicks in itself), scroll down the TOC for the thread I posted on and then, scroll down to see the most recent comments. I keep leaving messages and forgetting where I left them and I leave so many messages in so many different places, it's difficult to continue discussions. I may very well not make it back here to read people's negative responses and argue my point... --Username132 (talk) 17:51, 26 May 2006 (UTC)

In my opinion this is but one of many problems that would be solved by modifying the software to organize talk pages as message boards. Our culture is already so strongly against editing or deleting the comments of others that it makes little sense to give us the flexibility to do so, and we spend altogether too much time dealing with manual archiving and formatting our responses with appropriate indentation and so on. Wiki just doesn't make sense for discussion pages like this. Deco 21:07, 26 May 2006 (UTC)

I have to agree, but it's going to be low-priority. It's just too much work for something that works now (albeit imperfectly). —Simetrical (talk • contribs) 22:19, 26 May 2006 (UTC)

The advantage of the current system is that it does make that you have to learn wiki markup. Garion96 ^(talk) 22:36, 26 May 2006 (UTC)

It's a lot of work yes, but it's one-time work by a few people that produces an ongoing benefit for many people. As for wiki markup, there's no reason it can't be used within messages. I'm considering implementing a prototype of this sometime on my own Wikimedia server - maybe they'll take a patch from me. As for vandalism, I think letting admins delete messages is probably sufficient - it doesn't really matter how long it sits around on talk pages, they're not the "product". Deco 00:25, 27 May 2006 (UTC)

I find that discussions on Wikipedia are very difficult to follow and too long. I think there should be some sort of threading system. Or we could have a Wikipedia forum hosted on Google Groups (I wrote the Google Groups article - please give feedback at Wikipedia:Article Feedback Desk). I will be happy to own/manage the group. --J.L.W.S. The Special One 15:54, 27 May 2006 (UTC)

The devs have rejected usage of a forum as too unsecure for our purposes. (Although maybe this was just specifically meant for phpBB.) Anyway, the current system works fine IMO. If it ain't broke, don't fix it. Shouldn't this be among the perennial proposals anyway? Johnleemk | Talk 16:12, 27 May 2006 (UTC)

It seems silly to assert that a discussion board is insecure (although phpBB might be) - it's just a different interface that provides useful functions for organizing and navigating discussions among people, which is what we do on talk pages and discussion pages. The current system is workable, but has an array of disadvantages:

• It's difficult for new users to use. How many times have you seen an anonymous user post something at the top of a talk page, or misformat a reply, or screw up merging an edit conflict, or forget to sign their post using the magic tildes?
• It's annoying to painstakingly correctly format replies, especially with nontrivial formatting, or when the replies get deeply nested and the indenting has to be "reset". In large threads it's soon impossible to tell who is reply to who.
• Pages become very large very quickly and have to be manually archived, requiring constant attention, otherwise they become too slow to edit. A forum interface would allow deeply nested replies to be hidden and only recent posts to be displayed.
• A forum would be user configurable so a person could choose whether to view recent or old posts at the top, how many recent posts to display, how deeply nested replies to view. It would allow them to watch threads of interesting to them (rather than just entire pages), highlight their own posts, get e-mail notifications of updates, and so on.
• A forum would not have edit conflicts. The concurrent replies would just be simultaneously attached to the thread.
• Discussion pages are ugly, which makes them even less pleasant and more difficult to read.

In short, yes, it is broken. Yes, we should fix it. I barely even use forums but the advantages are painstakingly obvious here. Deco 21:04, 27 May 2006 (UTC)

As a frequent user of forums and someone who programmed a barebones forum myself, I disagree - for our purposes on Wikipedia, talk pages work better because they are organic. And as I alluded above, this is indeed a perennial proposal. Johnleemk | Talk 10:23, 28 May 2006 (UTC)

An idea isn't bad, just because its been suggested before. The current system of talk pages is a total mess. It's rediculously wasteful to have to watch a talk page with lots of unrelated edits, so that one can see the single reply to a message of interest. Plus, the current system, just can't scale properly. When lots of people are editing at the same time, you get those stupid "edit conflicts", which is silly. I'm not editing another person's text, so I shouldn't get an edit conflict. Also, we have absurd expectations of newbies, to be able to understand how things work. --Rob 10:53, 28 May 2006 (UTC)

I understand if you take that perspective, but really, while we may edit our own posts, or occasionally reformat threads, most of the time we treat it like a message board anyway - flexibility you don't use isn't useful. But the proof is in the pudding - eventually I'll get a prototype of this going and see how that works. Deco 12:06, 28 May 2006 (UTC)

How long until we can vote on it? I really think more people would welcome the change than oppose it. The discussion functions are the worst thing on wikipedia (or maybe co-worst with the slow page-loading that sometimes occurs). --Username132 (talk) 14:49, 28 May 2006 (UTC)

I don't think a mere vote is adequate for such a disruptive and difficult software change. It needs to be first established as effective in at least one case study external to English Wikipedia. Deco 08:08, 29 May 2006 (UTC)

When do you estimate your prototype to be ready? --Username132 (talk) 11:22, 29 May 2006 (UTC)

I'm afraid it'll probably be a while. I'm just one person and got lots of other things to do. Deco 23:26, 29 May 2006 (UTC)

I'd suggest you post at Mediazilla:1234 to note that you're taking up the bug, if you plan to seriously work on this (even if it's a long timeframe). I doubt the devs are going to suddenly take this up, but it's good to keep people informed to minimize the risk of duplication of effort. —Simetrical (talk • contribs) 05:54, 30 May 2006 (UTC)

Reference tagging that marks the SPAN of text supported by the reference

I wish I had paid more attention when the current reference tagging system was being developed.

One problem with the present system is that the tag is attached to a single point in the text, and it is therefore not clear what portion of the text is being supported. This gets worse if the text that's being tagged gets edited over time.

For example, consider:

Jack London desperately wanted to attend the University of California and, in 1896 after a summer of intense cramming, did so; but financial circumstances forced him to leave in 1897 and so he never graduated. Kingman says that "there is no record that Jack ever wrote for student publications" there.^[7]

Does footnote 7 support four facts (wanted to attend; did so 1896 after cramming; left in 1897; didn't write for student publications) or only one? You can't tell at a glance whether the whole paragraph is supported, or only the last sentence.

Worse, if it were the source for all four facts and if someone decided that the fact that he didn't write for student publications was uninteresting, it is quite possible that they might delete the reference along with the text, thus removing the support for the other three facts.

I wish that the ref mechanism involved not only a pair of tags containing the reference, but a pair of tags delineating the entire range of text that it is supporting.

This could have other potential benefits, as well. Currently, if an article actually comes close to meeting the requirements of WP:V and WP:CITE, it is likely to have so many footnotes as to interfere somewhat with readability. I'd like to see a choice of presentations for references. I think what I'd really like to see is one in which all the referenced material is given a slightly different text color than the rest of the article; perhaps a true black for referenced material and a slightly light, slightly tinted color (dark brown, perhaps) for unreferenced material. And a more subtle mechanism than superscripts for pointing to the note. For example, instead of putting the note numbers in the text itself, put them in the right margin. Dpbsmith (talk) 00:41, 27 May 2006 (UTC)

You can put whatever information you want in the footnote. If you want to specify that these three external links supoort this whole paragraph, you can say so. Likewise, if you wish to say that this page in this book says "..." quoting a pragraph, then you can say that. the solution is both more footnotes with sources and more information inside each footnote. I love footnotes. WAS 4.250 15:40, 29 May 2006 (UTC)

I've noticed similar problems to dpbsmith when adding footnotes. If it comes immediately after a quotation then it is clear; otherwise, I tend to use them next to statements readers might doubt even if they apply the further text in the same paragraph. It's true that footnotes needn't be just references, but sometimes mixing references and commments looks ugly. How would a variant on the system look? Perhaps something like

<ref name="Werther" reference="Hoffmeister, Gerhart. 
[http://www.litencyc.com/php/sworks.php?rec=true&UID=5596 
"Die Leiden des jungen Werthers (The Sorrows of Young Werther)"]. 
''The Literary Encyclopedia''. 17-Jun-2004. 
The Literary Dictionary Company. Retrieved 17-Mar-2006">
Like some modern bestsellers, the book spawned a [[spin-off]] 
industry, with items like Werther eau de cologne and porcelain 
puppets depicting the main characters.</ref>

This would have little difference on the page output at the moment. Alternatively, notes could be left for future editors as HTML comments (also ugly).

How to get shared IP blocked revoked fast?

I have just been blocked for 30 minutes, again!!!!

No I did not vandalise any page, I did not revert 4 times, actually I did nothing, I just happen to share the same IP as probably 500.000 other ISP users. Now I have a suggestion, when this happens again, and it will happen again until the fix to wikipedia code is done so that logged in users can edit while their IP is blocked is implemented I would like to suggest that there is one more page that all blocked users can write to. This would be something like Wikipedia:AdminHelp or something which would be linked from the block page, here all users can always write, it would not need to be a page that is reverted because of vandalism, but a page where I can write and state that e.g. the block of IP User: 202.156.6.54 affects half of Singapores users, maybe 4 link spams is not a good enough reason to block all of those users. This then hopefully would be a page that some admins would check and be able to correct hasty blocks that other admins had done. Is it possible to create a page like that with the current wikipedia code? Today I can not even edit the blocked IP user page, since it is not mine, even though I share the IP (I guess I could if I logged out ...), I can update my user page but which admin would see that? Stefan 14:29, 27 May 2006 (UTC)

I am also a StarHub user, and I keep getting blocked because of this as well. This is discouraging me from editing Wikipedia. Please allow registered users to log in from banned IPs. Or better still, remove any kind of IP editing. --J.L.W.S. The Special One 15:50, 27 May 2006 (UTC)

You can just add {{unblock}} to your talk page, which is always editable unless it's protected. Creating a separate page all blocked IPs can edit would be pointless because of all the frivolous edits legitimately blocked users would make. Johnleemk | Talk 16:15, 27 May 2006 (UTC)

Read what I wrote again! This would be a page where you do not need to revert, it is a page where I have a chance to communicate with a admin when I'm beeing blocked, see it as a temporary scratch pad, not a normal wikipedia page. I can edit my talk page, but not the blocked talk page. If I put the tag on my user page, the admin does not even know which IP I come from and what to unblock, but I will try next time. This is a issue of IP blocks overriding logged in user block and shared IPs. Stefan 01:04, 28 May 2006 (UTC)

http://whatismyip.com - use that. Paste your IP on your talk page. And explain how it would be a page where you do not need to revert? If any blocked user can edit it, there will be a need to revert. If you've found a way to screen out vandals and legitimately blocked editors, I'd like to hear it. Johnleemk | Talk 10:19, 28 May 2006 (UTC)

Obviously I can not describe what I mean. I want ONE scratepad page, like sandbox where I can communicate with a admin even when I am beeing blocked! Since admins should be able to read a history page they should be able to see my message even if the page have been vandalised. This is just to vent your frustration of blocks of shared IPs that many real wikipedia users suffers from, like AOL. Stefan 02:23, 29 May 2006 (UTC)

How is this something that cannot be served by existing user talk pages? You can still stick {{unblock}} on your talk page. (Not the IP's, though.) Johnleemk | Talk 11:22, 29 May 2006 (UTC)

and once youre unblocked you might like to add some comments at Wikipedia:Blocking policy proposal. BL Lacertae - kiss the lizard 19:23, 27 May 2006 (UTC)

I did, long time ago, and as I said that proposal is beeing worked on as far as I know, but my proposal could be implemented NOW. Stefan 01:04, 28 May 2006 (UTC)

Proposal: Articles with featured article status are automatically semi-protected

As Wikipedia moves towards being a more and more finished encyclopedia in many of its articles; it would be useful not to waste as much energy fighting off vandals. i recommend Articles with featured article status are automatically semi-protected. 4.250.132.134 15:44, 27 May 2006 (UTC)

User:Raul654/protection. Johnleemk | Talk 16:24, 27 May 2006 (UTC)

Also, featured articles are not strictly the ones on the Main Page, so this is even less desirable in that respect.--Sean Black 17:23, 27 May 2006 (UTC)

See also Wikipedia:Static version and Wikipedia:Stable versions, two similar but much broader proposals. Vandalism is a pain but usually quickly reverted - more problematic is well-meaning but misguided edits which degrade an article's quality over time. Worldtraveller 01:31, 28 May 2006 (UTC)

Who says Wikipedia is moving towards "being a more and more finished encyclopedia"? Reminds me of the 19th century patent office official who proposed closing the patent office since everything possibly invented had already been. User:Zoe|^(talk) 01:40, 28 May 2006 (UTC)

If we semi-protect our best (and most popular) articles (and the ones newbies are most likely to see), we may as well semi-protect the whole encyclopedia. Not necessarily a bad idea... Captainj 17:33, 29 May 2006 (UTC)

Portal:Browse

duplicate post, answered at Portal talk:Browse, -Quiddity 09:26, 28 May 2006 (UTC)

Landforms by country

Comments regarding a proposal at Wikipedia talk:Naming conventions (categories) that would make "in country" the naming convention for Landform by country categories would be very appreciated prior to a cfru. Kurieeto 22:24, 27 May 2006 (UTC)

Proposal for quasi-protection

Hello, all: I've written up Wikipedia:Quasi-protection policy, a proposal similar to semi-protection that would effectively limit sleeper accounts used to vandalize articles linked from the Main Page. I know that I've written a lot, and at first glance, the proposal may seem daunting. However, I truly believe that this would immensely improve Wikipedia and implore you to read it through and offer your thoughts on the talk page. Thanks! Flcelloguy (A note?) 22:49, 27 May 2006 (UTC)

Categorization of location

I have just created Wikipedia:Categorization of location, proposing a hierarchy of location-based categories. Once widely employed, these will allow the reader to quickly find articles about locations that are near that described by the article they're currently reading. All feedback welcome, as always. AxelBoldt 03:02, 28 May 2006 (UTC)

This is a fantastic idea! But create categories only as necessary: most of the planet is just water (and ice). I'm in full

support! -- Michael Janich 03:33, 28 May 2006 (UTC)

Prioritizing Wikipedia cleanup

I'm fairly active in trying to copyedit the massive amounts of articles at Category:Wikipedia articles needing copy edit and I've found that there is no good way to prioritize them; no way to know which ones have been unchanged the longest. So I looked around the whole Cleanup section and the closest we have to that is {{cleanup-date}} which is still limited to the month. So I was wondering if Wikipedia had DynamicPageList, and it doesn't. There is a modified version of the DPL called DPLforum that was originally made to be a forum. However, at Uncyclopedia, we also use it for the categorization of maintenance articles. They can be sorted by last edit, and provide a link to the page, the history, and display the last author. I think that this would help with prioritizing cleanup, but I recognize it is not the most efficient way of doing this. I'd like to propose that Wikipedia install an extension like this one for automating cleanup and such. I can easily contact the author of the extension if modifications are proposed, and if someone wants to write an extension similar but more effective (and less intensive on the database), that'd also be appreciated. Thoughts? --Keitei (talk) 08:47, 28 May 2006 (UTC)

You could probably download a database dump and come up with a suitable SQL query. There's also Special:Ancientpages. Deco 10:20, 28 May 2006 (UTC)

Thanks, but that's not what I was asking. I want to know what people think about using DPLforum on Wikipedia. </clarify> --Keitei (talk) 09:44, 29 May 2006 (UTC)

replace "recent changes" link with "new pages"

I thought it might be more useful to have "New Pages" easier to click on at the top left. Recent changes is useful to have in a smaller wiki where theres only a hundred or so changes a day, but whats the point in having it there to see hundreds of changes every minute? --Astrokey44 03:29, 29 May 2006 (UTC)

If you're interested, you can change that in your personal .js. It'd take a lot of deliberating to have it changed for everyone, but you can try it out now! :] Add the following lines to your personal .js (User:Username/skinname.js), such as User:Astrokey44/monobook.js, and then do a hard reload.

window.onload = Main;
function Main() {
    changenavbox();
}

function changenavbox() {
    document.getElementById('n-recentchanges').firstChild.innerHTML = 'New pages';
    document.getElementById('n-recentchanges').childNodes[0].href = 'http://en.wikipedia.org/wiki/Special:Newpages;
}

It's actually easier to change for the whole site, but there'd need to be a lot of consensus. :] --Keitei (talk) 13:44, 29 May 2006 (UTC)

thats cool I didnt expect a solution so quickly. though I changed it but it doesnt seem to be working. did I get it right? I held down shift while refreshing in firefox and it still says recent changes --Astrokey44 15:56, 29 May 2006 (UTC)

Try Ctrl-F5 instead (shift may also work but I always use the Ctrl method). At the least you'll need to hard-refresh your user JS, but you may also need to hard-refresh a page you want to see the change appear on. Also be sure you used "monobook" rather than "Monobook". Garrett^Talk 22:43, 29 May 2006 (UTC)

Wikipedia & Google partnership.

Wikipedia and Google are very similar. A partnership would make sense.

Google's mission is to "organize the world's information and make it universally accessible and useful". Wikipedia's mission is probably something similar, only worded differently. Wikipedia's information is contributed directly by users, while Google's information is also contributed, albeit indirectly, by users and webmasters. Google and Wikipedia could easily co-operate to form the largest information database in the world.

After Wikipedia and Google sign their partnership, there are some ways of implementing it.

• Google AdSense on Wikipedia pages.

Wikipedia pages could have Google AdSense ads on the left side. For certain groups of users, these ads could be optional.

How does it benefit Wikipedia?

Wikipedia will be able to earn more money from the ads, instead of relying on donations. Wikipedia can use this money to upgrade their servers and for more useful things. Users who wish to help contribute money to Wikipedia but lack cash to donate can do so with the ads.

Google AdSense delivers targeted ads. This will help users find what they are looking for. If I go to the Free web hosting service article, for example, the ads would introduce me to some free web hosting services. Someone may go to the webmail article, for example, to find a webmail provider.

How does it benefit Google?

Google's market share in the advertising industry will grow, and they will make more money.

• Google Wikipedia Search

Google offers all kinds of searches, such as Google Blog Search for blogs. Google could offer a Wikipedia Search allowing Google users to search Wikipedia. This could extend to Wikipedia's search engine.

How does it benefit Wikipedia?

Wikipedia can use Google as a launchpad. Google will "refer" many users to Wikipedia, and hopefully we will gain more contributors.

It will be easier to search for information on Wikipedia. Wikipedia's search engine has some flaws.

How does it benefit Google?

If Google Search powers Wikipedia's search, they will gain market share in the search market.

Wikipedia contains a lot of information Google can organize and make universally accessible and useful.

• Official Google Group for Wikipedia

I have proposed this before, and if Wikipedia and Google form a partnership, this will make even more sense. We will set up a Wikipedia forum on Google Groups, owned by...guess who - hildanknight@gmail.com, writer of the Google Groups article!

How does it benefit Wikipedia?

We currently have talk pages on Wikipedia. However, the system of talk pages has several major flaws. For example, discussion pages get very long because the discussions are not threaded - I don't like to scroll so much. The interface is decidedly user-unfriendly and difficult to navigate - I often screw up with my formatting. Finally, other users can edit my comments. For example, someone could change my comment to "Jimbo Wales is an idiotic mother f***ing b******", while leaving the Hildanknight signature in place, and an admin might block me, thinking I wrote the comment. (DISCLAIMER: This is not my opinion of Mr. Wales. I think he's cool.)

Creating a Google Group about Wikipedia would enable us to have threaded conversations about Wikipedia, circumventing limitations in the MediaWiki software. We can also discuss Wikipedia topics which would be difficult to discuss on Wikipedia itself - such as discussions about Wikipedia in general (we tend to discuss specific issues in talk pages) and suggestions for Wikipedia, as well as off-topic discussion and social interaction among the Wikipedia community (which hopefully will not become over-extensive).

We can use external communities about Wikipedia as launchpads to attract users of other sites to join us. For example, in Google Groups, you can join and start groups about your interests. We could join RuneScape World (a Google group about RuneScape [2]) and ask them to help us with the RuneScape article.

External communities will help Wikipedians expand their horizons and knowledge. They can then contribute this knowledge to Wikipedia.

How does it benefit Google?

While Wikipedia can use Google Groups as a launchpad, Google Groups can also use Wikipedia as a launchpad. We have about 1 million accounts on Wikipedia. If several thousand join the Wikipedia Google Group, and expand their horizons into other groups, the Google Groups userbase will expand.

As you can see, Wikipedia has a lot to gain from a partnership with Google. As Wikipedia expands to become one of the highest-trafficked sites on the Net, we should realize that we cannot stand alone while other companies and organizations unite and help each other. Google also has a lot to gain, and they will probably be interested in the amount of information Wikipedia has to offer. I do not think these suggestions will be difficult to implement. Your feedback is most appreciated.

--J.L.W.S. The Special One 04:55, 29 May 2006 (UTC)

All I'm gonna say is, ummm, no. This proposal combines at least three radical ideas that most people reject. It has about as much chance of passing as a monkey does of getting Hamlet right on his first try. Deco 08:05, 29 May 2006 (UTC)

Wikimedia's goals are likely best served by remaining free of outside corporate influence & advertising. I'd rather they solicit me personally for money, and I think a lot of others feel the same way. If Google wants to implement something that serves out "Google Encyclopedia" pages using cached versions of our GFDL content, though, all the more power to them! Warrens 08:17, 29 May 2006 (UTC)

I picked Google for two reasons:

• They are anti-corporate. That's why they are my favourite company.
• Their mission is to "organize the world's information and make it universally accessible and useful". Wikipedia and Google would thus strike a chord.

Targeted ads are better than the ads in, say, Yahoo! Mail. I mentioned an example of going to the webmail article to find a webmail provider. And they are surely better than all the spam links commonly added to articles. Wikipedia can earn more money, like the Mozilla Corporation. However, I understand Wikipedians' objections to advertising. Advertising raises NPOV issues. Wikipedia also might not wish to be involved in corporate affairs.

The suggestion of Google Wikipedia Search, I think, will not attract as much criticism as the other two. They have more information to "organize and make universally accessible and useful", and we will also get more users from Google. We currently have a partnership with Answers.com - we could do something similar with Google, where relevant search results from Wikipedia appear in a seperate section. What objections are there? Once again, I have noticed flaws in Wikipedia's search engine, and I think it should be powered by Google.

The suggestion of a Wikipedia forum on Google Groups is primarily intended to address various flaws in the current Wikipedia talk page system (mentioned earlier). I would be happy to know other ways for Wikipedia to fix the flaws. Remember, Google does not gain any money from our forum on Google Groups - Wikipedia and Google Groups only stand to gain users. As the owner of an active and successful Google group for teen chat, and a manager in two other large groups (and other groups), I will be happy to manage the Wikipedia Google Group, unless Mr Wales wishes to step in.

In short, I have found various flaws in parts of Wikipedia - such as the search engine and talk pages - and I am suggesting how a partnership with Google could help alleviate these flaws. If there are better methods to deal with these flaws, I would be glad to hear them. And these are only three possible implementations of the proposed Wikipedia-Google partnership. I am sure there are many more ways to implement such a partnership, and again, I would be glad to hear them. --J.L.W.S. The Special One 10:27, 29 May 2006 (UTC)

Absolute total nonstarter for all the reasons mentioned above. Being indentified with a big business would be a disaster for a project that needs to be seen as impartial. The financial position seems to be fine (at least fine enough for the quarterly fundraiser to be two months late) and there is no reason to suppose Wikipedia can't rely on donations forever like any other charity. Anyway, google isn't "anti-corporate", that's just a pose that is rapidly losing its credibility. They sold out to the Chinese dictatorship, or have you forgotten about that already? How long would it be before they insisted that Wikipedia did the same if it became dependent on them? Osomec 15:07, 29 May 2006 (UTC)

Wikipedia and Google are dissimilar, as one is primarily a content provider, and the other is primarily an index to content. Google/Lycos/Altavista etc. already help Wikipedia as much as they can by providing better sorted, faster and less CPU-intensive (if somewhat out-of-date) searches to content, using site:en.wikipedia.org or one of the Firefox plugins [3]. Wikipedia already helps Google/Lycos/Altavista etc. by 'making the Internet not suck' as Jimbo puts it and encouraging searching. However, one of the main reasons Wikipedia does not suck is the freedom from advertising - IMHO the Web when it first started was a useful academic resource, and only began to suck with the growth of advertising and wasted searching time. Google Groups, despite an irritating attempt to brand it, is merely a poor way of accessing Usenet and a useful archive of it. --Cedders^tk 23:52, 29 May 2006 (UTC)

There are several flaws in the OP's logic. FIrst of all, wikipedia is a content provider, Google is expressly not. Google is also for profit, wikipedia is not. By the same token, I think ads on wikipedia would be disasterous. Google also does provide a search for wikipedia, just as they do for every domain they index. In the search add "site:en.wikipedia.org" before your search terms, and it'll search just on the wikipedia domain. Lastly Google groups is nothing special - it's actually just a mirror of usenet. If we wanted to create a wikipedia discussion group, we could without any assistance from google. --Bachrach44 01:24, 30 May 2006 (UTC)

Computing Reference Desk

I feel that Wikipedia is in dire need (ok, not quite) of a computing reference desk, simply called, the computing desk, (not Computer Science or whatever) because of the immense number of programming language questions and people requesting advice on purchases, using the Science and Mathematics Reference desks out of lack of alternatives. It is not easy to find a suitable place to ask a computing question to a first time wikipedian, and as such, they tend to be distributed across all the desks... Simply make a computing desk. --Eh-Steve 05:01, 29 May 2006 (UTC)

I agree that this would be useful, but would it be specifically about programming or would we be spammed with "I need to use powerpoint for a presentation HELP!!!!"? Well, the spamming would probably happen either way, so rather, would we allow those questions? I'm not sure that we're prepared for an onslaught of PEBKAC questions, but I'm all for it anyways. :] --Keitei (talk) 13:56, 29 May 2006 (UTC)

Whoops, apparently PEBKAC is an insult. I just mean questions which are such that it is difficult to answer through wiki or online even, due to it being a problem of perception or assumption, and not with the computer. --Keitei (talk) 15:31, 29 May 2006 (UTC)

I suppose it would be for all computing questions, including the mundane powerpoint advice questions. But I think it should be turned into a project ASAP --Eh-Steve 18:35, 29 May 2006 (UTC)

User:Conrad Devonshire/Better means of identifying when an article receives or loses featured status

This is a proposal for the purpose of making it easier to identify the edit revision in an article's edit history at which point it has received/lost its featured status.--Conrad Devonshire ^Talk 04:28, 30 May 2006 (UTC)

Collapsable external links and see also sections

After trawling through a few articles today i thought that a lot of these may benefit from a purely aesthetic perspective if the See Also, External Links and Reference sections were made collapsable. I proprose this as not only would it my mind make pages seem more aesthetically pleasing but it would make a page look more manageable and less dense to a new reader.

Yakuzai 22:25, 30 May 2006 (UTC)